sábado, 16 de septiembre de 2017

¿Cómo representar Scrum técnico en una imagen?

El póster Scrum - @mariadelamareria
Habéis oído el refrán "Una imagen vale más que mil palabras". Yo andaba hace tiempo dándole vueltas a tener una imagen que sirviese para explicar lo que es Scrum técnico.

Según Scrum Manager hay dos formas de adopción de Scrum: técnica y pragmática. Cuando se adopta Scrum técnico se siguen unas reglas definidas, mientras que en la pragmática los equipos basándose en la experiencia acumulada pueden ir rompiendo las reglas para ejecutar un Scrum más acorde a sus necesidades específicas.

Ha sido hace unas semanas cuando alguien muy cercano a mí, me dijo: "si quieres preparo las imágenes". Y hala, nos pusimos a trabajar. Aunque esto no ha sido un desarrollo de software, la forma de trabajo se ha ajustado a los valores y principios del Manifiesto Ágil.

Empezamos por tener tres charlas a modo de sprints en las que le explicaba a la diseñadora cual es el proceso a seguir para desarrollar software con Scrum. Después de cada charla, ella me enseñaba algunos personajes y dibujos que representaban lo que le explicaba. Cuando ya tenía algunos personajes y dibujos seleccionados, me pidió que escribiera el proceso que le estaba contando. Tras esto realizó el diseño y me mostró la primera versión del póster. Sobre este le pedí cambios y este proceso lo repetimos 3 veces. En todo momento durante el proceso, aclarábamos las dudas que surgían manteniendo comunicación cara a cara o por whatsapp.

Tras esto le pedí su visto bueno a mi amigo Alex que puso su granito de arena, sugiriendo el cambio de algunos textos.

Tras este proceso en el que empleamos una gran dosis de ilusión obtuvimos el póster de la imagen.

Descargas / Downloads

martes, 12 de septiembre de 2017

¿Cómo aplicar Agile y Scrum en proyectos de infraestructura?

Proyecto de actualización en el CPD - Cortesía de Pixabay 
Los proyectos de infraestructura son aquellos que se producen en las áreas de sistemas y de arquitectura, suelen ser cosas como:
  • Actualizaciones de hardware o de software
  • Instalación de la infraestructura necesaria para que una aplicación de producto se pueda desarrollar y/o ejecutar
  • Instalación masiva de BBDDs distribuidas
  • Cambios de plataformas de correo
  • Migraciones masivas de BBDDs por cambio de versión del SGBD
A diferencia de los proyectos de producto, en los que siempre se construye algo "nuevo", los proyectos de infraestructura no siempre implican algo nuevo, pueden tener requisitos bien definidos y dependencias conocidas, lo que ocurre es que la incertidumbre emerge en forma de problemas imprevisibles. Por tanto la complejidad de los proyectos de infraestructura puede ser de menor grado, pero cosas como los problemas y otras restricciones, como que algunas de sus tareas solo se puedan realizar dentro de ventanas permitidas (fines de semana o fuera de horas de oficina) por ejemplo, hacen que Agile y Scrum puedan aportar grandes beneficios. También aquí la creatividad de las personas es esencial para la resolución de problemas, así como para encontrar maneras de hacer el trabajo de la forma más eficiente posible.

En este tipo de proyectos hay que averiguar qué ofrece valor, habitualmente suele tratarse del ahorro de costes o del coste de la demora para habilitar la construcción de funcionalidades de producto que si tienen valor de negocio. En un proyecto de migración a la nube por ejemplo, puede medirse el ahorro de costes asociado con el espacio de disco y la utilización de la CPU, y en un proyecto de infraestructura para un producto puede medirse el coste que representa el retraso en la puesta en marcha de una determinada funcionalidad.

La ejecución de Scrum se hace de la misma manera que en un proyecto de producto, la clave siempre está en los puntos de feedback y de integración que ocurre a final de cada uno de los sprintsPor ejemplo, si te tratara de un cambio de la plataforma de correo, se puede empezar por un grupo reducido de usuarios, los que estén a favor del cambio, se migran y se toma feedback, se hacen los ajustes correspondientes y se migra el siguiente grupo. Lo mismo para las BBDD, se empieza por una, se comprueba, se toma feedback y a por la siguiente.

