domingo, diciembre 25, 2016

Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning



Hola a todos

Uno de los primeros retos que enfrenta un Scrum Master con su Equipo es realizar el primer planning, pues para este no hay velocidad anterior (1), quiero compartirles tres propuestas de como se hace este cálculo, las cuales son muy sencillas, pues la verdad en la agilidad preferimos invertir más tiempo en el desarrollo de software que en la estimación que a la larga siempre fracasamos en ellas y terminan siendo un desperdicio.

Demos inicio.


Datos de entrada
  • Un equipo multifuncional de 6 personas
  • Un Product Owner (obviamente, no esperaría menos)
  • Un Scrum Master (obviamente, no esperaría menos)
  • Un sprint de 10 días)
  • Días de reuniones del sprint: 1.5 días aproximadamente  (ver tabla de tiempos reuniones de Scrum - clic aquí -)
    • Planning medio dia
    • Review y retrospectiva medio día
    • Refinamiento máximo el 10% del tiempo del sprint
  • Días efectivos del sprint: 8.5 días (8.5 días = 10 días del sprint - 1.5 días de reuniones)
  • Días-persona disponibles para el producto: 51 días-persona/sprint 
    • (8.5 días x 6 personas = 51)

Método 1: Un día-persona es igual a un punto (punto de historia)

Los pasos son los siguientes:
  1. Determino cuantos días-persona tengo (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que los hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 2 días de esfuerzo entonces son 2 puntos (o puntos de historia)
  5. Y la velocidad máxima que tendrá ese equipo en este sprint y en los demás sprints será de 51 puntos
  6. Luego se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas

  • Para toda la organización y todos los equipos la medida es única (1 día-persona = 1 punto)
Desventajas
  • Los equipos tienen velocidad estática, aunque mejoren sus procesos, interacciones, forma de trabajo, se automaticen tareas repetitivas su velocidad será siempre la misma
  • Serán fiscalizados en función los puntos que son capaces de lograr debido a la cantidad de integrantes y presionados a lograr el 100% de lo comprometido


Método 2: Un punto (punto de historia) es igual a una funcionalidad pivote

  1. Determino los días persona (datos de entrada: 51 días-persona)
  2. Le presento al equipo una funcionalidad, por ejemplo la siguiente pantalla, con todos sus criterios de aceptación
  3. Les pido que estimen la totalidad de esfuerzo(2) requerido en días(3) para realizar las siguientes actividades correspondientes a una Definition of Done:
    • Análisis de la historia de usuario
    • Diseño
    • Implementación (desarrollo)
      • Web services (Si es que los hay)
      • Modificaciones a la base de datos (si es que las hay)
      • Codificación
    • Pruebas unitarias
    • Inspección o prueba par
    • Realizar correcciones fruto de la inspección par (o prueba par)
    • Despliegue en ambiente calidad
    • Ajuste en calidad
    • Elaboración de casos de prueba
    • Probar
    • Reportar las pruebas
    • Corregir en ambiente de desarrollo
    • Despliegue en Calidad
    • Volver a probar
    • Hacer los manuales o documentos que al cliente le agregan valor (manual de usuario, manual técnico o cualquier otro documento de la Definition Of Done)
    • Alguna otra actividad de la Definition of Done
  4. El equipo estima que para esto por ejemplo toma 3 días de esfuerzo 
  5. Se considera esa funcionalidad será el pivote y es igual a 1 punto y que estimemos relativamente el resto de las historias de usuario o pantallas según el caso.
  6. La velocidad esperada ese primer sprint será = 17 puntos (51 días-personas/3 días =17 puntos) 
  7. Para la siguiente historia saco el lapicero de Will Smith de Men in Black y pido que miren fijamente, diciéndoles que olviden el cálculo 1 punto es aproximadamente 3 días y que sigamos pensando solo en la pantalla y estimemos relativamente respecto este pivote.
    Equipo por favor miren a acá un momento y olviden que esta historia de usuario toma 3 días.
  8. Se siguen estimando el resto de historias de usuario hasta que se se llega a la velocidad del sprint

Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Los equipos encuentran mejores formas de interactuar y de resolver los problemas con el tiempo, por lo tanto con seguridad habrá aumento de velocidad y esta pantalla que en inicio tomaba 3 días es probable que al sexto sprint tome menos viendo la organización de forma tangible la mejora del equipo.
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar

Método 3: "Ojo de buen Cubero" o "nos comprometemos hasta aquí"

  1. El equipo escucha las historias en orden, resuelven el qué y el cómo de cada una de ellas.
  2. hasta un momento donde el equipo dice: "Somos capaces con estas historias, paremos el planning"
Ventajas
  • Se desvincula el concepto de días u horas a las estimaciones
  • Es necesaria la confianza en el equipo
Desventajas
  1. Se pierde el “control” basado en días
  2. Los equipos no tienen velocidad estándar



Concluyendo

De estos tres métodos sugiero más al método 2 (aunque por años usé el método 1) y con equipos maduros al método 3. Espero que este post les sea de ayuda en su primer planning,

Saludos ágiles

Jorge Abad




Importante: compartí un cuarto método en: Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning (clic aquí)



Notas, referencias, comentarios y observaciones

  1. Para la estimación de la velocidad o capacidad del segundo sprint se usa un concepto que se llama “el clima del dia anterior”, y se basa en la premisa si ayer hizo un clima es muy probable que hoy haga el mismo clima, si el sprint pasado hicimos 30 puntos es muy probable que estemos cercanos a ese puntaje, entre 25 y 35, ya es potestad del Equipo y del ScrumMaster si van más allá o nó. Lectura Recomendada Comprometiéndonos un poco más allá en el planning - clic aquí- )
  2. Obvio es probable que entre una actividad y otra toque esperar un tiempo, pero nos estamos refiriendo solo a tiempo de trabajo y no se incluyen tiempos de espera)
  3. Se sugiere en días, pues  de esa manera se amortiguan las malas estimaciones.
  4. Lectura recomendada:Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad (clic aquí)
  5. Libro recomendado: Scrum y XP desde las trincheras (clic aquí)

