"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.
El manifiesto detalla cuatro valores clave para habilitar equipos de alto rendimiento.
- Los individuos y sus interacciones
- Entregar software que funciona
- Colaboración del cliente
- Responder al cambio
Por definición, las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.
El uso de Agile como una aproximación a la gestión de proyectos se ha incrementado dramáticamente en los últimos años. Gartner predice que en breve los métodos ágiles de desarrollo serán utilizados en el 80% de todos los proyectos de desarrollo de software.
Mucha polémica puede surgir, más hoy en día el arte de balancear ambas corrientes retribuye mucho mejor a los proyectos y al conformar una PMO (Oficina de Proyectos)
Algunos métodos ágiles de desarrollo de software:
- Adaptive Software Development (ASD)
- Agile Unified Process
- Crystal Clear
- Feature Driven Development (FDD)
- Lean Software Development (LSD)
- Kanban (desarrollo)
- Open Unified Process (OpenUP)
- Programación Extrema (XP)
- Método de desarrollo de sistemas dinámicos (DSDM)
- Scrum
- Metodología de desarrollo de software orientada a la generación de valor, Feature Driven Development (FCC)
- PMI-ACP (Agile Certified Practitioner)
Manifiesto Ágil:
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- 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.
- 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.
- El software funcionando es la medida principal de progreso.
- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Ahora comentaremos a nivel general las opciones ágiles más populares.
SCRUM
Un marco de trabajo por el cual las personas pueden acometer "problemas complejos adaptativos", a la vez que entregar productos del máximo valor posible productiva y creativamente. Scrum es:
- Ligero
- Fácil de entender
- Extremadamente difícil de llegar a dominar
Cada sprint comienza con una Reunión de planificación del sprint durante la cual se consideran las historias de usuario de alta prioridad para su inclusión en el sprint.
Un sprint suele durar entre una y seis semanas durante las cuales el equipo Scrum trabaja en la creación de Entregables (del inglés deliverables) en incrementos del producto potencialmente listos. Durante el sprint, se llevan cabo Reuniones diarias de pie muy breves y concretas (conocidas en inglés como Daily Standup Meeting —reuniones rápidas e informales en donde todos los asistentes están de pie a fin de que sean breves), en las que los miembros del equipo discuten progresos diarios. A medida que concluye el sprint, se lleva a cabo una Reunión de planificación del sprint en la cual se proporciona una demostración de los entregables al propietario del producto y a los socios relevantes. El propietario del producto acepta los entregables sólo si cumplen con los criterios de aceptación predefinidos. El ciclo del sprint termina con una Reunión de retrospectiva del sprint, donde el equipo presenta maneras para mejorar los procesos y el rendimiento a medida que avanzan al siguiente sprint.
Roles
+ Dueño de producto
+ Equipo de desarrollo
+ Scrum Master
Eventos
+ El Sprint
+ Reunión de planificación
+ Scrum diario
+ Revisión de sprint
+ Retrospectiva de sprint
Artefactos
+ Pila de product
+ Pila de sprint
+ Incremento
Tres pilares soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación.
Extreme Programming (XP)
Surge como una nueva manera de encarar proyectos de software, proponiendo una metodología basada esencialmente en la simplicidad y agilidad. Las metodologías de desarrollo de software tradicionales (ciclo de vida en cascada, evolutivo, en espiral, iterativo, etc.), parecen, comparados con los nuevos métodos propuestos en XP, como pesados y poco eficientes. La crítica más frecuente a estas metodologías “clásicas” es que son demasiado burocráticas. Hay tanto que hacer para seguir la metodología que, a veces, el ritmo entero del desarrollo se retarda. Como respuesta a esto, se ha visto en los últimos tiempos el surgimiento de “Metodologías Ágiles”. Estos nuevos métodos buscan un punto medio entre la ausencia de procesos y el abuso de los mismos, proponiendo un proceso cuyo esfuerzo valga la pena.
La metodología XP define cuatro variables para cualquier proyecto de software: Costo, Tiempo, Calidad y Alcance. Además, se especifica que, de estas cuatro variables, sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto). El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función de los valores de las otras tres.
Kanban
Utiliza principios y artefactos propios pero, diferentemente de Scrum, no indica cuales roles o reuniones hay que aplicar para llevar a cabo la gestión. Esto implica un menor impacto debido al cambio introducido, mayor flexibilidad y un menor coste de implantación.
Kanban se adapta a las estructuras existentes de cada organización
Los mismos roles y la misma estructura organizativa podrían ser un elemento que genere cuellos de botella (elementos que ralentizan el flujo) y, en este caso, deberían ser objeto de revisión gracias a las Reuniones de Retrospectivas: reuniones donde se analiza lo que ha funcionado, lo que no ha funcionado, lo que se ha hecho bien y lo que se debería hacer en futuro.
- Visualice lo que hace (su flujo de trabajo)
- Realice un seguimiento de su tiempo
- Utilice tarjetas de colores para distinguir los Tipos de trabajo, Prioridades, Etiquetas, Fechas límite y más.
- Identifique los cuellos de botella y elimine lo que resulta descartable.
Como era previsible, ambas metodologías tradicionales como PMI en su PMBOK y el modelo estructurado de PRINCE2 ofrecen sus opciones basadas en Agile donde son similares a SCRUM (SBOK) con ciertas adecuaciones particulares, que en el fondo ofrecen los mismos resultados.
SAFe
Si bien el Scaled Agile Framework ha tomado auge en los años recientes, su versión 4 está muy completa para evolucionar una mezcla de métodos conocidos. Parte de un espíritu similar a la Arquitectura Empresarial donde se ensambla con madurez cada parte de la cultura de trabajo y se puede iniciar desde la parte de negocio donde se vale canvas, el balanced scorecard, PMO, esquema agile de indicadores. Que se combina con un modelo DevOps, QA/QC, XP, Kanban, Scrum. Madurando al nivel de lograr CD/CI con un modelo de fábrica denominado PI(Program Increment)
Finalmente
La experiencia de cada líder y sus equipos es la garantía del éxito al adoptar un método de trabajo que todos conocerán y seguirán como disciplina; en acuerdo con el cliente.
Regularmente los procesos maduros balancean la para la PMO basada en OPM3 lo mejor que aporta el PMBOK, Prince2, Kanban, Scrum, SBOK, XP, CMMi. Y pueden alinearse a modelo como el MAAGTICSI y enriquecer su área de aplicación con TOGAF, Archimate, BPMN, BABOK, ITIL, COBIT, BSC. En esquemas con gobierno de IT, se puede imulsar SAFe o un modelo OPM3 mejorado que también armoniza las metodologías.
En la práctica suelo realizar este tipo de balanceo y se adapta a cada cliente y programa de proyectos. La madurez se consolida gradualmente al partir de pilotos y un modelo de seguimiento continuo que entre otras bondades permite detectar y mitigar riesgos oportunamente, con la visión de otener productos/servicios de alta calidad, satisfacción y rentabilidad. Es así como las estadísticas de consuelo quedan en el pasado.
@JormerMx
Program Manager, PMO
#JMCoach
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.