PROJECT MANAGEMENT . CUADERNO II

Estimados colegas
Seguimos con esta entrega del cuaderno V, siendo esta la segunda parte.
La entrega contiene documentos referidos al análisis de técnicas de control de proyectos de software.
Podríamos decir que ,en algunos casos, no se tratan en esencia de técnicas de control de proyectos sino de practicas o procesos de mejorapara el desarrollo de software .
Aun entendiendo la diferencia, preferimos incluirlas dentro de este tópico (administración de proyectos) porque el modo en el que se enuncian dichas practicas en los documentos que enviamos, exceden el marco de recetas y se centran en que es diseñar, producir software y que es un proyecto de software. Y creemos que las lecturas y el análisis de estos documentos ayudan a que los arquitectos, los ingenieros de software y los administradores o gerentes de proyecto encuentren que pueden formar un UNICO EQUIPO DE PROYECTO donde cada parte tiene una serie de roles de valor. Y esto solo sucederá si mas allá de la imprescindible voluntad de trabajar en equipo, se construye una visión común sobre nuestra profesión, sus riesgos y la riqueza y limitaciones de su domino de aplicación.
---------------------------SITIOS DE LA COMUNIDAD SCP--------------------------- Invitamos a todos a visitar el sitio de hosting del proyecto de código abierto que mantenemos alrededor del Framework de construcción de software al que llamamos CIRCO. (www.codeplex.com/circo).

El proyecto no solo trata de ser la prueba de concepto de las ideas que discutimos sino también un sitio donde pueda producirse colaboración en un proyecto de código abierto. Allí encontraran los releases del framework , discusiones sobre el rationale del mismo y videos y documentos sobre como utilizarlo. Hemos liberado una versión nueva del Framework y sus utilidades relacionadas , mejorado la documentación de uso, el proceso de instalación y el de aprendizaje.
También los invitamos a participar de las discusiones y novedades que están hosteadas en Linkedin: http://www.linkedin.com/groups?gid=107996&trk=hb_side_g
Estos son los documentos que adjuntamos con este envio y algunos comentarios sobre los mismos.
SEI Document_CMMI or AGile.pdf
*******************************
Este es un white paper del SEI: Software Engineering Institute) en el que se analizan los orígenes de CMMI y de los métodos Agiles y sus practicas de desarrollo de software. La lectura sobre los orígenes de ambas escuelas realmente paga la lectura del articulo.
Uno de los valores del informe esta en el rastreo del origen de las metodologías agiles en escuelas de ingeniera no ligadas al software, y el uso de estas técnicas y conceptos en proyectos de software y de otro tipo en el propio DoD (Department of Defense de los EEUU).
Hay referencias al trabajo de Tom Gilb (de quien también entregamos un white paper en este envío) y nosotros también agregaríamos que en este punto es de valor el documento de Craig Larman: “A History of Iterative and Incremental Development”. (Con referencia a este ultimo documento digamos que estaremos entregándolo con la tercer parte de este cuaderno V).
El valor que encontramos en este enfoque esta en que permite salir del ruido del marketing y las palabras de moda que estan en boga en los ambientes donde se promueve y se discute de metodologías agiles, tratando que las ideas y la experiencia sean las que produzcan valor.
Saliendo del ruido de marketing y enfocándonos en las ideas, podremos tomar lo mejor de las mismas y hacer crecer las nuestras, las propias que como ingenieros, programadores, arquitectos o gerentes debemos tener.
En algunos casos estas discusiones parecen perder de vista que se discute sobre como producir software. Y, mas allá que los conceptos agiles puedan haber nacido o sean aplicados en otras ramas de la ingeniería, para los ingenieros de software el problema es la construcción y entrega del software mismo. Este documento del SEI va al punto no solamente indicando los aspectos de valor en cada paradigma (Agile o CMMI) sino en aquello que NINGUNO DE LOS DOS PARADIGMAS PRODUCE NI RESUELVE.

Link a la nota comentada

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397670


