CMMI + PMI + Agile + Scrum ¿Utopia?

Llegado a este punto algunos lectores podran preguntar ¿quien es este tio que habla de agil y scrum? Realmente no me considero un experto en este tema sino todo lo contrario. Voy aprendiendo día a días las bondades de todo lo que puede aportar las metodologias agiles. Hace ya más de un año que me decidí investigar lo máximo posible todas las herramientas que se puedan usar para la gestion de proyectos. Empecé mirando el tema de la certificación PMP del PMI. Para esto se necesitan unos cuantos años demostrables de experiencia como Project Manager así como un numeros de creditos en cursos y un examen. Tambien miré el tema de certificar los procesos con CMMI. Un compañero de donde trabajo estuvo involucrado en una metodologia CMMI Nivel 5. Meternos en eso parecía un camino imposible. Despues apareción Scrum y las metodologias agiles. Se basaban en asumir que las tecnologias con las que se va a hacer un desarrollo pueden no ser conocidas y algo que se estima en 3 dias puede llevar 30 (al fin alguien que nos entendía).
Sin embargo siempre he visto esos mundos como opuestos. PMI certificando a jefes de proyecto en unas metodologias concretas y lineales, CMMI como certificadora de procesos y por otro lado, la propuesta agil que es vista por muchos como desarrollo sin control. Sin embargo todos estan confluyendo para dar cabida a proyectos cada vez más complejos, con tecnologias emergentes de las cuales los clientes cada vez entienden menos por lo que sus requerimientos son menos concretos.
Por un lado CMMI y Scrum estan conviviendo perfectamente. Los propios del SEI en este documento afirman que el CMMI sólo indica los requerimientos de un proceso sin embargo las metodologias agiles indican en cómo se puede cumplir esos requerimientos. De hecho existen pruebas de empresas que cumplen el CMMI Nivel 5, ¡sí, el nivel 5! usando Scrum
PMI y Agil estan tambien haciendose amigos. Se acaba de abrir una comunidad del PMI en la que se abarca todo lo relacionado con las metodogias agiles. ¿Estamos viendo el principio de una bonita amistad?
Objetivo que me planteo a ver cómo va: Scrum -> CMMI Nivel 2 -> PMP ¿Será posible? parece facil alcanzar el CMMI nivel 2 usando metodologias agiles pero.. ¿podré tener experiencia demostrable suficiente para el PMP dentro de unos años?
Ya iremos viendo. Mientras, sigo aprendiendo y compartiendo…
Un saludo a todos

Management rewired para PMs o Scrum Masters

Hola

Por fín terminé el libro “Management Rewired” de Charles S. Jacobs. Es un libro que recomendaban para los jefes de proyecto y esa recomendación no estaba nada mal encaminada.

El libro trata de cómo los avances en neurologia y los escaneres de actividad cerebral pueden dar explicaciones a cómo funciona el mundo dentro de las empresas. Todos nos guiamos por estímulos externos que intepretamos internamente según nuestro estado de animo o historias anteriores que hayamos pasado. Lo que puede parecer un regalo para unos, para otros puede parecer una patada en el culo. Además no se queda sólo diciendo lo que no funciona sino que acaba cada capitulo dando un recetario de cómo se debería hacer las cosas para usar este conocimiento a nuestro favor.

Un hallazgo muy importante es que el feedback, tanto positivo o negativo no funciona. El dar una recompensa por un buen trabajo o una critica casi nunca dan el resultado esperado. En lugar de esto recomienda hacer que sea la propia persona la que tenga datos objetivos suficientes para saber si lo está haciendo bien o mal. Esto coincide con lo que promulga la metodologia agil y el scrum en concreto. Dejar que el equipo sea autogestionado y darle toda la información necesaria para ello.

La organizacion también es un punto importante del que hace mención. Dice una cosa muy curiosa que es la lucha interna que existe en nosotros y nuestra vida en la empresa ya que segun los genes que tenemos de nuestros antepasados los hominidos, luchamos individualmente por llegar a ser el macho alfa (el jefe supremo), sin embargo, necesitamos trabajar en grupos para conseguir objetivos mayores que los que puede conseguir uno mismo. Recomienda el organizarse en pequeños grupos “autonomos” para que se pueda combinar la fuerza de ambas fuerzas. Coincide con cómo funciona el scrum, organizando en grupos de 7 personas más o menos.

Según el autor, el tipo de lider que hace falta para obtener el mejor resultado no es uno que ordene sino uno que pregunte. Una pregunta concreta puede mover a una persona con mucha mas motivacion y resultado que cualquier orden. Coincide con el scrum con el hecho de que cada día se hacen las preguntas del daily scrum (qué has hecho, qué vas a hacer y qué necesitas para hacer tu trabajo).

En fin. Es un libro que ha superado mis espectativas y contiene un conocimiento que no hay que dejar escapar

Nuevos roles en proyectos software

Ultimamente he podido identificar dos roles que son importates para la realizacion exitosa de los proyectos software. Voy a usar la analogia del rugby igual que se hace con el scrum.