Nunca es buena idea cambiar todo a la vez, cuando puede haber imprevistos es mejor empezar de forma acotada y expandir paso a paso, a través de sprints y priorizando por criticidad, ahorro de costes, coste de la demora, valor... una migración de servidores, por ejemplo, se podría afrontar incrementalmente incorporando en cada sprint nuevos servidores para dar servicio a los productos de más valor en función de los segmentos de cliente que más importen.

lunes, 11 de septiembre de 2017

¿Cuáles son las 50 mejores prácticas de Scrum para un Dream Team?

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum "50 Best Scrum Practices for Dream Team" y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum, que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

Scrum es uno de los frameworks más populares para implementar Agile. De hecho, muchas personas creen que Scrum y Agile son la misma cosa, aunque definitivamente no lo son. Agile es un grupo de metodologías de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agile pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.
Equipo
  • Los miembros del equipo trabajan en roles multifuncionales
  • El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
  • Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
  • Los miembros del equipo piden ayuda proactivamente
  • Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna
Scrum Master (SM)
  • El SM facilita la autoorganización del equipo
  • El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de Scrum)
  • El SM protege al equipo de distracciones externas e internas
  • El SM permite una estrecha cooperación en todos los roles
  • El SM interactúa con la alta dirección
Propietario del Producto (PP)
Definición de Hecho o Definition of Done (DoD)
Estimación
Reunión de planificación de Sprint
Sprint
Pila de Sprint (PS)
  • La PS está visible y es de fácil acceso para el equipo
  • La PS se actualiza todos los días
  • Las estimaciones de las tareas se actualizan todos los días
  • Los miembros del equipo actualizan la PS por ellos mismos
  • Las historias están claramente mapeadas
Scrum Diario (SD)
  • El SD tiene ocurre a la misma hora y lugar todos los días
  • El SD comienza y termina puntualmente
  • Todos los miembros del equipo están involucrados
  • El PP participa en la reunión por lo menos unas pocas veces por semana
  • El equipo revisa el gráfico de burndown y toma medidas si van retrasados
  • El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después
Revisión de Sprint
  • La demo formal se realiza después de cada sprint
  • Sólo las historias aceptadas por PP se demuestran
  • Todos los interesados se han invitado para la demo con antelación
  • Se anima a las partes interesadas a dar su opinión durante la demo
Retrospectiva
Sobre el autor: Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Mis agradecimientos a Gertrudis López por la traducción conjunta, link al post en su blog "Agile: lo bueno, lo feo y lo malo"

domingo, 10 de septiembre de 2017

¿Las historias de usuario son el mejor tipo de elementos para la pila de producto?

PBIs de la pila de producto
Siempre que pensamos en pilas de producto pensamos en historias de usuario. En esas historias de usuario representadas por post-its y usando la técnica de las 3 C's, esa forma excelente que se basa en mucha conversación y una comunicación muy cercana entre el Propietario del Producto y el equipo de desarrollo. Pero, ¿son siempre la mejor forma para recoger y gestionar requisitos?

Podríamos hacer una analogía de las historias de usuario con las diapositivas de una clase o de un seminario, no tratan de añadir detalle, sino de proporcionar claridad. Contienen gráficos y palabras clave que asientan la comunicación presencial cara a cara del ponente, podemos preguntarle directamente, y él puede resaltar partes en función de su audiencia e introducir cosas que no estén en las diapositivas.

Pensemos ahora en los requisitos tradicionales, éstos serían más bien como un libro en el que todo viene escrito con todo detalle, tiene que ser así ya que como lectores no tenemos posibilidad de preguntarle al autor.

Por tanto las historias de usuario son la mejor solución cuando el camino de la comunicación es reducido, cuando el Propietario del Producto es un miembro más del equipo, está presente y es fácilmente accesible, lo que es una de las piedras angulares de Scrum y la Agilidad.

Puede haber situaciones y proyectos en los que el Propietario del Producto no pueda estar muy cercano al equipo y donde las historias de usuario no sean una buena solución. En este caso necesitaríamos una solución de requisitos autoexplicativos como lo son los casos de uso, estos implican más transmisión de conocimiento escrita con el consuente empobrecimiento de la comunicación. Todo ello merma las posibilidades de Scrum y de la Agilidad, pero sin duda aporta los beneficios de los puntos de aprendizaje y de integración que conllevan los sprints.
Historias de usuario versus casos de uso
Es por todo ello que la Scrum Alliance habla de PBIs (Product Backlog Items), o elementos de la pila de producto, que define como unidades de trabajo lo suficientemente pequeñas como para ser completadas por un equipo en un sprint.

