martes, 5 de noviembre de 2013

Acercamiento a Scrum


“Lo que conduce y arrastra al mundo no son las máquinas sino las ideas”
Víctor Hugo.
La Ley de Moore (ley empírica propuesta por Gordon Moore y que sugiere el desarrollo exponencial del número de transistores por chip de silicio cada dos años a menor costo), se hace cada día más tangible, tanto para los estudiosos del tema como para el usuario común de las TICs.
Aun así, el desarrollo de software es una actividad joven, que en muchos casos se alimenta de lo sembrado por otras profesiones y que genera talento humano que debe estar capacitado para abarcar la mayor área posible del conocimiento tecnológico.
Como deducirá el lector, es insuficiente circunscribirse a las herramientas propias del sector informático que se practique, analistas, “testers”, programadores, BDAs, entre otros; es por ello que el ingeniero, de cualquiera de las ramas tecnológicas, deberá tener una visión más amplia del negocio que permita alejar la habitual lucha a contrarreloj, a la vez que se ameniza y produce, mientras se cumple con los requerimientos de los “propietarios de productos” (cliente o contratante), quienes cada vez son más exigentes, quizás por suponer, erróneamente, que el desarrollo de dispositivos más potentes es extrapolable a la producción de software de calidad en menor tiempo.
Es por tanto un placer para el autor, poderles mostrar esta metodología y que, afortunadamente, es común en gran variedad de proyectos, como se verá en próximas líneas.
Para finalizar esta introducción, se advierte la existencia de tres (3) maneras básicas de proceder tras leer el presente trabajo, la primera de ellas, usar la estrategia propuesta como camisa de fuerza para los proyectos a realizar, la segunda, enviar todo lo aquí plasmado a la papelera y al olvido, y por último, acción que se recomienda, usar lo que se considere necesario, adaptándolo a cada desarrollo.
¿Qué es Scrum?

Originalmente, el scrum (melé en español), es un tipo de formación practicada en el rugby, en la cual los integrantes del equipo se apoyan entre sí para obtener el balón y debilitándose, si alguno de los integrantes cae.
Lo anterior sirvió como símil para Hirotaka Takeuchi e Ikujijo Nonaka, para explicar las observaciones realizadas a diversas empresas norteamericanas y japonesas (Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M, Xerox y Hewlett-Packard).
Es así, como empieza a definirse uno de los marcos de trabajo con más seguidores, bebiendo de las fuentes propuestas por el manifiesto ágil y que persiguen:
  • Valorar más a los individuos y su interacción que a los procesos y las herramientas.
  • Valorar más el software que funciona, que la documentación exhaustiva.
  • Valorar más la colaboración con el cliente que la negociación contractual.
  • Valorar más la respuesta al cambio que el seguimiento de un plan.
En la práctica
 
Llevar a la práctica la metodología que nos ocupa, significa tener presente lo siguiente:
  • Los elementos.
  • Las reuniones.
  • Los roles.


Los elementos
Product backlog
 
Son los requisitos del cliente, “traducidos” en funcionalidades que deben ser parte del sistema a desarrollar. Este servirá de base para la posterior generación de lo que en Scrum se conoce “sprint backlog”.

Sprint Backlog

Es la descomposición en funcionalidades y tareas del product backlog como consecuencia de la reunión de preparación de sprint.
Es común que se usen historias de usuarios en este caso, incluyendo nivel de prioridad (bajo, medio o alto).

El incremento


No es otra cosa que la sección del sistema producida durante el sprint, y que debe estar completamente terminada y operativa al finalizar.
Las reuniones

En scrum se realizan tres (3) tipos de reuniones básicas, que se suceden antes, durante y después de cada sprint (iteración que representa la unidad mínima de desarrollo con una duración de entre quince (15) y sesenta (60) días de trabajo) cumpliendo con las siguientes funcionalidades:
Preparación del sprint


El dueño del producto y el equipo de trabajo se reunen, la mayoría de las veces por un período de tiempo superior a cuatro (4) horas, utilizando el product backlog, el producto desarrollado hasta la fecha (excepto en la primera reunión) e información del entorno.
Como resultado de esta inversión de tiempo se obtiene la pila, duración y objetivo del sprint, y fecha de la reunión de revisión.


Seguimiento del sprint


Reunión breve, con una duración máxima de quince (15) minutos, en la que se utiliza la pila de sprint y la gráfica burn-down (de avance), obteniéndose una actualización de esta última junto a las respuestas de las siguientes preguntas:
  • ¿Qué se hizo ayer?
  • ¿Qué se hará hoy?
  • ¿Cuáles son los impedimentos u obstáculos?

Revisión del sprint
 
Reunión posterior a la culminación del sprint en la que el dueño del producto y el equipo de trabajo se reúnen con la finalidad de obtener feedback del sistema, información para mejorar el valor de la visión del producto y convocatoria para la siguiente reunión.
La reunión se puede dividir en introducción, demostración del sprint, preguntas y comentarios.


Roles
Propietario del producto

Es el solicitante y conocedor del proceso de negocio del sistema a desarrollar o cam,bios a implentar.
Equipo

Personas unidas a través de un objetivo común, que en el caso que nos ocupa, es desarrollar a través de funcionalidades un sistema que cumpla con los requerimientos del propietario del producto.
Líder de equipo

Es el encargado de que las normas del proyecto sean seguidas teniendo presente:
  • Asesoría al propietario del producto.
  • Asesoría y formación al equipo.
  • Revisión y validación del product backlog.
  • Moderación de las reuniones.
  • Resolución de impedimentos que se presenten durante el sprint.
  • Gestión del equipo.
  • Configuración, diseño y mejora continua de las prácticas de Scrum.

No hay comentarios:

Publicar un comentario

Danos tu opinión...