jueves, noviembre 28, 2013

La métrica de la felicidad - Un elemento clave para Scrum

Hola a todos

Dentro de mi curso de Gerencia de proyectos informáticos el cual dicto en la Universidad Eafit - www.eafit.edu.co para el pregrado de ingeniería de sistemas, tengo la costumbre de poner a escribir a los estudiantes un artículo sobre un listado de posibles temas que les proporciono que tienen que ver con gerencia de proyectos y /o agilismo.

A continuación les comparto el artículo escrito por Miguel Baquero, el cual es una buena aproximación a una métrica que debe llevar el equipo y que debe ser revisada cada retrospectiva, LA METRICA DE LA FELICIDAD.





---
link al documento original - Clic aquí


La métrica de la felicidad.

Gestión de proyectos informáticos.
Miguel Baquero
mbaquer6@eafit.edu.co
Departamento de Ingeniería de Sistemas
Universidad Eafit

Medellín, Colombia


Gerentes y consultores piensan que la gente está harta de trabajar infeliz. La gente más joven en particular se resiste a trabajar bajo el esquema de mando y control, ambientes basados en culpa y castigo. Un cambio importante está sucediendo. Harvard Business Review dedicó todo un número a la Felicidad porque empleados felices conllevan a clientes felices y mejores negocios. Sin embargo, nunca se debe subestimar la capacidad humana de cometer errores. Puede pasar que el equipo sea muy complaciente, tenga exceso de confianza o no vea oportunidades para mejorar. El patrón “un peldaño a la vez”, recomienda enfocarse en un punto a mejorar, de manera que sea claro su impacto. Sin embargo, existen muchas oportunidades para mejorar y es necesario tener una forma de trabajar en las cosas que den los mayores beneficios.



A menudo se genera una larga lista de cosas que se supone ayudan a mejorar la velocidad. Al ser muchos ítems, es posible que se trabaje en algo que no logre mejorar la velocidad, y sí lo hace, no presenta una mejora importante. La gente comúnmente no se siente identificada con largas listas, por lo que no están suficientemente motivados para que funcionen. Es necesario trabajar en la mejora adecuada de manera que el equipo sienta pasión. La gente siente gran satisfacción al hacer bien su trabajo, además tienen un gran sentido de responsabilidad por su trabajo, particularmente si se encuentran en un equipo autónomo. Por esto, hay que encontrar qué mejora va a incrementar en la mayor medida posible la felicidad del equipo, e implementarlo para el siguiente Sprint.

Típicamente, el equipo decide cuál es el nivel actual de felicidad y cada uno de sus miembros expresa qué podría aumentar este nivel al máximo, luego como equipo, se decide cual va a ser la mejora que va a producir la mayor felicidad para todo el equipo. 

Existen varias maneras de medir la felicidad del equipo, pero se ha encontrado que una forma simple y subjetiva de un puntaje de uno a cinco es suficiente. La mejora deseada debe ser parte de la meta del Sprint, por lo que este patrón además, puede ayudar a formular esta meta.

Hay cierta vulnerabilidad en la expresión de estos deseos. Algunas personas podrían sentirse incómodas haciéndolo públicamente. En este caso, podrían expresarlo anónimamente. Sin embargo, esto no es lo ideal; es mucho mejor reforzar una “comunidad de confianza”, donde las personas se sientan bien expresando sus deseos. 

Enfocarse en la felicidad del equipo tiene una extraña habilidad de descubrir qué problemas evitan que el equipo sea más efectivo, no solo más feliz. Probablemente se deba a que las personas obtienen gran satisfacción al hacer un buen trabajo. Además, a menudo están en una posición que permite entender qué pueden hacerlos más efectivos y que cosas se interponen en su camino. Otra razón para que la Métrica de la Felicidad permita un mejor desempeño del equipo, es que la gente siente una mayor conexión personal y compromiso a mejorar.       

La Métrica de la Felicidad puede ayudar a prevenir el agotamiento. El agotamiento ocurre cuando la gente trabaja por largas horas o gastan mucha energía mental durante mucho tiempo sin descanso. El agotamiento puede destruir la productividad (“Every hour of overtime is offset by an hour of undertime” – Tom DeMarco) o también provocar la deserción de la gente a un ambiente más sano. Sí el agotamiento es una amenaza, alguien probablemente va a proponer como Métrica de la Felicidad, “detener las horas de trabajo no sanas”.       