domingo, diciembre 18, 2016

Tan cerca, Tan lejos. Una Comparación entre el Agile Inception y el Acta de Constitución del Proyecto (Project Charter) del PMBok



Hola a todos
Desde hace un tiempo me debía a mí mismo y a ustedes la escritura de este post, pues en numerosas ocasiones durante los entrenamientos de Scrum o Gerencia de Ágil de Proyectos he hecho esta comparación, y es bueno dejarla plasmada para ayudar mejor a la ilustración de lo que quiero decir.

Los Dos Mundos, el Predictivo y el Ágil

Dentro de los 47 procesos de la gerencia de proyectos del PMBoK (versión 5) existe el primer proceso llamado “4.1 Desarrollar el Acta de Constitución del Proyecto” (este proceso pertenece a los procesos de inicio) que cuenta básicamente con los siguientes aspectos
·         Objetivo
o   “Es el proceso de desarrollar un documento que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto”(1)
·         Entradas
o   Enunciado del trabajo del proyecto
o   Caso de Negocio
o   Acuerdos
o   Factores ambientales de la empresa
o   Activos de los procesos de la organización
·         Herramientas y Técnicas
o   Juicio de Expertos
o   Técnicas de Facilitación(2)
·         Salidas
o   Acta de constitución del proyecto
Y sugiere documentar los siguientes aspectos (1):
·         El propósito o la justificación del proyecto,
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Los riesgos de alto nivel,
·         El resumen del cronograma de hitos,
·         El resumen del presupuesto,
·         La lista de interesados,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto),
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.
Para mayor ilustración sugiero leer este articulo del PMI Colombia (Acta de Constitución del Proyecto) y este excelente ejemplo (Ejemplo Acta de inicio del Proyecto)
Ahora, si realizamos los talleres de Agile Inception (Inicio Ágil – en español) como los sugieren:
·         The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) de Jonathan Rasmussone (clic aquí)
·         Inceptions. Starting a Software Project de Enrique Comba Riepenhausen (clic aquí)
Encontramos que sugieren en un taller de 2 a 3 días obtener lo siguiente
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         Diseñar la caja de producto
·         Crear el Product Backlog Board(3)(4)
·         Crear la lista de No
·         Encontrar tu comunidad
·         Que te mantiene despierto en la noche
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         Story Mapping (Plan de Releases)
·         Qué vamos a obtener (Restricciones, Prioridades, Beneficios)
·         Cuánto va a costar y cuánto nos va a tomar

