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

PROJECT MANAGEMENT - CUADERNO I

Estimados:

Les agradecemos los comentarios que hemos recibido y trabajaremos para avanzar en varios de los puntos, temas y modalidades solicitadas.-
Respecto de este ultimo punto (modalidad de envío), consideramos que es mejor que enviemos documentos como lo hacemos actualmente y no links a un repositorio de publicación.-
Esto facilita la manipulación y el almacenamiento individual de los documentos para cada receptor, aun cuando al principio represente una carga en el buzón de e-mail.-
Documentos traducidos: No nos resulta facil disponer de tiempo para traducir documentos al castellano o al portugues.
Creemos firmemente que cada uno de nosotros piensa y describe sus ideas en su lengua maternaY asi debe ser. En un punto debemos encontrar una LINGUA FRANCA que actue como nexo. No discutiremos aca por que dicha LINGUA FRANCA es la inglesa. La inteligencia de nuestros colegas nos exime de eseanalisis. Pero eso es un hecho. De modo que debemos adecuarnos al mismo
De todos modos, va de suyo, que no hay ni habrá, documentos en lengua extranjera que no sea la inglesa.-
También agradecemos a aquellos que nos mandaron las direcciones de colegas que desean recibir estos envíos. Desde ya que los hemos invitado a ser parte de la comunidad (SCP:Software Construction Process) que es la unica forma de quedarregistrado para tales envios
Con respecto al contenido de los documentos que estamos compartiendo hoy:

Agile Project Management.pdf
******************************
Agile Project Management es un documento generado en CC Pace Systems por dos ingenieros que son gerentes de proyecto : Sanjiv Augustine y Susan Woodcook.-El punto de este documento es presentar una visión de las metodologías agiles como aporte real a la administración de proyectos. –Algo que en general no se valora correctamente por una mezcla de prejuicios de quienes prefieren metodologías formales y por fallas reales de quienes consideramos que estas metodologías son adecuadas sin aclarar su campo efectivo de alcance.-
La visión de Augustine y Woodcook es audaz: Mirar a los equipos de proyectos como sistemas complejos adaptativos.
El punto parecería mas bien una tesis para presentaciones universitarias, pero el origen del informe es de una consultora de prestigio en el “mundo real” y los autores, son ingenieros de campo en la administración de proyectos.- Nos parece que este tipo de documentos ayudan a aumentar la visión sobre lo que un administrador o gerente de proyectos debe hacer. No colocando su foco tanto en los documentos y las planificaciones, sino en el coaching sobre los que participan y el producto que el cliente espera.- En fin, el tema siempre es opinable y suscita discusiones.

M3 Algunas lecciones aprendidas_v1 0 2.pdf
******************************************
Y para eso, quisimos compartir una que tuvimos en M3 al cierre de un proyecto, como lecciones aprendidas (M3 Algunas lecciones aprendidas).- El informe es una compilación de posiciones del equipo de arquitectura y desarrollo, luego del cierre de un proyecto complejo.-En el contexto del tema que tratamos, preferimos compartir un documento de discusión de un caso real en carne propia, antes que un documento con una opinión “políticamente correcta”.- Ese proceso de discusión ayudo a enfocar aspectos importantes en el momento de cotizar un proyecto: ¿Cuanto sabemos de el ? ¿Cuanto sabe el cliente ¿? ¿Que grado de imprecisión tiene el requerimiento? Estos temas relacionados a la (inherente) baja calidad de ingeniería de especificación de los proyectos de software son los que afectan el día a día de cada proyecto. Los problemas en la especificación nacen no de la misma, sino de la ciega confianza que se desea depositar a menudo como algo totalmente definido al inicio de la construcción. En el documento tratamos sobre algunos aspectos que diferencian a la ingeniería del software con otras ramas de la ingeniería.-

