Ejemplos Algunos Artefactos de Gestión Tradicional - Esp UDEM 2016

Hola a todos

En un post pasado - http://www.lecciones-aprendidas.info/2016/05/ejemplos-de-artefactos-agiles.html -  les compartí los entregables "Ágiles"  que se realizaron sobre la primera parte del curso de especialización de ingeniería de software en la Universidad de Medellín - "Planificación de Proyectos Informáticos" (1)

Hoy deseo compartirles los artefactos que creamos bajo el marco de gestión tradicional -no trabajamos en todos los artefactos, solo algunos - para el mismo producto - proyecto.

• Visión
• Identificación de interesados
• Project Charter
• Alcance
• Linea base del alcance
• Enunciado del Alcance
• EDT
• Diccionario de la EDT
• Matriz de trazabilidad
• Cronograma
• Plan de gestión de costos
• Presupuesto por fases
• Presupuesto detallado
• Flujo de Caja Mensual
• Curva S de Costos
• Necesidades de Financiación
• Seguimiento y control
• Informe de segumiento

Los proyectos son:

• Gymsoft - sistema para administración de gimnasios -  (clic aquí)
• Sistema para administrar zonas de estacionamiento regulado - (clic aquí)

Saludos ágiles (aunque este post sea sobre gestión tradicional)

Jorge Abad

Notas, aclaraciones, referencias y comentarios

1. Mitad de la materia es sobre gestión y ejecución ágil, y la otra mitad sobre la planeación y ejecución tradicional

Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos

Hola a todos

Hoy quiero compartir una situación común en los proyectos y organizaciones, que se repite una y otra vez, adicionalmente creo que tanto ustedes como yo lo hemos vivido

El escenario es sencillo:
Se reúnen varios líderes asociados a la construcción de un proyecto (1) a deliberar ¿por qué este se encuentra mal o en riesgo?, Y la primera respuesta que sale es:

• ¡El problema son los RECURSOS! ( - refiriéndose al equipo de trabajo - ,wow ¿estudiamos 5 años, más las experiencias, diplomados, certificaciones, especializaciones y maestrías para responder esto?)

y acá veo varios  problemas en esta óptica que quiero compartirles:

1. En primer lugar no son recursos, son personas, esta eterna lucha por que comprendan que el trabajo lo hacen personas tan valiosas como quienes dirigen y que al pensar en una forma reduccionista sobre las personas lo que logran es ignorar o desperdiciar la capacidad creativa e innovadora del ser humano, y del equipo que los acompaña.
2. ¿Quién en sus cinco sentidos quiere hacer mal su trabajo? La verdad no dudo que los hayan (serán muy pocos), pero no es lo común, todos queremos hacer cosas que ayuden a otros, que sirvan, que sean útiles y que estén alineadas con el propósito para el cual sentimos que estamos acá en esta tierra, por lo tanto culpar al equipo de trabajo es una costumbre simplista que indica que no se quiere abordar con el debido interés la causa y la solución del problema.

Pero cuando lo opinión mágica no está orientada a los "recursos" se centra en otro tema (9), todos concuerdan, se abrazan y sonríen, deciden que hacer y salen de la reunión hasta que después sean convocados a otro comité para hablar sobre lo mismo y notar que los problemas no fueron resueltos o todos lo olvidan pues surgió otro proyecto en problemas para analizar.

¡Rayos! Y recuerdo siempre a la cita del periodista del siglo pasado H.L. Mencken

Para cada problema complejo hay una solución clara, simple y equivocada,( H.L. Mencken)

No lo niego, al principio yo era así, además cuando asumes posiciones de liderazgo tiendes a adoptar los mismos lenguajes y análisis de tus pares, pero luego cuando en el 2012 conocí las metodologías ágiles y el poder de las retrospectivas para mejorar un equipo y su forma de trabajo, realmente cambió mi forma de ver las cosas.

Con esta nueva óptica, encontrarme en reuniones como esta no niego que me daba enojo, pues tendemos a la simplificación o sobresimplificación por herida newtoniana, ¿cómo así? Todos hemos sido heridos en nuestra lógica por Newton y su causa y efecto y tendemos a creer que todo se resuelve así, por lo tanto, buscamos desesperada y angustiosamente una causa que explique nuestro problema (o efecto) y dado esto encontrar la solución y continuar con el siguiente problema pues hay muchos líos en la fila esperando a ser resueltos.

Algunos ejemplos de nuestra común sobresimplificación:

• ¿por qué el país está mal, por el presidente?
• como si todos no hiciéramos parte de un país y fuéramos parte de la maquinaria que lo mueve.
• los proyectos de software fallan principalmente por los requisitos
• es una de las causas pero no es la única causa
• ¿Y por qué fracasó su relación de pareja?, por una infidelidad de él/ella
• es muy probable que la infidelidad sea el síntoma y no la enfermedad, y la enfermedad era una serie de disfunciones en la pareja que hicieron que hubiese esa infidelidad,
• etc.

Y me topé con Cynefin

Cynefin es un framework para entender qué tipo de problema estamos enfrentando y proporciona herramientas de cómo resolverlo, este framework me fue presentado por mi estimado Ricardo Colusso (@rcolusso) y desde ahí comencé a aficionarme a el, y recientemente leí un minilibro sobre el tema en Infoq.com (4) y muchas ideas se aclararon - recomendada su lectura -. Explicaré brevemente en qué consiste.

El framework de Cynefin fue elaborado por el Investigador Dave Snowden, y el término significa "hábitat", divide los tipos de problema en 5 áreas y propone herramientas para solucionarlo

• El obvio:
• Problema conocido
• tiene relación directa causa efecto
• Ejemplo: Se chuzó la llanta, solución cambiar la llanta o parcharla
• Se resuelve con una mejor práctica
• Pasos de solución: inspeccione - categorice - responda
• El complicado
• Problema que se puede llegar a conocer
• Tiene relaciones causas y efectos conocidas
• Ejemplo: Se daño un vehículo y el mecánico luego de inspeccionarlo sabe los diferentes arreglos que hay que hacer para poner nuevamente el vehículo en marcha y estado óptimo.
• Se resuelve con las mejores prácticas, juicio de expertos, todo es perfectamente planeado (cronogramas, tiempos, planeación predictiva, PMP) y los expertos resolverán este tipo de problemas de la misma manera teniendo el mismo éxito.
• Pasos de solución: inspeccione -analice - responda
• El complejo
• Problema es entendido en retrospectiva
• las relaciones causa y efecto no son repetibles
• Ejemplo: La economía es excelente prediciendo el pasado y explicándolo pero no es precisa hacia el futuro
• Se resuelve con la multiexperimentación
• Pasos de solución: inspección - adaptación
• El caos
• El problema es incoherente
• las relaciones causa efecto no son perceptibles
• Ejemplo: Escenarios de I+D
• La solución es novedosa
• Pasos de solución: ensayo y error
• El desorden
• Corresponde al punto cuando llegamos a un problema y aún no lo hemos categorizado en los cuatro anteriores

Bajo todo lo expuesto quisiera invitarlos a varias cosas:

1. No caer en la sobresimplificación de los problemas que enfrentan, identificar si hay causa y efecto directamente relacionada o explicable, ya sea en el espacio de lo obvio o de lo complicado o realmente no.
2. Si lo anterior no se cumple trate de identificar si está en el espacio de lo complejo, desde mi punto de vista y de otros muchos en la industria del software (5) la gestión y ejecución de proyectos de software cae allí, o sino díganme ¿qué gerente de proyecto de software es capaz de predecir todos los percances que le van a presentar en la ejecución del mismo, por más buena gestión del riesgo que haga? La verdad no conozco el primero, son capaces de explicar que les pasó y porqué les paso pero no de predecirlo por más que llenen el cronograma de colchones para la gestión del riesgo..
3. Si estás en una reunión de estas de análisis de problemas, propón lo siguiente:
1. Identifiquen las causas
2. las prioricen (cuales son las que consideran más importantes)
3. Propongan soluciones
4. Las prioricen (cuales consideran claves, 3 o 4) (6)
5. las ejecuten y observen en un ciclo de no más de un mes (ojalá menos) los resultados de ese experimento y decidan qué pasos seguir, tal vez sea necesario otro experimento.

Para este último escenario existen diversas herramientas de 

• análisis de causa raíz
• retrospectivas (que incluyen lo anterior)(8)
• Toyota Kata (7)

que son bastante fuertes y útiles.

Por tanto, quisiera invitarlos a que abracemos la complejidad de nuestros proyectos y organizaciones y abandonemos la sobresimplificación.

Cerrando

Y bueno, propongo que los líderes de proyecto, gerentes, etc, seamos más creativos y demostremos nuestros años de estudio, experiencia y certificaciones identificando las verdaderas causas y dejemos la sobresimplificación de los problemas que enfrentamos, entendiendo que nos movemos en un espacio complejo sobre el cual no tenemos control, esta actitud, será mucho más útil, que ignorarlo.

"No estamos en las organizaciones para ofrecer soluciones rápidas sino para ofrecer las soluciones correctas"