jueves, 24 de agosto de 2017

¿Cómo se sincronizan los sprints en un marco de Scrum escalado?

Actualmente Scrum se ha introducido en muchas compañías, todavía estamos en un estadío temprano en el que falta mucho por hacer y muchas compañías aplican un Scrum adaptado lleno de disfunciones y ScrumButs, pero ya es una realidad. En las compañías que llevan más tiempo y ya tienen varios equipos funcionando con Scrum, surgen necesidades cada vez más urgentes de coordinación y alineamiento de sus equipos, necesidad ante la que Scrum formal se queda corto y no proporciona soluciones.

Para ello han emergido diversos marcos de Scrum escalado en los que se trata de crear equipos de equipos alineados que trabajen como un único organismo. La visión, la hoja de ruta, la estrategia, los entornos… deben de ser compartidos y estar alineados para todos alrededor de productos, proyectos e infraestructura. Esto se consigue cuando todos los equipos planifican las releases de forma cruzada a la vez, con todos presentes, trabajan con la misma cadencia y de manera sincronizada, y entregan software funcional de forma frecuente e integrada.

En caso de productos grandes que requieran varios equipos, la cadencia de construcción puede ser diferente a la de las entregas o releases. Con cada sprint se producen entregas parciales que sirven para alinear e integrar, la entrega a negocio se produce con una cadencia superior, un supersprint o incremento de programa (PI) en SAFe, que es el resultado de lo construido e integrado en varios sprints.
Equipos trabajando con la misma cadencia y de forma sincronizada
  • La cadencia hace que las reuniones sean predecibles y sea posible coordinar agendas, por otro lado reduce la variabilidad ya que la limita el tamaño de los sprints proveyendo ritmo al desarrollo.
  • La sincronización crea entendimiento común, unifica e integra las diferentes ideas y perspectivas de los equipos. Sin sincronización no habría puntos de integración y de aprendizaje sobre el producto y el proceso, la sincronización provee de avance a nivel de equipo de equipos.
  • La combinación de cadencia, sincronización y una planificación cruzada provee a los equipos de una práctica para construir de forma efectiva dentro de un marco de un producto cambiante.
La cadencia y sincronización proporcionan
puntos de integración y aprendizaje
Aplicando la misma cadencia y de forma sincronizada obtenemos puntos de integración y puntos de aprendizaje con cada sprint

Como todos los sprint acaban en el mismo momento podemos integrar las entregas de cada equipo y asegurarnos que lo que han construido todos ellos ensambla y funciona conjuntamente.

De la misma manera podemos inspeccionar a final de sprint la entrega integrada de todos los equipos y así aprender sobre el producto que estamos construyendo, sobre su viabilidad técnica y si las funcionalidades construidas son solución a problemas de negocio.

Finalmente cada final de sprint nos proporciona la oportunidad para efectuar retrospectivas y mejorar el proceso, en particular retrospectivas a nivel de equipos de equipos que permiten mejorar de forma continua el sistema al completo.

sábado, 5 de agosto de 2017

¿Se pueden gestionar proyectos de ingeniería civil con Scrum?

Ya en 1992 se dieron los primeros pasos en investigación Lean en el sector de la construcción. Lauri Koskela, un profesor finlandés, le dio a esta disciplina el nombre de Lean Construction. En 1997 se fundó el Lean Construction Institute que enseña Lean Construction y ha colaborado en numerosos proyectos constructivos a nivel internacional (Estados Unidos, Rusia, Inglaterra, Canadá, Alemania, Dinamarca, Finlandia, Australia, Israel, Noruega, Irlanda, Perú...).

Las herramientas modernas de simulación y realidad virtual han permitido el modelado de información de construcción denominado BIM (Building Information Modeling) que va más allá de las fases de diseño. Se trata de un proceso de trabajo colaborativo para la creación y gestión de un proyecto de construcción, incluidos costes, calendarios y mantenimiento, así como un modelo de información digital que centraliza los datos de un edificio, como son la geometría del edificio, las relaciones espaciales, la información geométrica y las cantidades y propiedades de sus componentes, y lo hace a lo largo de todo su ciclo de vida.

