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

miércoles, noviembre 30, 2016

Tengo un proyecto en cascada y quisiera agilizarlo (1)



Hola a todos

Muchas veces cuando comparto en entrenamientos sobre Scrum o Agile, o en conversaciones con gerentes, gerentes de proyecto, sale la siguiente pregunta a relucir:

- [Cliente] Ok, genial, podemos adoptar esto de ÁGIL o SCRUM en el siguiente proyecto, pero 

¿que hacemos para agilizar los proyectos existentes que tenemos en cascada?

Lo que recomiendo es ensayar AGILIDAD ORGÁNICA (http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html), que consiste en promover la agilidad de una forma natural y con feedback del entorno en que se encuentra inmerso el equipo o el proyecto.

Una posible secuencia de pasos a seguir para la agilidad orgánica sería:
  1. Existe un agente de cambio ágil - facilitador(2) - (que luego será el scrum master, o como deseen llamarlo)
  2. Propone al equipo hacer retrospectivas semanales o máximo cada 2 semanas (ver acá una guía de como realizar un retrospectiva - http://www.lecciones-aprendidas.info/2016/11/agenda-scrum-pasos-para-realizar-la.html - )
  3. En la retrospectiva el facilitador se enfoca en lo que más le duele al equipo (este enfoque se basa en encontrar dolores e ir sanándolos - Pain Driven Facilitator) y proponer un cambio, un experimento, y en la siguiente retrospectiva revisar el resultado del experimento.
  4. Un ejemplo, el facilitador en un momento apropiado propone como experimento para el próximo ciclo incorporar el Daily, y pregunta en luego del ciclo beneficios que observaron en este.
  5. Luego se preguntan sobre más dolores y se van incorporando prácticas, procesos o acuerdos  que el equipo las va "amando" pues fueron soluciones a sus problemas, que ellos mismos encontraron.
luego me dicen

- [Cliente] Perfecto, ¿y que hacemos con las entregas y los entregables?

mi propuesta ante esta situación es:
  1. Reprioricen las funcionalidades que están solicitando o esperando (3) en orden del valor que le pueden dar al negocio
  2. Hagan cascada de máximo dos meses, es decir, traten de generar u obtener valor lo antes posible de forma que se minimice el riesgo, esto lo logran reduciendo los tiempos de entrega de software con valor (software en el ambiente que será entregado el producto, ya sea en ambiente de calidad o preproducción, según el caso) al menor tiempo posible, 1 mes, 2 meses (exagerando 3 meses), de forma que ustedes puedan dar o recibir feedback sobre el producto y reaccionar sobre el mismo.
  3. Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.

y la última pregunta

- [Cliente] ¿y los proyectos que tenemos muy adelantados?

respondo
  1. El punto final anterior se conserva igual: Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.
  2. Realicen agilidad orgánica, pues la retrospectiva siempre será el motor de la mejora continua sin importar en que punto estemos del proyecto
  3. Y dentro de la agilidad orgánica habiliten el Daily que es valioso para dejar de trabajar como islas y comenzar a ser equipo.
Hasta acá este pequeño compartir, bienvenido el feedback.


Saludos ágiles

Jorge Abad



Notas, Referencias, Comentarios y Aclaraciones

  1. Este post podría llamarse también: "AGILIZANDO PROYECTOS EN CASCADA"
  2. Es importante que este facilitador conozca de prácticas ágiles para ir orientando al equipo en su proceso de agilización, recordemos El Paciente se Enferma de lo que el Médico Sabe
  3. Esto es, dependiendo si es cliente o proveedor quien hace la pregunta.

sábado, noviembre 26, 2016

¿Vale la pena ser precisos a la hora de escribir una historia de usuario?

Hola a todos 

Este tema es un pendiente a resolver de los entrenamientos y equipos a que he tenido la fortuna de acompañar.

En los entrenamientos de ágil se insiste en la necesidad de la conversación cara a cara, tanto cuando se explica el manifiesto agil, como cuando se "juega" la construcción del requisito especificado y el colaborativo (1).

Y los creadores del concepto de historias del usuario invitan a maximizar el contacto entre el usuario (o Product Owner,  en el caso de Scrum) y el equipo teniendo la excusa de una "necesidad" mal especificada.

Algunas frases de estos referentes son.
  • No sigamos especificando historias y comencemos a explicarlas (Jeff Patton) 
  • Prefiero una historia ambigua que una bien especificada,  la primera requerirá explicación mientras la segunda no. (debo la referencia) 
  • Una historia de usuario debe ser tan pequeña que requiera ser explicada (debo la referencia) 
  • Si una historia de usuario no cabe en media hoja,  trata de escribirla en un papel más pequeño. (debo la referencia) 
  • Debe ser suficiente con un título y un wireframe explicado (Jeff Patton) 
  • No entiendo por qué insisten en usar un formato (uno de los creadores de XP al referirse al formato propuesto por Mike Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO)
  • son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, (debo la referencia)

La verdad en mis entrenamientos enseño las 4 formas que conozco  de trabajar historias de usuario:
  • un solo titulo 
  • un título más un wireframe o boceto 
  • el formato de MIke Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO; más los criterios de aceptación,
  • o la anterior forma pero con los criterios de aceptación escritos en formato Gerkin (Given, When, Then - Dado, Cuando, Entonces), propuesto por Dann North.

Con los consabidos tips:
  • que la historia de usuario tome de 3 a 5 días en lograr la definición de terminado (o  de DONE)
  • que tenga máximo 6 criterios de aceptación (tendiendo a menos no a más) 
  • un buen Sprint Backlog debe contar entre 6 y 10 historias de usuario,  tendiendo al número mayor o más y todas en lo posible de tamaño uniforme.


Por último,  recordemos que las historias de usuario buscan maximizar la comunicación,  independientemente de  lo que usemos como formato desde que estás sean explicadas por el cliente o Product Owner y el equipo las comprenda logrando una confirmación de ellas (PRINCIPIO DE LAS CCC: CARDS CONVERSACIÓN Y CONFIRMACIÓN (2)) la tarea estará bien hecha y habremos logrado el propósito de esta práctica.

Lo que funcione será lo mejor,  hagamos inspección y adaptación, y no nos detengamos de buscar mejores formas de hacer las cosas y de hacer software.

Saludos ágiles
Jorge Abad


Notas, aclaraciones, comentarios y referencias

  1. Juego en el que los participantes se dividen en parejas y unos son los especificadores y los otros los artistas,  y los especificadores durante un timebox de 10 minutos describen de forma escrita (y aislada) un dibujo,  luego esta especificación se le entrega a los artistas y durante un tiempo igual construyen lo especificado (los resultados no son muy satisfactorios en algunos casos,  o la mayoría dependiendo del dibujo o la habilidad de las personas para escribir o interpretar),  y luego durante un tiempo igual de 10 (luego de intercambiar los roles)  los nuevos especificadores de forma colaborativa (y conjunta) le dictan un dibujo más complejo sin dejarlo ver a los artistas,  los resultados son asombrosos: menos tiempo, mayor calidad del dibujo y por ende mayor satisfacción.
  2. Adicional el criterio INVEST

lunes, noviembre 21, 2016

El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje




Hola a todos

Hace poco le escuche a un médico amigo de la familia la siguiente frase:

 “El paciente se enferma de lo que el médico sabe”  

y él me explicaba que era necesario que los médicos estén repasando lo aprendido y estudiando sobre lo nuevo, pues cuando llega un paciente con unos síntomas determinados, si ellos poco “saben” o “conocen” de esos síntomas, diagnosticarán mal al paciente y por ende le recetarán un tratamiento inadecuado (obvio, no se puede recetar sobre lo que no se conoce, por eso ellos envían a especialistas, pero si fueron muy livianos en su diagnóstico no identificarán correctamente la enfermedad, padecimiento o problema de su paciente).

En esta misma línea va este post, y es animar principalmente a los Scrum Master(1), y en segundo lugar a los Product Owner y Team Members, a que estén actualizándose, leyendo, buscando blogs, siguiendo en Twitter a los referentes de la industria, buscando nuevos enfoques o visiones más profundas que puedan enriquecer su experiencia con nuevas teorías o hallazgos, de manera que al momento que alguien se les acerque tengan argumentos para:

  • saber cómo enfrentar el problema
  • saber cuándo aplica la máxima de la gestión empírica:“inspección y adaptación”, y cuando no (2)
  • comprender que experimentos se pueden proponer o un posible espacio de solución
  • realizar las preguntas correctas que orienten y ayuden al coachee, al equipo, o a quienes se les acerque 
  • entre muchas otras situaciones

y de esa manera puedan brindar una mejor ayuda a los “síntomas” que se están observando.

Un Poco de Remedio

Como parte del remedio, les comparto algunos blogs y cuentas de twitter que sigo:


Un llamado a la Acción

Por ultimo quisiera hacerles un llamado a la acción (adicional al del propósito de este post que es invitarlos a que estudien y se actualicen constantemente), y es que compartan lo que aprendan y comprendan, sus experiencias y reflexiones son valiosísimas, creen un blog, pero si les resulta pesado tener un blog pues muchos me dicen que no se sienten con la confianza o el tiempo para escribir, compartan por twitter, pues lo que ustedes saben es útil para toda la comunidad(3), es una buena forma de generar conocimiento y de salir del anonimato, cosa por demás útil en el mundo de la agilidad.

Hasta acá esta corta reflexión.

Saludos Ágiles
Jorge Abad

_

Notas, Aclaraciones, Comentarios y Referencias

  1. Los Agile Coach también (y cualquier persona que tenga el rol de experto o consultor), pero la verdad un Agile Coach no requeriría este tipo de mensaje, pues sabe de la urgencia de estar aprendiendo y comprendiendo sobre como se mueve el entorno técnico, de equipos, de las personas, del coaching, de los frameworks, de las buenas prácticas, el empresarial entre otros.
  2. Les recomiendo leer este post: Por qué losagilistas como los gatos caemos parados
  3. Una frase que le digo a mis amigos "no sabemos todo lo que sabemos y creemos que lo nuestro es poco", en general somos inseguros acerca de nuestras experiencias, las creemos de poco valor, pero estoy seguro que son valiosas para alguien que se encuentre en una situación similar a ellas y esté buscando respuestas en la red.