Desarrollo basado en funcionalidades

Lea Karam
mayo 18, 2017
Agile web and app development, Desarrollo web
desarrollo agile

Compartir esta publicación

Table of Contents

Hemos hablado sobre el desarrollo guiado por pruebas y desarrollo guiado por el comportamiento, así que pensé, ¿por qué no cubrir el tema: desarrollo basado en funcionalidades? En realidad, no hay muchos que hablen de FDD, y se puede decir que Extreme Programming, Scrum y TDD son definitivamente los métodos ágiles más populares en este momento, pero aquí en Apiumhub, también valoramos mucho el desarrollo basado en funcionalidades.

Comenzando por lo obvio, ¿qué es el desarrollo basado en funcionalidades?

Primero, me gustaría mencionar que desarrollo basado en funcionalidadesfue creado por Jeff Luca a fines de los 90’s. En realidad, estaba intentando proporcionar una solución de desarrollo de software a un banco.
FDD es un proceso de desarrollo que, como todas las metodologías ágiles, es iterativo e incremental con el objetivo de entregar software que funciona. Desarrollo basado en funcionalidades mezcla las mejores prácticas impulsadas por lo que es importante para el cliente. Esto significa que los desarrolladores se enfocan en las características que el cliente valora, las funciones que esperan.

Digamos que con desarrollo basado en funcionalidades, las características son tan importantes como las historias de usuario son para scrum. Es lo que ayudará a los desarrolladores a la hora de planificar su trabajo.

Como mencioné anteriormente, Jeff Luca fue el creador de desarrollo basado en funcionalidades. Propuso una solución que es una mezcla de 5 procesos que cubriría el desarrollo del modelo, listado, diseño, planificación y, finalmente, la construcción de sus características. Entonces, para obtener una mejor comprensión, obviamente ayuda echar un vistazo a esos 5 procesos básicos de FDD.

Una descripción más detallada de los 5 procesos de desarrollo basado en funcionalidades

Una vez que revisemos todos los procesos, rápidamente reconocerás que el Programador Jefe tuvo un papel muy importante en desarrollo basado en funcionalidades. Casi comparable a un desarrollador principal, el programador jefe necesita tener habilidades técnicas y habilidades de liderazgo para poder dirigir un equipo de desarrollo interfuncional. Otra función muy importante es el experto en dominios, ya que tiene responsabilidades muy similares a las del propietario del producto en Scrum, aunque no es lo mismo.

Patrón de diseño: Special case pattern

1er proceso: desarrollo de un modelo general

En este primer proceso, desarrollo basado en funcionalidades empuja a los equipos a construir un modelo de objetos del problema del dominio. A diferencia de otros, el modelado FDD es una actividad interfuncional, iterativa y de colaboración. Los miembros del equipo (expertos en desarrollo, dominio y programadores en jefe) trabajan juntos para componer un modelo para el área de dominio y son guiados por un arquitecto jefe. La idea es tener diferentes equipos proponiendo diferentes modelos y más tarde, después de ser revisados, elegir una opción o mezclarlos. Finalmente, el modelo de área de dominio se fusionará en el modelo general.

En realidad, es una gran manera de comenzar el proyecto, ya que permite al equipo obtener una sólida comprensión del proyecto y una comunicación sólida.

Segundo proceso: creación de la lista de características

Aquí, se podría comparar la lista de características con la acumulación de productos en scrum, y la función sería una especie de historia de usuario. Después de tener listo el modelo general, basado en el conocimiento obtenido durante esa fase, tendremos que identificar las características que son valiosas para el cliente y que básicamente guiarán el proyecto. Las características no deben tardar más de dos semanas en completarse, y si lo hacen, entonces deberían incluirse en más de una función. Por lo general, se expresan como una acción, resultado y objeto.

3er proceso: planificación por función

En la tercera fase, como su nombre lo dice, se trata más o menos de planificar en qué orden se implementarán las características, se trata de organizar. Los conjuntos de características se asignan a los programadores.
Obviamente, durante la planificación tomamos en consideración diferentes aspectos como los riesgos, las dependencias de complejidad, la carga de trabajo del equipo, etc.

4to proceso: diseño por característica

Como en todos los procesos, utilizamos el conocimiento que obtuvimos del primer proceso de modelado. El programador jefe se responsabiliza de seleccionar un grupo de características que se deben desarrollar a continuación. Él también tendrá que determinar las clases de dominio que estarán involucradas. Después de que se forme el equipo de características, todos comienzan a trabajar juntos para realizar el trabajo, donde el experto del dominio se encargará de analizar y diseñar una solución para cada función.

