Si bien diferentes opiniones son aceptadas, y supongo que ya habrá quien critique la falta de justificación con modelos matemáticos y otros que elogiarán la flexibilidad las Metodologías de Ágiles, hace ya un par de años que han modificado el mapa del Desarrollo de Software no sin antes hacer ruido.
Obviamente, y quiero hacer la aclaración de ante mano, no es que de aquí encontremos el camino al "Santo Grial", si se me permite la metáfora, ya esto lo ha dejado claro Fred Brooks en aquel recordado y ya mitico artìculo "No Silver Bullet" y en su obra cumbre "The Mythical Man-Month", pero si entiendo que merecen ser traídas a cuenta a fin de su analisis y su crítica al menos.
Entre estas metodologías ágiles encontramos a SCRUM, que surgió originalmente como un modelo de desarrollo de productos tecnológicos, pero Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993, y si bien goza de una popularidad menor a XP (Extreme Programming) es una opcion sustentable a la hora de gestionar un proyecto.
¿Qué es SCRUM?
En la última frase del párrafo anterior radica la clave para entender a SCRUM. No podemos encuadrarlo como una Metodología de Análisis y/o Diseño como puede ser UML o RUP, sino que es una forma de gestionar el trabajo. Se parte de la premisa de la imprevisibilidad del procesos de Desarrollo de Soft, por lo cual no se asume como algo definido y determinativo, sino como una caja negra, un proceso volátil, que no tiene un comportamiento lineal; de esta forma el proceso de desarrollo por ejemplo puede iniciarse con cualquier actividad, no se sigue una secuencia (análisis, diseño, codificación, etc).
Las Iteraciones
El proceso iterativo se repite en SCRUM, al igual que en UML o XP, por ejemplo. Una iteración en Scrum es denominada SPRINT y, por lo general, dura entre 15 días y un mes. Para comenzar cada SPRINT se define una lista de requerimientos o BackLog, los cuales deben estar satisfechos al fin de la iteración.
Hay ocasiones en las que se puede optar por Sprints más largos al comienzo (mes y medio o dos meses) ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos (una semana o dos) cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.
BackLog de Producto, BackLog de Versión y BackLog de Sprint
El BackLog de Sprint es solo una de las ramificaciones que podemos encontrar. En un proceso SCRUM podemos distinguir 3 tipos diferentes de BackLog:
El Product Backlog: es la lista de requerimientos del producto, cuando se encuentre completados el producto estará listo. A diferencia de otras metodologías se encuentra siempre en crecimiento y evolución, no se lo da por completado tempranamente, a fin de poder adaptarlo con el avance del proyecto. Retornamos a la premisa de la adaptabilidad.
El Release Backlog o Backlog de Versión: es un extracto del Product Backlog con las prioridades ordenadas segun su necesidad y urgencia para la próxima versión (release). Se especifican con un mayor detalle que los requerimientos del product backlog.
El Sprint Backlog: reúne aquellos requerimientos que se completaran durante el sprint. Al decir completar debe entenderse: codificar, testear y documentar. Si bien originalmente el BackLog de Sprint debía permanecer inmutable, hay otras posturas que sostienen que se puede decidir agregar o quitar tareas según vaya adelantado o atrasado el proceso (flexibilidad).
Los Roles en SCRUM
A primera vista podemos distinguir tres roles fundamentales:
Product Owner (Dueño del Producto): es quien esta mas interesado en los requerimientos funcionales del proyecto (Product Backlog), será quien lidere el desarrollo y el encargado de tratar con el cliente. Es el responsable del proyecto y de una etapa fundamental en SCRUM: la planificación.
Scrum Master: es quien hace de nexo entre el Product Owner y el Equipo. Es básicamente un moderador, encargado de asegurar la cooperación y el cumplimiento de la planificación funcional realizada por el Product Owner. No es necesariamente el líder del equipo, aunque es recomendable que tenga esta distinción a fin de facilitar su trabajo y que sus responsabilidades vayan acompañadas de una apropiada autoridad. Es el encargado de prevenir conflictos y de sacar el mejor provecho de cada integrante del equipo en las reuniones diarias.
El Equipo:debe tener entre 5 y 9 miembros (7 es lo teoricamente ideal) es el conjunto de personas, los encargados de efectivizar la resolución de cada sprint y especificar los resultados del trabajo. Estan autorizados a llevar a cabo casi cualquier actividad a fin de llevar a cabo el objetivo final de cada sprint. De considerarlo necesario puede fragmentar el Sprint Backlog en sub tareas a fin de facilitar la consecución de las mismas. El equipo posee reuniones diarias de no mas de 15 minutos donde se ponen en comun las tareas realizadas en el ultimo día y las a realizar durante el presente; en el desarrollo de las mismas es de vital importancia el Scrum Master para preguntar a cada miembro del equipo que hizo desde la última reunión, que problemas tuvo y con que tareas continuará.
Etapas de SCRUM
Scrum se compone basicamente de cinco etapas: revisión de planes de release, distribución, revisión y ajustes de estandares de producto, sprint, revisión de sprint y cierre.
Obviamente, y quiero hacer la aclaración de ante mano, no es que de aquí encontremos el camino al "Santo Grial", si se me permite la metáfora, ya esto lo ha dejado claro Fred Brooks en aquel recordado y ya mitico artìculo "No Silver Bullet" y en su obra cumbre "The Mythical Man-Month", pero si entiendo que merecen ser traídas a cuenta a fin de su analisis y su crítica al menos.
Entre estas metodologías ágiles encontramos a SCRUM, que surgió originalmente como un modelo de desarrollo de productos tecnológicos, pero Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993, y si bien goza de una popularidad menor a XP (Extreme Programming) es una opcion sustentable a la hora de gestionar un proyecto.
¿Qué es SCRUM?
En la última frase del párrafo anterior radica la clave para entender a SCRUM. No podemos encuadrarlo como una Metodología de Análisis y/o Diseño como puede ser UML o RUP, sino que es una forma de gestionar el trabajo. Se parte de la premisa de la imprevisibilidad del procesos de Desarrollo de Soft, por lo cual no se asume como algo definido y determinativo, sino como una caja negra, un proceso volátil, que no tiene un comportamiento lineal; de esta forma el proceso de desarrollo por ejemplo puede iniciarse con cualquier actividad, no se sigue una secuencia (análisis, diseño, codificación, etc).
Las Iteraciones
El proceso iterativo se repite en SCRUM, al igual que en UML o XP, por ejemplo. Una iteración en Scrum es denominada SPRINT y, por lo general, dura entre 15 días y un mes. Para comenzar cada SPRINT se define una lista de requerimientos o BackLog, los cuales deben estar satisfechos al fin de la iteración.
Hay ocasiones en las que se puede optar por Sprints más largos al comienzo (mes y medio o dos meses) ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos (una semana o dos) cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.
BackLog de Producto, BackLog de Versión y BackLog de Sprint
El BackLog de Sprint es solo una de las ramificaciones que podemos encontrar. En un proceso SCRUM podemos distinguir 3 tipos diferentes de BackLog:
El Product Backlog: es la lista de requerimientos del producto, cuando se encuentre completados el producto estará listo. A diferencia de otras metodologías se encuentra siempre en crecimiento y evolución, no se lo da por completado tempranamente, a fin de poder adaptarlo con el avance del proyecto. Retornamos a la premisa de la adaptabilidad.
El Release Backlog o Backlog de Versión: es un extracto del Product Backlog con las prioridades ordenadas segun su necesidad y urgencia para la próxima versión (release). Se especifican con un mayor detalle que los requerimientos del product backlog.
El Sprint Backlog: reúne aquellos requerimientos que se completaran durante el sprint. Al decir completar debe entenderse: codificar, testear y documentar. Si bien originalmente el BackLog de Sprint debía permanecer inmutable, hay otras posturas que sostienen que se puede decidir agregar o quitar tareas según vaya adelantado o atrasado el proceso (flexibilidad).
Los Roles en SCRUM
A primera vista podemos distinguir tres roles fundamentales:
Product Owner (Dueño del Producto): es quien esta mas interesado en los requerimientos funcionales del proyecto (Product Backlog), será quien lidere el desarrollo y el encargado de tratar con el cliente. Es el responsable del proyecto y de una etapa fundamental en SCRUM: la planificación.
Scrum Master: es quien hace de nexo entre el Product Owner y el Equipo. Es básicamente un moderador, encargado de asegurar la cooperación y el cumplimiento de la planificación funcional realizada por el Product Owner. No es necesariamente el líder del equipo, aunque es recomendable que tenga esta distinción a fin de facilitar su trabajo y que sus responsabilidades vayan acompañadas de una apropiada autoridad. Es el encargado de prevenir conflictos y de sacar el mejor provecho de cada integrante del equipo en las reuniones diarias.
El Equipo:debe tener entre 5 y 9 miembros (7 es lo teoricamente ideal) es el conjunto de personas, los encargados de efectivizar la resolución de cada sprint y especificar los resultados del trabajo. Estan autorizados a llevar a cabo casi cualquier actividad a fin de llevar a cabo el objetivo final de cada sprint. De considerarlo necesario puede fragmentar el Sprint Backlog en sub tareas a fin de facilitar la consecución de las mismas. El equipo posee reuniones diarias de no mas de 15 minutos donde se ponen en comun las tareas realizadas en el ultimo día y las a realizar durante el presente; en el desarrollo de las mismas es de vital importancia el Scrum Master para preguntar a cada miembro del equipo que hizo desde la última reunión, que problemas tuvo y con que tareas continuará.
Etapas de SCRUM
Scrum se compone basicamente de cinco etapas: revisión de planes de release, distribución, revisión y ajustes de estandares de producto, sprint, revisión de sprint y cierre.
La Revisión de Planes de Versión se realiza una vez establecido el Release Backlog y es llevada a cabo por el equipo a fin de evaluar las diferentes factibilidades de los requerimientos y estimaciones.
Los desarrolladores, a continuación realizan los ajustes de los estándares y dejan todo listo para comenzar con la etapa fundamental de SCRUM: los Sprints.
Es durante el sprint que el desarrollo propiamente dicho se efectiviza. Engloba diferentes tareas: codificación, test, documentación y revisiones. No existe una secuencia definida de como encarar las subtareas de cada Sprint.
Posterior al Sprint, se desarrolla una revisión del mismo, donde se evaluan los resultados con respecto al Sprint Backlog. En este punto se pueden hacer modificaciones al product Backlog en caso de detectar algún requerimiento que no haya sido tenido en cuenta desde un primer momento (de ocurrir esto debe tratarse de un requerimiento no funcional). Por último se planifica el proximo Sprint.
El producto queda ahora en la etapa de cierre del release y posterior distribución. Es la última oportunidad para efectuar depuración (debugging) antes de construir el entregable y dar el proceso por finalizado. Una vez más, y teniendo en cuenta la imprevisibilidad del proceso de desarrollo de software y su mencionada volatilidad es imposible establecer en qué momento exacto se llegara a este punto.
Como se dijo en la introducción, mas allá de algunas falsas creencias sobre las metodologías ágiles, no existe un "Santo Grial" que nos provea la salvación, y Scrum no es la excepción que confirme esta regla, pero si puede ser una buena forma de reducir el impacto de los cambios en la consecución de un Proyecto de Software.
Fuentes:
http://www.chuidiang.com/
http://www.ingenierosoftware.com/
http://es.wikipedia.org/
Explicación de lo entendido
El SCRUM es necesariamente importante para poder lograr un trabajo eficaz que provoque el menor impacto posible en perdidas futuras de falla de software para ello es que existen distintos pasos a seguir a fin de crear la secuencia “perfecta” como lo es product backlog (Release Backlog o Backlog de Versión)que da prioridad a los pasos más importantes de product backlog y Sprint back log que prueba testea “Arma el software” dentro de un gran grupo de trabajo compuesto por el jefe el que tiene la “idea en si” el tipo que organiza la reuniiones a fin de acordar lo que se está llevando a cabo dentro del soft. y los trabajadores “equipo” que son los que colocan la mano de obra .
o.O porque quedo haci? pareciera un copi/paste desde un PDF =S
ResponderEliminar