Archivo de la categoría: Project Management

Las palabras del Daily Standup se las lleva el aire

Esto fue lo que había estado observando en un par de Dailyes. Un desarrollador podía decir a sus compañeros con pleno convencimiento: “Hoy voy a reticular los splines y fluzear los vértices del condensador” y al día siguiente decir que en el día anterior había hecho cualquier otra cosa sin inmutarse lo más mínimo. Lo más normal es que ni uno mismo se acuerde de cuales eran los objetivos que se había marcado el día anterior. ¡¡ Y mucho peor !!! Podía haber fallado completamente en cumplirlos por causas ajenas a su voluntad sin ni siquiera darse cuenta ni saber sus causas.

Otra cosa que había observado es que a veces se llega a los Dailyes sin tener claro cuáles van a ser los objetivos para ese día. Frases como “En cuanto termine esto ya veré con qué me pongo” o “Ahora miro el Kanban a ver que será lo siguiente”. En VSN hacemos los Daily standup a las 10 de la mañana, lo suficientemente pronto como para que sea el disparo de salida del día y lo suficientemente tarde como para que todo el mundo tenga claro ya en qué va a trabajar. El problema de no tener totalmente claros los objetivos para el día puede hacer que se acabe trabajando en las cosas urgentes y poco importantes que siempre surgen. Lo importante y no urgente se acaba retrasando hasta que es demasiado tarde. Además esto provoca que se acabe el día con la sensación de que aunque no se ha parado ni un momento,  no se ha hecho nada útil.

Eisenhower Matrix
http://www.gsdfaster.com/blog/wp-content/uploads/2015/02/eisenhower-matrix.jpg

Para evitar estos problemas, hemos llevado a cabo un experimento que por el momento está saliendo muy bien. Para el Daily todos llevan preparada un pequeña hoja (10cmx10cm) con la fecha y su objetivo (o máximo 2) para el día.  Usando estas pequeñas hojas leemos  lo que nos pusimos como objetivo el día anterior, si lo hemos cumplimos o no (y por qué) , cuál o cuales van a ser los objetivos para el día y qué bloqueos pueden ocurrir o qué necesidades vamos a tener para cumplirlos. Los Dailyes son ahora más productivos porque no se divaga con cosas que no tienen que ver con esos objetivos principales. Reuniones, tests, atenciones a soporte dejan de ser centro de conversación a no ser que hayan sido la razón para no cumplir lo importante.

TarjetaObjetivos

En el resto del día esa pequeña hoja encima de la mesa recuerda a qué se debe aferrarse. Conseguir este objetivo con la ayuda de herramientas como la técnica Pomodoro, reduciendo interrupciones, revisando el correo a horas fijas, gestionando correctamente las reuniones y automatizando lo automatizable… es otra historia.

 

Sentándose un día con un desarrollador

En Lean cuando hablamos de Gemba, significa que los que están a cargo de un equipo o una empresa se paseen o estén donde realmente ocurre la acción. En las plantas de producción tradicionales estos lugares son los pasillos donde se elabora el producto. En desarrollo de software el Gemba sólo se puede realizar sentándose con el propio desarrollador.

Sin embargo, lo normal es que cuando un líder, jefe o responsable se acerca para ver cómo está trabajando el desarrollador, éste se ponga en modo inspección y empiece a explicar qué está haciendo y cómo lo lleva. Lo que ocurre en ese momento es el Principio de Incertidumbre, lo que se quiere estudiar cambia su comportamiento solamente por observarlo. También es normal que el líder, después de esta más o menos breve explicación se levante y vuelva a su puesto dejando que el desarrollador continúe para no interrumpirle más.

¿Es esto suficiente? ¿Se pueden saber así los problemas reales con los que se enfrenta y ayudarle a realizar mejor su trabajo? Mi respuesta es que no. Para hacer un autentico Gemba hace falta que el desarrollador trabaje como si no estuvieramos ahí. Para ello tenemos que ponernos en pair programming y sentarnos al menos un día completo con él para que “se olvide de las cámaras”.  Trabajando juntos de este modo empezaremos a conocer sus problemas con el  framework, la arquitectura, lo que le cuesta un cambio de requerimientos, de datos de entrada, etc … . También en esas condiciones son en las  que podemos hacer coaching y enseñarle cómo organizar mejor el código, mejorar en TDD para desarrollar con mejor calidad y ayudarle a ser más productivo y ágil.