Saludos ágiles

Jorge Abad

Notas, Referencias y Aclaraciones

1. También puede ser una empresa, un área organizacional.
2. Es un trabajo arduo remover este vicio de la gerencia tradicional de proyectos
3. Expicación de Cynefin segun wikipedia -https://en.wikipedia.org/wiki/Cynefin_Framework
4. Excelente libro sobre Cynefinby por Greg Brougham, corresponde a la colección de minilibros gratuitos de infoq.com - (clic aquí)
5. Debo esta referencia, pero no dudo que los firmantes del manifiesto ágil hacen parte de este grupo,
6. No se deben hacer todas las mejoras, al menos 3 o 4 para saber cual fue la mejora, solución o experimento que más influyó en la solución del problema.
7. Excelente presentación sobre el tema de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
8. Retrospectivas (ver más acá)
9. He también visto como se centran estos comités en culpar a las pruebas y acusan de la calidad del software solo a esta actividad del proceso, o cualquier otro chivo expiatorio ¡OMG!

¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu

Usted o su empresa siendo el CLIENTE:

• ¿Formula proyectos que sabe de antemano que NO se van a ejecutar en el tiempo que tiene pactado?
• ¿Se busca quien haga su proyecto a pesar de tener expectativas irreales en cuanto tiempo y costo?
• ¿Argumenta que si hay un proveedor que es capaz de postularse es porque la solución es posible?
• ¿tiene reuniones afanosas donde todos se miran, sonríen, estrechan manos  diciendo que sí vamos a ser  capaces, vamos a poner todas las condiciones para que sea así?

Usted o su empresa siendo el PROVEEDOR:

• Le jura a su cliente que va a cumplir aunque no tiene ni las personas, ni la expertise para hacerlo
• Su gerente  general le dice a usted como gerente de proyecto:  tienes que hacer ese proyecto con las personas que tiene, pues el "no voy a contratar mas gente / - o mal llamados recursos -  "
• Se mienten entre sí en el posible equipo ejecutor diciendo:” tranquilo yo sé que ustedes lo van a lograr, ustedes son muy buenos” aunque no falta el pesimista que dice – “hombre esta es la misma historia de siempre, vamos a caer en lo mismo”, lo ignoran y siguen adelante…
• Se diseñan estrategias super-apretadas para cumplir algo irrealizable (el Project, el Gantt y el Power Point pueden con todo)
• Estima proyectos grandísimos sin la participación del equipo ejecutará.

A ustedes dos (cliente y proveedor) ya lo saben:

El proyecto será:

• un fracaso
• o un eterno desgaste  muy difícil de cerrar
• Reuniones y reuniones
• Actas firmadas
• Revisión de documentación
• Y hasta invitación a revisión de los abogados

Alguien pagará los platos rotos

• Lo más seguro es que sea el proveedor 
• Estos platos los pagan los trasnochos del equipo de trabajo, de esta forma se pagará la “mala planeación” que si somos sensatos fue la mala venta o presentación a un proyecto problemático.
• Y pasará a engrosar la lista de proyectos problemáticos que harán que nuestro valor hora de venta hacia el mercado aumente.
• Su reputación estará nuevamente en juego.
• En muy pocos casos los pagará el cliente, pero si es así, con seguridad le costará su puesto, o su reputación.

Se verán abocados (cliente y proveedor - gerente del lado del cliente y gerente del proyecto) a realizar reuniones continuas y constantes de re-planeación de proyecto donde se pasarán horas reformulando el proyecto, creando nuevos cronogramas  (donde el tiempo lo sacarán del tiempo de descanso correspondiente  a los desarrolladores) y firmando con sangre nuevas fechas (a ratos no sé de dónde sacan tanta sangre cierto tipo de empresas) y lo peor al no cumplirlas usted (ya sea cliente o proveedor) perderá credibilidad y la palabra dada ya no servirá.

 En esta circunstancia es probable que su Jefe o Gerente (los CEO, o plumas blancas como le decimos en mi país) tengan que ir a reuniones a repactar todo nuevamente.(y lo peor es probable que las reputación y palabra de ambos también se desgaste en este tipo de círculos viciosos)


Si usted es el cliente:

• Su jefe le estará preguntando por qué eligió ese proveedor y tendrá constantes reuniones de seguimiento y de estrés con él.
• Usted pensará de nada me sirvió haberme desgastado en la elección o haber confiado en la empresa “x” o en mi amigo “y” que trabajaba en esa empresa.

Si usted es el proveedor

