Principios y valores de Agile, por Jeff Sutherland
Jeff Sutherland inventó Scrum en 1993 y trabajó con Ken Schwaber para formalizar Scrum en OOPSLA'95. Juntos, extendieron y mejoraron Scrum en muchas empresas de software y ayudaron a escribir Agile Manifesto. Jeff revisa en su blog los orígenes y los procedimientos recomendados de Scrum en http://scrum.jeffsutherland.com. |
"Desarrollo ágil" es un término derivado del Manifiesto Ágil (Agile Manifesto), escrito en 2001 por un grupo que incluía: a los creadores de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) y Crystal; un representante de desarrollo controlado por características; y otros coordinadores diversos del pensamiento en la industria del software. El Manifiesto Ágil (Agile Manifesto) estableció un conjunto común de valores y principios dominantes para todas las metodologías ágiles individuales en el momento. Los detalles del manifiesto cuatro valores básicos para habilitar los equipos alto- que realizan.
Los individuos y sus interacciones
Entregar software que funciona
Colaboración del cliente
Responder al cambio
Estos valores básicos se sustentan en 12 principios, que puede encontrar en el siguiente sitio web: Manifesto for Agile Software Development.
Estos valores no son sólo algo que los creadores del Manifiesto Ágil (Agile Manifesto) pensaban encomiar y, a continuación, olvidarse. Son valores que funcionan. Cada metodología ágil individual enfoca estos valores de una manera ligeramente diferente, pero todas estas metodologías tienen procesos y ejercicios concretos que fomentan uno o más de estos valores.
Individuos e interacciones
Los individuos e interacciones son esenciales para los equipos de alto rendimiento. Los estudios de "saturación de la comunicación" durante un proyecto mostraron que, cuando no existe ningún problema de comunicación, los equipos pueden rendir 50 veces más que el promedio del sector. Para facilitar la comunicación, las metodologías ágiles confían en frecuente inspeccionar-y- adapte los ciclos. Estos ciclos pueden variar de cada pocos minutos con programación entre iguales, cada pocas horas con integración continua o todos los días con una reunión de puesta en marcha, hasta cada iteración con una revisión y retrospectiva.
No obstante, simplemente aumentar la frecuencia de los comentarios y la comunicación no es suficiente para eliminar los problemas de comunicación. Estos ciclos de inspección y adaptación solo funcionan bien cuando los miembros del equipo presentan varios comportamientos clave:
respeto por el valor de cada persona
veracidad en cada comunicación
transparencia de todos los datos, acciones y decisiones
confianza en que cada persona respaldará al equipo
compromiso con el equipo y los objetivos del equipo
Para fomentar estos tipos de comportamiento, la administración ágil debe proporcionar un entorno de apoyo, los entrenamientos del equipo deben facilitar su inclusión y los miembros del equipo deben mostrarlos. Sólo entonces podrán lograr los equipos todo su potencial.
Para que los equipos lleguen a estos tipos de comportamiento son más difíciles que puede parecer. La mayoría de los equipos evitan la verdad, la transparencia y la confianza debido a las normas culturales o las experiencias negativas pasadas de conflictos generados por comunicadores sinceros. Para combatir estas tendencias, la dirección y los miembros del equipo deben facilitar el conflicto positivo. Cuando los equipos enganchan en conflicto positivo, no sólo fomentan un comportamiento más productivo, pero también funcionan para tener acceso a otras ventajas:
La mejora del proceso depende de que el equipo genere una lista de impedimentos o problemas en la organización, se enfrente a ellos directamente y, a continuación, los elimine sistemáticamente en orden de prioridad.
La innovación solo se produce con el intercambio libre de ideas conflictivas, un fenómeno estudiado y documentado por Hirotaka Takeuchi e Ikujiro Nonaka, los padrinos de scrum.
La resolución de las agendas conflictivas aparece cuando los equipos alinear alrededor de los objetivos comunes y aflora los aspectos y conflictos potenciales.
El compromiso de trabajar juntos sólo se consigue cuando las personas acuerdan los objetivos comunes y, a continuación, se esfuerzan por mejorar personalmente y como equipo.
Este último punto, sobre el compromiso, es especialmente importante. Sólo cuando los individuos y los equipos se comprometen, se sienten responsables para entregar un alto valor, que es la línea de base para los equipos de desarrollo de software. Las metodologías ágiles facilitan compromiso y la uno mismo- organización de los miembros del equipo a de extraer elementos de una lista de trabajo clasificada por orden de prioridad, administrar su propio trabajo, focus en mejorar sus prácticas de trabajo. Estos procedimientos forman la base de un mismo- organización, que es la fuerza que controla para lograr resultados en un equipo ágil.
Para crear equipos de alto rendimiento, las metodologías ágiles valoran a los individuos y las interacciones sobre los procesos y herramientas. Hablando prácticamente, todas las metodologías ágiles buscan aumentar la comunicación y colaboración a través de los ciclos de inspección y adaptación frecuentes. Sin embargo, estos ciclos solo funcionan cuando los coordinadores ágiles fomentan el conflicto positivo que se necesita para compilar una base sólida de verdad, transparencia, confianza, respeto y compromiso en sus equipos ágiles.
Software que funciona sobre la documentación completa
El software que funciona es una de las grandes diferencias que aporta el desarrollo ágil. Todas las metodologías ágiles que se representan en el Manifiesto Ágil (Agile Manifesto) subrayan la entrega al cliente de partes pequeñas de software que funciona a intervalos fijos.
Todos los equipos ágiles deben establecer lo que significa que digan "software que funciona", conocido con frecuencia como la definición de terminado. En un nivel alto, una parte de la funcionalidad se ha completado solo cuando sus características pasan todas las pruebas y pueden ser utilizadas por un usuario final. Como mínimo, los equipos deben ir más allá del nivel de la prueba unitaria y probar en el nivel del sistema. Los mejores equipos también incluyen pruebas de integración, rendimiento y aceptación del cliente en su definición de lo que significa haber terminado una parte de la funcionalidad.
Una compañía de CMMI nivel 5, que ya tiene una de las tasas de defectos más bajas del mundo, ha mostrado con datos extensos en muchos proyectos las ventajas de procedimientos ágiles. Específicamente, se sistemáticamente la velocidad doble eficaz de producción y reducen defectos en un 40 por ciento con las siguientes acciones:. Esto de una compañía.
Defina las pruebas de aceptación al definir la característica.
Implemente las características consecutivamente y en orden de prioridad.
Ejecute las pruebas de aceptación en cada característica tan pronto como se implementan.
Corrija los errores que se identifican como prioridad máxima lo más rápidamente posible.
El Manifiesto Ágil (Agile Manifesto) recomienda que los equipos entreguen el software que funciona a intervalos establecidos. Capaces de acuerdo en equipo en qué correcto significa es una de las maneras prácticas que los equipos ágiles dan lugar al alto rendimiento y alta calidad necesaria para lograr este objetivo.
Colaboración del cliente sobre la negociación del contrato
Durante las dos últimas décadas, las tasas de éxito de los proyectos han aumentado a más del doble en todo el mundo. Estas mejoras se produjeron como resultado de los proyectos menores y de entregas frecuentes, que permitía que los clientes proporcionadas comentarios sobre el software que funciona parcialmente a intervalos regulares. Los redactores del manifiesto sabían de qué estaban hablando cuando enfatizaron que conseguir la implicación del cliente en el proceso de desarrollo de software es esencial para el éxito.
Las metodologías ágiles fomentan este valor ya que un representante del cliente trabaja mano a mano con el equipo de desarrollo. Por ejemplo, el primer equipo de Scrum tenía miles de clientes. Dado que no era posible implicarlas todas en el desarrollo del producto, seleccionaron a un proxy de cliente, llamado propietario del producto. El propietario del producto representado no solo todos los clientes en el campo, sino también la administración, ventas, soporte, servicios de cliente, y a otros interesados. El propietario del producto era responsable de actualizar la lista de requisitos cada cuatro semanas a medida que el equipo liberaba el software que funciona, teniendo en cuenta la realidad actual y los comentarios reales de los clientes y partes interesadas. Forma activamente ayudada customers el software que fue creado.
El primer equipo de XP comenzó con un proyecto de TI interno. El equipo de XP podría tener un usuario final de la compañía en su equipo con ellos días. Aproximadamente un 10 por ciento del tiempo, de consultores y los equipos internos pueden encontrar a un usuario final que trabaje con el equipo todos los días. Para el otro 90 por ciento del tiempo, deben designar a un representante. Este representante del cliente, a quien los equipos de XP llaman "el cliente", trabaja con los usuarios finales para proporcionar una lista clara, clasificada por orden de prioridad de las características que los desarrolladores de software deben implementar.
Es con la colaboración diaria del cliente (o proxy cliente) que los datos del sector muestran que los proyectos ágiles tienen más de dos veces el índice correcto de proyectos tradicionales en mundial medio. Dado que las metodologías ágiles reconocen el valor comprometer de cliente, han creado en sus equipos de desarrollo un lugar que es específicamente para el representante del cliente.
Responder al cambio sobre seguir un plan
Para que los equipos crean los productos que los clientes y proporcionar valor comercial, los equipos deben responder al cambio. Los datos del sector muestran que más del 60 por ciento de los requisitos de producto o de proyecto cambian durante el desarrollo de software. Incluso cuando los proyectos tradicionales finalizan a tiempo, según el presupuesto y con todas las características del plan, los clientes se sienten a menudo insatisfechos porque lo que encuentran no es exactamente lo que deseaban. " La "Ley de Humphrey" dice que los clientes nunca saben lo que desean hasta que ven el software que funciona. Si los clientes no ven el software que funciona hasta el fin de un proyecto, es demasiado tarde para incorporar sus comentarios. Las metodologías ágiles buscan los comentarios del cliente en el proyecto para que los equipos puedan incorporar comentarios y nueva información a medida que se desarrolla el producto.
Todas las metodologías ágiles tienen procesos integrados para cambiar sus planes a intervalos regulares en función de los comentarios del cliente o su representante. Sus planes están diseñados para entregar siempre primero el mayor valor comercial. Dado que el 80 por ciento del valor representa el 20 por ciento de las características, los proyectos ágiles bien realizados tienden a finalizar temprano, mientras que la mayoría de los proyectos tradicionales finalizan tarde. Como resultado, los clientes están más satisfechos y los desarrolladores de software disfrutan más de su trabajo. Las metodologías ágiles están basadas en el conocimiento de que para tener éxito, se debe planear para cambiar. Por eso han establecido procesos, como revisiones y retrospectivas, diseñados específicamente para desplazar las prioridades con regularidad en función de los comentarios del cliente y el valor comercial.
El desarrollo ágil es un marco incluyente y las metodologías son implementaciones
El desarrollo ágil no es una metodología en sí mismo. Es un término incluyente que describe varias metodologías ágiles. En la firma del Manifiesto Ágil (Agile Manifesto) de 2001, estas metodologías incluían el Scrum, XP, Crystal, FDD y DSDM. Desde entonces, también han emergido las prácticas eficientes como una valiosa metodología ágil y, por tanto, se han incluido bajo el paraguas del desarrollo ágil en la ilustración que se encuentra más adelante en este tema.
Cada metodología ágil tiene un enfoque ligeramente diferente para implementar los valores básicos del Manifiesto Ágil (Agile Manifesto), exactamente igual que muchos lenguajes de computación manifiestan las características principales de la programación orientada a objetos de maneras diferentes. Una encuesta reciente muestra que aproximadamente un 50 por ciento de quienes usan metodologías ágiles dicen que su equipo está haciendo Scrum. Otro 20 por ciento dice que están haciendo Scrum con los componentes XP. Un 12 por ciento adicional dice que están haciendo XP exclusivamente. Dado que más del 80 por ciento de las implementaciones ágiles en todo el mundo es Scrum o XP, MSF for Agile Software Development v5.0 se centra en los procesos y prácticas básicos de Scrum y XP.
.png "Marco incluyente de desarrollo ágil")
Scrum es un marco de trabajo para los procesos de desarrollo ágiles. No incluye prácticas de ingeniería concretas. A la inversa, XP se centra en las prácticas de ingeniería, pero no incluye ningún marco de trabajo dominante de procesos de desarrollo. Esto no significa que Scrum no recomiende ciertas prácticas de ingeniería ni que XP no tenga ningún proceso. Por ejemplo, el primer Scrum implementó todas las prácticas de ingeniería que ahora se conocen como XP. Sin embargo, el marco de trabajo de Scrum para el desarrollo de software se diseñó para hacer que un equipo empezara en dos o tres días, mientras que las prácticas de ingeniería suelen tardar muchos meses en implementarse. Por consiguiente, queda la pregunta de cuándo (y si se deben) implementar practicas concretas para cada equipo. Los creadores de Scrum, Jeff Sutherland y Ken Schwaber, recomiendan que los equipos de Scrum empiecen inmediatamente y creen una lista de impedimentos y un plan de mejora del proceso. Como las prácticas de ingeniería se identifican como impedimentos, los equipos deben recurrir a las prácticas de XP como una manera de mejorar. Los mejores equipos ejecutan Scrum complementado con prácticas de XP. Scrum ayuda a XP a escalar y XP ayuda Scrum a funcionar bien.
La siguiente tabla muestra cómo se pueden intercambiar las condiciones clave en Scrum y XP.
Scrum |
XP |
|---|---|
propietario del producto |
cliente |
scrummaster |
Instructor de XP |
equipo |
equipo |
sprint |
iteración |
reunión de planeación de sprint |
juego de planeación |
Vea también
Conceptos
Realizar un seguimiento del trabajo con Visual Studio ALM y TFS