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 . Sin embargo, he oido recientemente en podcasts de scrummanager que no es camino fácil. Si se quiere obtener el CMMI sólo por la marca, se puede automatizar con scripts la generacion de la documentación necesaria mientras se sigue trabajando de un modo ágil.
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.

Productividad de los desarrolladores de software

Hola de nuevo.
Llevo tres posts en pocos dias. Estoy consiguiendo todo un record personal. 🙂

Hace un par de dias leí un post de Martin Fowler, gurú del desarrollo agil, sobre que es imposible medir la productividad de un desarrollador. La entradas son:
http://martinfowler.com/bliki/CannotMeasureProductivity.html
o en español
http://www.dosideas.com/liderazgo/439.html?joscclean=1&comment_id=687

Este post habla muy inteligentemente de los problemas que tiene los sitemas de medir la productividad:
Por lineas de codigo: Más lineas de código no significa un producto mejor o con más funcionalidades. En ocasiones incluso es lo contrario. Un par de lineas bien escritas puede ser un trabajo mucho más productivo que hacer copy-paste de varios proyectos a uno sin saber exactamente qué se está haciendo.
Por puntos de función: Un mayor numero de puntos de funcion no significa un incremento en lo que un desarrollo puede aportar al cliente o a la empresa, que es de lo que se trata cuando se quiere medir la productividad.

Entonces, ¿no se puede medir? Hace tiempo que veo de vez en cuando lo que las metodologias como Six Sigma o Lean quieren aportar al mundo del desarrollo. Estas se basan en sistemas de producción tradicionales y estudian el numero de outputs validos respecto a la entrada y numero de outputs no valido (errores). Si no se puede medir el desarrollo, ¿no se puede mejorar?

Realmente si que hay maneras de evaluar la productividad de un desarrollador, pero no son cuantificables de modo sencillo. Voy a comentar una:
En el equipo en el que trabajo hay varios desarrolladores de varia indole: ingenieros en informatica, ingenieros tecnicos y telecos. Cada uno aporta un lobulo de lo que sería el cerebro general que representa al equipo de desarrollo. Igual que ocurre en la serie House, cada integrante tiene una especialidad en la que aporta sus herramientas, pero además debe ser capaz de entender el problema que se le presenta y aportar soluciones racionales que lleven al objetivo final. Es importante la funcion de mentor y de aprendiz en todos y cada una de las materias que se tocan en el desarrollo. Cuando ocurre un problema en su area debe ser capaz de exprimir al maximo todas las posibilidades y pruebas antes de quedarse en blanco. Debe aportar sus conocimiento de testing unitario/refactorizacion/patrones de diseño/punteros/base de datos… ya sea en su propio desarrollo o colaborando en el desarrollo de otro.
Esto… dificil de evaluar cuantitativamente y por lo tanto mejorar. Pero quienes entamos en direccion de proyectos o de departamentos de desarrollo lo vemos dia a día. Quizá de aqui pronto salga un diagrama o tabla en la que poder hacerlo.
Espero vuestros comentarios.

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.

Analogias de Scrum y partida de Rol

Hace ya más de un año que llevo mirando temas de gestion de proyectos. Empecé mirando la certificación Six Sigma para la optimización de procesos pero decidí empezar a aprender qué se mueve en concreto en la gestion de proyectos software. Lo que he ido encontrando lo pondré en este blog en breve pero primero quiero poner unas analogias que se me ocurrieron entre la metodogia Scrum y lo que se mueve en un juego de rol.

Hay muchos que como yo, hemos pasado una parte de nuestra juventud jugando a juegos de rol. De algun modo el rol/comics/informatica esta raramente conectado. Bien, empecemos:

Scrum Team/ jugadores de rol

El scrum team es un grupo heterogeneo de especialistas que se compromenten en conseguir un objetivo en un tiempo dado (un sprint). Ese grupo puede estar compuesto por programadores/testeadores/expertos en BD,…

En el rol hay pocas cosas más heterogeneas que un grupo de rol (paladin, orcos con mala leche, elfos con más pluma que las de sus flechas,…). Ese grupo tiene una misión para hacer en un tiemplo dado (una partida).

Scrum Master/ Dungeon Master o Máster

El Scrum Master está a disposición del equipo. Les ayuda a elegir un grupo de tareas para completar en un sprint. Les ofrece toda la ayuda que está en su mano para que el equipo lo unico que tenga que hacer es centrarse en el objetivo. Es el interfaz entre el equipo y el resto de interesados en el proyecto y con la dirección.

El Dungeon Master les plantea el escenario a los jugadores y se preocupa en que el juego sea dinamico y que vayan avanzando en la misión con los personajes y situaciones que se inventa durante la misión. Normalmente es el que pone la casa, aporta las patatas fritas, hojas, lapices, refrescos ….

