1) El documento presenta los principios del Manifiesto Ágil para el Desarrollo de Software, el cual valora a los individuos e interacciones sobre procesos y herramientas, software funcionando sobre documentación extensiva, y colaboración con el cliente sobre negociación contractual. 2) Firman el manifiesto expertos en metodologías ágiles como Scrum, Extreme Programming, Crystal y otros enfoques. 3) Se propone adoptar los principios ágiles en la gestión de proyectos software a través de enfoques como diálogos cara a cara,
1. MANIFIESTO PARA EL DESARROLLO ÁGIL DE SOFTWARE
DISEÑO DE SOFTWARE INVERSO Y EXPERIMENTACIÓN
CONFERENCIAS TÉCNICAS DSN_XP SOBRE INGENIERÍA DE SOFTWARE
CONFERENCIA DICTADA EN LOJA ENERO 2011
2. El manifiesto ágil <?>
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,
Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber
Jeff Sutherland, Dave Thomas
2001
3. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Kent Beck
PROGRAMACIÓN EXTREMA:
Inclusión del cliente al equipo, historias de usuario, jugar a
la planificación, pequeñas liberaciones, pruebas de
aceptación, espacios abiertos, diseño dirigido por pruebas,
comunicación por metáforas, diseño simple, recodificación
continua, integración continua, programación en parejas,
código fuente comunitario, estándares de codificación,
ritmo sostenible.
4. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
James Grenning
RENACIMIENTO DEL SOFTWARE:
Programación extrema, diseño dirigido por pruebas, poker
de planificación, historias de usuario, pruebas automáticas,
integración continua, desarrollo iterativo e incremental,
negociación con el cliente sobre tiempos y alcances,
pruebas de aceptación, creación de la visión del producto y
desarrollo por características.
5. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Robert C Martin
ENSEÑANZA DE OBJETOS:
Diseño simple orientado a objetos, principio de
responsabilidad única, principio de abierto-cerrado, principio
de sustitución de Liskov, principio de segregación de interfaz,
principio de inversión de dependencia, programación
extrema, diseño dirigido por pruebas de aceptación, pruebas
unitarias, formación de equipos multidisciplinares.
6. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Mike Beedle
E-ARQUITECTURA:
Adopción de SCRUM, adaptación y aprendizaje, creación de
equipos multidisciplinares para soportar el CAOS, entornos
altamente productivos, adopción de cambios culturales en la
organización.
7. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jim Highsmith
TRABAJOS PENSANTES:
Liderazgo adaptativo, imaginación adaptativa, colaboración
con el negocio, adopción de SCRUM, trabajo en equipo,
formación de líderes, formación de ejecutivos, desarrollo
iterativo e incremental en períodos cortos de tiempo, retorno
de inversión, cadenas de valor productivas para el negocio.
8. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Steve Mellor
MÉTODO DE SHLAER-MELLOR:
Diseño orientado a objetos, desarrollo dirigido por modelos,
uso de UML para el ciclo de vida, uso de lenguaje específico
del dominio, meta modelado de la arquitectura, intercambio
de metadata con XML, computación con objetos
empresariales distribuidos.
9. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Arie van
Bennekum
MÉTODO DE DESARROLLO DE SISTEMAS DINÁMICOS:
Desarrollo rápido de aplicaciones, marco de trabajo para
gestión de proyectos tecnológicos con presupuestos fijos y
tiempos cortos de desarrollo limitados por el mercado,
enfoque para retorno de inversión.
10. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Andy Hunt
PROGRAMADORES PRAGMÁTICOS:
Aprendizaje y pensamiento pragmático, estudio del
comportamiento humano en desarrolladores y miembros del
negocio, desarrollo de perfiles adecuados en equipos
multidisciplinares, estudio de la resistencia al cambio y la
necesidad de abrazar el cambio continuo.
11. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ken Schwaber
SCRUM:
Diseño de la metodología SCRUM y del método para la
gestión de proyectos tecnológicos de software, definición de
artefactos y principios para el desarrollo iterativo e
incremental de forma ágil, estudio de la ingeniería de
software y de los métodos predictivos que conducen al
fracaso de los proyectos de desarrollo.
12. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Alistair Cockburn
METODOLOGÍA CRYSTAL:
Estudio del equipo enfocado en el manejo del talento
humano, desarrollo de perfiles adecuados en equipos
multidisciplinares, factores de comunicación entre equipos,
incremento del retorno de inversión, entrega temprana de
resultados, anticipación y adaptación, manejo de la
incertidumbre y de las expectativas, desarrollo de la
creatividad e innovación.
13. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ron Jeffries
PROGRAMACIÓN EXTREMA:
Adopción de XP en proyectos tecnológicos, estudio del
rechazo al cambio, integración de principios de XP y SCRUM
en el desarrollo de software, diseño dirigido por el dominio,
diseño dirigido por pruebas, integración continua.
14. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jeff Sutherland
SCRUM:
Diseño de la metodología SCRUM y del método para la
gestión de proyectos tecnológicos de software, definición de
artefactos y principios para el desarrollo iterativo e
incremental de forma ágil, estudio de la ingeniería de
software y de los métodos predictivos que conducen al
fracaso de los proyectos de desarrollo.
15. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Ward
Cunningham
PROGRAMACIÓN EXTREMA:
Adopción de XP en proyectos tecnológicos, estudio del
rechazo al cambio, integración de principios de XP y SCRUM
en el desarrollo de software, diseño dirigido por el dominio,
diseño dirigido por pruebas, integración continua.
16. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Jon Kern
PROCESOS ADAPTATIVOS:
Programación orientada a objetos, metodología COAD, diseño
con Java, UML, herramienta de modelado TOGETHERSOFT,
interacción con el equipo, resultados tangibles y frecuentes,
involucramiento del cliente, adaptación al cambio.
17. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Dave Thomas
LABORATORIOS IBM DE TECNOLOGÍA INTERNACIONAL DE
OBJETOS:
Tecnología orientada a componentes y objetos, estrategias de
negocios, desarrollo de productos software basados en
componentes y marcos de trabajo.
18. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Martin Fowler
TRABAJOS PENSANTES:
Liderazgo adaptativo, imaginación adaptativa, colaboración
con el negocio, investigación de métodos y mejoras para el
diseño y desarrollo de software, patrones de diseño, diseño
orientado al dominio, integración continua, pruebas unitarias y
de integración.
19. ¿Quiénes firman el manifiesto ágil?
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
Brian Marick
ALIANZA ÁGIL:
Desarrollo ágil de software, disciplina y perfiles en trabajos con
equipos multidisciplinares, diseño dirigido por ejemplos,
desarrollo iterativo e incremental, utilización de herramientas
para acelerar el proceso productivo del equipo..
20. Los creadores del manifiesto para el desarrollo ágil de
software poseen una vasta experiencia en proyectos
exitosos de software, sin embargo, todas estas buenas
prácticas que han sido descubiertas a lo largo de la
existencia de la industria son la base para una nueva
filosofía de trabajo.
“El movimiento ágil”
Estamos cansados de la forma clásica
de producir software :o)
21. • ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN
LA GESTIÓN DE PROYECTOS SOFTWARE?
• Nuestra experiencia adquirida en proyectos
22. Los proyectos se desarrollan en torno a individuos motivados.
Hay que darles el entorno y el apoyo que necesitan y confiarles
la ejecución del trabajo. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es considerado como un recurso, por lo tanto, es sujeto de
control. Tanto el cliente, como el usuario y el equipo de desarrollo son parte del
elemento humano y entre elementos humanos es necesaria la presencia de un
entorno apropiado para la transferencia de ideas y conceptos sobre un evento en un
determinado contexto. <DSN_XP>
23. Así adoptamos este principio
CRECIMIENTO, CUIDADO Y RESPETO POR EL EQUIPO HUMANO Y SU ENTORNO
NATURAL <Principio DSN_XP>
24. El método más eficiente y efectivo de comunicar información al
equipo de desarrollo y entre sus miembros es la conversación
cara a cara. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es considerado como responsable de una actividad, por lo tanto,
sujeto a evaluación. Tanto el cliente, como el usuario y el equipo de desarrollo son
parte del elemento humano y entre elementos humanos es necesaria la presencia de
un lenguaje apropiado para la transferencia de ideas y conceptos sobre un mismo
resultado o expectativa. <DSN_XP>
25. Así adoptamos este principio
DIÁLOGOS CONTINUOS FACE TO FACE Y FACE TO FACES
<Principio DSN_XP>
26. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es propenso a cometer errores, por lo tanto, sujeto a sanciones.
Tanto el cliente, como el usuario y el equipo de desarrollo son parte del elemento
humano y entre elementos humanos es necesario reconocer al error como factor
importante dentro del proceso de aprendizaje y mejoramiento continuo. <DSN_XP>
27. Así adoptamos este principio
RETROSPECTIVAS Y COMPROMISOS
<Principio DSN_XP>
28. La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Individuos e interacciones sobre
procesos y herramientas
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, el
elemento humano es un elemento productivo, por lo tanto, sujeto a explotación.
Tanto el cliente, como el usuario y el equipo de desarrollo son parte del proceso
productivo por lo que es evidente la necesidad de equilibrar esfuerzos mediante
equipos multidisciplinares comprometidos con su trabajo que colaboran entre sí de
forma simple, con modelos simples y acciones simples. <DSN_XP>
29. Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
30. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
calidad del producto final.
Cada fuerza es asociada a una variable de cálculo, el tiempo se convierte en
cronograma, los recursos en costos y el alcance en funcionalidades, la resultante se
mide en el éxito o fracaso del proyecto.
El equipo de desarrollo es responsable del alcance, el tiempo y los recursos son
asignados al cliente, el proceso creativo del software tiene que ser transformado en
retorno de inversión de acuerdo al esfuerzo aplicado a una funcionalidad específica.
31. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás del diseño de un producto, cualquier alteración a una
de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas
determina la demanda del producto final.
Cada fuerza es asociada a una variable de cálculo, el producto se convierte en
esfuerzo, el mercado en ingresos y la administración en costos, la resultante se
miden en el éxito o fracaso del producto.
El equipo de desarrollo es responsable del producto, la administración y el mercado
son asignados al cliente, el costo de fabricación del software tiene que ser
transformado en la optimización de recursos de acuerdo al esfuerzo aplicado a una
funcionalidad específica.
32. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto software, cualquier alteración a una
de estas fuerzas se propaga en las otras 2, la conjugación correcta de las mismas
determina el entorno de trabajo.
Cada fuerza es asociada a una perspectiva de interés en el éxito del proyecto, el
software determina la usabilidad, el business determina el factor de oportunidad y el
team determina el compromiso de cada uno de los miembros del equipo
multidisciplinar. El adecuado proceso de estimación de esfuerzos tiene que ser
equilibrado para evitar cansancio en el team (sobrecarga de trabajo) ya que un
equipo cansado y no motivado repercute en el entorno de trabajo, en la calidad del
producto y en la entrega a tiempo de las funcionalidades.
33. • ¿CÓMO SE ADOPTA EL MANIFIESTO ÁGIL EN
LA EMPRESA?
• Nuestra experiencia adquirida en proyectos
34. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el factor de oportunidad está determinado por la estrategia adecuada
adoptada por el negocio, la adopción de la tecnología requiere de un correcto
entendimiento del procesamiento de la información para la toma de decisiones. El
equipo de desarrollo es responsable del código fuente y de su diseño. <DSN_XP>
35. Así adoptamos este principio
LA LIBERACIÓN DEL PRODUCTO SE REALIZA POR VERSIONES
<Principio DSN_XP>
LIBERACIÓN INTERNA DEL PROTOTIPO
INICIAL
LIBERACIÓN INTERNA DEL PROTOTIPO
FINAL
LIBERACIÓN PÚBLICA DEL PROTOTIPO
FINAL
ESTAMOS ESTABILIZANDO LA SALIDA A
PRODUCCIÓN
36. El software funcionando es la medida principal de progreso
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el software debe hacer lo que dice puede hacer, para determinar este
comportamiento del software se requiere un gran entendimiento del producto que
se desea construir o mantener. El equipo de desarrollo es responsable de la
concepción modular del producto y de su arquitectura. <DSN_XP>
37. Así adoptamos este principio
LA VISIBILIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
38. La atención continua a la excelencia técnica y al buen diseño
mejora la agilidad <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, los criterios de diseño y arquitectura son transparentes para el negocio
durante el proceso de estimación de esfuerzo, se requiere disciplina para aplicar este
principio. El equipo de desarrollo es responsable de la definición de estándares de
programación incluyendo la adopción de una escuela de diseño y un entendimiento
apropiado del lenguaje de programación. <DSN_XP>
39. Así adoptamos este principio
TODA IDEA ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
40. Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la auto organización es producto de un adecuado balanceo de
responsabilidades entre los miembros de equipos multidisciplinares. El equipo de
desarrollo es responsable de realizar mejoras al diseño de forma continua y de que
dichos cambios no afecten la coordinación de esfuerzos. <DSN_XP>
41. Así adoptamos este principio
EQUIPOS MULTIDISCIPLINARES
<Principio DSN_XP>
BASE DE DATOS DEVELOPERS & QA
NEGOCIO Y PRODUCTO ARQUITECTURA
42. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Software funcionando sobre
documentación extensiva
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, una
vez que se ha creado un producto software, el proceso de mantenimiento no es
considerado dentro de las tareas planificadas y si se desea mantener un producto ya
realizado no existe una estrategia adecuada de refactorización del producto. El
equipo de desarrollo es responsable de tomar decisiones sobre el diseño y
construcción del producto de forma continua. <DSN_XP>
43. Así adoptamos este principio
LA ESTIMACIÓN ADECUADA ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
REPORTES DE CODIFICACIÓN REPORTES DE AVANCES
REPORTES DE DESARROLLO REPORTES DE ARQUITECTURA Y DATABASE
44. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
45. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
46. • ¿CÓMO SE NEGOCIA CON EL CLIENTE BAJO
UN DESARROLLO ÁGIL?
• Nuestra experiencia adquirida en proyectos
47. Nuestra mayor prioridad es satisfacer al cliente mediante la
entrega temprana y continua de software con valor
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el retorno de valor se aplica en el lado del negocio (donde se ejecutará el
software) se compone tanto de la usabilidad del producto como del manejo de la
información. El equipo de desarrollo es responsable de comprender adecuadamente
las expectativas del cliente. <DSN_XP>
48. Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
49. Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la participación activa del cliente se pone de manifiesto en la transferencia
de conocimientos y en la demanda de funcionalidades. Es responsabilidad de todos
el definir un canal adecuado de comunicación (metáforas y criterios de aceptación)
para un correcto entendimiento del producto y del impacto en el negocio en su
implantación. <DSN_XP>
50. Así adoptamos este principio
LA HONESTIDAD ES BIENVENIDA SIEMPRE
<Principio DSN_XP>
51. Los procesos ágiles promueven el desarrollo sostenible.
<Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, un
desarrollo sostenible va más allá de una relación contractual, resulta como
consecuencia de un perfecto entendimiento entre las partes sobre un mismo objetivo.
Es responsabilidad del equipo de desarrollo el buscar los medios más adecuados para
mantener íntegra la confianza del cliente mediante entregas tempranas de software
funcionando que genera retorno de inversión para el cliente. <DSN_XP>
52. Así adoptamos este principio
EQUIPOS MULTIDISCIPLINARES
<Principio DSN_XP>
53. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a
valorar: Colaboración con el cliente sobre
negociación contractual
Usualmente en la gestión de proyectos, no se toma en cuenta a este principio, la
visibilidad se utiliza para transparentar el proceso de desarrollo, tanto el cliente como
el equipo de desarrollo encuentran en las métricas indicadores que sirven para ajustar
continuamente el esfuerzo asignado. Es responsabilidad del equipo de desarrollo el
mantener actualizada esta información para una adecuada gestión del proyecto.
<DSN_XP>
54. Así adoptamos este principio
CONTROL DIARIO DE ACTIVIDADES Y RETROSPECTIVAS DIARIAS
<Principio DSN_XP>
55. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un proyecto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
usabilidad del producto final.
Cada fuerza es asociada a una fuente de información, el stakeholder provee las
necesidades de requerimientos para la toma de decisiones, el usuario provee el
conocimiento y el proceso que se desea abstraer, el desarrollador provee las mejoras
al proceso y la simplicidad de la herramienta. Es responsabilidad del equipo de
desarrollo el comprender y balancear estos requerimientos en funcionalidades y
servicios para el uso correcto del producto.
56. El uso de las triadas en la gestión de proyectos
de desarrollo de software <Principio DSN_XP>
Existen 3 fuerzas básicas detrás de un producto, cualquier alteración a una de estas
fuerzas se propaga en las otras 2, la conjugación correcta de las mismas determina la
calidad del producto final.
Cada fuerza es asociada a un factor de diseño, las historias de usuario capturan las
necesidades del producto por parte de los usuarios (retorno de inversión), los
criterios de aceptación capturan las necesidades del stakeholder principal
(priorización) y las sentencias de trabajo definen sin ambigüedades las
especificaciones del software (esfuerzo). Es responsabilidad del equipo de desarrollo
el verificar que cada historia posea los tres indicadores para una adecuada gestión
del proyecto.
57. • ¿CÓMO SE SOPORTA EL CAMBIO EN LA
GESTIÓN DE PROYECTOS?
• Nuestra experiencia adquirida en proyectos
58. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta este principio, la
concepción de ágil descasa específicamente en este principio, a diferencia de la
escuela tradicional, el cambio continuo es la mejor estrategia de desarrollo, “las
buenas ideas no surgen exclusivamente al inicio de un proyecto sino que aparecen del
mismo entendimiento del producto durante su fabricación” <prototipo>. Es
responsabilidad del equipo de desarrollo el aplicar un diseño sencillo para el control
de cambios dentro de la configuración modular del producto. <DSN_XP>
60. Los procesos ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la ventaja competitiva para el cliente implica de por sí la involucración del
cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son
responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa
para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora
continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un
cambio en la gestión de su negocio. <DSN_XP>
61. Así adoptamos este principio
PLANIFICACIÓN CONTINUA DEL PRODUCTO
<Principio DSN_XP>
62. Los promotores, desarrolladores y usuarios debemos ser
capaces de mantener un ritmo constante de forma indefinida
<Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, el ritmo constante se adquiere en base a un adecuado proceso de
estimación de esfuerzos, aprendizaje y compromiso. Es responsabilidad del equipo de
desarrollo el gestionar adecuadamente el proceso de construcción mediante el uso de
mejores prácticas, marcos de trabajo, patrones de diseño y recodificación continua.
<DSN_XP>
63. Así adoptamos este principio
TRANSPARENCIA, INSPECCIÓN, ADAPTACIÓN
<Principio DSN_XP>
64. A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo y a continuación ajustar y perfeccionar su
comportamiento en consecuencia. <Principio Ágil>
A través de este trabajo hemos aprendido a valorar:
Respuesta ante el cambio sobre seguir un plan
Usualmente en la gestión de proyectos, no se toma en cuenta apropiadamente este
principio, la ventaja competitiva para el cliente implica de por sí la involucración del
cliente en el proceso de desarrollo, tanto el cliente como el equipo de desarrollo son
responsables del éxito o fracaso de un proyecto, pese a lo dicho, el fracaso representa
para el equipo de desarrollo una ventaja a favor del aprendizaje y de la mejora
continua. Es responsabilidad del cliente el definir adecuadamente el impacto de un
cambio en la gestión de su negocio. <DSN_XP>
65. Así adoptamos este principio
TRABAJO COMO UN SOLO EQUIPO
<Principio DSN_XP>
66. Follow DSN_XP
• En twitter: @dsn_xp
• En Facebook: /dsnxp
• E-mail: pacotoscano@gmail.com