¿Cuánto tiempo hace que no te sientas un día completo con un desarrollador?

¿Incluyo el trabajo de documentación en la estimación de historia?

Esta es una duda que nos surgió este sprint y que seguro que surge en más de un equipo. Aquí viene mi análisis.

Opción 1) Si todo el trabajo del escritor técnico está incluido en la capacidad del equipo o es un porcentaje fijo y no  realiza historias aparte de documentación.

En este caso, todas las historias tienen su parte de documentación, más pequeña o más grande. En este caso, en circunstancias estables, el equipo al completo desarrolla a una velocidad estable. Es importante valorar bien la parte del manual en las historias de desarrollo porque podría pasar el no llegar a completar el número esperado de historias, ya que la parte del manual que corresponde se había infravalorado.

Si la documentación NO forma parte de la definición de DONE de la historia. Como se puede realizar la documentación en otro sprint, tendríamos que revisar el tamaño estimado de esa historia cuando no se va a realizar en ese momento la documentación.

 

Opción 2) Si sólo una parte variable del trabajo del escritor técnico afecta al trabajo del equipo.

En este caso recomiendo no incluirlo, ya que impediría obtener la capacidad de la parte del equipo que sí que aportan el 100% de su tiempo. Podría pasar que distintos sprints en las mismas condiciones se tuvieran velocidades distintas dependiendo de si tienen más o menos trabajo en el manual. Haría más difícil la planificación por la variabilidad de esta velocidad del equipo.

Si la documentación SÍ está incluida en la definición de DONE, recomiendo una doble estimación, la del tamaño del desarrollo y de la propia documentación. En este caso, el equipo que está en el desarrollo del producto puede planificar cuántas historias desarrollar en base a su velocidad como equipo y el escritor técnico tener en cuenta su aportación y tenerla en cuenta a la hora de planificar su propio sprint junto con otras historias propias.

 

Sobre la transparencia y los tests hechos por desarrolladores

Hace poco me contaron que un CEO de nuestra competencia vio un vídeo en Youtube diciendo que no teníamos equipo de QA. El vídeo en cuestión es la charla que di para el Lean Kanban South Europe 2015. En esta charla hablaba de cómo usabamos Kanban para reducir el tiempo de feedback entre desarrollo y testing y cómo podíamos responder a requerimientos de proyectos, a soporte y además avanzar en producto.

Mi frase  “No tenemos ningún tester ni equipo de QA” se sacó de contexto y se usó como comentario para crear malestar. En VSN tenemos cerca de los 2000 tests automáticos que se pasan varias veces al día y que incluyen de unidad, de integración y de interfaz. Tenemos procedimientos muy concretos, certificados con una ISO 9001 sobre hacer el test cuando terminamos de desarrollar y además realizamos una batería completa de tests manuales de regresión en la que todo el equipo comprueba de manera transversal todo el producto antes de dar por buena una entrega. Usamos muchas de las técnicas incluidas en las certificaciones internaciones de Agile Testing. El no tener equipo de tests separado cada vez se está adoptando más para conseguir una respuesta rápida al cliente sin bajar en calidad. Además empresas como Atlassian estan descubriendo y demostrando que los desarrolladores pueden ser buenos testers. Piensan igual que yo que cuando los desarrolladores tienen el mismo criterio de calidad que los testers, los productos de alta calidad se CONSTRUYEN desde el principio.

Volviendo al tema de la charla, creo que el hablar sobre cómo trabajamos en VSN es más beneficioso que perjudicial. VSN cada vez está mas presente en charlas y conferencias a nivel nacional e internacional. Aquellos que usan frases sueltas de lo que decimos  y basan su “perfección” en su oscurantismo son los que deberían reflexionar sobre cómo hace las cosas. Nosotros esta reflexión la hacemos cada 3 semanas desde hace más de 6 años de manera contínua y es la que nos permite ser cada vez mejores, piensen lo que piensen otros.

 

¿Qué motivadores consideras más importantes en tu vida?

Me encantó el libro Workout de Jurgen Appelo. Expone claramente por qué deberíamos tener otra perspectiva del management, con más gente que se auto-dirija y menos directores. Esto permite un incremento de productividad, creatividad y motivación que no se pueden conseguir fácilmente con métodos tradicionales.

