Metodología de desarrollo basado en funciones (FDD)
Metodología de desarrollo basado en funciones (FDD) está alineada con la metodología de desarrollo ágil. Se trata de un proceso orientado al diseño, desarrollado y refinado por Jeff De Luca, Peter Coad y otros colaboradores.
El proyecto se divide en características. Estas características son pequeñas piezas de un proyecto completo. De todas y cada una de ellas te hablaremos a continuación.
Qué es FDD
El desarrollo basado en funciones (FDD por sus siglas en inglés) es una metodología de desarrollo de software centrada en el cliente conocido por iteraciones cortas y lanzamientos frecuentes.
Al igual que Scrum, FDD requiere que el cliente, también conocido como propietario del negocio del proyecto, asista a la reunión de diseño inicial y las retrospectivas de iteración.
Al lanzar nuevas funciones de forma incremental, los desarrolladores pueden priorizar las solicitudes de los clientes, responder a las solicitudes de manera oportuna y mantener a los clientes satisfechos. Para lograr esto, los desarrolladores planifican qué características son capaces de crear, dividen las solicitudes complejas en una serie de conjuntos de características más pequeños y luego crean un plan sobre cómo completar cada objetivo con el tiempo.
El desarrollo basado en características consta de cinco pasos claves, sin embargo hemos agregado la recopilación de datos como un paso adicional, teniendo en cuenta la importancia de esta tarea. Todos estos pasos te los detallamos a continuación.
Pasos
Usado típicamente en proyectos de desarrollo a gran escala, existen seis pasos o actividades básicas durante la FDD:
- Recopilación de Datos
- Desarrollar modelo general
- Crear lista de funciones
- Plan por característica
- Diseño por característica
- Construir por característica
Recopilación de datos: Al igual que con todas las metodologías ágiles, el primer paso en FDD es obtener una comprensión precisa del contenido y el contexto del proyecto, y desarrollar una comprensión clara y compartida del público objetivo y sus necesidades. Durante este tiempo, los equipos deben apuntar a aprender todo lo que puedan sobre el por qué, el qué y para quién sobre el proyecto que van a comenzar. Esta recopilación de datos puede considerarse como la etapa 0, pero no se puede omitir. Comparar el desarrollo de productos con la redacción de un trabajo de investigación: este es el paso de investigación y desarrollo de tesis.
Desarrollar y modelo general: Continuando con la metáfora del trabajo de investigación, esta etapa es cuando se redacta el bosquejo. Utilizando la "tesis" (también conocida como objetivo principal) como guía, el equipo desarrollará modelos de dominio detallados, que luego se fusionarán en un modelo general que actúa como un esquema general del sistema. A medida que se desarrolle y el equipo aprenda, se agregarán detalles.
Crear una lista de características: Usa la información reunida en el primer paso para crear una lista de las características requeridas. Recuerda, una característica es una salida valorada por el cliente. Has una lista de características (que se puede completar en dos semanas) y ten en cuenta que estas características deben ser propósitos u objetivos más pequeños, en lugar de tareas.
Plan por característica: Analiza la complejidad de cada característica y planifica las tareas relacionadas con los miembros del equipo. Durante la etapa de planificación, todos los miembros del equipo deben participar en la evaluación de las características teniendo en cuenta la perspectiva de cada etapa de desarrollo. Luego, utiliza la evaluación de la complejidad para determinar el orden en que se implementará cada característica, así como los miembros del equipo que se asignarán a cada conjunto de características.
Esta etapa también debes identificar a los propietarios de las clases, los desarrolladores individuales asignados a las clases. Debido a que cada clase de la característica de desarrollo pertenece a un desarrollador específico, alguien es responsable de los principios conceptuales de esa clase, y si se requieren cambios en varias clases, entonces es necesaria la colaboración entre los propietarios de cada una para implementarlas.
Y aunque los propietarios de clase son importantes para FDD, también lo son los equipos de características. En los equipos de características, se definen roles específicos y se alienta una variedad de puntos de vista. Esto asegura que las decisiones de diseño consideren múltiples pensamientos y perspectivas.
Diseño por característica: Un programador jefe determinará la característica que se diseñará y creará. Asimismo, determinará los propietarios de las clases y los equipos de funciones involucrados, mientras define las prioridades de las funciones. Parte del grupo podría estar trabajando en diseño técnico, mientras que otros trabajan en el marco. Al final de la etapa de diseño, todo el equipo completa una revisión de diseño antes de seguir adelante.
Construir por característica: Este paso implementa todos los elementos necesarios que respaldarán el diseño. Aquí, se construyen interfaces de usuario, al igual que los componentes detallados en el diseño técnico, y se crea un prototipo de función. La unidad se prueba, inspecciona y aprueba, luego la característica completa puede promoverse a la construcción principal. Cualquier característica que requiera más tiempo que dos semanas para diseñar y construir se divide en características hasta que cumpla con la regla de las dos semanas.
Diferencias con Scrum
FDD está relacionado con Scrum, pero como su nombre lo indica, es un método centrado en características (en oposición a un método centrado en la entrega). Las características son una pieza fundamental de FDD. Se trata de funciones pequeñas que son altamente valoradas por el cliente.
Durante la FDD, se debe entregar una función cada 2-10 días, que difiere de Scrum, en la cual los sprints suelen durar entre dos a cuatro semanas. FDD valora la documentación más que otros métodos (Scrum y XP incluidos), lo que también crea diferencias en los roles de las reuniones. En Scrum, los equipos generalmente se reúnen a diario; en FDD, los equipos confían en la documentación para comunicar información importante y, por lo tanto, generalmente no se reúnen con tanta frecuencia.
Otra diferencia clave es el usuario final: en FDD, el usuario real es visto como el usuario final, mientras que en Scrum es típicamente el propietario del producto quien es visto como el usuario final.
Más métodos y metodologías: