He notado que muchos profesionales de TI (o IT) el concepto de agilidad está asociado a desarrollar a la “Maldita Sea” (1), es decir, sin cuidado alguno y sin reglas, donde:
Afirmación más falsa no puede haber ( ver Ser ágil es y no es...)
Bienvenidos los comentarios y/o observaciones.
- no se hace documentación,
- las pruebas son pocas o nulas
- poco o nada de análisis
- el ciclo de vida de desarrollo es “codificar y corregir” y así infinitamente
- se afirma que “son ágiles” porque “comercialmente es lo que estamos diciendo, pero no sabemos que significa”
- entre muchos otros desaciertos
Afirmación más falsa no puede haber ( ver Ser ágil es y no es...)
Pero también he observado que no tenemos claro por qué los equipos ágiles son más veloces (2) y productivos (3) (ver Productividad mejor que Velocidad) que la ejecución tradicional, sabiendo que las actividades de desarrollo siguen siendo las mismas:
- requisitos
- análisis y diseño
- implementación
- pruebas
- despliegue
o incluso pueden ser más actividades (debido a que los equipos ágiles son más disciplinados y orientados a prácticas técnicas(4)), como por ejemplo :
- requisitos
- análisis
- implementación empleando pruebas unitarias (TDD)
- pruebas
- automatización de pruebas funcionales
- adicionar pruebas unitarias, funcionales y otras al servidor de integración continua
- despliegue
La razón radica en que las siguientes prácticas de Scrum mitigan bastantes problemas del desarrollo tradicional y aligeran el desarrollo
- eliminando reprocesos
- mitigando riesgos más rápido
- suprimiendo el desperdicio
- acabando burocracia y
- Maximizando la comunicación
Nota: Si aúen no has leído sobre Scrum te recomiendo este post (Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO)
| PRÁCTICA | CÓMO SE LOGRA | VELOCIDAD QUE INYECTA | PRINCIPIO LEAN |
|---|---|---|---|
LOS ROLES | |||
Los roles adecuados
| Los tres roles trabajan en sinergia juntos y continuamente sprint, tras sprint. |
|
|
| Product Owner que resuelve dudas durante el sprint | El Product Owner está disponible para responder dudas puntuales del equipo sobre las inquietudes que se presentan |
|
|
| Un Scrum Master que remueve impedimentos | El Scrum Master es un líder servicial enfocado en remover los impedimentos, ya sea que los resuelva el mismo o busque la colaboración de otros |
|
|
| El equipo jala trabajo (pull) en vez de que se le asigne (push) Equipo auto organizado | Se posee un sprint backlog que generalmente se encuentra dispuesto en un tablero kanban y el equipo decide la mejor forma de hacer el trabajo |
|
|
LOS ARTEFACTOS | |||
| Enfoque en valor | Product Backlog priorizado y enfocado en lo que más retorno proporcione al producto | Se evita construir desperdicio y funcionalidades poco útiles.
Se posterga el desarrollo de lo incierto. |
|
| Sprint Backlog congelado durante el sprint | El compromiso para el sprint es definido y congelado |
|
|
LAS REUNIONES / CONVERSACIONES | |||
| Planning | Al principio del ciclo el equipo se reúne con el Product Owner para definir un compromiso y la forma de lograrlo. |
|
|
| Scrum Diario o Daily | Diariamente todo el equipo se reúne a la misma hora, por un máximo de 15 minutos a contarse,
|
|
|
| Review | El equipo muestra el resultado del trabajo hecho durante el Sprint al Product Owner |
|
|
| La retrospectiva | Cada ciclo –corto - de desarrollo el equipo se reúne a reflexionar como mejorar para el siguiente ciclo |
|
|
| El refinamiento | Una reunión donde se contextualiza al equipo sobre el trabajo que se va a realizar el próximo sprinr |
|
|
LAS PRÁCTICAS O FORMA DE HACERLO | |||
| Ciclos cortos de desarrollo - Sprints | Se trabaja en ciclos cortos de trabajo donde se construye un producto de forma incremental y completa cada ciclo |
|
|
| Se trabaja por incrementos | Cada ciclo entrega un incremento en el producto, el cual es usable , integro y útil. Nota: en la ejecución tradicional, hasta que no se terminan todas las fases no se posee un producto. |
|
|
| Historias de usuario en Ready para el sprint backlog (6)(7) | Las historias de usuario deben ingresar claras y bien definidas, sin ambigüedades, ni dudas al sprint backlog, tanto por parte del Product Owner como del Equipo | El equipo navega con certidumbre en el espacio del sprint, y no se incurre en reprocesos por requisitos incompletos, o mal entendidos |
|
| La definition of done / DoD/ Definición de Terminado / Realizado | Existe un punto indiscutible de cómo deben hacerse las cosas para ser aceptadas. |
|
|
| Un equipo multidisciplinario que logra el Done | Un equipo con todos los roles requeridos para lograr el DONE!! |
|
|
| Historias Just in Time – JIT - / Justo a Tiempo | El equipo entrega las funcionalidades que cumplen el Done antes del review al Product Owner para su aceptación |
|
|
Bienvenidos los comentarios y/o observaciones.
Saludos ágiles
Jorge Abad
Jorge Abad
Definiciones y aclaraciones
(1) Hacer las cosas a la maldita sea: expresión colombiana que en muchos casos significa ejecutar con poca atención, descuido, desgano – hasta con disgusto - y alta probabilidad de error, de forma que las cosas quedan medio hechas y requiere casi volver a hacerlas para que queden bien.
(2) Velocidad: cantidad de software producido en una unidad de tiempo
(3) Productividad: construir el producto correcto
(4) Las prácticas “ágiles” (o técnicas) no son propiedad de las metodologías ágiles – o marcos ágiles –y pueden ser empleadas en contextos de gestión tradicional con igual éxito
(5) Principios de Lean Software Development (ver más acá):
- Eliminar los desperdicios
- Ampliar el aprendizaje
- Decidir lo más tarde posible
- Reaccionar tan rápido como sea posible
- Potenciar el equipo
- Crear la integridad
- Véase todo el conjunto
(6) Esta práctica no pertenece a Scrum pero es muy empleada con el marco de trabajo.
(7) Aunque Scrum no habla de historia de usuario, si habla de Sprint Backlog con ítems en “ready”, estos ítems, pueden ser historias de usuario, casos de uso, requerimientos en prosa, lo que sea que el equipo determine usar, aunque si es más ampliamente recomendado emplear historias de usuario