Daily Scrum/Turno

El Scrum Master se reune a primera hora de la mañana con el equipo y estos cuentan 3 cosas: qué han hecho desde la anterior reunion, qué haran hasta la proxima y qué dificultades tiene para  realizar ese trabajo.

En cada turno el master pregunta a cada uno de los jugadores qué va a hacer en ese turno y le cuenta las consecuencias de su elección hasta el siguiente turno.

Gestion de proyectos/Llevar una partida de rol

Scrum: Se debe conocer muchas metodologias y herramientas pero sólo usarlas si ayudan a realizar mejor su trabajo, que es el objetivo de esa misión. No intenta preveer al detalle todo el trabajo a realizar y realizar un analisis exaustivo sino saber responder rapidamente a las necesidades del equipo y ayudarles a orientarse.

Rol: El master conoce las normal del juego en cuestion pero las ignora cuando molestan. Si estan en plena batalla no se pone a hacer tiradas de probabilidades de que les salga un erpes labial aunque en el libro ponga que el contacto tiene 2/100 de que se les contagie. Esto puede afectar al objetivo principal de cualquier juego de rol (pasarlo bien). No tiene un mapa detallado de todos los puntos por los que pasaran con todos los PNJ y sus personalidades sino que se va inventando lo necesario y moviendo de sirio los lugares que ha ideado.

Si a alguien se le ocurren más analogias que me las comente y las voy añadiendo a la entrada.

Framework para objetos Mock propuesto

Ahora estamos peleando con Unit Testing y claro, a no ser que tu codigo solo calcule series fiabonacci o algoritmos de ordenación, existe una serie de elementos externos como bases de datos, hardware especializado, uso de ficheros y del sistema operativo. Para aislar el codigo a probar de esta serie de elementos se usa los objetos Mock.

Un objeto Mock es un objeto que es llamado por el codigo a probar y que permite especificar su comportamiento al detalle para forzar todas las situaciones posibles. El codigo a testear no debe tener logica que sea distinta segun sea en situacion de testeo o en produccion. Despues de darle muchas vueltas y un par de intentos fallidos se ha llegado a este framework. Esta diseñado en C++ que es el lenguaje que uso más que el castellano.

Se creará una clase abstracta que tendrá todos los metodos necesarios para simular la clase. De esta clase heredaran una clase que será la que realmente haga el trabajo en situacion real y otra clase que será la Mock.

Se pueden definir estas clases para simular DLL’s, acceso a bases de datos, acceso a ficheros, llamadas al api de windows (GetProfileInt, MessageBox, Sleep,…), tambien se puede crear una clase para las peticiones de datos con dialogos al usuario.

Ejemplo: Clase que simula al API de Windows

// Clase abstracta
class CWinApiBaseClass {
CWinApiBaseClass();
virtual CWinApiBaseClass();
virtual int MessageBox(HWND ventanaPadre,LPCTSTR mensaje,LPCTSTR title,int flags)=0;

}

//Clase real (wrapper sobre el codigo llamado)
class CWinApiWrapper:public CWinApiBaseClass {
CWinApiWrapper ();
virtual CWinApiWrapper ();
virtual int MessageBox(HWND ventanaPadre,LPCTSTR mensaje,LPCTSTR title,int flags);

}

int CWinApiWrapper::MessageBox(HWND ventanaPadre,LPCTSTR mensaje,LPCTSTR title,int flags){
return ::MessageBox(ventanaPadre,mensaje,title,flags);
}

//Clase mock
#define WinApiMock_MaxCalls 100 // Permite definir el maximo de los arrays de datos
class CWinApiMock:public CWinApiBaseClass {
CWinApiMock();
virtual CWinApiMock();
virtual int MessageBox(HWND ventanaPadre,LPCTSTR mensaje,LPCTSTR title,int flags);

//Para MessageBox
unsigned int m_nCallsMessageBox; // Permite saber si se ha llamado o no a la funcion
HWND m_ListMessageBoxHWND[WinApiMock_MaxCalls];
CString m_ListMessageBoxMessage[WinApiMock_MaxCalls];
CString m_ListMessageBoxTitle[WinApiMock_MaxCalls];
int m_ListMessageBoxFlags[WinApiMock_MaxCalls];
int m_ListMessageBoxRetValue[WinApiMock_MaxCalls]; //Permite indicarle qué va a retornar

}

CWinApiWrapper::CWinApiWrapper(){
// Se inicializa los contadores a 0 y todos los arrays que lo necesiten a 0 con ZeroMemory
}

