Scrum – Gestión Ágil de Proyectos y V
Reglas de Scrum
1.- Variabilidad e incertidumbre
Hay que acoger la variabilidad útil, desarrollo iterativo e incremental y reducir la incertidumbre simultáneamente
2.- Predicción y adaptación
Hay que mantener las opciones abiertas, no se puede lograr todo desde el inicio, hay que favorecer la exploración y adaptación y ser sensible económicamente
3.- Aprendizaje validado (LEAN)
Hay que validar en vez de asumir y aprovechar la retroalimentación
4.- Trabajo en progreso
Hay que usar tamaños d ecarga económicamente sensibles, enfocarse en el trabajo en espera y no en trabajadores en espera
5.- Progreso
El progreso es lo entregado y validado, hay que enfocase en la entrega centrada en valor, el progreso ayuda a adaptarse y a replanificar
6.- Rendimiento
Hay que ir rápido pero sin apurarse, construir con calidad utilizando la mínima/suficiente ceremonia/protocolo
Datos de Adopción de Scrum
| Pregunta | Razón | Primer Resultado |
| Causa del fracaso en ágil | Filosofía de la compañía o desacuerdo fundamental cultural | 13% |
| Obstáculos al adoptar ágil | Habilidad para cambiar cultura organizacional | 53% |
| Preocupaciones sobre adoptar ágil | Falta de planificación anticipada | 30% |
| Resultados (tiempos) en proyectos ágiles | Más rápida | 73% |
| Beneficios obtenidos | Habilidad para cambiar prioridades | 92% |
| Ayudas para implementación | Apoyo de la gerencia | 22% |
Pros y contras de Scrum
- El cliente obtiene resultados importantes e utilizables desde etapas tempranas
- Se comienza el proyecto con requisitos de alto nivel
- Los cambios se administran de manera natural
- Se mitigan los riesgos del proyecto desde el inicio
- Se gestiona la complejidad al apuntar a la construcción de aqullo que brinda más valor
- Optimiza los recursos disponibles
- Minimiza el número de errores y se aumenta la calidad
- La disponibilidad del cliente debe ser alta durante el proyecto
- EL Product Owner debe tener disponibilidad de manera continua (Igual que los desarrolladores)
- La relación con el cliente es más colaborativa que contractual
- Cada iteración/sprint es un compromiso/acuerdo de requisitos implementados o “hechos”, minimizando las tareas pendientes
- Es una metodología recomendada para proyectos de dominio complejo
Tres maneras de fracasar en un proyecto ágil
1.- El contrato, el cliente y el modelo de negocio
Decía el manifiesto ágil que aquello de que la agilidad requería de “Colaboración con el cliente sobre negociación contractual”.
Pero claro, si tu cliente es de los que te entrega al principio del proyecto un documento enorme lleno de requisitos, clausulas y posibles penalizaciones y no vuelves a verlo hasta el último día
de proyecto… olvídate de la agilidad, en serio, no va a funcionar.
La agilidad pretende obtener software que cumpla lo que los usuarios necesitan no que cumpla lo que pone en un documento de requisitos
2.- La calidad del software
Antes de ser ágil, hazte las siguientes preguntas…
¿Tenemos un robusto control de versiones? ¿programamos con calidad? ¿hacemos código espagueti? ¿copy paste? ¿complejidad ciclomática disparada? ¿pruebas unitarias? ¿diseño mantenible?
¿refactorizas? etc., etc., etc. Supongo que saber por dónde voy, no es cuestión de seguir con la lista.
Los anteriores son tan necesarios en un proyecto ágil, como en cualquier proyecto software, pero en uno ágil, por lo cortas que son las iteraciones… tiene el doble de impacto…si no las tienes a la
perfección… dudo que la agilidad te dure más de 5 iteraciones.
Como decía Fowler, “If you’re afraid to change something it is clearly poorly designed”.
3.- La documentación
Volviendo al manifiesto ágil… “Software funcionando sobre negociación extensiva”. Lo que no es lo mismo que “Software funcionando Y NO documentación comprensiva”.
Que en agilidad la documentación es menor, cierto. Que ocupa otro rol, cierto. Que se crea de otra manera, también. Pero no que no hay documentación.
Recuerda aquello de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad.
Puedes encontrar más información en este libro:
Fundamentos de los Requisitos de Software
Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.