Una herramienta que voy a empezar a usar es la de “Moving Motivators“. Con este ejercicio, uno evalúa distintos motivadores y se ordenan de derecha a izquierda según  tienen más o menos importancia para el/ella. Estos motivadores son:

Curiosidad. Ver cosas novedosas, fuera de lo común. Aprender cosas nuevas cada día

Aceptación. Ser miembro de un equipo como uno más tal y como es y con lo que hace. Formar parte de los éxitos y ser reconocido cuando se hacen bien las cosas

Maestría. Llegar a ser un experto de una tecnología o técnica mediante estudio o experiencia y poder compartirlo con otros

Poder. Poder tomar las decisiones que tienen que ver con la forma de trabajar y el entorno. Expresar autoridad.

Libertad. Poder hacer cosas sin preguntar y ser creativo. No depender de aprobaciones de otros o normas estrictas.

Relaciones. Relaciones sinceras y abiertas con otras personas. No trabajar sólo.

Orden. Estabilidad, concreción, determinismo, sin sobresaltos, con procedimientos y opciones claras

Objetivos. Poder cumplir objetivos personales o profesionales.

Status. Tener un posición importante y respetada por el resto.

Moving motivators right to lefty
Tarjetas con los motivadores puestos en orden. Más importante a la derecha, menos importante a la izquierda.

Esta semana empezaré a usarlos y haré un experimento cuyos resultados quiero compartirlos dentro de poco.

 

 

Wastes o desperdicios en desarrollo de software

Me he propuesto hacer el ejercicio de identificar qué desperdicio Lean está asociado a cada lastre de una retrospectiva y cual se elimina o reduce en cada motor. Para saber de qué estoy hablando con motores y lastres entra aquí

Para que no vayas buscando en la wiki o páginas aparte cada lastre voy a resumir cuales son los 7 +1 wastes en desarrollo de software

1. Esperas. Esperas por recibir un detalle de un requerimiento, esperas para tener un build completo, esperas a que se completen los tests, esperas hasta que lo que has desarrollado lo prueba el cliente y te dice si es lo que quería, esperas a que un compañero te resuelva una pregunta que no te deja continuar…

2. Sobreproducción. Hacer programas que nadie necesita y nadie usará nunca.

3. Sobreingeniería. Es parecido al anterior. Desarrollar funcionalidades que no se han pedido sólo por aprovechar el tiempo en algo. Por ejemplo, preparar un sistema para millones de usuarios cuando es una panadería local.

4. Stock. Sí, en desarrollo también existe el stock. Stock de análisis de historias que nunca llegan a desarrollarse, stock de desarrollo que nunca se completa o se prueba, stock de funcionalidades que nunca llegan a deploy. Cada uno de estos stocks ocupan espacio en complejidad, y hace más difícil nuevos desarrollos sin que haya dado valor.

5. Transporte. En desarrollo de software el transporte está relacionado con el cambio de contexto. Cada vez que tienes que pasar contenido de la memoria a largo plazo a  la de corto plazo hay trasaporte. Ejemplos son cambios de historias en el mismo día, cambios de lenguajes de programación, cambios de rol del programador.

6. Movimiento. Es movimiento de personas tanto en espacio físico (para preguntar, pasar a otro ordenador, etc..) como movimientos virtuales (entrar en una ruta de directorios compleja, muchos clics para resolver un problema o hacer una acción)

7. Defectos. No creo que haya discusión en esto. Cualquier defecto en diseño, desarrollo o test provoca trabajo extra. Cuanto más se retrasa el momento del defecto a su descubrimiento y resolución, mayor suele ser ese trabajo extra o coste.

y el +1. Talento. Cada vez que uno realiza un trabajo que puede hacer otro, desaprovechando el talento o conocimientos que nadie más tiene, es un desperdicio.  Muchas veces ocurre por aliviar un cuello de botella pero hay que evaluar el sobrecoste de ese desperdicio de talento para buscar otras formas de gestionarlo.

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países “más modernos” prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>

Los tres primeros pasos en la gestión Ágil/Lean

Cuando uno empieza a querer organizar su forma de trabajar quizá lo que aporta Internet es demasiada información. Hace falta saber qué buscar para conseguir lo que necesitas para empezar a cambiar. Después de todos los años que llevo estudiando y aplicando las metodologías ágiles lo que aconsejo siempre es empezar con 3 sencillas cosas. El ABC de la gestión Agil.

