FANDOM


La Filosofía de FDD

“Feature-Driven Development” (FDD) propone tener etapas de cierre cada dos semanas, lo cual implica que los desarrolladores tendrán nuevas actividades que realizar en dicho período de tiempo. Esto hace que la motivación del equipo se mantenga durante todo el proyecto debido a que se ven los resultados periódicamente.

A los gerentes les fascina tener resultados a la vista cada cierto período de tiempo ya que reducen el riesgo del proyecto por tener entregas periódicas y tangibles. Con FDD, se obtienen porcentajes reales del proceso, lo cual ayuda a demostrar al cliente donde se encuentra el proyecto.

A los clientes también les gusta esta idea ya que pueden tener planes con entregas y resultados frecuentes. Además, los clientes saben cuán lejos está el proyecto de su finalización.

Con FDD se pretende dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar al proyecto.

Roles y Responsabilidades

El FDD clasifica sus roles en las siguientes tres categorías:

Key roles

Project Manager

Es el líder administrativo y financiero del proyecto. Una de sus tareas principales es proteger al equipo de distracciones externas y permitir que el equipo pueda trabajar en las condiciones apropiadas. En el FDD el Project Manager tiene la última palabra sobre temas referidos al alcance, tiempo y personal.

Chief Architect

Es el responsable por el diseño global del sistema y de la ejecución de todas las etapas del diseño. También tiene la última palabra sobre las decisiones del diseño de todo el sistema. Si es necesario, este rol puede ser dividido en dos roles como ser Domain Architect y Tecnical Architect.

Development Manager

Lleva diariamente las actividades de desarrollo y resuelve cualquier conflicto que pueda ocurrir con el equipo. Además, este rol incluye la responsabilidad de resolver problemas referentes a los recursos. Las tareas de este rol pueden ser combinadas con las del Chief Architect o el Proyet Manager.

Chief Programmer

Es un desarrollador con experiencia, el cual participa en el análisis de los requerimientos y el diseño del proyecto. El Chief Programmer es el responsable de guiar a pequeños equipos en el análisis, diseño y desarrollo de nuevas funcionalidades. Además, selecciona las funcionalidades a desarrollar de la lista de funcionalidades de la próxima iteración en la última fase del FDD, identifica las clases y el Class Owner que se necesita en el equipo para la iteración. Con la ayuda de otros Chief Programmers resuelve problemas técnicos y de recursos, y reporta el progreso del equipo durante la semana.

Class Owner

Trabaja bajo la guía del Chief Programmer en las tareas de diseño, codificación, testing y documentación. Él es responsable del desarrollo de las clases que se le asignaron como propias. Para cada iteración los Class Owner participan en la decisión de que clase será incluida en la lista de funcionalidades de la próxima iteración.

Expertos del Dominio

Los expertos del dominio pueden ser un usuario, un cliente, un sponsor, un analista del negocio o una mezcla de estos. Su tarea es poseer el conocimiento de los diferentes requerimientos del sistema. El experto del dominio pasa el conocimiento a los desarrolladores de manera tal que asegure que estos entreguen un sistema completo

Domain Manager

Lidera al grupo de expertos del dominio y resuelve sus diferencias de opinión concernientes a los requerimientos del sistema.

Supporting roles

Realese Manager

Controla el avance del proceso mediante la revisión de los reportes del Chief Programmer y realiza pequeñas reuniones con él. Además, reporta el progreso del proyecto al gerente.

Language Lawyer/Language Guru

Es un miembro del equipo responsable de poseer un vasto conocimiento en, por ejemplo, un específico lenguaje de programación o tecnología. Este rol es particularmente importante cuando el equipo trabaja con una nueva tecnología.

Build Engineer

Es la persona responsable de preparar, mantener y correr el proceso de construcción, incluidas las tareas de mantenimiento de las versiones y la publicación de la documentación.

Toolsmith

Es un rol para la construcción de herramientas específicas para el desarrollo, conversión de datos y testeo. Además, puede trabajar en la preparación y mantenimiento tanto de bases de datos o sitios web destinados al proyecto.

System Administrator

La tarea del administrador del sistema es configurar, administrar y reparar los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.

Additional roles

Tester

Verifica que el sistema recién creado cumpla con los requerimientos del cliente. Puede llegar a ser una persona independiente del equipo del proyecto.

Deployer

Es el encargado de convertir la información existente requerida por el nuevo sistema y participa en el lanzamiento de los nuevos productos.

