Segunda parte del post sobre FDD.
Proceso 1: Desarrollar el modelo global (Develop overall model)
Una de las cosas más polémicas, criticadas y oscuras de los proyectos ágiles es cómo y cuándo se crea el diseño y la arquitectura. En el mundo ágil, hay incluso quienes, erróneamente, asocian la palabra diseño con el ciclo de vida en cascada, tan denostado por el agilísimo extremo.
En la metodología ágil FDD si se recomienda, y deja claro, que hay que tener un diseño previo. No un diseño documentado y detallado al máximo, pero si un borrador de la arquitectura. Y que además éste se construya de manera iterativa. El modelo OO es más en anchura que en profundidad. La profundidad (los detalles) van saliendo iterativamente a lo largo del proyecto. El diseño es un artefacto vivo.
A diferencia de otras metodologías como Scrum, la metodología ágil FDD contempla una fase de diseño y el rol del “Chief Architect”, o diseñador experimentado. También recomienda el uso de UML en colores, la metodología de modelado de Coad.
Proceso 2: Construir una lista de características (Build feature list)
En la metodología ágil FDD a los requisitos se les llama “features” (utilizaré en el post la palabra feature, en inglés, por ser la forma más usada en FDD). FDD define una feature como una pequeña función orientada al cliente. Por pequeño se entiende que suele durar de 1 a 3 días de desarrollo.
A diferencia de Scrum y Extreme Programming, que utilizan una lista plana de requisitos, o historias de usuario (te dejo el post de historias de usuario), la metodología ágil FDD organiza sus features en una jerarquía de tres niveles. Y, de nuevo, proyectos o equipos más grandes agradecen esta jerarquía. Jerarquizar los requisitos ayuda a manejar un mayor número de requisitos.
“Lead developers” (desarrolladores líder) o “chief programmer” (o programadores Jefe) organizan la lista de “features” con los conocimientos adquiridos durante el modelado (FDD utiliza los términos “lead developers” y “chief programmer” en reconocimiento a Brooks, te dejo un post sobre Brooks)
Proceso 3: Planificar (Plan by feature)
Tercer y último proceso de los que conformarían la iteración cero. Su objetivo, crear una planificación inicial y asignar responsabilidades.
La metodología ágil FDD también se aleja de conceptos muy arraigados en el mundo ágil, como el de la propiedad colectiva del código. En lugar de que “todo el código sea de todo el mundo”, en FDD se asignan como responsables de partes del código a desarrolladores concretos. Esta asignación de responsables tiene lugar durante el proceso de planificación. Y ojo, que en FDD hablamos de responsabilidad del código no de exclusividad.
Esto es otra muestra más de cómo FDD está pensada para proyectos grandes, en los que a veces aquello de que el código es de todos no funciona muy bien.
Proceso 4: Diseñar (Design by feature)
En esta parte se realiza un diseño para cada feature. El programador responsable (chief programmer) elige un grupo de features a desarrollar durante las próximas dos semanas.
En la metodología ágil FDD se realizan diagramas de secuencia para cada feature, y se refina el diseño o modelo global.
Proceso 5: Construir (Build by feature)
Después de una inspección diseño exitosa, los propietarios de cada clase, o partes del código, desarrollan el software.
La metodología ágil FDD contempla el uso de las pruebas unitarias e inspecciones de código, tras las cuales la feature se sube al “build” principal.
Seguir leyendo sobre la metodología ágil FDD…
Te recomiendo este post, que hace un buen resumen, el libro A Practical Guide to Feature-Driven Development y la web de Jeff De Luca .
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Pingback: Bitacoras.com