Aparte de Scrum y XP hay otras metodologías ágiles, como Feature-Driven Development (FDD), una metodología que también ayuda a crear software mediante un ciclo de vida iterativo e incremental (el mismo que usa Scrum).
Si no encuentras manera de encajar Scrum a tu proyecto, pero necesitas algo ágil, pero tu equipo es grande, utilizas personal externo, no tienes claro que tu equipo sea auto-organizado, sigues pensando que debe haber un jefe de proyecto y arquitecto, que hay que tener un diseño / arquitectura antes de empezar a desarrollar… puede que en FDD encuentres la respuesta a tus problemas.
La metodología ágil FDD está orientada a equipos más grandes, con más personas que aquellos a los que normalmente se aplican otras metodologías ágiles como Scrum. La metodología ágil FDD contempla la figura del jefe de proyecto y una fase de arquitectura.
Como sabéis, las populares Scrum y XP suelen usarse, y recomendarse, para equipos pequeños y auto-organizados (de dejo aquí el post sobre qué es un equipo auto-organizado) y en estas metodologías no queda claro que haya una fase de diseño. Y ahí es donde muchas empresas tienen grandes problemas; bien porque han intentado aplicar Scrum a equipos numerosos, y no han sabido cómo, o les falló la arquitectura o el equipo no era del todo auto-organizado.
Por lo anterior, para mí, en muchos casos, metodología ágil FDD es una metodología más pragmática, mas con los pies en el suelo, es decir, más cercana a lo que son los equipos de desarrollo reales que te encuentras en las empresas, aquellos que necesitan hacer una arquitectura, un diseño, y que tienen jefes de proyecto y arquitectos.
En esta serie de dos post te dejo un breve resumen de la metodología ágil FDD. En el post de hoy veremos algunos datos importantes a conocer de FDD y una introducción a sus procesos. En el post de mañana veremos los cinco procesos de la metodología ágil FDD.
Unos pocos datos y antecedentes importantes a conocer de la metodología ágil FDD
Aunque aquí hablamos de la “metodología FDD”, siendo rigurosos, al igual que sucede en Scrum, FDD es, concretamente, un “framework” o una meta-metodología, es decir, que necesita ser adaptado al caso concreto.
El padre de la metodología es Jeff De Luca. Y por ello la metodología ágil FDD tiene gran influencia de las ideas de Peter Coad, en su día gurú de la Orientación a Objetos, y hoy, en los tiempos de lo ágil, menos conocido. Quizás los antiguos del lugar recordarán en su día un famoso libro de Coad llamado “Java Modeling In Color With UML (1999)”, en el que aunque el primer autor del libro era Coad… el libro también lo firmaba Jeff De Luca.
El libro que mejor describe la metodología es el A Practical Guide to Feature-Driven Development y la web de referencia es la del autor: Jeff De Luca´s website.
Los procesos la metodología ágil FDD
FDD es una metodología dirigida por modelos, y de iteraciones cortas.
FDD define 5 procesos: Proceso 1 – Desarrollar el modelo global (Develop overall model), Proceso 2 – Construir una lista de características (Build feature list), Proceso 3 – Planificar (Plan by feature), Proceso 4 – Diseñar (Design by feature) y Proceso 5 – Construir (Build by feature). Los 3 primeros pueden considerarse la “iteración cero”, aunque en FDD no le llaman así, y los consideran “procesos iníciales”.
Ya en el libro de gestión ágil hablábamos de que en la práctica los equipos de desarrollo necesitan un tiempo previo para arrancar, montar entornos, planificar, e incluso hacer un estudio previo de la arquitectura. Esto normalmente se suele hacer en lo que comúnmente se llama iteración cero (o sprint cero para quienes siguen Scrum). Pero, por ejemplo, en Scrum no se dice mucho de esta iteración cero, sin embargo FDD la detalla mucho más.
Los dos primeros procesos son secuenciales y definen el modelo global. Los tres finales se iteran para cada “feature” (que vienen a ser los requisitos).
La última versión de los procesos de FDD la podéis encontrar aquí.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pingback: Bitacoras.com
Pingback: Enlaces de los martes (18 sept 2012) « Ruben ChT's Blog
Pingback: ¿FDD o Scrum? 6 ventajas de FDD frente a Scrum - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Las metodologías Crystal. Otras metodologías ágiles que, quizás, te puedan encajar más que Scrum - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Lean software development « Ruben ChT's Blog
Pingback: El Sprint cero y el Sprint de release - Javier Garzás | Javier Garzás
Comentario
Estimado, no existe tal cosa como sprint 0 en scrum, la arquitectura tambien se construye en iteraciones y en forma incremental.
¿Un sprint donde sólo existen Historias Técnicas, y que se utiliza para preparar la infraestructura de cara a los siguientes sprints? Yo sí lo llamo sprint 0 y así lo utilizo. El PO no tiene nada que hacer, nada que validar, nada que aceptar.
La arquitectura se tiene que elaborar como otro proyecto, no existe Sprint cero. Además un Sprint no es suficiente para hacer pruebas de concepto y personalizar una arquitectura.
En mi experiencia es dificil empezar un proyecto de software sin determinar que se debe hacer, el «sprint 0» de FDD esta orientado y detallado a la fase previa a definir los sprint de desarrollo, de esta forma al comenzar con un modelo de dominios base, ya se comienza a establecer los limites del proyecto, pensando en que la mayor parte de ellos son finitos y con un presupuesto asjustado, es como diriamos «conocer el tamaño del animal primero que ir a matarlo»