Translate - Traduce

enero 17, 2020

¿En qué consiste el Desarrollo Dirigido por Características (FDD)?


Soy Iván Rivera, PMP


Soy fan de Starwars, disfruto la Ciencia Ficción y escribo sobre gestión de proyectos (o lo que se me ocurra). Puedes leer un poco sobre mi formación aquí.

Desde el Blog de My Agile Partner propongo ahora este interesante artículo de Judicaël Paquet que explica en qué consiste el Desarrollo Dirigido por Características (FDD: Feature-driven development).

Wikipedia lo traduce como desarrollo basado en funcionalidades (en inglés, feature-driven development, FDD): "un enfoque de desarrollo ágil de software desarrollado por Jeff De Luca y Peter Coad en 1997 para un banco de Singapur".


Se trata de un método ágil basado en conceptos incrementales e iterativos.


El proceso del diseño y construcción comprende cinco fases:


  1. Preparar un modelo global con un diagrama de clase UML
  2. Elaborar una lista de características que se espera desarrollar
  3. Planificar por funcionalidad, asignando características específicas a cada desarrollador
  4. Diseñar por funcionalidad, creando una plantilla para cada una de las características
  5. Desarrolla cada una de las características
El autor nos dice que este método ágil es antiguo y, aunque es cierto que la agilidad ha evolucionado con el tiempo, el FDD se considera uno de los métodos ágiles existentes a pesar de sus contradicciones con los métodos ágiles como XP o Scrum.

El FDD (desarrollo basado en características) propone:

  • Iteraciones cortas y grandes
  • Tener una mejor comunicación durante todo el desarrollo
  • Hacer entregas frecuentes con trabajos reales realizados
  • Contar con información precisa del progreso
  • Tener procesos apreciados por clientes, desarrolladores y gerentes
  • Realizar iteraciones con los 5 pasos mencionados mas arriba
Los 6 roles clave en FDD
La metodología define 6 roles clave:

- Administrador de Proyecto (PM). 

En FDD existe este rol que es tan rechazado por las comunidades ágiles. Su función es hacer buenos informes de progreso, trabajar por el bienestar del equipo, haciendo frente a presupuestos, contrataciones y logística.


Si observamos detenidamente esta descripción, a menudo es el papel atribuido a Scrum Masters en grandes empresas que tienen problemas para convertirse en 100% Scrum Master.


- Arquitecto jefe (CA)

La CA es responsable del modelado completo de la arquitectura del producto en desarrollo.

- Gerente de Desarrollo (DM)

El DM es responsable de la actividad de los desarrollos. De hecho, estamos en un método ágil totalmente opuesto a Scrum; y el autor dice es más cmún encontrar este tipo de roles dentro de las grandes empresas. Y si bien puede parecer que trabajar con roles tan precisos desalienta fuertemente otros métodos ágiles, la agilidad ha evolucionado hay quién ahora recomienda estos esquemas de responsabilidades compartidas.

- Programadores Senior

En FDD, los desarrolladores experimentados trabajarán en la parte de análisis y las especificaciones técnicas. Serán responsables de un grupo de 3 a 6 desarrolladores.

- Dueño de clase

Estos son desarrolladores que trabajan en grupos pequeños justo debajo del Programador Senior para desarrollar, probar y documentar las funcionalidades realizadas.

- Expertos en dominios

Este rol está representado por usuarios clave, patrocinadores y analistas de negocios. Están allí para identificar necesidades y permitir que los desarrolladores trabajen. Su presencia es esencial para tener un producto de calidad.

- Roles transversales

Existen algunos roles transversales propuestos por el método como Release Manager, Language Guru (entrenador de desarrolladores), Build Engineer (responsable de las compilaciones de aplicaciones), Toolsmith (desarrollador de pequeñas herramientas o bibliotecas para desarrolladores) y el Administrador del sistema.

El FDD también propone agregar equipo de pruebas, implementadores y documentadores técnicos.


Prácticas de FDD

En FDD, se privilegian algunas prácticas. Por ejemplo, necesitamos usar UML con colores para hacer los modelos de clase.

Implementación de características

El FDD favorece fuertemente el desarrollo basado en características. Debe ser posible desarrollar una "característica" en dos semanas -como una historia de usuario-. De lo contrario, se recomienda dividir la función en dos.

Además, existe un formato clásico para escribir características de FDD:


<acción> 
<artículo (el/la/los/las)> 
<resultado> 
<mediante | para | de | a | > 
<un(a)> 
<objecto> 

Por ejemplo, podríamos tener:


Calcular [acción] el total [resultado] de una venta [objeto]. 

El equipo responsable del desarrollo de esta característica también será elegido en el futuro para desarrollos relacionados con su alcance.

Estos equipos deben ser autónomos al trabajar en su alcance.

Los desarrolladores son responsables.
Una práctica totalmente opuesta a los métodos ágiles que se utilizan actualmente en las empresas es la "propiedad de la clase". Básicamente, una clase en el código es propiedad de un desarrollador (o dos desarrolladores) mientras sean parte de la organización. El desarrollador asignado trabajará en este código en el futuro, cuando sea necesario.

Sin embargo, se recomienda cuando es posible tener dos Propietarios de clase para reducir el riesgo que implica un único responsable en caso de problemas.

Construcciones regulares
El FDD impone el hecho de tener compilaciones regulares para probar regularmente el avance del producto. La retroalimentación es un punto esencial en los métodos ágiles.

Herramienta de informes de progreso
En FDD se deben realizar informes de progreso como en Scrum. Es muy importante en los proyectos tener transparencia en el progreso del proyecto para poder resolver los obstáculos lo antes posible.

Entonces ¿FDD es realmente un método ágil?
De hecho, el FDD responde a los valores y principios del Manifiesto Ágil. Como dice el autor, mucha gente comete un error al pensar que está prohibido tener roles técnicos muy precisos, asignar el trabajo a los desarrolladores, etc. Sibién Scrum rechaza totalmente estas prácticas, no estan prohibidas en el mundo de la agilidad.

Pero es cierto: la forma de trabajar en FDD recuerda más a las prácticas tradicionales que a las recientes.

Conclusión
¿Las empresas que hacen Scrum con gerentes de proyectos y arquitectos no son ágiles? Incluso cuando algunos equipos se desvían las reglas de scrum, eso no los hace anti-ágiles.

Judicaël cierra el artículo recomendando tener equipos técnicos multidisciplinarios. Este concepto funciona bien: con equipos motivados, y entregas con menor riesgo.


Si requieres ayuda con tus proyectos, puedes contactarme a través de mis redes sociales:


No hay comentarios.:

Entradas populares