La gente puede tener distintas percepciones de la felicidad, por lo que es importante no dejar a una sola persona encargarse de la Métrica de la Felicidad; es una decisión del equipo qué es lo mejor para ellos. Al mismo tiempo, cada persona debe ser escuchada, haciéndolos parte de la decisión final. Algunas personas (como gerentes con mucho tiempo en el oficio), temen que el equipo “engañe” este sistema, decidiendo que la felicidad puede ser mejorada tomando los viernes libres, por ejemplo. Esto podría ser posible, sin embargo, como todos los aspectos de la anatomía del equipo, se debe confiar que el equipo siga el espíritu del juego. (Si no se confía en el

equipo, esto viola el espíritu del juego, por lo que se tiene problemas más serios). Así como todas las mejoras, la Métrica de la Felicidad debe ser medible, de manera que indique que realmente se han producido mejoras.       

Un ejemplo: Un equipo usa la Métrica de la Felicidad de forma que puedan identificar y priorizar las mejoras. En una escala de 1 a 5 se les pregunta cómo se sienten con su rol en la compañía y como se sienten acerca de la compañía. Luego comparten qué los haría sentir mejor y el equipo utiliza planning poker para estimar el peso de las cosas que los miembros del equipo consideran importantes para esto. El equipo estima el valor (opuesto al esfuerzo) de los ítems del backlog. El equipo estimó 50 puntos. “Mejores historias de usuario” fue la mejora más importante que consideró el equipo. Remover este impedimento tuvo más de 60 puntos. El product owner se preguntó si remover este impedimento podría doblar la velocidad al obtener un mayor puntaje que todo el product backlog para el Sprint. “Mejores historias de usuario” se agregó al Product Backlog para el siguiente Sprint y una nueva Definición de Done. Esta Definición de Done fue implementada como criterios de aceptación que tenía métricas que fueron calculadas en el siguiente Spring review. Estas incluyeron:      
  1. Cuantas historias de usuario estuvieron en el Sprint que no alcanzaron el criterio INVEST (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable) este debe ser 0.
  2. ¿Cuántas veces los desarrolladores tuvieron que acudir al product owner para clarificar una historia durante el sprint?
  3. ¿Cuántas veces las dependencias forzaron una historia a estar en estado de espera durante un Sprint? 
  4. ¿Cuántas historias tuvieron una eficiencia de más del 50% en el proceso? 
  5. ¿Cuántas historias no fueron claras para los desarrolladores? Medir por el número de miembros que se quejaron de la historia 
  6. ¿Cuántas historias implicaron mayor implementación técnica que la aclaración de la experiencia de usuario deseada?
  7. ¿De cuántas historias de usuario los desarrolladores entendieron la relación entre una historia, el tópico que produjo la historia y las necesidades del negocio que la generaron? Medida por el número de miembros del equipo que tienen quejas que no entienden qué estaban haciendo durante la historia.   
Los resultados: Mientras que la mejora a la calidad de las historias de usuario nunca termina, el sprint review mostró la mejora significativa en este ítem del Backlog medido por los criterios de aceptación. Mejoras significativas resultaron en un incremento de la velocidad después de varios sprints. Después de doblar la velocidad, el impedimento cayó del encabezado de la lista y fue reemplazado por otro impedimento. Un equipo feliz es un equipo mucho más productivo.         

Referencias:
Sutherland, Jeff. SCRUM LOG JEFF SUTHERLAND. 2012 . En: http://scrum.jeffsutherland.com/2010/1 1/happiness-metric-wave-of- future.html (consultado en noviembre de 2013).
Harrison Neil B, Sutherland Jeff. PROCESS IMPROVEMENT. 2013. En: https://sites.google.com/a/scrumplop.o rg/published-patterns/retrospective- pattern-language/happiness-metric (consultado en noviembre de 2013).
Schwartz, Tony. Happiness is overrated. 2010. En: http://blogs.hbr.org/2010/10/happiness -is-overrated/ (consultado en noviembre de 2013).


------------
link al documento original - Clic aquí

martes, noviembre 26, 2013

Pruebas automáticas de código sin framework

Estas pruebas, dan cobertura al funcional al código.





Un excelente aporte de  Julian Vargas @app_config 
Sirve para TDD y ATDD
___

Scrum: Hoja del Sprint y los Riesgos


Una de las características de scrum y de las metodologías ágiles es la importancia que se le da a la visualización de información o radiadores de información, esto no implica que no haya seguimiento y elementos digitales pero se le da prelación a lo visual (preferiblemente papel) esto logra:
  • compromiso del equipo 
  • información instantánea (no se requiere ingresar a url para saber algo)
  • el equipo sabe el status del compromiso en el Sprint y en el Release de manera constante.
  • se visualiza la deuda técnica
  • se observan los bugs y problemas que han habido durante la construcción del producto
  • se visualiza la velocidad a través de los sprints.