Entrenador: Aunque se puede confundir por el scrum master, tiene un papel distinto. Hay proyectos, sobre todo cuando es trabajar sobre una aplicacion ya existente, que necesitan un conocimiento profundo de su arquitectura. Ese conocimiento puede tenerlo una persona que no está dentro del equipo de desarrollo. Esto ocurre por ejemplo en empresas de software en las que empezaron pocos programadores y esos programadores pasan a llevar cargos de gestión cuando la empresa crece.
El entrenador participa en las estimaciones como uno más del equipo. Cuando se usa poker planning, el entrenador tiene una baraja ya que su opinion sobre lo facil o dificil de una tarea en particular es muy importante. Si hay discrepancia entre el equipo y el entrenador se puede optar por la mayor de las estimaciones o la del equipo, que es realmente quien se compromete en esa estimación.
El entrenador participa en los daily scrum. Si hay algo de lo que ha hecho el equipo que puede dar problemas el entrenador lo detectaria en ese momento y actuaría sin tener que esperar a estar en las fases finales para descubrir ese problema.
Puede participar como pair programmer cuando se necesite, sobre todo cuando los deadlines son ajustados y se va con retraso.

Defensa: Esto más que un rol continuo es un rol que cada miembro del equipo puede ir asumiendo una o varias veces durante un sprint. En rugby el defensa va protegiendo a quien tiene el balón para que vaya lo más rapido posible. En un proyecto software el defensa va asumiendo las tareas de mantenimiento urgente que puedan venir de incidencias de cliente.
Hay momentos en el proyecto en el que todos los miembros del equipo no pueden trabajar a la vez directamente en el mismo codigo fuente. Cuando esto ocurre esos programadores actuan de defensa. Evitan que los que sí que estan trabajando directamente en el proyecto no tengan que dedicarse a otro desarrollo urgente.

Poker Planning o juguemos a estimar proyectos

Hace poco un compañero me pasó un link. Hablaba de un tipo de planificación usada en desarrollo agil. Acabo de encontrar el link de una pagina que habla solo de eso. La pongo para quien quiera profundizar pero voy a comentar como la realicé yo.

http://www.planningpoker.com/

El tema es sencillo. Se hacen unas tarjetas como cartas en las que ponga los numeros de la serie de Fiabonacci. 1-2-3-5-8-13-21 . Estos numeros es porque la imprecision va aumentando segun el tiempo de estimacion aumenta. Tambien se añade una carta que ponga NPI. NPI significa (no literalmente) que no se tiene suficiente informacion en ese momento para realizar una estimación concreta. El significado literal ya lo sabreis.

De esas cartas se hace un mazo por compontente del grupo de desarrollo. Yo actué como Scrum Master y no debia hacer estimaciones. Los que van a trabajar directamente en el proyecto son los que deben comprometerse con una estimacion.

Se va tarea por tarea haciendo una estimacion que debe ser consensuada entre todos los miembros del equipo de desarrollo. El procedimiento es el siguiente: cada uno pone una carta boca abajo con su estimacion. Todos le dan la vuelta y se busca el menor y mayor valor. Esos quien han hecho las estimaciones extremas deben explicar al resto el por qué piensan en ese valor. Despues de aclarar los puntos de vista se hace otra tirada y se repite el proceso hasta que se llega a un consenso (todos con el mismo valor)

Ventajas de este sistema:
- Toda la estimacion proviene del equipo que se compromete en ella
- Todos acaban entendiendo los pormenores de cada tarea.
- Se sacan a la luz codigos de ejemplo/ideas ya existentes que ayudaran a desarrollar más rapido.

Es importante tener toda la informacion posible para la estimacion. Un caso que ocurrió es que uno de los miembros hizo una estimacion alta. No sabia que uno de los compañeros de otra oficina tenia un codigo de ejemplo. Como no estabamos seguros de si el codigo era realmente tan iluminador como esperabamos el resto llamamos por telefono en ese momento al desarrollador de la otra oficina. Su llamada confirmo que aunque existia el ejemplo, era un codigo antiguo y no usado por lo que podia tener problemas.

Es importante hacer iguales todas las tarjetas. La ventaja de tirar todas las cartas boca abajo hace que todos pongan su punto de vista sin fijarse en algun desarrollador mas experimentado pero que quiza no tiene toda la informacion sobre la tarea en cuestion.Cuando yo lo hice, algunos se fijaban en el tamaño de las tarjetas del resto para adivinar cual era su estimacion.

Ventajas inesperadas:
- Más cohesion en el grupo. El compartir todos los puntos de vista hace que empiecen a trabajar más como equipo que como conjunto de individuos.
- No deja de ser un modo divertido de hacer estimaciones. Se empieza el proyecto con buen humor.
- Se trabaja de modo más comprometido ya que todos y cada uno han apoyado la estimacion. No se la han impuesto.

Ha sido una gran experiencia y se la aconsejo a todos los jefes de proyecto/Scrum Masters/jefes de desarrollo etc. Normalmente se ve asociado a desarrollo agil pero no es necesario que el proyecto sea agil sino que se puede hacer con proyectos con metodologia más lineal.

Espero vuestros comentarios.