1.- Daily Standup. Reuniones de máximo 15 minutos con los miembros del equipo en posición de pie en la cual cada uno comparte en qué trabajo el día anterior, en qué va a trabajar y qué obstáculos o problemas tiene en su camino.

Consejos:

  • No debe ser un informe al jefe. La información es de todos para todos
  • Debe empezar lo antes posible para que de pistoletazo al día pero que este presente el máximo número de personas
  • Si se abre un tema que necesite discusión larga se deja para después del daily.
  • Gente fuera del equipo puede hacer participaciones cortas que ayuden a algún problema. Lo fundamental es no pasarse de los 15 minutos.

2.- Tablero kanban. Panel en el cual hay una columna por fase por la que pasa cada elemento de trabajo representadas por etiquetas. Estos elementos pueden ser historias de usuario, diseños que hay que hacer, máquinas que montar, arreglar, etc.. Cada mes se limpian las etiquetas completadas en la última fase. Cada miembro del equipo mueve la etiqueta de una columna a otra según se va completando. Permite una visión común de cómo va el trabajo y permite tomar decisiones de mejora y de eliminar los bloqueos.

Consejos

  • Ponerlo en un lugar visible y accesible para todos
  • No debe haber más de 20 etiquetas por equipo para que se pueda ver de modo más sencillo
  • Debería haber límites máximo por columna aunque sean altos a principio. Si llega un momento en el que se supera ese límite debería analizarse la causa del problema y mejorar.
  • Ir bajando ese límite máximo según se va mejorando para conseguir un sistema más lineal y eficiente.

3.- Retrospectivas. Reunión a final de mes en cual se junta el equipo para ver qué han hecho bien y qué pueden mejorar. Se puede usar el método del barco  para además identificar las minas, es decir, los elementos externos que os afectan como equipo y para las que tenéis que estar preparados. No debería durar más de una hora u hora y media.

Consejos:

  • Sinceridad pero sin buscar culpables. Algo mal hecho es porque no se tenía conocimientos o herramientas para hacerlo mejor. Esta reunión sirve para buscar estas cosas.
  • Los problemas encontrados deberían buscarse soluciones. Asignar responsables para trabajar en ellas.
  • Se puede usar para dar pequeñas formaciones que ayuden al equipo. Club de lectura, vídeos de Internet, etc..

Con estas tres herramientas cualquier equipo puede empezar a trabajar mejor y de forma más organizada. Es posible que se vean nuevos problemas y se piense que antes no estaban, pero seguramente sea porque antes no se veían. Surgirán problemas que estaban ocultos y que ahora salen a la luz. Permitirá que surjan nuevas necesidades para ir mejorando cada vez más vuestro método de trabajo. Es posible que necesitéis nuevas herramientas para cubrir esas necesidades pero estas tres herramientas básicas os acompañarán día tras día.

Conseguir el ISO y el CMMI3 sin dejar de ser Ágiles, interesante reto

Este año en VSN nos hemos propuesto a pasar la certificación ISO para poder optar a proyectos en que lo requieren. Estamos con la ayuda de un consultor que nos va diciendo lo que tenemos que hacer.

De momento lo que vamos haciendo consiste en documentar todos nuestros procesos internos. No parece más que dejar bien por escrito todo lo que hacemos de manera corporativa. En desarrollo es concreto me toca escribir cómo manejamos los requerimientos en sprints, cómo hacemos seguimiento mediante los dailys y el Diagrama de Flujo Acumulado, como aseguramos la calidad mediante los tests automáticos y manuales. Como hemos ido escribiendo todo lo que ibamos estandarizando en las retrospetivas tenemos bastante escrito.  Sobre todo parece que hay que tener manual de todo lo que se desarrolle. No puede salir un desarrollo nuevo sin un escrito en el que se dice qué y cómo funciona. Yo espero que lo que escribimos como procedimiento de test para que otro desarrollador lo pruebe sea suficiente documentación.

Aparte del ISO se nos recomienda tener una certificación concreta de software. Yo estoy seguro que podemos optar a un CMMI 3 también con el modo ágil en el que trabajamos. De momento me toca ir empollando bien qué piden y si nos falta algo más que gestionar. Cuento con que mejoremos sin dejar de ser ágiles. Veremos si en lo que escribí a mediados de 2009 tenía razón.

Iré contando los avances…

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.