The New Methodology.docx
*************************
Muchos de los conceptos vertidos en el documento anterior encuentran su soporte en este maravilloso articulo de Martin Fowleren el que razona sobre las caracteristicas especificas de la construccion de software y los problemas de la produccion de DISEÑO.Ya que eso, diseño, es precisamente el software. Esa caracteristica natural de nuestra porfesion es pasada por alto muchasveces por quienes administran proyectos de software como si fuesen pavimentaciones de calles... (o mas aun, preparacionesde tortas con una receta perfectamente experesada en cantidades). Esa discusion encuentra una base en el llamado "sentido comun": Tenemos que planificar y dar fechas certeras, asi como estimaciones certeras de tiempos y recursos.Si no lo hacemos no entendemos como son los negocios. Seamos claros. Los que sostenemos otras posiciones entendemos tambien como son los negocios. Solo que los negocios no sontodos iguales. ALgunas desafios admiten una mayor prediccion que otros. Algunos negocios son mas riesgosos que otros. En fin, nos gustaria que lo central en este analisis estuviese en una mayor comprension de las particularidades y caracteristicas del proceso de construccion de software, y entendemos que este artiuclo de Fowler va en ese sentido

Famous failures of complex engineering systems.docx
****************************************************
Y finalmente el documento “Famous failures of complex engineering systems”, es un extracto de unas presentaciones del año 1997 del Instituto de Tecnología de California (Caltech) sobre fallas en sistemas de ingeniería complejos. Nos interesa que revisen el caso del sistema de equipajes del Aeropuerto de Denver y el del transportador de satélites Ariane 5. Estos son clásicos ejemplos de “errores de software”, que pueden ser entendidos mejor como “errores de diseño”. Es esa esquiva cualidad de diseñar, la que finalmente termina regulando la calidad de los proyectos.-
Esperamos que disfruten de estas lecturas.-
Atentamente

LINKS a documentos mencionados en esta nota

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

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_437877813

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_437878735

http://www.box.net/files/0/f/30066652/1/f_312406480#/files/0/f/30066664/1/f_312385120

EL PROCESO DE CONSTRUCCION - CUADERNO II

Estimados colegas:
Seguimos con esta entrega del cuaderno VI, siendo esta la segunda parte.
La entrega contiene documentos referidos al análisis sobre el proceso de construccion de software
Hemos elegido para esta entrega un material clasico y uno actual El primero es un capitulo del libro de Uno Frederick Brooks "The Mythical man-month" El otro es un extracto de un capitulo del libro de Allistair Cockburn "Agile Software Development"- 2nd Edition

Mythical Man Month-Chapter 2
****************************
"...When a task cannot be partitioned because of sequential constraints,the application of more effort has no effect on the schedule (Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging..."

Allistair Cockburn-Cooperative Game-II:
**************************************
Imagine a competition in which each team must build something somewhere in a swamp. They don't know exactly what they have to build, they don't know where they have to build it, and they don't have a map of the swamp, but they are in a race to build it. They will create subteams. Some will scavenge for building materials, others will explore the swamp, and so on. Note that this corresponds to people finding different specialties in software development.If they have to play only one round of the game, they will find it optimal to build the weakest, sloppiest bridges and to draw the most careless maps possible to get to the end of the game. However, if they know another team will be coming in after them, they may choose to make better maps, better bridges, better paths. This difference between strategies corresponds to a software project team updating their system documentation and training their junior people.

----

Estimados, como ven, este envio tiene material que es bueno leer mas de una vez y analizar y discutir con colegas que construyen software y llevan adelante proyectos de desarrollo de software. El analisis de estas ideas junto a una practica intensa de estos modelos para diseñar y construir nos llevara sin duda a conceptos mas solidos y maduros para nuestras soluciones
Atentamente

EStos son los links a los documentos mencionados en esta nota

http://www.box.net/files#/files/0/f/30066652/1/f_312407236

http://www.box.net/files#/files/0/f/30066652/1/f_312406322