Lo que hay detrás de las siglas de BIM:
  • Building (edificio): un proyecto colaborativo compuesto por áreas (arquitectos, constructores, ingenieros, clientes, propietarios...) en constante diálogo y apoyados por la visualización en tres dimensiones del edificio.
  • Information (información): creación y desarrollo de una base de datos siempre actualizada en sus diferentes perspectivas.
  • Modelling (modelado): el edificio y la gestión del proyecto asociado se modela y construye sobre datos organizados.
B.I.M. es un acrónimo de Building Information Modeling
Agradecimientos a Bonela
El hecho de que todos tengamos móviles ayuda a trabajar con ciclos cortos, al estar hiperconectados y podemos compartir al momento desde fotos a decisiones y todo tipo de actualizaciones del edificio. Todo ello permite iteraciones durante la construcción del edificio sin añadir costes al proyecto, iteraciones que facilitan el contacto y feedback del cliente ya desde la fase de diseño, lo que permite su inclusión en la toma de decisiones.

BIM se ha ido implantado de forma paulatina en diferentes países alrededor del mundo. Siguiendo la Directiva Europea de Contratación Pública 2014/24/UE en Inglaterra su uso ya es obligatorio en todos los proyectos públicos. En España, el Ministerio de Fomento creó en 2015 la Comisión Nacional es.BIM, en la que se está analizando cómo implementar BIM en el sector público y como introducirlo en las licitaciones públicas.

Para la gestión de proyectos de construcción de esta naturaleza, en los que prima trabajar de forma colaborativa, el producto final es complejo y donde la gestión de tiempos y riesgos es clave, se utiliza Scrum en la fase diseño. Marc Bach en su artículo "Scrum in construction" nos describe en 10 puntos en qué consiste Scrum en el ámbito de la construcción:
    BIM hace posible la aplicación de Scrum
    en la construcción - cortesía de Pixabay
  1. Definir el plazo del proyecto y seccionarlo en sprints (normalmente semanas o meses).
  2. En cada sprint se definirá un entregable en BIM a supervisar por la propiedad o el representante.
  3. Se definirán unos roles: Propietario del Producto (definición similar al Bim Manager en pequeños proyectos), Scrum Master (mentor del equipo de desarrollo) y equipo de desarrollo (los modeladores BIM).
  4. Unas reuniones semanales y diarias con los agentes que definen el proyecto con tiempo y tareas a comentar estandarizados.
  5. Las tareas se reflejarán en un panel visual. Así como gráficos de control y avance del proyecto.
  6. Cada sprint es una iteración. Y hay que planificar las tareas a realizar en cada sprint por el equipo de desarrollo.
  7. Es un trabajo colaborativo. Se toman las decisiones en equipo.
  8. El Propietario del Producto es el responsable de coordinar los requisitos del proyecto ejecutivo. Deberá asegurar que el modelo BIM que vaya definiendo el equipo de desarrollo cumple los requisitos del cliente tanto a nivel de coste, plazo, definición y uso posterior.
  9. Se trabaja con rendimientos y duraciones de tareas. Por lo tanto la recopilación de datos será muy importante para proyectos posteriores.
  10. El objetivo perseguido es establecer unos estándares de colaboración y ejecución definidos desde el principio con unos roles claros para garantizar un producto final (modelo BIM) de valor con un uso efectivo de los recursos. La clave del éxito es la repetición de esta estructura diaria y semanal durante el tiempo que dure la redacción del proyecto.

Quiero invitaros a visitar mi post que describe un ejercicio de simulación de Scrum en el que los alumnos construyen un resort del caribe con post-its y material del papelería. Lo hacen con 3 sprints y una de las exclamaciones de alumnos que más me llamó la atención fue: "¡Me esperaba algo más sencillo, no hubiera pensado que construiríamos algo tan bonito!".

Mis agradecimientos a Marc Bach cuya pasión es la divulgación de las buenas prácticas Lean y Agile, que buscan la eficiencia y eficacia, en el sector de la construcción.

jueves, 3 de agosto de 2017

¿Qué representan el objetivo y la pila de sprint?