Una de los elementos radiar es la "Hoja del Sprint" o "Página de Información del Sprint" la cual cuenta con los campos:
  • Nombre del equipo
  • Nombre del producto
  • Número del Sprint
  • Objetivo del Sprint
  • Pila del Sprint (debe estar en orden, arriba las historias mas prioritarias con su respectivo puntaje)
  • Velocidad estimada
  • Calendario (fecha y lugar de la diferentes reuniones)
    • Daily
    • Refinamiento
    • Review
    • Retrospectiva
  • Equipo (cada miembro con su dedicación)
    • Product Owner (PO)
    • Scrum Master (SM)
    • Cada miembro del team developer 




Un campo adicional que he observado que sirve a todo el equipo de Scrum (PO, SM y Team Developer) para poner atención a los elementos que pueden hacer fracasar el sprint, es el de RIESGOS.

La idea es poner este campo con los posibles riesgos priorizados que afectan al sprint y las historias que estan siendo afectadas por este riesgo en caso que aplique, por ejemplo:

  • Riesgos
    • No se llegue a un acuerdo sobre los campos (afecta historia: Depósito)
    • La migración no sea "transparente" (afecta historia:  Herramienta migración)
Aunque una cosa es cierta, el SM y todo el equipo deben procurar que al sprint no se entren historias con riesgos que hagan "caer" el sprint y los puntos comprometidos (por lo general se usa un SPIKE, que es una historia con TIMEBOX y salidas definidas que permiten resolver los riesgos durante un sprint anterior, ejemplo: "realizar pruebas de concepto de la migracion",valor asignado 2 puntos). Si inevitablemente se debe entrar al sprint con riesgos, la visualización de los mismos hace parte de una buena gestión de impedimentos en cabeza SM y de todo el equipo Scrum.

De todos modos, no se debe perder la oportunidad de la retrospectiva para aprender si fue efectiva o no la gestión de riesgos y los resultados obtenidos por permitir su ingreso al sprint.




Saludos ágiles

Jorge Abad









_

lunes, noviembre 25, 2013

Personalización del Manifiesto y Principios Ágiles para la Ejecución de Proyectos.

Hace unos días hablé sobre el Framework de Scrum a una empresa que trabaja planes y proyectos de prevención en salud, el objetivo primordial es aumentar la efectividad en la realización de estos.

Dentro de los temas que facilité, fue una adaptación del Manifiesto Ágil [1] y de los Doce Principios Ágiles para el Desarrollo de Software [1] al contexto de dicha empresa. En esta actividad invitaba a los participantes a reflexionar,  pintar y dramatizar como estos elementos les harían mejor su trabajo. Bueno el resultado fue excelente, las personas siempre reaccionan como: "¡CLARO, OBVIO, ESO ERA, ESTO ES LO QUE YO NECESITABA!",


A continuación mi adaptación:



MANIFIESTO PARA EJECUCIÓN EFECTIVA DE PLANES Y PROYECTOS
Estamos descubriendo formas mejores de ejecutar planes y programas tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Entregar Resultados sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.






PRINCIPIOS PARA PARA LA EJECUCIÓN EFECTIVA DE PLANES Y PROYECTOS
1.       Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de resultados con valor.
2.       Aceptamos que los requisitos cambien, incluso en etapas tardías de la ejecución del proyecto. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3.       Entregamos resultados frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4.       Los responsables de negocio (y de  la visión del proyecto) y el equipo ejecutor trabajamos juntos de forma cotidiana durante todo el proyecto.
5.       Los proyectos se desarrollan en torno a individuos  motivados. Hay que darles el entorno y el apoyo que  necesitan, y confiarles la ejecución del trabajo.
6.       El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7.       Los resultados entregados frecuentemente son la medida principal de progreso.
8.       Los procesos Ágiles promueven el desarrollo sostenible. Todos los participantes en el proyecto (líderes y ejecutores) debemos ser capaces de mantener un ritmo constante de forma indefinida.
9.       La atención continua a la excelencia técnica y a la correcta ejecución mejora la Agilidad.
10.   La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11.   Las mejores soluciones emergen de equipos auto-organizados.
12.   A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

---
Realizaré seguimiento a los resultados de la aplicación del framework y pronto estaré elaborando un paper sobre este asunto.

Saludos ágiles:
Jorge Abad.






