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

Masoca's tools

Así llamabamos a los juegos y aplicaciones que instalabamos hace 15 años con una pila de 20 discos de 3 1/2. Eran epocas gloriosas. Para hacer funcionar un juego (backup o con los discos originales) teniamos que trastear el autoexec.bat para cargar unas cosas sí y otras no. Todo esto para liberar las 640 K de memoria base y el juego arrancara.

Aplicaciones como el ‘a.exe’ que le autocompletaban directorios cuando cambiabas usandolo en lugar del ‘cd’, comprimiendo y descomprimiendo con el pkunzip, arj,  formateando los discos con el 2MF para lograr que los discos de 1,4 se conviertieran en 2MB, … Habia que complicarse para lograr pequeños hacks que ibamos necesitando para el dia a dia.

Ahora la administracion de los PCs se ha vuelto mucho más intuitiva, con el boton derecho del raton tienes acceso a todas las opciones que te brinda el sistema operativo, en Internet tienes informacion de cómo mejorar tu sistema operativo hasta hacerlo tan rapido como si tuviera la version anterior del mismo 😉  Sin embargo en cuestiones de administracion uno se vuelve muy perezoso. Puedo aguantar meses y meses pulsando una tecla al arranque para que no me analice mi C: porque tarda la vida, el escritorio se me va llenando de iconos, tengo el mismo wallpaper desde hace más de 2 años,…

Sin embargo en cuestion de programación aun tengo esa costumbre de intentar saber bien que hace exactamente el código que escribo. Desde hace más de 5 años programo en C++ con Visual Studio 6. Me manejo con mucha soltura con MFC, que es una pesadilla para los programadores de Visual Basic pero para los que sabemos que habria que hacer para programar lo mismo con el API de Win32 es una maravilla. Pero el tiempo avanza…

Llegan nuevas tecnologias y APIs de programacion: Windows Presentation Fundation, Windows Communication Fundation, las clases ya trabajadas que se usan en .NET,.. Todo un mundo de tecnologias ya hechas que, aunque quiera resistirme (que no es el caso), noto que necesito aprender y adaptarme. Donde trabajo tenemos mucho, mucho codigo en proyectos como he comentado (C++ con MFC). Hemos decidido dar el gran paso, pero darlo como Dios manda. Cuando empezamos no sabiamos de .NET, de patrones Modelo-Vista-Controlador (MVC) y practicamente nada de Unit Testing. ¿Que hacer para arreglarlo? Hacerlo todo a la vez mientra migramos a Visual Studio 2008.

En este blog voy a intentar ir publicando las cosas que vamos descubriendo que espero que le sirva a otros programadores, tan “masocas” como yo que prefieren seguir usando C++ con toda la parafernalia de nuevas tecnologias que nos llegan.

Empezamos el viaje…

Windows CardSpace, breve descripción y comentarios

Como se habrá visto en mi anterior post de programación, estoy haciendo el curso de desarrollador 5 estrellas de microsoft (www.dce2005.com). El primer curso de la cuarta estrella trata de Windows CardSpace. Esto es una idea de Microsoft para intentar reducir el problema de phising (peticion de password al usuario creando una web haciendose pasar por la original).

El uso de password lo sustituye por tarjetas de identificacion que se almacenan en el ordenador del usuario. Estas tarjetas no contienen informacion del usuario sino que se usan para pedir esa informacion de modo cifrado a una tercera entidad llamada proveedor de identidad (identity provider). Esta entidad le devuelve el grupo de informacion en un token al usuario que a la vez lo envia a la web para identificarse. El token esta formado por una serie de claims que cada uno es un dato, puede ser usuario, dirección, … De estos datos la web coge los que necesita para identificar al usuario.

De aqui surgen varios inconvenientes.

Primero que la informacion se almacena en el ordenador del usuario y necesita exportarlo por ejemplo a un USB e instalarlo en el ordenador que vaya a usarlas, por ejemplo un Cybercafe. Microsoft entiende que esto es un problema e informa que en la proxima version se podrá usar directamente del USB sin instalarla. Esto sí es una buena idea ya que igual que tus llaves de casa puedes llevar encima tus tarjetas de identidad para usar en distintas webs.
Segundo que tampoco eliminan el problema del phising al completo, ya que una persona maliciosa podria crear una web falsa que solicitara el token del usuario. Es el usuario es que debe distinguir la web original de la copia y no aceptar a entregarle la informacion si no es de su confianza. Si el usuario es un poco avispado puede darse cuenta que si ya ha entrado en esa web anteriormente no deberia pedirle el sistema confirmacion para entregar la informacion ya que se hace de forma automatica. Microsoft informa que para evitar esto se esta estudiando el certificar las imagenes de la web (logos) para que el usuario confirme que realmente son de la web que espera. Aqui mi pregunta es: ¿por que no se hace eso directamente con el sistema de password actual?

Me parece que es un buen intento pero no soluciona nada y complica demasiado el sistema de autentificación sobre todo para el desarrollador de la web. Para el usuario se le presenta un sistema muy intuitivo y bonito con tarjetas e imagenes pero aun tiene un par de flecos por mejorar.

Espero vuestros comentarios y correcciones.

Enlaces:

White paper de Microsoft. http://msdn2.microsoft.com/en-us/library/aa480189.aspx
Un pdf de cómo implementarlo (hands on labs) http://www-sor.inria.fr/~galland/papers/HOL07techdays.pdf