5 ° proceso: creación por características

Una vez que el experto en el dominio finaliza y basándonos en el trabajo realizado en el proceso de diseño por función, los propietarios de la clase tendrán que implementar todos los elementos que sean necesarios para poder apoyar el diseño. Por lo tanto, trabajamos en el código que se ha desarrollado y con la unidad lo probamos e inspeccionamos para garantizar que todo sea correcto y aprobado por el programador jefe, que luego dará la autorización para comenzar a construir.

Katas de código; una manera de convertirse en un mejor desarrollador de software

Así que usamos Scrum, usamos XP programming, FDD y más, así que creo que puede ser interesante hacer una breve comparación de estos 3. Feature Driven Design tiene un poco de eXtreme Programming, así como un poco de Scrum pero añadiendoles Técnicas de Diseño guiado por el dominio. Lo bueno es que es muy fácil trabajar en equipos grandes usando FDD. En realidad es extremadamente escalable.

Comunicación; verbal y escrito

Todos sabemos que las metodologías Ágil tienen un fuerte enfoque en la comunicación entre el equipo y el resto de las personas involucradas.
En la programación de XP y Scrum, la documentación es importante, pero no empuja al equipo a poner un gran esfuerzo en ello y los dirige más hacia la comunicación verbal con el resto de las personas implicadas en el proyecto. Con desarrollo basado en funcionalidades es un poco diferente porque realmente creen que la documentación debería ser trabajada.

¿Enfoque centrado en el usuario?

Los software son o al menos deberían diseñarse y desarrollarse con un enfoque centrado en el usuario. Con la programación de XP, por ejemplo, necesita la participación del usuario durante el proceso de desarrollo, ya que desarrollamos con iteraciones cortas donde el usuario siempre prueba el software en funcionamiento.

En desarrollo basado en funcionalidades, el usuario final también está involucrado en el proceso, pero de una manera diferente, es en realidad durante el informe. Y en Scrum, el usuario final no está realmente involucrado, es el dueño del producto el que se ve como el usuario final.

La longitud de sprint

Esta no es una regla general, por supuesto, pero en general como mencionamos para desarrollo basado en funcionalidades, cuanto más corto, mejor. Digamos que un sprint sería entre 2 y 10 días. ¡Lo que difiere de Scrum que está entre 2 y 4 semanas y la programación de XP que puede durar hasta 6 semanas!

¿Qué hay de las reuniones?

Como la comunicación es importante, obviamente, las reuniones son importantes con las metodologías ágiles. Con la programación de Scrum & XP, hay reuniones diarias en las que participan todos los miembros del equipo y donde hablan sobre el proyecto y deciden juntos cómo debería continuar el proyecto. Esas reuniones son en general bastante informales y rápidas.

Crear, Usar y Construir un DSL

Con desarrollo basado en funcionalidades es bastante diferente porque, en general, la información se comunicará a través de la documentación.

¿Qué tan grande puede llegar el proyecto?

Al elegir metodologías Ágil, todo depende de los requisitos del proyecto. Por ejemplo, para proyectos pequeños que no son complejos, podría ir fácilmente con la programación de XP. Mientras que Scum y desarrollo basado en funcionalidades serían recomendados cuando se trata de proyectos de software que son más complejos y que son más grandes.

Entonces, ¿qué hay de genial en desarrollo basado en funcionalidades?

FDD es increíble para grandes proyectos y en realidad es bastante escalable y propenso a lograr el éxito.
Los 5 procesos mencionados anteriormente ayudan cuando se trata de conseguir que nuevos miembros se unan al equipo, especialmente en cortos períodos de tiempo.
El Desarrollo basado en funcionalidades se basa en las mejores prácticas que son reconocidas por la industria y que considera las fortalezas y debilidades de los desarrolladores.
El hecho de que con FDD haga compilaciones regulares garantiza que el sistema esté siempre actualizado y se lo pueda mostrar al cliente. Puede identificar fácilmente los errores en el código fuente de las características.
A lo largo de los procesos, usted tiene una alta visibilidad de progreso y resultados debido al hecho de que hay frecuentes informes de progreso que se realizan en todos los niveles del proyecto.
El primer proceso, el desarrollo del modelo general nos hace tener una comprensión profunda del alcance y el contexto del proyecto.
El hecho de que tenga una comprensión más profunda de los requisitos y las expectativas, de que haga pequeñas iteraciones y construya partes pequeñas, una por una, implica que el riesgo realmente se reduce. ¡Menos sorpresas no deseadas!