Reflexiones sobre la planeación

• Planear no garantiza que las cosas no salgan mal, pero NO-PLANEAR, sí. (Similar al pensamiento: PENSAR es gratis, pero no pensar puede salir muy caro)

• Los planes deben trabajar para el proyecto, no  el gerente de proyecto para los planes. 

• Hacer los planes necesarios y suficientes para que tu proyecto este controlado, revisa de los siguientes planes cuales realizar:
• alcance
• tiempo 
• costo
• recursos humanos
• calidad
• comunicaciones
• riesgos
• adquisiciones  
• (es decir, identificar si requieres cubrir las áreas de conocimiento del pmbok, o más, o menos necesidades en tu proyecto).

Recomendaciones sobre el sobre-esfuerzo del equipo en un proyecto

Si por alguna circunstancia el equipo se debe sobre-esforzar, trabajar horas extras, trabajar de más, etc (ojalá esto no sucediera, pero pasa), ya sea por:

• Mala planeación
• Premura del proyecto por algún requisito del cliente, externo o interno.
• Imprevistos
• etc

considere las siguientes sugerencias para el equipo o miembro del equipo:

• Sea humano...
• Por lo general aplazar el almuerzo no genera valor. Permita que su equipo o miembro del equipo almuerce con tranquilidad y calma, de forma que regrese de nuevo a las labores críticas que tiene encomendadas.
• No permitir que se trabaje de forma sobre-esforzada por más de dos semanas pues al final, aunque su equipo sea comprometido, después el agotamiento se volverá en su contra impidiendo concentración, y éxito en las tareas encomendadas. Descanse una semana (horario normal) y retome el sobre-esfuerzo en caso de ser necesario.
• Cuando comprometas un sobre-esfuerzo que sea hasta un máximo de horas adicionales, ejemplo: 2 horas más, 3 horas más al día, durante un periodo, pero:
• Que se descanse los domingos
• Y si se se trasnocha que sea una sola noche. dos seguidas o más veces seguidas el agotamiento se vendrá en contra del equipo y el rendimiento bajará.
• Acompañe a su equipo no lo deje solo sobre-esforzándose. En caso de no poder estar presente, esté disponible para resolver cualquier inquietud.
• Si alguien del equipo durante el sobre-esfuerzo requiere un permiso, concédalo, no tiene sentido que el sacrifique su tiempo pero cuando se le pida un permiso usted no lo autorice.
• Mantenga esta regla: PRIMERO LAS PERSONAS QUE EL PROYECTO. Si pasa algo grave, o alguien se enferma, etc, primero es la persona que el proyecto, no sea inhumano con su equipo.

Dice Sun Tzu en el arte de la guerra:

"Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho:"Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces,aunque tengas consejeros sabios,al final no podrás hacer que las cosas salgan bien."

Mi experiencia con SCRUM

Hay que reconocer que el desarrollo iterativo no fue inventado por la metodologías ágiles pero si fue reforzado por ellas.

Esta es la historia...

Antecedentes

Hace tres meses (hoy es 29 de septiembre de 2012) vengo liderando un proyecto móvil con las siguientes características:

• Dispositivo IPADs, (aunque se quiere que tambien funcione en web)
• PhoneGap como framework de implementación de la interfaz gráfica
• Arquitectura: SOA - Consulta a la capa de datos a través de mediaciones sobre Websphere ESB
• Motor de reglas de negocio: DROOLS.
• Duración del proyecto: 8 meses aproximadamente
• Fecha de inicio: Mayo de 2012
• Ciclo de vida cascada
• Reporte en Project Server
• Horas de equipo de 5 personas con 45 horas diarias laborales de trabajo.

Cuando recibí  el proyecto ya se encontraba 2 meses avanzado y el entregable para pruebas del cliente era para mediados de noviembre. Por lo tanto solo hasta 3 semanas antes de esa DEADLINE (nombre muy bien puesto.. si seguiamos asi.. sería la muerte) podría hacer clic en el sistema.

Nudo

Decidí implementar todo lo que había leído y recopilado de SCRUM (ver diapositivas) y defendido en las cursos de gerencia de proyectos informáticos que dicto en el un pregrado (Ingeniería de sistemas - Universidad Eafit - Medellín) y un posgrado (Especialización en Ingeniería de Software - Universidad de Medellin)

Elementos adoptados de SCRUM:

• Product Backlog
• Sprint Backlog  (reporte de avance en google docs)
• 3 Sprints de 1 mes (concertado con el equipo)
• Burndown Chart (reporte de avance en google docs)
• Velocidad  (reporte de avance en google docs)
• Standup meeting 
• Sprint review
• Sprint retrospective

No se adoptaron:

• Un el backlog de tareas sin dueño y cada cual va y "selecciona" la tarea que quiere.
• El cliente inmerso en el equipo
• Escritura de historias de usuario.

Se conservó:

• Artefactos requeridos por la metodología de la empresa:
• Casos de uso
• Documento de arquitectura
• Casos de prueba
• Manual de instalación y despliegue
• Manual de usuario
• Prototipo navegable
• Gestión de proyectos basada en el PMBoK

Y se tenían los siguientes problemas

• El único que conocía el avance era el gerente de proyecto
• Los ingenieros tenía un listado de tareas que realizaban según disponibilidad de los insumos sin un objetivo común
• Los ingenieros percibían que no iban a alcanzar a realizar la entrega pero no lo habian comunicado.

Desenlace
Luego de implantar Scrum estas son algunas de las conclusiones.

• El seguimiento es propiedad del equipo, no solo del gerente del proyecto. Siendo el burndown chart una propiedad del equipo y un compromiso de todos tenerla actualizada.(a todos nos da felicidad de la gráfica baje!!!)
• Las reuniones de seguimiento diario han mejorado comunicación y dinámica del equipo (más detalle acá)
• Se resolvieron problemas de salida a pruebas mucho tiempo antes de enfrentarnos con ellos en 
• El cliente tiene un lugar donde hacer  "clic" y percibir el avance.
• El equipo se encuentra altamente motivado.
• Mitigación temprana de riesgos de desarrollo, y pruebas.
• Equipo enfocado en un objetivo común: EL SPRINT!!.
• Obtencion de una velocidad del equipo que permite predecir entregas (de 25 a 33 horas por día - similar a lo que dice PSP, que solo es efectiva la mitad de nuestro tiempo laboral).
• Menos presión sobre el cronograma
• Un enfoque a los objetivos

Burndown Chart - Iteración 1

Velocidad - Iteración 1

Standup meeting - ventajas y observaciones

Responder siempre:

• qué se hizo ayer
• qué se va a hacer hoy
• existe algún impedimento
• [adición 2013-01-24] (una buena cuarta pregunta) que nivel de confianza tiene de que vamos alcanzar el objetivo.
• [adición 2013-01-24] (otras dos preguntas) 
• ------ que aprendí
• ------ que me tiene inconforme y que me molesta

Consejos

• enfocarse en responder las tres preguntas
• no extenderse en explicaciones que no corresponden al contexto
• mantener el foco 
• SE PUEDE HACER SENTADO..  :) [corrección 2013-01-27] Aunque se puede hacer sentado, definitivamente estar de pie hace que no divaguemos tanto, y contestemos rápidamente las tres preguntas. 
• Se puede llevar una lista (hoja de cálculo de google docs, excel publico) donde todos observen que se va  haciendo
• lo que se respondió ayer en " qué se va a hacer hoy" para una persona sirve para iniciar la lista de " qué se hizo ayer" de una persona
• Controlar el tiempo
• No es una reunión para reportar tiempos.. existen otros espacios para eso

Ventajas

• todo el equipo mantiene el contexto
• el equipo sabe que están haciendo sus miembros y buscan como ayudar y hacer más eficiente el día.
• Se identifica en equipo el foco del día.

Si la entrega esta enredada - planear al detalle

Llevas tratando de entregar el proyecto hace un buen tiempo y siempre incumples la fecha de entrega.

Realiza:

• un plan detallado con tu equipo de trabajo
• identifica todas las dependencias externas e internas
• plásmalas en el cronograma
• identifica riesgos y priorizalos de forma que no hayan más sorpresas.
• no presiones a tu equipo para que te dé fechas irreales

Equilibrio en en el seguimiento

No realizar micro-seguimiento

y cada semana es demasiado lejos

Lograr un equilibrio 

Proporcionalidad entre la Presión y Estimados Irreales

A mayor presión sobre el equipo de trabajo en realizar estimados se logrará un estimado más irrealista.

El equipo se comprometerá con fechas no factibles para satisfacer los compromisos irreales.


Conclusiones:

• No presione por tiempos y compromisos irrealistas. 
• Respete los tiempos que dice el equipo y logre un compromiso sobre ese tiempo de proyecto
• Defienda el tiempo proporcionado por el equipo ante las diferentes instancias

__