int CWinApiWrapper::MessageBox(HWND ventanaPadre,LPCTSTR mensaje,LPCTSTR title,int flags){
m_nCallsMessageBox++;
m_ListMessageBoxHWND[m_nCallsMessageBox]=ventanaPadre;
m_ListMessageBoxMessage[m_nCallsMessageBox]=mensaje;
m_ListMessageBoxTitle[m_nCallsMessageBox]=title;
m_ListMessageBoxFlags[m_nCallsMessageBox=flags];
return m_ListMessageBoxRetValue[m_nCallsMessageBox];
}

Es importante tambien definir una variable global por cada clase que contenga el objeto wrapper real. Este objeto se usará para iniciar por defecto todos los usos al uso el produccion.

// En el WinApiBaseClass.h
#ifndef CWINAPIMOCK_CPP
#define CWINAPIMOCK_CPP
extern CWinApiWrapper glWinApiWrapper;
#endif

// En el WinApiBaseClass.cpp
CWinApiWrapper glWinApiWrapper;

// En el .h la clase a testear
protected:
CWinApiBaseClass *m_winapi;

//En el constructor de la clase a testear se inicia el puntero
CClaseATestear::CClaseATestear(){
m_winapi=&glWinApiWrapper;
}

//Cada vez que el codigo llame a MessageBox se usa el puntero a la clase abstracta, iniciada por defeco a la
// real para que no haya problemas en produccion

int ret=m_winapi->MessageBox(GetSafeHwnd(),_T(“¿Quiere continuar?”),_T(“Mi aplicacion”),MB_YESNO);

//Cuando se testea el codigo hay que cambiarle el puntero para que apunte al objeto mock

CTestClaseATestear::TestFuncionATestear(){
CWinApiMock mock;
CClaseATestear miClase;

miClase.m_winapi=&mock;
mock.ListMessageBoxRetValue[0]=IDYES; //Forzamos el retorno del messagebox
CPPUNIT_ASSERT(miCLase.FuncionATestear());
CPPUNIT_ASSERT(mock.m_nCallsMessageBox==1); // Comprobamos que realmente se ha llamado
}

Y esto es todo. Espero vuestros comentarios

Six sigma o Seis sigma. Primera entrada

Hasta hace poco menos de un mes no tenia ni idea de qué era esto. Unos amigos que trabajan en Amsterdam me lo comentaron como lo mas normal del mundo pero parece que eso para España no se ha estrenado mucho.

Segun la wikipedia es una metodologia de gestión de proyectos en la que se analizan los procesos de produccion de modo estadistico para optimizarlos eliminando las causas de los problemas y mejorando la calidad.
http://es.wikipedia.org/wiki/Six_Sigma
http://en.wikipedia.org/wiki/Six_Sigma

Fue inventado por Motorola y es usado por muchas compañias en todo el mundo. Habla de procesos de producción en general pero para mi como jefe de proyecto me interesa el cómo aprovecharlo en el desarrollo de software. Hay webs que indican claramente que no soy el unico que cree que se puede aprovechar para el software.
http://software.isixsigma.com/

Establece unos niveles de conocimiento y responsabilidades a la hora de usar la metodologia. Esos niveles se establecen como cinturones en las artes marciales. El cinturon amarillo lo deben tener los operarios/programadores que usan six-sigma en su trabajo. La persona que los coordina debe tener el cinturon verde. Despues estan los cinturones negro, masters , campeones y Liderazgo Ejecutivo que ya es el CEO de la empresa. Para tener los cinturones hay que hacer examenes certificados como por ejemplo esta web http://www.sixsigmaonline.org/ donde se puede conseguir online pero aun me queda comprobar si realmente su certificacion es oficial. Lo normal es hacer un curso presencial pero en España no he visto que den ninguno.

Yo voy a ver de sacar el cinturon verde e intentar aplicarlo en el trabajo de jefe de proyecto. Todo lo que vaya descubriendo lo intentare añadir a este blog.

Personas autistas como perfecto tecnico de test

Hace ya unas semanas leí en el diario “El Mundo” que una compañia de software danesa estaba triunfando en todo el mundo. Su “secreto”, tener el 75% de sus empleados eran personas autistas. La compañía en especial se dedicaba al outsorcing del testing, es decir, en ser subcontratadas por empresas de software para que su producto tuviera calidad. Por más que lo he conseguido no he conseguido encontrar una referencia online en español para indexarla aqui. La empresa en cuestion es Specialisterne. Segun el presidente, que tiene un hijo autista, las cualidades que debe tener un perfecto tester son las que tiene un autista, al menos con alguno de los tipos de autismo: memoria fotografica, ejecucion mecanica de una serie de pasos y responder ante los minimos cambios en una rutina programada.

Esta noticia me gustó primero porque soy desarrollador de software y despues por el lado humano porque confirma que todos nosotros podemos ser utiles, seamos como seamos.

Noticia en ComputerWeekly

Web de la empresa