Nota:
[1]Todo es una adaptación de El Manifiesto Ágil (http://agilemanifesto.org/iso/es/) y Los Principios Ágiles para el Desarrollo de Software (http://agilemanifesto.org/iso/es/principles.html) 



_

martes, noviembre 19, 2013

Cómo luce (se ve) una historia de usuario - un pequeño ejemplo

Cuando se explican las historias de usuario, las personas no creen que son tan simples de escribir y creen que hay quedan cabos sueltos. La verdad es que si son simples (es solo cumplir el criterio INVEST [2] ) y no quedan cabos sueltos debido a dos elementos:
  • Criterios de Aceptación
  • Conversación


Las historias de usuario tienen dentro de sus objetivos:
  • sincronizar las espectativas del PO (Product Owner) con el Equipo respecto a una funcionalidad
  • servir como elemento que dirigirá construcción del software
A continuación quiero compartir un ejemplo de como luce (o se vé) una historia de usuario:

Nota : todo lo referente al ejemplo de la historia de usuario, lo registraré en color azul.


TEMPLATE
Yo como  <usuario>
necesito / deseo / quiero  <funcionalidad>
para <beneficio de negocio>



USANDO EL TEMPLATE PARA UN SISTEMA DE PRESTAMOS CREDITICIOS

 SOLICITUD DE INFORMACIÓN LABORAL DEL CLIENTE
(Nota : El título no sobra, algunas veces también se le adiciona codificación a la historia)


Yo como  CLIENTE DEL BANCO
Deseo INGRESAR MI INFORMACIÓN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO


Criterios de aceptación 
(se pueden manejar dos opciones)


Criterios de Aceptación
 en Prosa
Criterios de Aceptación
en Formato BDD

GIVEN – DADO
WHEN – CUANDO
THEN – ENTONCES

(La verdad, prefiero este formato, ayuda a que no queden cabos sueltos)
Que pida lo datos de la empresa
Escenario 1: Solicitar Datos de la empresa

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO se soliciten los datos de la empresa
ENTONCES se pedirá el nombre de la empresa.


Que pida el nit (identificador único nacional para las empresas) y lo valide
Escenario 2: Solicitud de Nit

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO solicite la información de nit
ENTONCES se verificará el número del nit que su estructura sea correcta.

Que pida salario actual
Escenario 3: Solicitud de Salario

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando el salario
ENTONCES verifique que el valor sea entero y positivo
Y menor a $100.000.000
Que pida fecha de ingreso a la empresa
Escenario 4: Solicitud de fecha de ingreso

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando la fecha de ingreso a la empresa
ENTONCES la fecha sea superior a 50 años antes a partir de hoy
Y la fecha sea inferior a hoy
Que pida tres comprobantes de pago
Escenario 5:  Solicitud de 3

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando los comprobantes de pago
ENTONCES solicite tres comprobantes de pago en formato imagen.




---------

Conversación
 (la conversación son aclaraciones realizadas por el PO durante el refinamiento o el planning, y muchas de esas aclaraciones son solicitadas por los miembros del equipo al entender las historias de usuario y comprender el negocio)
  • Los datos de la empresa son nombre, teléfono y dirección
  • Que la validación del nit sea contra el web service de la Direccion de Impuestos (DIAN)
  • El minimo valor de salario actual debe ser el salario minimo, el que debe ser leído de la tabla de parámetros
  • La fecha de ingreso a la empresa debe ser superior a 6 meses
  • Los comprobantes de pago deben ser en formato jpg, gif y máximo de 2 megas cada uno.
(Como fruto de una conversación puede resultar que se actualicen los criterios de aceptación o solo que se deje el registro aclaratorio.


-----
Durante el sprint no se cambiarán los criterios de aceptación y en caso de que se observen mas criterios de aceptación, estos harán parte de otra historia de usuario que se construirá en otro sprint)



Donde seguir

Ver más acerca de las historias de usuario en:





Importante:

La historia de usuario debe ser de un tamaño tal que a lo sumo tome 3 días una persona construirla, probarla  (quedando con cero errores) y desplegarla en el ambiente de pruebas (o el ambiente indicado), de majera que el equipo de trabajo pueda decir tranquilamente y sin ningún temor "¡ESTA LISTA PARA PRODUCCIÓN!"



Referencias:

[1] WHAT’S IN A STORY?  http://dannorth.net/whats-in-a-story/
[2] Características de una buena historia de usuario - http://lecciones-aprendidas.blogspot.com/2013/07/caracteristicas-de-una-buena-historia.html

-------- Ver más ejemplos

miércoles, noviembre 06, 2013

Unas frases que me he topado de agile / Scrum



---
#Scrum doesn’t make all your problems go away. It makes them visible. When they are visible, you can deal with them.
https://twitter.com/mojoneill/status/395169303634247681

---
Scrum does not make you faster, it helps you understand why you are slow. bit.ly/H4hshf #scrum #scrumalliance #agile

https://twitter.com/tirrellpayton/status/394890388588490753

---
La escuche por ahí.. o la leí

"El Scrum Master es un agente de cambio"


sábado, noviembre 02, 2013

Scrum: La Reunión de REFINAMIENTO, clave para reducir Riesgos y reducir tiempo del Sprint Planning

El refinamiento aunque no es una de las reuniones oficiales de Scrum [1], si se dice que el 10% del sprint debería dedicarse a esta actividad.

Dice la guia [1]:

"El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y
orden a los elementos de la Lista de Producto. Se trata de un proceso continuo, en el cual el
Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos
de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan 
sus elementosEl Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente 
consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos
de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a
criterio suyo."

Bajo este escenario la duración de la reunión de refinamiento debería ser:


Duración máxima de la reunión en horas
Tamaño del Sprint
1 Semana
2 Semanas
3 Semanas
4 Semanas
Refinamiento
4
8
12
16

Si lo miramos bien toma un tiempo considerable del sprint (aunque he experimentado en sprints de 2 que semanas 4 horas son suficientes),  tal vez se haga en una sola sesión o en varias según el caso, pero una de las ideas claves de scrum es:

"tengamos las reuniones suficientes de manera que no sea necesario hacer más reuniones, y podamos enfocarnos en lo que nos gusta, la construcción del producto."

.

Lo cierto es que esta actividad tiene grandes beneficios tanto para el sprint que viene, como para la construcción del producto.

Esta reunión (no-oficial) de scrum tiene como objetivo, presentar los próximos ítemes de backlog al equipo que van a entrar tanto para el siguiente sprint como para los 2 o tres próximos y discutir aspectos sobre ellos. Una de las agendas que he empleado en los refinamientos es la siguiente:

  1. Lectura y estimación de las historias de usuario que posiblemente entran en el PRÓXIMO SPRINT. Se leen las historias de usuario con sus criterios de aceptación, se realiza la conversación, entendimiento y ajuste sobre las mismas.
  2. Lectura de historias de usuario (no al detalle, solo el título de las mismas) que entrarán en los próximos  2 ó 3 sprints
  3. En equipo se identifican los insumos requeridos para estas historias tanto desde el punto de vista de conocimiento como de entes externos al equipo (otras áreas, otros proveedores, etc)
  4. En equipo se identifican los riesgos que pueden hacer que esas historias no se completen y se identifican actividades a realizar para mitigarlos.
De este manera:
  • El Scrum Master y el Product Owner (y en ocasiones el Team Develper) comienzan a trabajar conjuntamente en la resolución previa de:
    • riesgos
    • insumos 
    • e impedimentos
  • El equipo conoce que viene para el próximo sprint
  • El planning es una reunión mas liviana donde se presentan los aspectos modificados o afinados de las historias de usuario y algún cambio en la priorización.
  • Todo el Equipo Scrum (Product Owner, Scrum Master, Team Developer) van observando como se va construyendo la visión del producto y se pueden alinear desviaciones.

Saludos ágiles

Jorge Abad.


Referencias

[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100

Tiempos máximos de las reuniones de Scrum según el tamaño del Sprint


Hola a todos

A continuación relaciono el tamaño máximo de las reuniones de Scrum, según el tamaño del sprint. Estos tiempos fueron extraídos de la guía de Scrum [1]:


Tamaño del Sprint
1 Semana
2 Semanas
3 Semanas
4 Semanas

Duración máxima de la reunión en horas
Sprint Planning
2
4
6
8
Sprint Review
1
2
3
4
Sprint Retrospective
0,75
1,5
2,25
3
Daily (15 minutos)
0,25
0,25
0,25
0,25
Refinamiento (tiempo máximo)
4
8
12
16


La idea es que estos  tiempos se respeten, logrando el TIMEBOX o tiempo asignado para el objetivo defnido.

Es importante resaltar los siguientes aspectos:

  • El Scrum Master como dueño del proceso, es responsable de que estos tiempos no se superen.
  • Los primeros 2 o 3 sprints es muy probable que no se cumplan con los TIMEBOX, pero se debe trabajar en equipo y en la retrospectiva buscando la causa y las acciones a realizar para que esto no se repita. 
  • Los únicos TIMEBOX que desde el inicio se deben respetar son:
    • Daily = 15 minutos
    • Duración del Sprint = la definida (no se sugiere estar cambiando la duración de sprints, se debe buscar trabajar a un ritmo regular y constante)


Saludos ágiles
Jorge Abad.


Referencias


[1]Scrum Guides - https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-ES.pdf#zoom=100