Agile Project Management by Jeremy Savell
Una visión general básica y directa de lo que es Agile, presentando algunos ejemplos de frameworks bien conocidos hoy, como Scrum o Kanban—todo condensado en un libro de unas 100 páginas que puedes leer en un par de horas.
Capítulos#
- El manifiesto fluido
- Siendo ágil
- Proceso ágil
- Planificando para el éxito
- Comunicación ágil
- Fundamentos de Scrum
- Introducción a Kanban
- Construyendo un equipo adaptativo
- Liderazgo y gestión colaborativa
- Errores comunes detrás del fracaso ágil
- Palabras finales: ágil es adaptación
“Los beneficios de los proyectos Ágiles se extienden no solo al equipo que lo usa, sino también al cliente que recibe el producto final.”
“Hay una métrica crítica subyacente que consistentemente lleva al éxito de un proyecto Ágil: la comunicación. La mala comunicación, la poca comunicación, o la comunicación deficiente de cualquier tipo lleva al colapso y fracaso de dicho proyecto.”
Puntos clave#
Los proyectos que seguían una metodología Waterfall tendían a exceder sus gastos con el tiempo, mientras que el producto entregado estaba por debajo del estándar y era difícil de usar.
Esa situación originó que un grupo de desarrolladores firmara un breve manifiesto de 68 palabras en 2001.
Un breve trasfondo#
Durante los años 1960, el software entró en una gran crisis; crear software era complejo pero cambiarlo después se convirtió en puro caos. Waterfall al rescate.
Waterfall delineó un conjunto simple y lógico de procesos que una empresa necesitaría seguir para que un proyecto fuera exitoso. Su nombre viene de la metáfora del agua cayendo suavemente en una corriente predecible, constante e incremental. Su ciclo de vida de desarrollo de software estaría en seis pasos simples.
- Requisitos
- Análisis
- Diseño
- Código
- Testing
- Operaciones
Durante 10 años, Waterfall fue la metodología estándar en el universo del software. Y durante 10 años más, el caos persistió. Aunque la intención era buena, la realidad es que el conjunto siempre cambiante de restricciones no se lleva muy bien con esta metodología porque cada paso depende del anterior.
El 86% del tiempo que una empresa usa el método Waterfall para gestión de proyectos, el cliente recibe software inadecuado o inútil. Muchos proyectos de software no se usaron o nunca se terminaron.
Durante los años 70 y 80, Desarrollo Iterativo e Incremental (IID) probó ser una opción viable. En los 90 surge la Entrega Evolutiva (ED), que cambia la situación. El desarrollador es responsable de escuchar las reacciones del usuario temprana y frecuentemente. El usuario comienza a jugar un rol directo en el proceso de desarrollo.
Unos años después, surgió un nuevo método Prototipado de Producción Iterativa Rápida (RIPP), más tarde llamado Desarrollo Rápido de Aplicaciones (RAD), que afirmaba “Software funcionando en 90 días… o te devolvemos tu dinero.”
Por último, durante los 90 se definieron en detalle Extreme Programming (XP), Scrum y Crystal.
Estas soluciones distintas pero similares estaban descentralizadas, trabajando independientemente unas de otras. Esta realización llevó a esa noche en Utah la unificación de estas ideas bajo una bandera, en un documento.
Agile se convirtió en el estándar definitivo para el desarrollo de software.
El Manifiesto Ágil#
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación comprehensiva
- Colaboración con el cliente sobre negociación de contratos
- Responder al cambio sobre seguir un plan
Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
Artículos relacionados
- Trabajando ágil con equipos no ágiles ¿Cómo puedes trabajar con otros equipos que no son ágiles?
- ¿Ignorando Scrum para ser más Ágil? Matando la agilidad con reuniones excesivas
- Entrevista sobre XP y Agile Agile trata sobre CÓMO haces ciertas cosas
Lecturas relacionadas
- Clean Agile por Robert C. Martin
- Agile Product Management with Scrum por Roman Pichler