Technical Writer

Se encarga de preparar la documentación para los usuarios, quienes pueden formar parte o no del equipo del proyecto.

Vale la pena aclarar que un miembro de un equipo puede ejercer varios roles y un rol puede ser compartido por varias personas.

El Proceso

Dicho proceso consiste de cinco fases secuenciales durante las cuales el diseño y la construcción del sistema se llevan a cabo.

Proceso.png

La parte iterativa del proceso de FDD (Diseño y Construcción) soporta un desarrollo ágil, con adaptaciones rápidas para cambios de último momento en los requerimientos.

Develop an Overall Model

Cuando esta fase comienza, los expertos del dominio ya tienen una idea del contexto y los requerimientos del sistema. Es probable que el documento de especificación de requerimientos ya exista. Sin embargo, FDD no hace énfasis en la recolección y administración de los requerimientos. Los expertos del dominio presentan un informe llamado walkthrough en el cual los miembros del equipo y el Chief Arquitect son informados a través de una descripción de alto nivel del sistema.

El dominio global es dividido en diferentes áreas y se realiza un walkthrough detallado para cada una de dichas áreas por parte de los expertos del dominio. Luego de cada walkthrough, un grupo de desarrolladores realizan un modelo de objetos para el área del dominio. Además, el equipo de desarrollo discute y decide cual es el modelo de objetos más apropiado para cada área del dominio. Simultáneamente, el modelo global del sistema es construido.

Build a Features List

Los walkthroughs, el modelo de objetos y los requerimientos existentes ofrecen una buena base para construir una features list (lista que agrupa toda la funcionalidad del sistema). En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Las funcionalidades son presentadas por cada área del dominio y éstas forman un Major List Sets. Dicha lista es dividida en subconjuntos en base a la funcionalidad. Estas representan diferentes actividades con un área específica del dominio. La features list es revisada por los usuarios y sponsors del sistema para su validación y aprobación.

Plan by Feature

En esta etapa se incluye la creación de un plan de alto nivel, en el cual la features list es ordenada en base a la prioridad y a la dependencia entre cada feature (son pequeñas funcionalidades que el cliente quiere). Además, las clases identificadas en la primera etapa son asignadas a cada programador.

Design and Build by Feature

Un conjunto de features es seleccionada de la features list.

El diseño y construcción de la funcionalidad es un proceso iterativo durante el cual las features seleccionadas son producidas. Una iteración puede llevar desde unos pocos días a un máximo de dos semanas. Este proceso iterativo incluye tareas como inspección del diseño, codificación, testing unitario, integración e inspección del código. Luego que la iteración llega a su fin se realiza un main build de la funcionalidad en el cual se integra la funcionalidad. Dicho main build se realiza mientras la siguiente iteración comienza.

Resumen del Proceso

Las tareas marcadas con gris son opcionales.

Proceso detalle.png

Reporte de Avance de las Tareas

El Release Manager se reúne con los Chief Programmers para que éstos reporten como es el avance de las tareas. En esta reunión, que tiene una duración de 30 minutos o menos, cada Chief Programmer informa de manera verbal el avance d sus features. Hacer esto de forma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo de escuchar a los otros y saber dónde están situados los demás en el proceso de desarrollo. Al final de la entrevista, el release manager anota los resultados, actualiza la base de datos y genera los reportes.

El release manager reporta los resultados obtenidos semanalmente, tanto para el equipo, para el cliente y para el Project Manager. Para los clientes y los gerentes, el reporte debe incluir el porcentaje de avance de cada feature. Para el equipo se informa cual es el desempeño del mismo.

Conclusiones

  • FDD es un proceso que ayuda al equipo a producir resultados periódicos y tangibles.
  • Esta metodología utiliza pequeños bloques que contienen la funcionalidad del sistema, llamados features.
  • Organiza los bloques que están relacionados entre sí, en una lista llamada feature set.
  • Hace énfasis en la obtención de resultados cada dos semanas.
  • Incluye estrategias de planificación que hacen que las features puedan desarrollarse en dichos lapsos.

¡Interferencia de bloqueo de anuncios detectada!


Wikia es un sitio libre de uso que hace dinero de la publicidad. Contamos con una experiencia modificada para los visitantes que utilizan el bloqueo de anuncios

Wikia no es accesible si se han hecho aún más modificaciones. Si se quita el bloqueador de anuncios personalizado, la página cargará como se esperaba.

También en FANDOM

Wiki al azar