Scrum y XP (1)

Hola, muchas veces cuando debemos desarrollar o implementar rapidamente un software, tenemos demasiado poco tiempo, sobre todo cuendo el asunto es partir de cero y no tenemos tiempo para análisis, modelamiento perfecto de UML, etc.

Para estos casos se ha puesto de moda Scrum y XP, ambas son tecnicas de desarrollo agil de software.

Los equipos de trabajo deben conocer los principios de Scrum. ¿Cómo se crea y se estima una pila de producto? ¿Cómo se transforma en una pila de Sprint?
¿Cómo se gestiona un gráfico de burn-down y se calcula la velocidad del equipo?

Para responder esto veremos una introducción practica de Scrum.

La ejecución correcta de Scrum se está convirtiendo en un factor cada vez más importante para los equipos que buscan inversión de capital.

¿Por qué es esto tan importante? Si los equipos no conocen su velocidad, el Dueño de Producto no puede crear una hoja de ruta del producto con fechas de lanzamiento creíbles. Sin fechas de lanzamiento fiables, la ompañía podría fracasar y los inversores perder su dinero.

Tanto Scrum como Programación Extrema (XP) requieren que los equipos completen algún tipo de producto potencialmente liberable al final de cada iteración. Estas iteraciones están diseñadas para ser cortas y de duración fija.
Este enfoque de entregar código funcional cada poco tiempo significa que los equipos Scrum y XP no tienen tiempo para teorías. No persiguen dibujar el modelo UML perfecto en una herramienta CASE, escribir el documento de requisitos perfecto o escribir código que se adapte a todos los cambios futuros imaginables. En vez de eso, los equipos Scrum y XP se enfocan en que las cosas se hagan. Estos equipos aceptan que puede que se equivoquen por el camino, pero también son conscientes de que la mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel teórico de análisis y diseño y sumergirse en él, ensuciarse las manos y comenzar a construir el producto.

Este es un proceso de aprendizaje continuo, así que la historia no acaba aquí.
Estoy convencido de que esta empresa seguirá aprendiendo (si se siguen haciendo las Retrospectivas de Sprint) y adoptando nuevas perspectivas sobre las mejores formas de implementar Scrum en su contexto particular.

Si necesitas averiguar más antes de seguir puedes ver los siguientes link's

• http://agilemanifesto.org/
• http://www.mountaingoatsoftware.com/scrum
• http://www.xprogramming.com/xpmag/whatisxp.htm

Sino, no importa, veremos la forma practica de implementar scrum rapidamente, bueno eso es en realidad, imprimir energia y rapidez al desarrollo de software.

Pila de producto.
La pila de producto es el corazón de Scrum, y simplemente es la priorización de los requisitos que debe tener una aplicación solicitada por el cliente.
A esta lista de requisitos le llamamos historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente. Llamamos a esto historias, o a veces simplemente elementos de la Pila.
Esta pila de requisitos puede ser escrita en una planilla excel de manera simple para que el cliente la entienda en su lenguaje natural, dejamos de lado aqui los administradores de tareas como Jira u otros bug-tracker.

Para hacerlo simple y productivo nuestra pila de producto (lista priorizada de requisitos) contiene los siguientes campos:

• ID – un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.
• Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de transacciones”. Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos
hablando, y suficientemente clara como para distinguirla de las otras historias. Normalmente, 2 a 10 palabras.
• Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, 10. O 150. Más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la
“máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?
• Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”. Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas
sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4 puntos).
• Como probarlo – una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y
entonces debería ocurrir aquello”. Si practicas TDD (Test-Driven Development, desarrollo orientado a test) esta descripción puede usarse como pseudo-código para vuestro test de aceptación.
• Notas – cualquier otra información, clarificación, referencia a otras
fuentes de información, etc. Normalmente muy breve.

Ejemplo de Pila de Producto:

Sigamos, vemos en la tabla anterior la implementación de una pila de producto simple, falta completar campos, como la estimación, prueba y notas, estos deben ser completados en conjunto con el equipo Scrum (equipo de desarrollo).

En la practica se pueden agregar otros campos, pero a la larga estos son los mas recurrentes tras los Sprint.

Como mantenemos la Pila de Producto a nivel de negocio.
Si el Dueño de Producto tiene una formación técnica, puede que añada historias del tipo “añadir índices a la tabla de eventos”. ¿Por qué quiere algo así? El auténtico objetivo probablemente será algo como “aligerar el formulario de búsqueda de eventos en el backoffice” (con un índice).
Puede ocurrir que los índices no fueran el cuello de botella que hiciera al formulario ir lento. Puede que fuera algo completamente diferente. El equipo está normalmente mejor capacitado para averiguar como resolver algo, así que el Dueño de Producto debería concentrarse en los objetivos de negocio y no en modificarnos la pila luego de los requisitos ya vistos y entregados.

Pronto, va la segunda parte de este doc. de Scrum.

Saludos y Suerte !!