Introduccion
¿Qué es DoR?
¿Por qué necesitas un DoR?
Dónde usar DoR
Cuando usar DoR
Modelo de INVERSIÓN
Conclusión
Referencias
Introduccion
Seguramente has escuchado más de una vez, probablemente incluso usaste el artefacto Scrum - Definición de Hecho con el equipo, en adelante - DoD. Quizás lo use sin siquiera darse cuenta. Se han escrito muchos artículos en ruso sobre DoD. Hablan de él en conferencias y entrenamientos. Comprender por qué se necesita este artefacto y encontrar ejemplos no es difícil. DoD define los criterios por los cuales cada miembro del equipo entiende que la tarea está cerrada. El objetivo más profundo es sincronizar el concepto de Hecho entre cada miembro del equipo. Por encima de estos criterios, a menudo, el equipo trabaja durante una retrospectiva. Existe un artefacto similar sobre el cual, por alguna razón, no se menciona a Scrum en los recursos de habla rusa, y donde se menciona este artefacto, no se explica qué es, por qué es necesario y cómo usarlo.
Lo más probable es que frases como la suya sonaran en su equipo: "Fallamos en el objetivo porque evaluamos incorrectamente la tarea", o "Nuestro PO regresó con la tarea sin una descripción adecuada". En mi equipo, tales "señales" aparecieron más de una vez, y durante mucho tiempo estuve buscando una forma de resolver este problema.
Definición de Ready, en lo sucesivo denominada DoR, me topé por casualidad en un chat de perfil dedicado a Agile. Intentando encontrar información, no encontré una sola mención en RuNet sobre este tema. Por lo tanto, fui a leer y traducir artículos en inglés. Ahora comparto el resultado con ustedes, espero que esto ayude a que su equipo sea aún más genial y productivo.
¿Qué es DoR?
Entonces, ¿qué es DoR? El traductor de Google le dirá que esta es una "definición de preparación". Si DoD incluye criterios para completar una tarea, entonces DoR - criterios para la preparación de una tarea para llevar a trabajar. Es decir, si una tarea cumple con los criterios de DoR, el equipo puede llevarla a la planificación del trabajo. Parece ser simple, probablemente ya comenzó a pensar cómo, finalmente, junto con el equipo, hacer una lista completa de los requisitos para su PO para que comience a escribir una tonelada de documentación, y el resto de los miembros del equipo puedan sentarse tranquilamente en su computadora y escribir código en silencio. Esto es solo el comienzo, y DoR no es lo que parece a primera vista.
¿Por qué necesitas un DoR?
Primero, respondemos la pregunta: ¿por qué se necesita este artefacto? ¿Qué beneficio traerá al equipo? DoR ayudará al equipo a:
- Evite comenzar a trabajar en funciones que no tienen una definición clara de los criterios de finalización. El equipo comprenderá cuándo se considera completa la historia del usuario y qué se debe hacer para hacer esto.
- No pierda mucho tiempo en vano en largas discusiones, tareas mal pensadas. Una tarea preprocesada ahorrará el tiempo de todo el equipo. Calcule cuánto tiempo lleva discutir una tarea "mala" para una persona. Ahora multiplique por la cantidad de personas en el equipo. Y ahora para el número de tales tareas.
- Concentre el tiempo y la energía en cosas que sean lo más "seguras" posible. Uno de los desmotivadores más potentes es la funcionalidad que se arroja al contenedor.
- Involucre a cada participante en la discusión de las tareas. En primer lugar, motiva al equipo. En segundo lugar, ayuda a revelar a cada miembro del equipo como especialista. En tercer lugar, los desarrolladores ofrecerán su propia visión del problema. Durante la discusión, pueden surgir otras soluciones que diferirán radicalmente de la idea original.
Echemos un vistazo a la lista de problemas que indirectamente o directamente resultan de la falta de DoR:
- Las discrepancias en la comprensión del problema aparecen regularmente entre los miembros del equipo. Al final del sprint, la discrepancia se intensifica, lo que conduce a incidentes cuando se producen cambios en el proceso de desarrollo, lo cual es natural. Pero en vista del hecho de que estos momentos no se registraron, solo el que los encontró directamente sabe de ellos.
- Los requisitos funcionales cambian más rápido de lo que el equipo logra comprenderlos. Dado que la tarea entró en el sprint, con una gran incertidumbre, para cuando la parte esté lista y se coloque la "base", aparece nueva información que requerirá un regreso al comienzo. Cuanto peor se resuelva la tarea, más a menudo surgirá tal situación en el sprint. Al final, esto conducirá a un fakap.
- A menudo hay problemas para evaluar el resultado obtenido de lo funcional, el equipo no sabe cómo recopilar métricas, o peor aún, se olvidó de ellas. Scrum se trata principalmente de los beneficios para el cliente, usuario o comprador. Si el equipo no evalúa los beneficios de la tarea, no recibe comentarios y la capacidad de ajustar el curso del desarrollo del producto. Esto puede conducir al fracaso completo.
- Además, la falta de DoR tiene un gran impacto en las pruebas, y en lugar de las expectativas de prueba de control de calidad en la historia del usuario, pondrá a prueba las expectativas de los desarrolladores. El código puede funcionar perfectamente, las pruebas automáticas funcionarán como un reloj, pero la funcionalidad no funcionará en Producción.
Al final, esto lleva al lanzamiento de un producto que no está funcionando, inútil, no resuelve el problema principal. Y esto es una pérdida de tiempo que todos quieren gastar en cosas importantes. En uno de los artículos, me encontré con un excelente dicho: "La basura entró, salió la basura".
Dónde usar DoR
Los DoR se utilizan en el refinamiento de la cartera de pedidos del producto en lo sucesivo denominado PBR o el nombre de artefacto más familiar: Grooming. Durante esta actividad, las historias de usuario se vuelven listas. Esto significa que el resultado del evento, en la cartera de pedidos del producto, es Ready US. Se necesita DoR para describir el estado en el que los EE. UU. Pueden ser discutidos sobre la planificación. Esto se llama Takin in - aceptado por los Estados Unidos.
Para ir más lejos, estoy prestando atención a cómo Jeff Sutherland, uno de los fundadores del manifiesto Scrum y Agile, habla sobre DoR y DoD en sus videos. Sutherland presenta los conceptos de Done-Done y Ready-Ready. Cuando un miembro del equipo dice que una tarea está lista o completada, se entiende que cumple con los criterios que el equipo definió en DoD y DoR, respectivamente. Este es un aspecto importante, cada miembro del equipo debe entenderlo y no olvidarlo. De lo contrario, surgen situaciones divertidas cuando Petya le informará al Daily que la tarea ya se completó, y luego resulta que las pruebas deben agregarse allí, y sería bueno refactorizar el código, y la Revisión del Código aún no ha pasado.
Por lo tanto, hasta que los EE. UU. Alcancen el estado Ready-Ready, no existe y no se discute en la planificación. La parte superior de la cartera debe ser solo de EE. UU., Con un estado Listo-Listo. La mejor manera de lograr esto es trabajar en los Estados Unidos con el equipo. Esto nos permitirá ver el problema desde diferentes ángulos, involucrar a cada miembro del equipo en el proceso y, posteriormente, desarrollar la responsabilidad colectiva de la funcionalidad lanzada. Los desarrolladores serán responsables del resultado y de la calidad ellos mismos si se dan cuenta de que este es el fruto de "su" trabajo conjunto.
Cuando usar DoR
Cuando el equipo comprende durante el PBR que la tarea no corresponde a DoR y conlleva demasiada incertidumbre, haga una lista de preguntas, elija un investigador y posponga la tarea hasta el próximo PBR. En mi equipo, se llamaba Investigación, pero luego cambiamos a Spike desde XP, porque pensamos que trae más resultados y claridad sobre el resultado del estudio. Asegúrese de limitar el estudio por tiempo y designe el resultado que desea obtener al final. Durante Spike, el investigador puede atraer cualquier ayuda externa, por ejemplo, miembros de otros equipos, metodólogos, OP, arquitectos ... en general, cualquier persona que lo considere conveniente. Resultado: respuestas a preguntas, nuevos datos, prototipo. Si hay muchas Historias de usuarios de este tipo, puede tomar 1-2 Picos en cada sprint para la próxima iteración, asegurando así un flujo constante de tareas de Listo.
Como se mencionó anteriormente, DoR es un conjunto de criterios. El equipo puede intentar componer estos criterios ellos mismos. Trabaje a través de esas "señales" que se rastrean en iteraciones. Discuta en retrospectiva estos puntos, encuentre la causa raíz. Si no desea pasar la próxima retrospectiva en esto, use soluciones preparadas.
Muchos artículos describen el modelo INVEST, que es similar a SMART, pero más adecuado para User Story. Además de los artículos, este modelo también se recomienda en la literatura de Agile. Por ejemplo, Roman Pichler en el libro "Product Management in Scrum" o Mike Cohn - "User Stories". Desarrollo de software flexible ".
Modelo de INVERSIÓN
- Independencia independiente: trate de evitar la creación de EE. UU. Que dependan unos de otros, ya que tales problemas causan problemas de priorización y planificación. El cliente puede elegir los EE. UU. Con una alta prioridad, que depende de la tarea con una prioridad más baja. Los Estados Unidos dependientes deben fusionarse, dividirse de manera diferente o aumentar.
- Negociabilidad negociable: EE. UU. No es una obligación o requisito contractual formal. Estados Unidos no es una tarea técnica. Durante el sprint, pueden y deben ser discutidos y enmendados. Una tarjeta con un historial, en cualquier forma que exista, es una breve descripción de la funcionalidad, cuyos detalles deben aclararse durante el trabajo. Deje notas en las tarjetas para generar discusión cuando se complete la tarea. Es importante encontrar un punto medio aquí, porque el exceso de notas, el equipo lo percibirá como información exhaustiva, y no habrá discusión en absoluto. Mi equipo se dio cuenta de esto muy rápidamente. Los detalles discutidos se convierten en pruebas que se pueden escribir en el reverso del documento o en el comentario en la tarjeta electrónica. Las pruebas de aceptación son simples y claras para todos.
- Valor valioso para el usuario o cliente: "Cada historia debe tener un cierto valor para el usuario", una declaración que es incorrecta. Olvídate constantemente del comprador. Enfoque, dependiendo de su empresa: B2C, B2B, B2G. Lo principal es evitar historias que sean valiosas solo para desarrolladores. Tales historias deben reformularse para que los beneficios se hagan evidentes y el cliente pueda establecer prioridades. No es necesario tirar las tareas arquitectónicas a la basura, explicar al cliente qué beneficios traerá dicha tarea y reformularla.
- Valoración estimada: los desarrolladores deberían poder estimar el tamaño de los EE. UU., Es decir, el tiempo aproximado que llevará implementarlo. Hay tres razones principales por las cuales la intensidad del trabajo puede no ser medible:
- El equipo carece de conocimiento de la materia
- El equipo carece de experiencia técnica.
- La historia es demasiado grande
En el primer y segundo caso, Spike te ayudará. En el tercero, EE. UU. Necesita descomponerse en otros más pequeños. - Compacidad pequeña: mucho depende del tamaño de los EE. UU., Los EE. UU. Demasiado grandes y demasiado pequeños son difíciles de evaluar. Es difícil trabajar con las epopeyas, ya que consisten en varios Estados Unidos. Las epopeyas se pueden dividir en dos tipos:
- Compuesto Aquí todo es simple: nos descomponemos. Considere el resto de los puntos, lo primero que probablemente sugiera el equipo: dividir los EE. UU. Por tipo de capa arquitectónica: por EE. UU. En una base de datos, backend, frontend, etc.
- Complicado El gran tamaño de los EE. UU. Se debe a su esencia, no se descomponen o es muy difícil. En este caso, usamos spike.
- Verificabilidad comprobable: la confirmación de que EE. UU. Se ha desarrollado con éxito, sirve como una prueba exitosa. Si no se puede evaluar a los EE. UU., El equipo no sabrá cuándo se completa la creación o se les ocurrirán los criterios. Además, cada miembro del equipo serán diferentes.
Conclusión
En conclusión: usando DoR, no eliminarás los espacios que se filtrarán en el sprint. Esto tampoco significa que durante el sprint no haya necesidad de un contacto constante entre PO y los desarrolladores. Registre constantemente los resultados de las discusiones en forma de pruebas de aceptación, para que ninguno de los equipos pierda la comprensión del estado de la tarea. Analice y discuta con el equipo los problemas actuales, quizás estén relacionados con la falta de DoR.
DoR es un artefacto que permitirá al equipo pensar mejor en los EE. UU., Lo que en última instancia reducirá los riesgos y permitirá que cada miembro del equipo discuta constantemente las tareas. Encontrará mucha información detallada sobre INVEST y User Story en el libro "User Stories". Recomiendo que cada miembro del equipo lea este libro, o al menos lo lea usted mismo y comparta información con ellos.
Escriba en los comentarios qué DoD y DoR se utilizan en su equipo.
Referencias
1) Roman Pichler "Gestión de productos en Scrum"
2) Mike Cohn "Historias personalizadas. Desarrollo de software flexible "
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com