¿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:

¿Cómo reconocer un proyecto?

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í.

Me pareció interesante este post que encontré en el blog de Lockout Tagout Safety Ltd. 

¿Como reconocer un proyecto?. En complemento a la definición formal, aquí hay algunas ideas.

Reconcer un proyecto a tiempo permitirá aplicar los procedimientos de Adminsitración de proyectos adecuados y crear ventajas buscando lograr el resultado por el costo correcto, con la calidad correcta y a tiempo.

Así que, en términos más simples, ¿cómo reconocer un proyecto? La respuesta obvia es que prácticamente cualquier cosa que se haga podría tomarse como un proyecto, desde tareas minuciosas hasta grandes actividades de construcción. Siempre que exista una meta, o el deseo de algo, podría pensarse en un proyecto.

Siete pasos para recuperar un proyecto encaminado al fracaso

Voy a cerrar el año con este artículo en el que J. Frank Carr nos propone en su blog "Visual Basic notebook for .net": 7 pasos para recuperar un proyecto encaminado al fracaso. 

1. Deje de trabajar y tire a la basura el plan de trabajo actual. 

La primera recomendación de Frank es: detengamos el trabajo. Si cuando surgen problemas el trabajo continúa, es probable que se caiga en una espiral mortal. 

Se fuerza al equipo a trabajar horas extra, provocando estrés, o se aplican otras técnicas igual de malas como aumentar el equipo con nuevos consultores o programadores, o empezar a usar una nueva herramienta con la esperanza que ella nos saque del problema. 

Pero Frank hace una afirmación que aunque parece obvia, es difícil de asimilar: Si las cosas ya empezaron a ir mal, seguir el mismo curso solo las va a empeorar. 

Harry Potter y las siete características necesarias en el Administrador de Proyectos

Iniciemos el año con la continuación de un análisis que inició aquí. Ahora revisemos a Harry Potter y las siete características necesarias en el Administrador de Proyectos que Linda Richter nos propone en brighthub. 

1. El Administrador de Proyectos nunca debe pensar que está solo o que es el único capaz de realizar el trabajo. 

Como señala Linda, en las primeras historias a partir del momento en que descubre que él es el niño que vivió, Harry desarrolla la idea de que esta solo en su misión. Y luego conforme crece va aprendiendo a identificar de sus tareas, a confiar en su equipo, e involucrar a todos los interesados. Esto es algo que los buenos administradores de proyectos ya saben. 

2. Si debe pedir ayuda, asegúrese de haber identificado el proyecto primero. 

Linda apunta al hecho de que tristemente Harry no es capaz de identificar cuál es su proyecto: en los primeros cuatro libros, se dedica a descubrir quién es en realidad, y solo hasta que está a punto de morir Dumbledore identifica el proyecto y se lo explica a Harry.