Una historia de superación Érase una vez un equipo que quería mejorar su forma de trabajar....
42
Implementando Scrum Jose Luis Soria, Plain Concepts ALM Sessions ’12 #almsessions12
-
Upload
jose-luis-campos-fernandez -
Category
Documents
-
view
214 -
download
0
Transcript of Una historia de superación Érase una vez un equipo que quería mejorar su forma de trabajar....
Implementando ScrumJose Luis Soria, Plain Concepts
ALM Sessions ’12#almsessions12
Jose Luis Soria
ALM Team Leaden Plain Concepts
PST de Scrum.org
[email protected]://geeks.ms/blogs/jlsoria@jlsoriat
Text/Pic
¿Por qué otra sesión de Scrum con Visual Studio?
Fuente: State of Agile Development Survey 2011 http://bit.ly/AsvWvK
Fuente: State of Agile Development Survey 2011 http://bit.ly/AsvWvK
Una historia de superación
Érase una vez un equipo que quería mejorar su forma de trabajar.
Conocían Scrum, pero no estaban seguros de estar aprovechándolo al máximo.
Habían oído hablar de herramientas que podían ser de ayuda, pero desconocían cómo sacar todo el partido de ellas.
Afortunadamente, contaban con un buen Scrum Master, dispuesto a ayudar al equipo en su afán de mejora
Lo primero que hizo el Scrum Master, fue asegurarse de que todo el mundo conocía los fundamentos de Scrum.
El Manifiesto Ágil – El alma de Scrum
Estamos descubriendo formas mejores de desarrollarsoftware tanto por nuestra propia experiencia comoayudando a terceros. A través de este trabajo hemosaprendido a valorar:
Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.
Scrum en esencia
Scrum es un framework empírico para el desarrollo de productos complejos.
Se trabaja en iteraciones fijas de 2 a 4 semanas llamadas Sprints, que se suceden hasta que se completa el proyecto.
Los requisitos y peticiones de cambio se gestionan usando una lista ordenada y priorizada llamada Product Backlog.
El Product Backlog es gestionado por el Product Owner, que colabora con los interesados y con el equipo. El orden es determinado según el valor entregado.
Scrum en esencia (II)
El Scrum Master se asegura de que Scrum se aprovecha al máximo, entrena al equipo y gestiona problemas que surjan.
Los Equipos son auto-organizados y multifuncionales, y se componen de 6±3 personas.
Al principio de cada Sprint, se lleva a cabo la Reunión de Planificación de Sprint, en la que el equipo pronostica la parte del Product Backlog que será completada. El plan se refleja en el Sprint Backlog.
Scrum en esencia (III)
Para el final de cada Sprint, el Equipo intenta completar un incremento de funcionalidad de valor, potencialmente entregable, que se resume en el objetivo del Sprint.
Una vez que se ha seleccionado un objetivo del Sprint, el alcance, Equipo y duración se consideran fijos para ese Sprint.
Todos los días durante el Sprint, el Equipo lleva a cabo la reunión Daily Scrum, en la que se sincronizan los esfuerzos, se comprueba el progreso, se sacan a la luz impedimentos y se planifican los siguientes pasos.
Scrum en esencia (IV)
El estado del proyecto y de la iteración son conocidos en todo momento. Las métricas esenciales son el trabajo restante y la velocidad.
Scrum en esencia (V)
Al final de cada Sprint, el Equipo muestra el incremento que ha sido completado en la Revisión de Sprint. El Product Owner recopila todo el feedback a tener en cuenta para Sprints futuros.
Después, el Equipo mantiene una reunión de Retrospectiva para hablar de la marcha del Sprint e identificar acciones de mejora.
Durante todo el proyecto, el Product Owner promueve el “grooming” del Product Backlog, para introducir cambios y reordenaciones según las necesidades de negocio.
Después, se plantearon qué tipo de herramientas podrían ser útiles para aplicar todas esos conceptos y prácticas.
Tras mucho buscar, encontraron algo que podría cubrir la mayoría de sus necesidades.
Construyendo el Product Backlog
El Equipo Scrum quería aplicar cuanto antes los conceptos y prácticas que acababan de conocer.
“Pero, antes de empezar, deberíamos asegurarnos de que tenemos un buen Product Backlog”
Recuerda: sólo con los requisitos no es suficiente. Vas a necesitar el orden y las estimaciones.
El Product Owner construyó el backlog inicial, y pidió al Equipo ayuda para las estimaciones. Entonces tuvo mejor criterio para tratar con la ordenación.
Empezaron a utilizar las características de gestión de elementos de trabajo de Team Foundation Server.
Scrum Norris
Scrum Norris completa todo el Product Backlog en cada iteración.
Scrum Norris no estima. Él sabe.
Scrum Norris gana al Planning Poker
La Definición de Hecho
Una vez que el backlog inicial estaba listo, surgió una pregunta… ¿cómo podremos saber si hemos terminado de trabajar en un elemento en particular?
El Scrum Master se apresuró a responder: deberíais preparar una Definición de Hecho, que resuma las condiciones que se deben cumplir para que una funcionalidad se considere lista para ser entregada.
El Equipo acordó una Definición de Hecho, lo suficientemente buena para garantizar que entregarían valor al final de cada Sprint.
A continuación la publicaron en Team Foundation Server, para que todo el mundo pudiese consultarla cuando fuese necesario.
El Objetivo del Sprint
“Hemos llegado a la Reunión de Planificación de Sprint, y es el momento de pronosticar qué seremos capaces de completar. Nos vendría muy bien tener alguna pista….”
“Después, una vez que estemos a gusto con el pronóstico realizado, lo resumiremos en el Objetivo del Sprint, que servirá de guía durante la iteración.”
“Estaría muy bien tener una idea de nuestro rendimiento en el pasado, para poder hacer un pronóstico en base a esa información”
Enseguida se dieron cuenta de que esa información se la iba a proporcionar TFS, sin mucho esfuerzo. Así que hicieron el pronóstico, acordaron un Objetivo del Sprint y lo reflejaron todo en TFS.
Scrum Norris
La velocidad de Scrum Norris es de 50.000 puntos por Sprint.
El Sprint Backlog
La segunda parte de la Reunión de Planificación de Sprint fue dedicada a determinar cómo transformar los elementos del Product Backlog pronosticados, en un incremento de valor del producto.
El Equipo construyó un Sprint Backlog inicial, teniendo presente que se trata sólo de una ayuda para guiar el trabajo, y que, como tal, cambiaría y evolucionaría a lo largo del Sprint.
“Comenzaremos diseñando el trabajo, y descomponiendo las tareas resultantes para que tengan un tamaño manejable”
Como ya se habían familiarizado con la gestión de elementos de trabajo en TFS, trabajar con el Sprint Backlog no fue nada complicado.
Scrum Norris
Scrum Norris ya ha implementado todo al terminar la reunión de planificación.
Scrum Norris no planifica. Él ya sabe lo que hay que hacer.
Durante el Sprint
El Equipo comenzó a auto-organizarse para trabajar en los elementos pronosticados, sabiendo que el alcance no sería alterado durante el Sprint. Los Daily Scrums se sucedieron sin mayor problema.
El Sprint Backlog se actualizaba con regularidad, y las gráficas de Burndown reflejaban el progreso hacia el Objetivo del Sprint.
Mientras tanto, el Product Owner continuaba con el “grooming” del resto del backlog, evolucionándolo para que reflejase mejor las necesidades de negocio, y pidiendo ayuda al Equipo cuando lo necesitaba.
Completando el trabajo
El Equipo era consciente de que cualquier característica implementada, debía cumplir la Definición de Hecho, para poder presentarla en la Revisión de Sprint.
Se trataba de un Equipo multifuncional, así que consiguieron asumir casi todas las tareas que iban apareciendo.
El Scrum Master se mantenía alerta para asegurarse de que el Equipo trabajaba en un entorno adecuado, y de que cualquier problema era gestionado antes de convertirse en una amenaza para el Objetivo del Sprint.
Una vez más, el Equipo utilizó sabiamente las herramientas que tenían a su disposición
Visual Studio y Team Foundation Server están repletos de características útiles para el Equipo durante el Sprint.
Scrum Norris
A Scrum Norris se le permite llegar tarde a la reunión diaria.
Scrum Norris sabe que un burndown real necesita napalm.
Scrum Norris puede hacer Sprints de 6 meses.
Scrum Norris escribe primero el código, y después el test.
Tratando con lo inesperado
Un día, durante el Sprint, el Equipo se encontró con trabajo no planificado que debía ser realizado. Cuando actualizaron el Sprint Backlog para reflejarlo, el Sprint Burndown reveló que no iban a ser capaces de entregar todo lo que habían pronosticado.
Inmediatamente, el Scrum Master y el Equipo se lo comunicaron al Product Owner, para que pudieran decidir qué hacer.
Decidieron cancelar las subidas de sueldo al Equipo, y despedir a alguien, para que aprendiesen a tener más cuidado la próxima vez.
El Product Owner y el Equipo acordaron qué sacar del alcance en el Sprint actual, e intentaron aprender del error de cara al futuro.
La entrega
Se llevó a cabo la Revisión del Sprint, para que los interesados pudiesen ver qué había sido completado y expresasen sus opiniones sobre ello.
Todo el mundo tuvo la oportunidad de dar feedback, el cual se tuvo en cuenta para la evolución futura del producto.
El Product Owner se sirvió del Product Backlog y de la velocidad, para proyectar posibles fechas de entrega. También recogió todo el feedback para poder actualizar el backlog.
Mejorando
Tras la Revisión del Sprint, el Equipo siguió con la Retrospectiva, en la que trataron de resumir cómo había ido el Sprint que estaba terminando, buscando prácticas, herramientas, artefactos o cualquier elemento susceptible de ser mejorado, reutilizado o descartado.
Tomaron nota de los resultados de la Retrospectiva, y hablaron de cómo aprovecharlos
Una vez más, utilizaron las herramientas que tenían a mano para registrar y gestionar toda esta información.
Scrum Norris
Scrum Norris no hace revisiones o retrospectivas. No hay mejora posible para el proceso de Scrum Norris.
Al final, estaban listos para comenzar con el siguiente Sprint, siguiendo con el empeño de entregar valor.
Usando Visual Studio y Team Foundation Server, habían conseguido mejorar sustancialmente la forma en la que trabajaban.
Q&A, RecursosEnlacesMáquina virtual pruebas: http://bit.ly/aC5Lb2Plantilla VS Scrum 1.0: http://bit.ly/hmgkRUGuía de Scrum: http://www.scrum.org/scrumguides/Scrum Norris: http://bit.ly/dMsz01
Cursos Professional ScrumCalendario e información http://bit.ly/xc3rPEMadrid 12 de MarzoBilbao 19 de MarzoPalma de Mallorca 7 de MayoPamplona 4 de JunioMás fechas a publicar en breve, cursos privados
[email protected]://geeks.ms/blogs/jlsoria@jlsoriat
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
