Scrum primer

INFORMACIÓN BÁSICA DE SCRUM
(THE SCRUM PRIMER)
Por Pete Deemer Gabrielle Benefield Craig Larman Bas Vodde Versión 1.1 Traducción de Leo Antoli Agile-Spain

Certified Scrum Training Worldwide | www.ScrumTI.com

Esta obra tiene licencia Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0. Para ver la licencia en español: http://creativecommons.org/licenses/by-nc-nd/3.0/es/Para ver la licencia en inglés y otros idiomas: http://creativecommons.org/licenses/by-nc-nd/3.0/us/ O manda una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

Nota al lector: Hay muchas descripciones concisas de Scrum en Internet, y este texto básico quiere proporcionar el siguiente nivel de detalle. Este texto no está pensado como lo úniconecesario para aprender Scrum; es recomendable que los equipos que estén pensando en usar Scrum tengan alguno de los libros de Ken Schwaber, Agile Project Management with Scrum o Agile Software Development with Scrum, y que examinen las opciones de cursos y coaching disponibles; se puede encontrar más información en www.scrumalliance.org. Agradecemos a Ken Schwaber, Jeff Sutherland y Mike Cohn sugenerosa contribución. © 2009 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde

2

Desarrollo tradicional de software
La forma tradicional de construcción de software que usan empresas de todos los tamaños es el ciclo de vida secuencial conocido normalmente como “en cascada”. Aunque hay muchas variantes (como el modelo en V), normalmente empiezan con una fase de planificación detalladadonde se piensa cuidadosamente en el producto final, se diseña y documenta en gran detalle. Se determinan las tareas necesarias para ejecutar el diseño, y el trabajo es organizado usando herramientas como diagramas de Gantt y aplicaciones como Microsoft Project. El equipo hace la estimación del tiempo de desarrollo sumando las estimaciones detalladas de cada uno de los pasos individuales. El equipoempieza a trabajar una vez que todos los interesados en el proyecto han revisado el plan concienzudamente y han dado su aprobación. Los miembros del equipo van completando su parte especializada del trabajo y se lo pasan a los siguientes, parecido a una línea de producción. Cuando se termina el trabajo, se manda al grupo de testing (a veces llamado grupo de calidad o de QA, “Quality Assurance”),que completan las pruebas antes de que el producto llegue al cliente. Durante todo el proceso se siguen estrictos controles para detectar desviaciones sobre el plan para asegurarse de que el producto es realmente el que se diseñó. Este enfoque tiene ventajas e inconvenientes. La principal ventaja es su lógica aplastante – piensa antes de construirlo, escribe todo, sigue un plan, y mantén todo lomás organizado posible. Solo tiene un pequeño inconveniente: participan personas. Por ejemplo, este enfoque implica que todas las buenas ideas se nos tienen que ocurrir al principio del ciclo de entrega, que es cuando podemos incorporarlas al plan. Pero como todos sabemos, las buenas ideas pueden aparecer a lo largo de todo el proceso –en el comienzo, en el medio, y a veces incluso el día antes dellanzamiento, y un proceso que no permita el cambio coartará esta innovación. Con el ciclo de vida en cascada una gran idea tardía no es una bendición, es una amenaza. El ciclo de vida en cascada pone gran énfasis en escribir todo como el principal método de comunicación de información crítica. La asunción razonable es que si puedo anotar en papel todo lo que tengo en la cabeza, será lo más fiablepara pasárselo a los demás miembros del equipo; además, si está en papel, hay una prueba tangible de que he hecho mi trabajo. La realidad, sin embargo, es que la mayoría de las veces nadie lee los documentos detallados de requisitos de 50 páginas. Y cuando se leen, los malentendidos se van acumulando. Un documento escrito es un dibujo incompleto de mis ideas; cuando tú lo lees, te creas otra...