El objetivo o meta del sprint
Cortesía de Pixabay
He vivido varios equipos que no ponen objetivo o meta de sprint (sprint goal) a sus sprints. Cada sprint debe de tener un objetivo y debe de que quedar reflejado en el tablero scrumboard. Se trata de darle una función coherente a los elementos de la pila de sprint, podemos pensar en el objetivo de sprint como un elevator pitch que habla de los beneficios que va a obtener negocio con lo que se construya en ese sprintLo importante es que el equipo se comprometa con el objetivo, no con el paquete de historias de usuario de la pila de sprintExisten dos términos en inglés que nos dan la pista sobre estos dos conceptos:
  • Output: la salida producida
  • Outcome: el resultado producido en términos de beneficio o de resolución de problemas para negocio
En la gestión clásica de proyectos ponemos el foco en la construcción de outputs. Lo hacemos en forma de funcionalidades, nos basamos en un input a base de una lista de requisitos que llamamos alcance, y a lo largo del proyecto construimos un paquete grande de funcionalidades que cubra esos requisitos, y lo hacemos de forma optimizada para el paquete completo.

Output vs. Outcome, no hay correlación entre uno y otros
Imagen de las monedas cortesía de Pixabay
En cambio en Agile y Lean el foco está en producir outcomes, en construir soluciones a problemas de negocio para hacer una compañía competitiva y que obtenga beneficios de forma sostenida.

Encontraremos ambos términos en cada uno de los sprints en Scrum, cuando obtenemos la pila de sprint y el objetivo en la planificación de sprint. La pila de sprint es el output y el objetivo el outcome; no importa tanto si las historias de usuario entregadas corresponden a lo que se planificó, lo que importa es que las historias entregadas sean la mejor solución para el negocio. Lo clave es que el objetivo guíe al equipo a lo largo del sprint focalizados en la necesidad o problema a solucionar.

Imaginemos la siguiente pila de sprint:
  • Como lector quiero buscar libros por título para encontrar los libros que me gustan
  • Como lector quiero buscar libros por autor para ver otros libros de autores que me gustan
  • Como lector quiero poder ver los resultados de la búsqueda efectuada para seleccionar el que me interesa
  • Como lector quiero una búsqueda avanzada para explorar la librería
cuyo objetivo es:
Permitir la búsqueda de libros a nuestros lectores

Ahora imaginemos que el sprint es a finales de agosto, a las puertas del comienzo de las clases, y a medio sprint nos damos cuenta que lo que necesitan nuestros clientes es otra historia de usuario:
  • Como madre quiero buscar libros por ISBN para comparar los libros de texto para mi hijo
Una posible solución sería incluir esa nueva historia dejando fuera la de menor valor, la búsqueda avanzada por ejemplo. De esa manera no se rompe el objetivo del sprint y maximizamos los beneficios que obtendrá la tienda.

En gestión clásica podemos construir por ejemplo 45 funcionalidades y en un proyecto con Scrum 22, en la gestión clásica quizá se hayan dado solución a 2 problemas de negocio (outcomes) con esos 45 outputs, en Scrum 10 soluciones con esos 22 outputs... esa es la verdadera esencia de Agile y Lean.

Vyacheslav Moskalenko nos describe en su artículo "7 Sprint Goal Patterns for Building Great Teams, Part One" 7 patrones que nos guiarán en la correcta identificación de un objetivo del sprint:
Veamos que ocurre con Scrum escalado, ¿los objetivos siguen siendo la clave para guiarnos hacia buenas soluciones de negocio?

Si miramos el marco de SAFe podemos observar que a nivel de los equipos se construye con iteraciones guiadas por objetivos (Goals), tal como marca Scrum. Cuando escalamos vemos que tenemos pilas de elementos a diferentes niveles, que priorizadas por valor de negocio (realmente WSJF), llevan las intenciones estratégicas a los equipos. Estos las cocinan y así obtienen los objetivos que escalan al equipo de equipos (Agile Release Train) en forma de objetivos agregados (PI Objetives). Estos son un plan factible de entrega de valor para las mejores soluciones a los problemas de negocio.
Essential SAFe con los elementos que guían hacia los outcomes - cortesía de Scaled Agile
La realidad, los verdaderos outcomes, se producen al final de los PI, en PIs guiados por los objetivos y la Continuous Delivery Pipeline. Recordemos que no todo puede saberse al principio, una buena solución se descubre y redefine a lo largo del camino, mediante exploración continua para despejar incertidumbre, puntos de integración y aprendizaje continuo que mejoran de forma iterativa el producto, así como con despliegue continuo que permite validar asunciones y conseguir la mejor solución posible a problemas reales.