• El comercial dirá: “yo solo cumplí con vender el proyecto, acá lo aceptaron, nadie dijo NO, ni nadie me detuvo, además yo logrando otro estoy en otro proyecto si quieren me invitan a una reunión a ver que hacemos”. (la caricatura que sigue es.. inspiradora.)

(pero bien..sigamos con el tema)

• Al gerente de proyecto le dirán
• mire como planea mejor ese proyecto, para que salga adelante
•  otras veces le dirán: Nos va tocar hacer ESO aunque no esté en el alcance para calmar al cliente (léase ESO como una nueva fuente de problemas pues va a estar muy seguramente mal especificado y como siempre este tipo de regalos salen caros).
• El gerente hablará con los desarrolladores y todo su equipo.
• "Muchachos tenemos que trabajar fuerte, el proyecto es un lío, ustedes saben que yo no lo vendí, pero estamos acá para sacar las cosas adelante. Vamos a trabajar duro, les daremos pizzas y pollo para que trabajen de noche y fines de semana. Yo sé que lo vamos a lograr, yo confío en ustedes, y si lo logramos voy a buscar como logro una bonificación de la gerencia general."

----

Y a todas estas, todos dicen en su interior… este es el mismo deja vu de siempre, repetimos y repetimos los mismos errores, acá en esta organización no aprendemos. De nada nos sirve tener procesos definidos y/o rigurosos como CMMi, certificados o no, todo es el mismo desgaste (por no querer decir todo es la misma m…).

Muchas veces el desarrollador o el gerente de proyecto  se va para otra empresa y allá vuelve y encuentra la misma historia.

---


La verdad no entiendo la industria de software, ni los clientes, ni los proveedores, no acogen muchas veces Procesos Ágiles que son transparentes porque les da miedo, pero ¿acaso todo este recurrente deja vú no es peor que una película de terror que se repite y reinventa con nuevos y/o los mismos protagonistas?

Esto es cómo jugar a la ruleta rusa entre 4 personas y con 5 balas en el tambor.

No entiendo ¿por qué los Clientes (aclaro "los malos Clientes") no quieren pagar el costo de un buen proyecto?, y  ¿por qué los que son/somos proveedores no aprendemos a decir que NO?

Hasta acá esta pequeña diatriba y desahogo... hasta la próxima.


----

¿Quieres jugar un juego?

Hagamos un proyecto a la forma tradicional con una metodología robusta, mirarás el RFP (la convocatoria, la licitación) y sabes que no lo lograrás, si no lo haces saldrás del mercado, pero si lo haces cortaré la libertad de tu equipo de trabajo y trabajarán horas y horas, perderás tiempo y dinero sin lograr el alcance, ni cerrar el proyecto. Tienes 3 días para presentar la propuesta… tic tac.. tic tac

Una dinámica/juego para enseñar Scrum - Revista Scrum

El pasado 20 de marzo de 2013 en la materia Gestión de Proyectos Informáticos la cual imparto para lacohorte 9 de laEspecialización y Maestría en Ingeniería de Software en la Universidad de Medellín (Medellín - Antioquia - Colombia) www.udem.edu.co ,  realizamos una simulación para aprender como funciona de Scrum.

Antes del Juego se realizó la presentación  SCRUM (ver diapositivas) en la cual se revisaron los conceptos principales y más importantes del marco de trabajo (framework) de SCRUM.


Los parámetros fueron los siguientes:

3 equipos de 6 personas, cada equipo provisto al menos de:

• Un Scrum Master (elegido por el equipo)
• Un Product Owner (elegido por el equipo)
• 3 Revistas de variedades
• 3 Tijeras
• Pegante
• 40 Hojas reciclables tamaño carta
• 2 tacos (bloques) de Pos-it/Sticky Notes/
• Lapiceros y marcadores

Objetivo:

• Construir una revista basada en recorte de imágenes y textos que estos sean pegados en las hojas reciclables tamaño carta. 

Requisitos:

• La revista debe contar con un índice de artículos y numeración para cada hoja.
• Todo a excepción del indice de artículos debe ser cortado y pegado

Para construir las hojas se emplearán fotos de diferente tipo y renglones de texto cortados en forma de rectángulo. Se emplearán los siguientes tipos de fotos

• A: Foto de una mujer
• B: Fotos de un carro
• C: Fotos de un hombre
• D: Foto de algo que sea diferente a A, B, C y D

 Las hojas de la revista pueden de las siguientes tipos:

