“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.
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.
Llevar a la práctica la
metodología que nos ocupa, significa tener presente lo siguiente:
- Los elementos.
- Las reuniones.
- Los roles.
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”.
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.
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:
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.
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.
