sábado, diciembre 31, 2011

Administración de Riesgos en Scrum

Hace unos meses apareció una gran duda en mi mente: ¿Cómo se acoplan la administración de riesgos en Scrum u otras metodologías ágiles? Luego de haber leído mucho sobre metodologías ágiles y también sobre Riesgos, no recuerdo haber leído en ninguna parte el nexo entre estos dos temas.

Realmente es algo de lo que todavía no se habla mucho dentro de las metodologías ágiles, no existe ningun template o framework oficial. En las metodologías clásicas tipo PMI, se presta mucha atención a los riesgos, ocupando una de las áreas de conocimiento del PMBOK. Al comienzo del proyecto se listan los riesgos, se discuten con el equipo y otros interesados, se le asigna una probabilidad y un impacto, se calcula la severidad, se acepta el riesgo o se prepara un plan de mitigación si vale la pena. Lamentablemente, este plan queda generalmente abandonado cuando se está acercando la fecha de entrega del proyecto y el ritmo de trabajo aumenta. El PM es el dueño de la administración de riesgos en el proyecto y tiene que dedicarle esfuerzo y tiempo al control y monitoreo de estos.

En Scrum, parte de la administración de riesgos es implícita, dentro del framework: Al usar Sprints cortos, realizar reuniones y revisiones periódicas, mantener comunicaciones más eficientes y manejar a un equipo autoadministrado trabajando cerca con el cliente, priorizando, inspeccionando y adaptándose a los cambios y a nueva información. Sin embargo no todo está contemplado por las prácticas de scrum, el mismo Ken Schwaber lo reconoce: “Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management.”. Hay ciertos riesgos que son externos al proyecto, y que deben ser administrados por el equipo. Alguno de estos son:
  • Riesgos políticos involucrados en la relación del equipo con el product owner, y de la posición e influencia de esta persona dentro de la organización.
  • Riesgos financieros y legales.
  • Riesgos de trabajar con otras empresas y de tercerizar.
  • Factores de infraestructura y medio ambiente del equipo de trabajo.
  • Riesgos de integración e interdependencia con otros proyectos, conflictos de recursos.
  • Distribución o implementación del producto

Para cerrar este artículo, podemos concluir que se necesita administración de riesgos en proyectos manejados por Scrum, enfocados más afuera que adentro, ya que Scrum ayuda a minimizar riesgos de alcance, calendario y calidad mediante sus principios y prácticas. Scrum es ingenuo en asumir que el desarrollo de software se hace en un vacío, sin que nada pueda afectar al proyecto fuera del equipo. Aunque asumamos que el equipo trabaja correctamente con riesgos técnicos y que otros riesgos inmediatos de calendario se contienen trabajando incrementalmente y utilizando buenas practicas, hay que monitorear y administrar riesgos y problemas fuera del desarrollo del producto. El correcto manejo de estos riesgos externos puede hacer la diferencia entre un éxito y un fracaso.

Fuentes: La fuente principal que nutre este artículo es el blog Building Real Software de Jim Bird. Luego también saque información de Thushara Wijewardena en el blog Projectized y de Agile101. Estos dos últimos proponen un acercamiento ágil de la administración de riesgos, les recomiendo que le pequen una mirada.

martes, diciembre 20, 2011

Agile Software Development with Scrum

"Agile Software Development with Scrum" de Ken Schwaber y Mike Beedle es el primer libro escrito sobre Scrum. Es un buen libro pero no es grandioso, los autores reconocieron en una ocasión que fue escrito a las apuradas para ser presentado a tiempo en una conferencia. Lo leí porque hace pocos meses me certifiqué como ScrumMaster y mi instructor fue el mismo Mike Beedle.

Al ser tan "primitivo", no existen varios conceptos "modernos" de Scrum que hoy tanto se usan como las historias de usuario y la estimación en puntos de historias de usuario (o user story points), una práctica que junto a Scrum, es un avance muy significativo en la gestión de proyectos de software.

Lo que mas valoro de este libro primero es que haya sido escrito, permitiendo a mucha gente adoptar Scrum, y a que muchos otros mejores libros sobre el tema hayan sido escrito, como "Agile Project Management with Scrum" de Ken Schwaber (uno de los coautores del libro en cuestión). 

Para cerrar el artículo, vale mencionar que este libro me hizo reflexionar sobre la variable abierta en Scrum, que es el scope del sprint. Teniendo un equipo y un tiempo de sprint fijo, lo que puede variar en un sprint es el scope, siempre que se logre alcanzar el objetivo y se logre consenso con el product owner. 

Si se sienten curiosos y quieren ver como Scrum fue concebido inicialmente, les recomiendo que lean este libro, pero solo como material histórico, no para aplicar sus conceptos al pie de la letra ya que está bastante desactualizado. Como primer lectura sobre Scrum, les recomiendo el libro de Ken Schwaber mencionado arriba y para consejos prácticos no dejen de leer "Scrum and XP from the Trenches" de Henrik Kniberg.