• Hoja Tipo 1:  1 foto + 1 descripción
• Hoja Tipo 2:  2 fotos + 2 descripciones
• Hoja Tipo 3:  3 fotos
• Hoja Tipo 4:  5 fotos + 1 descripciones
• Hoja Tipo 5:  Menú
• Hoja Tipo 6:  2 fotos
• Hoja Tipo 7:  3 fotos + 3 descripciones

Fotografía 1

Por lo tanto si se me pide una Hoja Tipo 7 con fotos A, significa que la hoja debe contener:

• 3 fotos de mujeres recortadas
• 3 descripciones de texto recortadas

DETALLES DEL EJERCICIO

1. Se crearon los tres equipos
2. Se explicó la forma de armar la revista
3. Se creó un Product Backlog priorizado para cada equipo (Ver imagen en las columnas PB1, PB2, PB3)
4. Se definió un Sprint de 41 minutos con las siguientes características de tiempo:

• Plannig = 8 minutos
• Duración del dia 1= 7 minutos
• Reunión de daily 1 = 2 minutos
• Duración del día 2 = 7 minutos
• Reunión de daily 2 = 2 minutos                                    
• Duración del día 3 = 7 minutos                                   Fotografía 2
• Review = 4 minutos
• Retrospectiva 4 minutos

Al final del ejercicio se realizaron 3 sprints, para un total de 123 minutos. (2 horas de trabajo)

5. Se realizó una calificación (al inicio del juego) por puntos para cada "HOJA TIPO" en donde por votación por EL JUEGO DEL POKER (puntuando con 1, 2, 3, 5, 8,13 - y empleando cada integrante la aplicación para Android Scrum Poker para simular las cartas) se puntuaron cada de las hojas asi:

• Hoja Tipo 1:  3 puntos
• Hoja Tipo 2:  8 puntos
• Hoja Tipo 3:  5 puntos
• Hoja Tipo 4:  13 puntos
• Hoja Tipo 5:  3 puntos
• Hoja Tipo 6:  3 puntos
• Hoja Tipo 7:  13 puntos

Fotografía 3

6. A cada Scrum Master se le enfatizó las características de su rol.
7. A cada Product Owner se le enfatizó las características de su rol y la potestad de recibir o rechazar las Hojas con sus diferentes fotografías y descripciones (que vendrían a ser el símil de las historias de usuario), adicionalmente de hacer respetar la prioridad del product backlog
8. Se estableció el criterio de DONE como: "una hoja con todos sus elementos correctamente pegados"
9. Se insistió que el objeto del planning era:

• establecer el compromiso de puntos
• realizar el tasking plasmando la hoja (u símil de Historia de Usuario) de la siguiente manera :

   HISTORIA TIPO 4 = Foto1 + Foto2 + Foto3 + Foto4 + Descripción1 

(ver la Fotografía 1)

• Construir el Kanban de acuerdo al tasking y  poniendo en la parte superior la historia de mayor prioridad.
• Construir el Burndown chart

10. Se insistió que NO era un ejercicio donde se COMPETÍA por construir la mayor cantidad de Backlog, sino que tenía como objeto REALIZAR CORRECTAMENTE Y PASO A PASO LO FORMULADO POR EL FRAMEWORK DE SCRUM.

12. Se empoderó al equipo para que alguien dentro del mismo se encargara de actualizar la gráfica de BURNDOWN CHART con los puntos pendientes al final de cada día.

13. [esto se olvido, aunque se debió haber hecho] En el uso de Kanban se debe recordar quien va y toma una tarea del kanban (va y "merca" decimos donde trabajo) para ejecutarla debe firmala y pasarla WIP y luego a DONE cuando la termine.

Fotografía 4

Fotografía 5

Fotografía 6

RESULTADO FINAL DEL EJERCICIO

1. Se realizaron 3 Sprints para construir el Backlog.
2. Los equipos lograron con las retrospectivas corregir el proceso y ser más eficientes construyendo páginas y de esta manera aumentaban el compromiso durante los dos planes subsiguientes.
3. Durante el ejercicio se corrigieron aspectos como:

• la necesidad de hacer el daily de pie
• la actualización día a día del Burndown chart
• la actualización y paso de tareas en el kanban
• en el kanban en la columna del WIP (work in progress) solo puede existir una tarea por miembro del equipo.

4. Se hizo una retrospectiva del ejercicio por parte de los estudiantes diciendo que la compresión del framework aumento de forma considerable con el ejercicio.

-----

Este fué el ejercicio que se realizó, pienso seguir empleándolo en las capacitaciones que dicto y en los cursos que imparto.

Queda así a disposición de la comunidad ágil y si tienen retroalimentación será bienvenida.

Saludos

Jorge Abad