Y si comparamos ambos
Realizando la comparación de ambos, se tienen muchas coincidencias:
Agile Inception
Acta de Constitución del Proyecto (PMBoK)
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Aplica parcialmente, no siempre es un taller.
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         El propósito o la justificación del proyecto,
·         Diseñar la caja de producto
·         Product Backlog Board
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto -  esta última parte no corresponde a un inception - ),
·         Crear la lista de No
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Encontrar tu comunidad
·         La lista de interesados,
·         Que te mantiene despierto en la noche
·         Los riesgos de alto nivel
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         La descripción de alto nivel del proyecto y sus límites,
·         Story Mapping (Plan de Releases)
·         El resumen del cronograma de hitos,
·         Que vamos a obtener (Restricciones, Prioridades)
·         Los supuestos y las restricciones,

·         Cuánto va a costar y cuánto nos va a tomar (estos valores son aproximados, nunca cerrados)
·         El resumen del presupuesto,
·         No aplica
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         No aplica
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.


¿Entonces en dónde radica la diferencia?

En esencia, se observa que es lo mismo para ambos tipos de iniciativas (predictiva o ágil), aún más el PMBoK sugiere que sean talleres facilitados y no dudo que algunos gerentes de proyecto lo hagan así, pero lo que si es cierto es que en Agile es necesario (por no decir obligatorio) que sea un taller y que se maximice la comunicación cara a cara como lo sugiere el manifiesto ágil y sus principios (5) para garantizar el éxito de lo que se va a realizar.
Adicional en proyectos tradicionales (en los cuales la planeación predictiva es ideal):
-          Construcción de edificios
-          Construcción de puentes
-          Construcción de carreteras
-          Ampliaciones de fábricas
-          Construcción de barcos
Se hace hasta lo imposible por cerrar el alcance y no dejar lugar a la incertidumbre, pues el costo de los cambios es altísimo (¿o no creen que un dos nuevos carriles en la carretera o 2 pisos más en el edificio, fuera de afectarán gravemente los planes, cambiará el diseño de temas importantes?), cosa muy distinta en desarrollo ágil donde el software es más maleable y  donde somos tenemos una arquitectura base sobre la que podemos evolucionar.
Para cerrar esta pequeña comparación, les comparto esta tabla en donde presento las principales diferencias de ambos enfoques:

Agile Inception
Acta de Constitución del Proyecto (PMBoK)
Propósito principal

No es el objetivo del Inception, esto debe ser resuelto antes.
Autoriza formalmente la existencia de un proyecto
No tiene como objetivo entregar Autoridad.


confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto
Es un taller que permite a los interesados y al posible Product Owner(PO):
·         Entender la idea que se tiene a un nivel más profundo
·         Identificar las posibles dificultades del proyecto
·         Decidir si se continuará o no con el mismo
·         Proporciona al PO y a sus Interesados información suficiente para guiar al equipo de desarrollo en la construcción del producto
No corresponde a su objetivo primordial
Respecto al alcance
Se busca tener una primera versión u hoja de ruta sobre las cuales realizaremos la construcción del producto mínimo viable (MVP - http://www.lecciones-aprendidas.info/search/label/mvp ) y seguiremos creciendo incrementalmente hasta que construyamos el producto que requiere el negocio.
Se centra en esbozar el alcance va a detallar y gestionar en las siguientes grupos procesos de la gerencia de proyectos:
·         Planeación
·         Ejecución
·         seguimiento y control
·         y cierre
Transparencia
Esta información queda disponible al lado del equipo del proyecto para que sirva como radiador de información y le sirva para tomar decisiones
Muchas veces no es un taller, se comparte con el equipo y los interesados del proyecto, pero no se garantiza que todos la conozcan aunque se sugiere que todos la dominen.

Hasta acá esta corta comparación, los invito a profundizar en estos links
-          Sprint Cero o Agile Inception
-          Colección de entregables generados en un Inception

Bienvenidos sus comentarios y feedback.

Saludos Ágiles, 

Jorge Abad        


Notas, aclaraciones, referencias

1.       Guía de los Fundamentos para la Dirección de Proyectos. Guía del PMBoK Quinta Edición.
2.       Se enumeran entre varias posibles actividades: la tormenta de ideas, resolución de conflictos, gestión de reuniones para realizar la obtención de este entregable.
3.       Aunque no Corresponde a una propuesta de Agile Samurai o Inceptions, es ampliamente usado y recomendable para este proceso
4.       Ejemplos del Product Backlog Board - http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board
5.       http://agilemanifesto.org/iso/es/principles.html - “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.”,  “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.”

martes, diciembre 13, 2016

Leído y Recomendado: Toolbox for the Agile Coach - Visualization Examples

Gran post sobre herramientas de visualización para un equipo.

Imperdible

Toolbox for the Agile Coach - Visualization Examples (Clic Aquí)

Tarjetas que ayudan a identificar y remover impedimentos: Impediment Cards



Hola a todos

En un gran equipo del cual tuve la fortuna de ser parte de ellos durante un año como Scrum Master generamos una base de conocimiento para ayudar a identificar impedimentos en el proceso de desarrollo, de forma que la consultaba el team member:

  • cuando algo no funcionaba
  • cuando no sabíamos que pasaba con el sistema
  • cuando estaba el desarrollador bloqueado y no se le ocurría como solucionar el impedimento
  • y en especial para ayudar a los novatos en su búsqueda de respuestas, pues muchas veces estos no querían cubrir su curva de aprendizaje y preguntan incesantemente al programador experto hasta colmarle la paciencia (¿o no les ha ocurrido esto en sus equipos?).
La estrategia consistía en primero revisar la base de conocimiento y si esta no ayudaba a resolver el problema, sí pedir ayuda a un compañero experimentado, o a todo el equipo en pleno. (en algunas ocasiones a los novatos, sino cumplían revisar la base de conocimiento no se les ayudaba - este fue el acuerdo de equipo -).

Esta base de conocimiento decidimos que en vez de manejarla como una lista de verificación (o checklist), sería un grupo de tarjetas individuales con una pregunta a ser resuelta o que da pistas de donde buscar el error o problema al cual se esta enfrentando el desarrollador o team member, poco a poco fuimos engrosando las tarjetas a medida que nos encontrábamos con problemas típicos o ganábamos experiencia. A continuación les comparto el listado que contenía el mazo de cartas "Impediment Cards":

  • ¿Revisaste los webconfig, web.xml o el xml de configuración de la aplicación?
  • ¿Leíste bien el mensaje de error?
  • Insisto: ¿Leíste bien el mensaje de error y comprendiste que te decía?
  • ¿las IP son las correctas?
  • ¿el proxy lo está bloqueando?
  • Si es un bug ¿le preguntaste el correcto funcionamiento al Product Owner?
  • ¿revisaste si las contraseñas cambiaron?
  • No tiene lógica pero: reiniciaste ¿el IDE, El PC, El server, y/o bd?
  • ¿borraste caché?
  • ¿Reiniciaste el server para que reflejara los cambios?
  • ¿Seguro revisaste detalladamente el archivo de configuración?
  • ¿Tienes correctamente instaladas las dependencias?
  • ¿hiciste una correcta conversión de tipo de dato?
  • ¿será que el puerto o la IP están bloqueados en tu PC o en el Server?
  • ¿el usuario de cualquiera de los sistemas le quitaron o expiraron los permisos?
  • ¿Verifique si la versión del software es la soportada?
  • ¿el usuario tiene permisos / no tiene permisos?
  • ¿los servicios, bases de datos, etc apuntan a la dirección correcta o al ambiente correcto?
  • ¿la memoria RAM esta copada?
  • ¿el disco duro esta copado?
  • ¿soportamos la versión del navegador y/o del sistema operativo?
  • ¿los sistemas base tienen los parches?
  • ¿se encuentra sobre la versión del framework correcta?
  • ¿la versión del sistema operativo es la soportada?
  • ¿la versión sobre la cual se reporta el problema AUN DAMOS SOPORTE SOBRE ELLA?
  • ¿El tipo de dato en el software es el mismo que en la base de datos?
  • ¿las trazas, logs corresponden a la fecha de análisis del problema (fecha y rangos correctos)?
  • ¿hiciste copy-paste?, si es así, ¿no te parece mejor crear una clase, método que haga lo mismo?
  • Si la consulta esta lenta: ¿el procedimiento almacenado o consulta tiene un MAX, sobre una tabla de millones de registros?
  • ¿revisaste la documentación oficial del framework o componente?
  • ¿revisaste si el problema es de TIPO DE DATO?
  • ¿buscaste en Google?
  • ¿leiste bien el mensaje de error o log? ¿lo entendiste?
  • ¿lo solicitado se encuentra dentro de la garantía o del alcance del proyecto?
  • ¿estás lanzando y capturando la excepción?
  • ¿estás en el BRANCH correcto del proyecto o versión?
  • ¿hiciste DEBUG paso a paso?
  • ¿estás trabajando con las últimas versiones de los fuentes?
  • ¿revisaste conectividad, (incluido el cable)?
  • ¿la tabla tiene índices?
  • ¿borraste las cookies? (Fuente: Heimar Vega)
  • ¿borraste el historial del explorador? (Fuente: Heimar Vega)
  • ¿Se desplegó la versión correcta?(Fuente: Heimar Vega)
  • ¿Se ejecutaron las pruebas unitarias? (Fuente: Heimar Vega)
  • ¿verificaste estar conectado a la vpn? (Fuente: Anónimo)
  • ¿Verificaste si el servicio está operativo? (Fuente: Anónimo)
  • ¿Verificaste si la estructura del wsdl es la misma? (Fuente: Anónimo)
  • Problemas de rendimiento : Millones de registros , sugiere el uso de tablas históricas
  • ¿Todos los componentes de la solución corresponden a la misma versión?
  • ¿el web server se encuentra arriba? ¿la base de datos se encuentra arribla? ¿hiciste PING?
  • ¿preguntaste si esto había ocurrido antes?
  • Penúltima opción: Seguro: ¿buscaste en Google?
  • Última opción: No siendo más, pregúntale a un compañero
Estas cartas estaban disponibles en el "lugar o zona lúdica del equipo", allí donde teníamos fotos, chistes para leer, dibujos para colorear y descansar, entre otras cosas (¿tienes un espacio para tu equipo en tu zona de trabajo?, es una buena práctica y genera cohesión e identidad de equipo)

Hasta acá este pequeño y poderoso compartir, si tienes más causas de impedimentos típicas que puedas compartirme para agrandar la lista te lo agradecería, y si lo ves útil compártelo y con base en este listado crea tu propio mazo de cartas de Impediment Cards.


Las ImpedimentCards las puedes descargar aquí



Saludos ágiles

Jorge Abad