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.