Eficaces retrospectivas de sprints
David Starr es responsable de la creación de software para Scrum.org, donde se centra en la mejora de la profesión de desarrollo de software. También fundó la comunidad técnica en línea, ElegantCode.com.
Julio de 2012
Analizar las calidades básica y los procedimientos utilizados para garantizar Retrospectives son la herramienta más eficaz de mejora de un equipo. Ir más allá de las técnicas, este artículo proporciona maneras de mantener y mejorar la práctica y los resultados de Retrospectives.
Se aplica a
Administración del ciclo de vida de la aplicación, Visual Studio, Team Foundation Server
Aumentar la definición de terminado
Crear los compromisos procesables
Cuando no funciona Retrospectives
Sin deliberadamente mantener y mejora de rendimiento, la tendencia de los sistemas hacia entropía y reduce con el tiempo. Esto es tan true de los equipos de desarrollo de software como es de atletas profesionales y de coches de deportes costosos. Por eso scrum prescribe Sprint Retrospective, un evento con regularidad que aparece centrado en el estado y el rendimiento del equipo scrum propio.
Sprint Retrospectives es las reuniones en las que los equipos scrum reflejan en ellos y su trabajo, genera un plan procesable para mejorar. Sprint Retrospectives es el evento final de cada Sprint, marcar el final de cada ciclo de Sprint.
De guía de scrum de octubre de 2011:
Sprint Retrospective es la posibilidad de que el equipo scrum se inspeccione y cree un plan para que las mejoras son decretadas durante el siguiente Sprint.El propósito del Sprint Retrospective es:• Inspeccione cómo Sprint último se en lo referente a personas, las relaciones, en proceso, y herramientas;• Identifique y ordena los elementos principales que se bien y mejoras posibles; y,• Cree un plan para implementar mejoras a la forma en que el equipo scrum hace el trabajo.
Sprint Retrospectives es utilizado por los equipos para mejorar deliberadamente. Sprint eficaz Retrospectives es un ingrediente importante para ayudar a los buenos equipos es grande y grandes equipos se mantienen.
Información general
Porqué importan las retrospectivas de Sprint
Las retrospectivas se muestran ampliamente como el más imperativa de técnicas ágiles persona- enfocadas. Mentira de inspección y de la adaptación en el mismo núcleo de la agilidad, focus de las retrospectivas en inspeccionar y adaptar el activo más valioso de una organización de software, el equipo propio. Sin la prosecución de mejora como retrospectivas requiere, agilidad verdadera no es simplemente en funcionamiento.
El rendimiento se puede mejorar ni ni mantener sin práctica. Simplemente provocar una reunión no es bastante a efectuarse, sin embargo. La cuenta se debe prestar a asegurarse de equipos mejoras del plan. Si un plan a mejorar no forma parte del resultado, no era realmente Sprint Retrospective.
Cuando se realizan correctamente, las retrospectivas son a menudo la elaborados más beneficiosa procedimientos de un equipo. Cuando se hace mal, las retrospectivas pueden ser derrochadores y penosas de asistir.
Anatomía de un Healthy Sprint Retrospective
Scrum es poco sobre la estructura interna del Sprint Retrospectives. En lugar de prescribiendo cómo se dirige Sprint Retrospective, scrum especifica la salida del Sprint Retrospective: mejoras que el equipo scrum decretará para el siguiente Sprint.
Esta flexibilidad birthed una amplia gama de herramientas y las técnicas diseñadas específicamente para realizar retrospectivas. Varios procedimientos populares se describen más adelante en este artículo, pero independientemente de la técnica concreta utilizada, buen Sprint Retrospectives tiene estas características:
Contratan a todo el equipo
La descripción se centra en el equipo en lugar de individuos
La definición de equipo realiza se visita y se supone se expanda
Una lista de los compromisos procesables se crea
Los resultados de Sprint anterior Retrospective se visitan
La explicación es relevante para todos los asistentes
Todo el equipo scrum asiste a cada Sprint Retrospective. Normalmente, esto significa que el propietario del producto y el equipo de desarrollo asisten como participantes mientras el scrummaster facilita a la reunión. En algunos casos, los equipos scrum llama a otros participantes a la reunión. Esto puede ser especialmente útil al trabajar estrechamente con los clientes u otras partes interesadas.
Con independencia de quién asiste, el entorno para el Sprint Retrospectives debe ser seguro para todos los participantes. Esto significa que los asistentes deben ser honestos y transparente mientras tratan otros relativa. Las pasiones pueden iniciar en retrospectivas mientras que las aplicaciones el rendimiento y la mejora se tratan; los facilitadores expertos delimitados conversaciones permanecen positivos y profesional, centrarse en la mejora del equipo en conjunto. Esto no es una oportunidad para las críticas o el ataque personales.
(Para obtener más información sobre las herramientas de Microsoft Visual Studio 2012 para ayudarle a planear y administrar sprint, vea Colaborar [redirigido].)
Aumentar la definición de terminado
Los equipos de desarrollo en scrum utilizan una definición de realiza para dar cuenta de lo que debe ser true para su trabajo antes de que se considere completado. Por ejemplo, un desarrollo Team puede decidir que cada característica que implementa debe tener al menos una prueba de aceptación automatizada que pasa. O la definición de equipo realiza puede especificar que todo el código debe ser par revisado.
La definición de un Equipo de desarrollo de terminado está diseñado para expandir con el tiempo. Un equipo recién formado tendrá invariable una definición menos rigurosa y más pequeña de hace que un equipo más maduro con un historial compartido de mejora. Expandiendo la definición de un equipo de está listo en el muy básico de Kaizen, un término japonés que significa un enfoque escuchas y constante en mejorar. Mientras que un equipo puede requerir inicialmente solo que generar código antes de que se proteja, debe desarrollar con el tiempo estándares más exigentes como la necesidad de pruebas unitarias de para nuevo código.
Con cada Sprint, los equipos de desarrollo se supone aprenden algo que informa a la extensión la definición de terminado. Sprint Retrospective es el foro directo para analizar qué se observados y aprendidos durante el Sprint y qué cambios se pueden realizar en la definición de terminado como resultado.
Porque no cada propietario del producto tiene interés o implicación en procedimientos internos del equipo de desarrollo, algunos equipos scrum dividen Sprint Retrospective en dos diferentes fases:
Foco en todo el equipo scrum
El foco en el equipo de desarrollo
Para obtener más información sobre la definición de terminado, vea el artículo Tareas realizadas y no realizadas de MSDN.
Crear los compromisos procesables
Aunque la descripción puede divergir y converger durante la reunión, no hay Sprint Retrospective correctamente si no da lugar a los compromisos del equipo. No es suficiente para reflejar simplemente en lo que ha sucedido durante el Sprint. El equipo scrum pasa a los compromisos procesables para qué:
Al hacer Keep
Al hacer de inicio
Detenga el hacer
La palabra “procesable” es significativa. Los compromisos procesables tienen pasos claros completamente y los criterios de aceptación, como un buen requisito. Compromiso procesable es articulada y entendida claramente por equipo.
Cuando los equipos primero comienzan realizar retrospectivas, la encuentran a menudo más fácil identificar problemas que plan qué hacer sobre ellos. En consecuencia, los compromisos publicadas por equipo pueden parecer siguientes:
Trabajo en lotes más pequeños
Cree los requisitos más fáciles de leer
Escriba más pruebas unitarias
Sea más preciso al calcular
Éstas no los compromisos; son objetivos o denuncias quizás preciso veladas. Éstos son siempre problemas que combina puede desee discutir durante el Sprint Retrospective, pero una lista de los compromisos procesables se parece más a esto:
Protegen el código por lo menos dos veces al día: antes de almuerzo y antes de inicio que va
Nuevos elementos express de trabajo pendiente del producto como casos de usuario y criterios de aceptación de inclusión
Cree una prueba automatizada que produce errores que pruebe que un defecto existe antes de corregirlo
Utilice la planeación Poker durante las sesiones de preparar el trabajo pendiente del producto
Los compromisos adquiridos en el Sprint anterior Retrospective se visitan en cada nuevo Sprint Retrospective. Esto es necesario para que las retrospectivas conservar su significado y valor. Las pocas acciones son los frustrando como permanece en un equipo que continuamente confirmaciones a mejorarse sin progresar tangible para ello.
Para el Sprint Retrospective ser miembros del equipo valiosos debe estar más que el muestre, deberían invertir. La colaboración para crear los compromisos procesables contrata a asistentes y los invierte en el éxito del equipo.
Conservandola Relevant
Sprint Retrospectives es fundamental una técnica utilizada para revelar prácticas y comportamientos de Scrum Team a sí mismo. Cuando un sistema autogestionado deja de estar uno mismo- monitores, uno mismo- fijo y mejora deliberadamente cuando se le proporciona las herramientas para ello.
Para que las retrospectivas sean útiles, deben ser significativas para los participantes. Si el foco no está en algo valorado por los participantes, no realicen las ventajas simplemente. El equipo debe tener la posibilidad de ver y mejorar en áreas que cree es importante. Además, si un facilitador o una personalidad clave supervisa la reunión retrospectiva a una final concreta, el equipo evita asumir la responsabilidad de sí mismo y su trabajo.
Los temas visitados deben ser relevantes para todos los niveles de experiencia. Por ejemplo, hay algún valor de visitar puntos finos de escenario Prueba- controlada avanzadas de (TDD) de desarrollo si algunos miembros del equipo no son incluso familiarizados con las pruebas unitarias. El valor real puede estar en decidir aumentar el número de pruebas que el equipo está escribiendo, en obtener algún aprendizaje, o en tener un miembro del equipo confía en instructor de TDD otros.
Mantenga el foco en el equipo scrum, no el individuales, y no la organización mayor. El centrar holístico permite que el equipo auténtico se vea como unidad autogestionado, en lugar de como confederación separada de personas.
Las aplicaciones de direccionamiento el rendimiento individual no son adecuadas durante una reunión retrospectiva del equipo. No solo la información personal determinada más adecuadamente posible en comportamientos privados, individuales no es algo que el equipo puede cambiar junto. Tener el centrarse en un individuo durante el Sprint Retrospective es receta para el desastre y puede producir daños irremediable a la confianza del miembro del equipo entre sí.
Para que las retrospectivas es importante, deben centrarse en los problemas que el equipo puede controlar. La crítica de una directiva de empresa de vacaciones puede ser gratificante para el complainer que busca un oído comprensivo, pero hace poco para ayudarle a mejorar. La cuenta debe tener los problemas que el equipo puede afectarse, como la reacción puede elegir una directiva establecida.
Variación de la técnica
Hay técnicas numerosas para realizar retrospectivas. Intentando distintas construcciones de la reunión de Sprint Retrospective mantiene cosas nuevas e interesantes. Mientras que los facilitadores primarios para scrum combinan, los patrones de scrum deben por lo menos estar familiarizados con algunas de las técnicas más populares.
Hay libros completos acerca de retrospectivas y artículos blog en abundancia para ayudar a las personas a obtener la mayor parte del procedimiento. Algo de más popular se describe brevemente aquí.
Técnicas básicas
En el más básico de un facilitador de Sprint Retrospective hace simplemente las preguntas básicas del equipo y facilitan la discusión. El facilitador o el scrummaster puede utilizar diversas técnicas de la reunión de reflexión para obtener el equipo a:
¿Qué fue bien en este Sprint?
¿Qué sucedió en este Sprint que podría utilizar la mejora?
¿Qué confirmar a hacer en el Sprint?
Una técnica simple de derivar estas respuestas tiene cada escritura de miembro del equipo 2-3 respuestas a estas preguntas de notas rápidas durante un período minucioso 3-5 de silencio. Una vez que se crean, las sugerencias se agrupan en un muro para que todos ver antes de ser votado sobre. Una lista de los compromisos procesables se puede de esta manera derivar de la sabiduría colectiva del equipo.
La mayoría de las otras técnicas de Sprint Retrospective son variaciones de este tema y pueden centrarse en solo una pregunta o fase de este proceso. En cualquier caso, los resultados son los más importantes y cualquier buena técnica admite este modelo básico.
Revisar los compromisos anteriores
Además de anticipar a El siguiente, cada Sprint Retrospective debe incluir una revisión de los compromisos adquiridos en el Sprint anterior y una explicación sobre el éxito del equipo en cumplir estas compromisos. Si esta explicación no forma parte de cada Sprint Retrospective, los asistentes pronto ven que no importan sus compromisos, y dejen el cumplir de ellas.
Además, el lugar correcto para revisar los compromisos del Sprint Retrospective está en el Sprint, no solo en el extremo. Una vez que los compromisos para la mejora se protegen, enviarlas pueden ayudar públicamente las aseguran se consideran todos los días. Algo combina los compromisos de asociación de valor adquiridos durante el Sprint Retrospectives en la pared en un área pública como aviso todo el mundo qué debe centrarse en la mejora de cada día.
Técnicas especializadas
Hay muchas otras técnicas para realizar partes o conjunto de Sprint Retrospective. Los nombres de muchas técnicas se enumeran y cada uno es digno de la discusión detallada. Todos los siguientes son conectado bien documentado y en varias publicaciones.
Técnicas para Sprint Retrospectives
Fishbowl
Alegre triste incorrecta enojado
Estrellas de mar
Árbol de problema
Líneas de acción
6 Sombreros de reflexión
Retrospectiva elogiosa
Parte superior 5
Plan de acción
Instructor de carreras
The chasm
El juego de la perfección
El juego de mejora
Retrospectivas de velero
Análisis de campo de fuerza
Cuatro L
Café universal
Sismógrafo emocional
Dos determinado recursos enriquecidos para los facilitadores muy para expandir sus cuadros de herramientas retrospectivos son:
El sitio http://agileretrospectivewiki.org Web.
El libro Agile Retrospectives: Creando un Buen combina Great de Ester Derby and Diana Larson.
Sprint Retrospectives no es el patio de scrummaster. Tientan los patrones de acuñados scrum a veces para variar las técnicas descontrolado a de Sprint a Sprint. Mientras la variedad en retrospectivas impedir que los equipos el menor en una rodera, moderando esto con alguna coherencia hará que los mejores resultados. Los equipos que se centran en resultados procesables verán el valor de sus retrospectivas.
Cuando no funciona Retrospectives
Peor de ser ineficaz o una pérdida de tiempo, mal funcionamiento Sprint Retrospectives puede ser destructivo y malintencionado en el equipo. Por esta razón, teniendo una acción experta de facilitador recomienda la reunión muy, especialmente cuando los equipos son nuevos a la práctica.
La aceleración es normalmente el trabajo maestro de Scrum, pero para los patrones de Scrum nuevos al rol, esto puede no ser un área de especialización. Requiere más de un conocimiento práctico de scrum para Sprint Retrospectives tener resultados positivos; requiere funciones de la aceleración y la habilidad de provocar un grupo fuera de la discusión negativa hacia resultados positivos.
Olores comunes
Un ejemplo común de una retrospectiva incorrecta es una que deteriora en una sesión de la queja. Es mucho más fácil recordar que se mal que identificar las cosas que se correctamente, y un chorrito “las sugerencias de mejora” fácil convertir en un torrente de denuncias cuando el facilitador no redirige esta conversación.
Otros olores que no funciona Sprint Retrospective bien incluyen:
En la vista de la reunión retrospectiva un informe post-mortem” o “después- acción” “en lugar de una oportunidad de planear la mejora
Asistentes Unengaged
Un rendimiento person único Critiquing
Ninguna compromisos procesables resultantes
Si ningún “qué manamos” las respuestas; necesidad de equipos de entender y de apreciar sus comportamientos y procedimientos positivos así como negativos
En todas las situaciones anteriores, suele ser fácil traza la causa principal de la negatividad a una falta de confianza y de la memoria asignada de parte de uno o más miembros del equipo. Aunque no hay viñeta plateado para resolver esto, scrum carga específicamente el scrummaster con trabajar en situaciones de direccionamiento como éstas.
Funcionó se detuvo tan bien
Aunque Sprint Retrospectives sea eventos eficaces y valiosos, son un elemento normalmente descartado de scrum. Los equipos scrum correctamente reciente y regular tienden a racionalizar fuera la necesidad de resolver Sprint Retrospectives. Esto es suficiente como una persona apta que decide dejar de ejecutar.
La Meta- conversación puede suene algún como el siguiente:
Seis Meses después de Introducción ScrumDeveloper Dave: La calidad está hacia arriba, los errores está presionado. La moral es alto, costo manual de regresión es baja. Puesto que estamos hacerlo correctamente, no es necesario Sprint Retrospectives ayudarnos a mejorar más. Administrador Bob: Que suena razonable. La cancelación de esa reunión se guardará el tiempo que se puede pasar en agregar más características. Seis meses de LaterBoss Bob: Calidad ha interrumpido y errores aumentan. Descontentan a los miembros del equipo y gran parte del trabajo de regresión se harán manualmente. Desarrollador Dave: Se debe a scrum. Le indicamos que no fuera una viñeta plateado y no funciona obviamente. Administrador Bob: True. Encontraré a un consultor de la metodología para implementar un nuevo proceso.
Obviamente, no era scrum a error aquí. La decisión de organización para omitir un ingrediente clave de éxito de scrum era el catalizador para el error. Desgraciadamente este escenario es común demasiado.
Scrum combina alcanzando que el estado que más tenue de alto rendimiento es rara, hermoso, y frágil. Las retrospectivas significativas son un ingrediente significativo en conservar esos equipos trabajar en estos niveles. El reflejo sobre sí mismo permite el uno mismo- ajuste de equipo y alcanza incluso niveles de rendimiento y una calidad del producto más altos. Es la misma esencia de Kaizen, y base a cualquier programa real de mejora.
Cuando funcionan las retrospectivas, los resultados son palpables. Hay un entusiasmo en el equipo para intentar nuevas cosas. Cuando funcionan las retrospectivas, estos elementos se inevitable sean verdaderas:
El equipo alcanza niveles de calidad mensurable más altos y más altos en el tiempo
Individuos entender su rol en el contexto del equipo
Los compromisos procesables son conocidas por todos los miembros del equipo
Finalmente, cuando el trabajo del Sprint Retrospectives correctamente, el equipo crezca focused, productivo, y objeto de valor organization. Los equipos excelentes de desarrollo de software no aparecen simplemente. En el tiempo y después producen únicamente la atención deliberada para mejorar. Sprint Retrospectives es un ingrediente clave en esa aparición.