Su navegador no soporta JavaScript. Voices From the Past: Uncle Bob on Project Management - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS

Varias personas me han pedido que vuelva a publicar información histórica sobre Scrum. Se publicó en mi sitio web en 1995, después de que Bob Martin, firmante del Manifiesto Ágil, opinara sobre la gestión de proyectos.

Grupo: comp.lang.smalltalk

De: rmartin@rcmcon.com Robert Martin

Org: R. C. M. Consulting Inc. 708-918-1004

Date: Fri, 3 Feb 1995 16:05:49 GMT

Subj: Re: Gestión de proyectos OO

____________________________________________________________

Se ha planteado la pregunta: "¿Cómo utilizamos nuestro proyecto estándar

herramientas de gestión que ayuden a gestionar los proyectos de OO"? A primera vista

cosas, esto parece ser un problema importante. Hemos utilizado el

conjunto normal de herramientas para la gestión de proyectos "en cascada", y es

difícil ver cómo pueden utilizarse para gestionar proyectos "iterativos".

Sin embargo, el conjunto estándar de herramientas de gestión de proyectos (por ejemplo, PERT y

CPM y Ghant) no son incompatibles con el desarrollo iterativo. Pueden consultarse en

están diseñados para modelizar los calendarios de los proyectos, y los iterativos

proyectos siguen teniendo un calendario.

La dificultad estriba en que los puntos del calendario son diferentes. En

gestión de proyectos en cascada, los elementos del calendario son

"Análisis", "Diseño", "Implementación", "Prueba", etc. Sin embargo, en

desarrollo iterativo normalmente no tiene sentido utilizar tales

artículos. ¿Qué artículos debemos utilizar?

Existe el mito común de que los proyectos iterativos son proyectos sin

horarios. Van de un lado para otro, hasta que algún técnico

decide que ha hecho suficiente trabajo y declara el proyecto

completa. Esto no es así. Un proyecto iterativo tiene un calendario

como cualquier otro proyecto, y ese calendario puede modelarse con

herramientas estándar de gestión de proyectos

Cuando se inicia un proyecto iterativo, la aplicación se desglosa en

muchos subproyectos, cada uno con un número muy reducido de características. Estos

Los subproyectos se denominan a veces rodajas verticales, o simplemente rodajas.

Cada tajada representa una pequeña cantidad de trabajo que debe ser

logrado. Debe ser posible ordenar las rebanadas en el tiempo, tal

que las características implementadas en rodajas anteriores no dependen del

características implementadas en rodajas posteriores. De este modo, los slices pueden

aplicadas por orden cronológico.

Una vez asignadas las rodajas, cada una puede estimarse en cuanto al

recursos necesarios para su aplicación. A continuación, estas rebanadas

en un diagrama PERT o en cualquier otra herramienta de gestión de proyectos.

elaborar una estimación completa del proyecto. Sin embargo, esta estimación es

extremadamente poco fiable.

Cuando comience el proyecto, el tiempo necesario para poner en marcha los primeros

se registra y se introduce en el programa. Cada vez que un corte

en completado aprendemos más sobre cuánto tiempo las otras rebanadas

tomar. De este modo, nuestro calendario se vuelve más y más preciso a medida que pasa el tiempo.

sobre. La fecha final del calendario cambiará (probablemente retrocederá) a medida que

se obtienen más datos sobre la aplicación de las rodajas.

Fred Brooks dijo una vez: "Añadir mano de obra a un proyecto tardío lo hace

más tarde". Esto es cierto cuando 80% de la programación se ha

agotado y sólo se ha completado 40% del proyecto. El beneficio

a la programación iterativa es que la retroalimentación relativa a la precisión de

el horario vuelve muy pronto. Después de las primeras rebanadas,

los gestores de proyectos pueden empezar a medir el error en su

estimaciones y planificar los cambios de recursos. Así pueden añadir mano de obra

a un proyecto temprano para que no se convierta en tardío. (O pueden

decidir abandonar el proyecto).

Tenga en cuenta que los elementos que se colocan en la herramienta de gestión de proyectos

no son "Análisis", "Diseño", etc. Son las propias rodajas.

En los proyectos realmente grandes, los trozos deben dividirse en

utilizando exactamente el mismo esquema. La programación de estas

también deben desglosarse en subprogramas, y el proceso

se repiten de forma jerárquica.

es_ARSpanish
Acciones