Buscar en Gazafatonario IT

Cargando...

lunes, mayo 27, 2013

Scrum Orgánico para Iniciantes

Advertencia: al final de este artículo podrás empezar a usar Scrum en tus proyectos.

Marco de Trabajo Scrum
Marco de Trabajo Scrum
Presentación
Cuando publiqué la lista de chequeo de Scrum, asumí que mis lectores ya conocían este método de desarrollo de software o que estarían familiarizados con el concepto de métodos ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé que  no hacía falta abordar los aspectos más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la primera incursión en esta forma de construir productos de software. Así es que decidí volver a lo fundamental. Aquí vamos otra vez.

Scrum es un marco de trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente. “Scrum es un marco de trabajo con el cual podemos afrontar problemas complejos y adaptativos y con el cual podemos emplear distintos procesos y técnicas, así como también podemos optimizar nuestra predictibilidad y tener un mejor control de los riesgos”[i].

Métodos Ágiles

Pero Scrum no es el único método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:

·         Adaptive Software Development (ASD)
·         Agile Unified Process (AUP)
·         Crystal Clear
·         Dynamic System Development Method (DSDM)
·         Essential unified process (ESSUP)
·         Feature Driven Development (FDD)
·         Lean Software Development (LSD)
·         Open Unified Process (OpenUP)
·         Extreme Programming (XP)
·         Kanban
·         Use Case 2.0

La Filosofía Ágil

Todos estos métodos tienen sus cimientos en lo que se conoce como Filosofía Ágil:

·         Usted no puede predecir o planear con absoluta certeza lo que va a entregar, cuándo lo entregará y cuánto será su costo.
·         Empiece con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la revisión continua de estas restricciones a medida que avanza.
·         La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es “mejor”.

Scrum

Scrum define explícitamente tres roles, cuatro ceremonias y dos artefactos principales. El Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes tienen bajo su responsabilidad entregar software probado y funcionando cada cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las actividades regulares de desarrollo de software, realiza cuatro ritos durante cada iteración que en Scrum se llama Sprint: Planeación del Sprint, Reunión Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el equipo actualiza la Bitácora del Producto y la Lista de Impedimentos.

Actores en Scrum

El Dueño del Producto es la persona encargada de maximizar el valor del producto elaborado por el equipo de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto y quien proporciona al equipo todo el conocimiento del negocio necesario para que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es el responsable de construir el producto, teniendo en cuenta las necesidades y prioridades del dueño del producto. En Scrum no existen roles especializados, es simplemente el equipo, comprometido todo con el éxito del proyecto.

Finalmente, el Scrum Master es un servidor, es quien vela porque se ejecute el proceso como está definido y que se lleven a cabo cada una de las ceremonias Scrum como está consignado en la Guía de Scrum. También es el encargado de introducir nuevas prácticas al proceso y al proyecto, acompañando de cerca su implantación y monitoreando los resultados. Es importante aclarar que el Scrum Master no es un gerente, aunque bien podríamos decir que hace parte de y reporta al área de manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el SM, el equipo Scrum no debe superar las 9 personas.

Ceremonias y Artefactos Scrum

En un proyecto gestionado bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una iteración de un tiempo máximo de 4 semanas. La industria del software está gritando a cielo abierto que este tiempo sea de solo 2 semanas. Al principio del Sprint se realiza la Planeación del Sprint. En esta reunión, el dueño del producto asiste con la Bitácora del Producto actualizada y priorizada, de acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se seleccionan algunos de los ítems de la bitácora, usualmente los de mayor prioridad, para ser desarrollados durante la iteración.

Estos ítems seleccionados conforman lo que se llama la Bitácora del Sprint, invariable por definición. A continuación, el equipo de desarrollo define cómo hará el desarrollo y estima el esfuerzo necesario para cada uno de los ítems, teniendo en cuenta que el esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas premisas, el Scrum Master elabora la Definición de Hecho y la comunica al equipo y al dueño del producto para su revisión, ajuste y acuerdo final. Esta “definición de hecho” se convierte en el “contrato” del sprint, define las cláusulas sine qua non el incremento del producto no satisface a su dueño ni a la organización.

Con la definición de hecho en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante 15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión, cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es para saludarse ni para hablar de asuntos que no estén relacionados con el proyecto o con las personas que lo ejecutan. Tampoco es para resolver los problemas expuestos.

De la reunión diaria sale actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión, por cada uno de los responsables de solucionarlos. En Scrum, el equipo es auto-gestionado, multidisciplinario y debería tener la capacidad de resolver sus propios problemas sin la ayuda de alguien externo. Hacia el final de la iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan la bitácora del producto si fuese necesario. En definitiva, el dueño del Producto verifica que se haya cumplido la Definición de Hecho.

Justo a continuación de la revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no repetiremos? ¿Por qué no se alcanzó la Definición de Hecho? ¿Qué hicimos bien que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en esta reunión. En esta sesión también deberíamos separar unos instantes para realizar una introspectiva: ¿Cómo está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones de mejoramiento podemos introducir a partir del siguiente Sprint?

Conclusión

Estos son, grosso modo, los elementos que subyacen el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil es algo que eres, no algo que haces. Una vez que puedes diferenciar esto, entonces convertirse en ágil será algo fácil. Extrapolando, una organización no puede forzar la filosofía ágil en su cultura, sino que debe permitir que su cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una forma de pensar y de ver las cosas.

Se me olvidaba decirles, la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.
Lecturas Adicionales
Mi artículo de Scrum Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

La lista de verificación de Scrum que desató esta serie de artículos  la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Otros sitios que pueden visitar para aprender más de Scrum y libros que pueden leer son:


  • http://www.scrum.org/scrumguides
  • http://www.scrumalliance.org
  • http://www.mountaingoatsoftware.com/
  • http://scrum.jeffsutherland.com/
  • http://www.controlchaos.com/
  • http://americalatina.pmi.org/latam/CertificationsAndCredentials/PMI-ACP/PMI-ACPExamPreparation/MaterialsAndResourcesInAgile.aspx
  • Essential Scrum: A Practical Guide to the Most Popular Agile Process. Mike Cohn.
  • Succeeding with Agile: Software Development Using Scrum. Mike Cohn.
  • Agile Project Management with Scrum (Microsoft Professional). Ken Schwaber.
  • Agile Product Management with Scrum: Creating Products that Customers Love. Roman Pichler.
  • Professional Scrum Development with Microsoft® Visual Studio® 2012. Richard Hundhausen.
  • User Stories Applied: For Agile Software Development. Mike Cohn.



  • [i] La Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff Sutherland, Todos los Derechos Reservados.


    No hay comentarios.:

    Publicar un comentario