Ron Jeffries-Extreme Programming and the Capability Maturity Model.doc
************************************************************************
Este documento es un corto resumen que bien podrían ser las notas de lecturas del autor (Ron Jeffries) del libro de Paulk sobe el modelo CMM. Pero Ron no solo ha sido uno del firmantes originales del Documento sobre métodos agiles (Agile Manifesto), sino que fue el coach del equipo que trabajo en el legendario proyecto C3 de Chrysler, un proyecto seminal en el desarrollo de las metodologías agiles.
Lo que lleva a Ron Jeffries a hacer esta nota es una referencia a una discusión en un grupo e Google afirmando que exTreme Programming puede ser uno de los procesos del SEI , Nivel I (uno). De modo que es una opinión valiosa. Y aunque es menos extensa y profunda que el documento anterior, nos parece una buena fuente de reflexión, siendo que esta escrita por quien administraba los esfuerzos del proyecto C3 y manejaba la relación con el cliente y sus expectativas. Algo que esta en la verdadera esencia de la administración de proyectos.

Link a la nota comentada :

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397590
---------------
UNA REFLEXION:
---------------
Mas alla de la necesidad (como hemos marcado en otras entregas) de tomar de cada escuela o paradigma lo que se consideremejor y formar el PROPIO CUERPO DE IDEAS, creemos que existe una diferencia fundamental en la cultura de los practicantesde CMMI y AGile: La certificación. Si las metodologías agiles se transformasen en un MODELO, que requiere certificación veríamos una proliferación mayor aun de gurúes, un aumento del marketing (alrededor de la certificación y no de la practica) y una miríada de evangelizadores, que por haber leído la "palabra divina" creerán estar en condiciones de decir como se hace software.
De modo que mientras los métodos agiles eviten conformar una Central que, través de la certificación, indique que es lo que esta bien y que lo que esta mal, tendrán el crédito de quienes tratamos de pensar libremente y armar nuestras propias conclusiones.
De todos modos queda abierta la duda de si el ámbito de aplicación de las metodologías agiles escala adecuadamente, en proyectos con varios contratistas, de larga duración y con equipos distribuidos. En mi punto de vista no veo como estas metodologías pueden aplicarse como núcleo de la administración de proyectos de escala. Un punto a discutir y del que nos gustaría conocer sus ideas.

Gilb-EVO-Evolutionary Project Management.pdf
********************************************
Este documento de Tom Gilb nos resulta interesante porque es la opinión, respecto del manejo de proyectos de alguien formado en el corazón de las escuelas formales de administración de proyectos: El DoD (Deparmento de Defensa de los EEUU). Gilb explica los conceptos de un método de administración que considera que la construcción y el diseño son una evolución y que no es correcto asumir para (la mayoría de los proyectos) que los requerimientos de los usuarios NO están definidos y cerrados en la etapa previa al construcción. Las ideas plasmadas en esta técnica datan de 1960 ,bien antes que Cockburn, Beck, Jeffries o Fowler implementasen y relanzasen estas técnicas a través de XP, TDD , Integración continua, etc.
Con simpleza Gilb sostiene que esta mecánica incremental de construcción ( Y POR ENDE DE ENTENDIMIENTO DEL PROBLEMA, por lo tanto de alcance, por lo tanto de plazo-recursos-dinero) es parte de un ciclo de la naturaleza: Aprender, adaptarse y sobrevivir.
Evo tiene principios que han inspirado a las metodologías agiles y muestran que esta discusión es critica para que podamos encarar proyectos exitosamente:
Early delivery of project results to stakeholders (for example, ‘next week’!)
Frequent releases to stakeholders (for example, ‘every Friday’)
Small increments (‘steps’) (for example, no more than 2% of total project)
Useful-to-stakeholder steps (benefit delivered, value experienced)
Selection and sequencing of steps according to degree of stakeholder benefit; usually but not always, high-profit steps first (using dynamic priority determination).

Link a la nota comentada

http://www.box.net/files/0/f/30066664/1/f_312384976#/files/0/f/30066664/1/f_312397574

Estos 3 documentos de la segunda entrega de este cuaderno V, son realmente ricos y un soporte conceptual para quienesdebemos participar de la visión general, implementación y administración de un proyecto para entregar un producto útil a los usuarios finales.
Esperamos que estas lecturas ayuden a sus tareas, a la evolución de sus ideas y al éxito de sus emprendimientos
Atentamente