¿Cuándo es el mejor momento para crear tareas de historia?

Del mando y control a la autoorganización

Parece que su equipo (y tal vez su organización) está luchando con la transición del estilo de gestión de comando y control a ágil. Este artículo tiene algunos consejos.

Desde mi experiencia, aquí hay algunas cosas que podrían ayudar:

• ¿El propietario del producto describe el objetivo del Sprint al comienzo de cada reunión de planificación del Sprint? Esto ayudará al equipo a comprender qué se espera que logren y por qué.
• El Scrum Master no debe crear tareas. Esto debe dejarse en manos del equipo de desarrollo. Ellos son los que van a hacer el trabajo.
• ¿Cómo se estiman los puntos de la historia? Recomiendo el método de póquer de planificación . Todo el equipo de desarrollo tiene la oportunidad de familiarizarse con el trabajo que se realizará a continuación.
• Una forma de animar a los desarrolladores a participar es dividir la Planificación del Sprint en dos partes. En la primera parte de la Planificación del Sprint, el equipo puede analizar las historias en orden de prioridad, obtener aclaraciones sobre los requisitos y los criterios de aceptación del propietario del producto y comprometerse con la cantidad de trabajo que se puede realizar en el Sprint (según los puntos de la historia). . En la segunda parte, el Scrum Master puede dar un paso atrás y dejar que el equipo de desarrollo tome la iniciativa. El equipo crea tareas para cada historia en función de cómo pretenden lograrlo.
• Como sugirió @CodeGnome, envíe más personas a la capacitación Scrum. Si tiene un presupuesto ajustado, haga que los que ya están capacitados capaciten a los demás.

Introducción

La división de historias en historias más pequeñas debe ser realizada por el propietario del producto. Scrum Master y los desarrolladores pueden ayudar en eso, especialmente durante el refinamiento de la acumulación (preparación).

La división de historias en tareas (es decir, tareas técnicas) es solo responsabilidad del equipo de desarrollo ; se trata de CÓMO se implementarán las historias.

Así que creo que ni Scrum Master, PO ni usted (si no es un desarrollador) no deberían dividir las historias en tareas (técnicas).

Acabo de responder una pregunta sobre "¿quién?" y no "¿cuándo?", pero eso fue para aclarar. Ahora responde a tus preguntas:

respuestas

a) La respuesta a "¿Cuándo?" es, en mi opinión: durante la planificación del sprint . Creo que ninguna otra reunión formal está destinada a eso en Scrum. Además, siempre que alguien vea que se puede agregar una tarea a la historia, puede agregarla. Pero formalmente, CÓMO se implementarán las historias se discute entre los desarrolladores durante la reunión de planificación de Sprint.

b) Pídele al Scrum Master que deje de hablar ;), que deje de ingresar cosas a JIRA durante la reunión de planificación. Debe facilitar la reunión y alentar a los desarrolladores a hacer este trabajo y no hacerlo en su lugar. Entregue bolígrafos y etiquetas autoadhesivas con los nombres de las historias a los desarrolladores y permítales escribir en una etiqueta las tareas para esa historia. Y toma el teclado de Scrum Master . No lo necesita durante la reunión. Dáselo a otra persona.

Piense en el empoderamiento, en alentar la autoorganización del equipo de desarrollo. No empezarán a hacer este trabajo si SM lo está haciendo por ellos. Es necesario crear algo de "espacio". Haz que se sientan responsables de las soluciones técnicas, de dividir las historias en tareas.

c) SM debe apoyar a PO antes de la planificación en la creación y división de historias de usuario y hacerlas más comprensibles . ¿Él hace eso?

ACTUALIZACIÓN sobre a):

Las tareas como: diseño, pruebas, revisión deben ser parte de la Definición general de Hecho del equipo. No creo que sea necesario ponerlos en la historia durante la planificación. Depende de cuál sea el objetivo de agregarlos allí: visualizarlos para que el tamaño de la historia se pueda estimar bien o simplemente tener una lista de verificación si se realizaron todos los pasos.

Si es necesario para la estimación y el equipo prefiere tenerlo por escrito, está bien. Si el equipo quiere tener esas tareas en JIRA para tener una especie de lista de verificación (¿quieren? ¿O tú la quieres? :)), entonces un desarrollador cuando comienza a trabajar en una historia puede agregar esas tareas genéricas. Durante la planificación, sería suficiente mencionarlo; eso es algo que SM puede hacer: "muchachos, recuerden que también necesitan pruebas unitarias".

En mi equipo, las tareas agregadas a una historia durante la sesión de planificación son más como: agregar un nuevo botón a la pantalla A, crear una nueva pantalla B, crear una nueva tabla db, mejorar la consulta SQL. Usualmente ponemos tareas de "pruebas unitarias" cuando sabemos que en una historia específica esperamos mucho esfuerzo en hacer/mantener pruebas unitarias. Por lo general, no anotamos la tarea de "pruebas unitarias" en una historia, ya que todos sabemos que debe hacerse.

Este es el problema común al que se enfrentaron todos los que son nuevos en Agile. Porque Agile se trata más de asumir la propiedad y la responsabilidad que faltaba en otros métodos. Para responder tu pregunta..

1. Antes de ir a la reunión de planificación de Sprint, el analista comercial y el propietario del producto deben discutir y priorizar la lista de funciones que tiene de acuerdo con las necesidades de su negocio. Antes de priorizar, el Business Analyst debe dividir las funciones en tareas pequeñas y, con PO, estas deben priorizarse. De esta manera, cuando asista a la reunión de planificación de Sprint, puede evitar el tiempo en la discusión sobre las características que se abordarán.

2. Para lograr una mayor participación de sus desarrolladores, primero debe enseñarles cómo funciona Agile. Hágales entender que se supone que debe tomar posesión. Se puede hacer de una manera simple, en sus reuniones iniciales, evite a las personas del equipo de administración, haga que su equipo de desarrollo se sienta cómodo, asegúrese de que lo que hablen no se comunicará al equipo de administración. Pueden ser los primeros días en los que puede darles algo de tiempo, decirles que estas son funciones de acuerdo con la prioridad, volver a hacer una estimación del esfuerzo y dejar que el equipo sepa cuánto tiempo necesita, quién trabaja en qué función, etc. De esta manera, puede involucrarlos.

3. Como mencioné anteriormente, PO y BA deben reunirse antes de planificar la reunión y priorizar las historias de usuario que se tomarán para cada Sprint.

Como han indicado otras respuestas, en realidad se trata de propiedad. En mi experiencia, a los desarrolladores les gusta mucho resolver problemas, es lo que les da satisfacción en su trabajo. Por lo general, cuando veo un bajo nivel de interacción, es porque los desarrolladores sienten que les están dando una lista de cosas que hacer y simplemente están de acuerdo. Eso puede o no ser lo que está sucediendo, pero nunca he visto un caso de baja participación en el que esa no fuera la percepción.

Este es el mismo problema que tiene la cascada. El nivel 1, liderazgo empresarial, decide sobre algunos requisitos y los transmite al nivel 2, la PMO, luego hacen tareas y se las dan al nivel 3, los desarrolladores, que las hacen, luego volvemos a subir en la cadena y esperamos susurrar. el callejón no sucedió.

La clave es que todos los niveles estén comprometidos al mismo tiempo. El proyecto debe comenzar con el equipo obteniendo una visión de alto nivel de lo que están tratando de lograr en el proyecto, luego, a medida que aborda cada sección, antes de entrar en la planificación del sprint, examina las ideas y los requisitos con los miembros del equipo (¿no? No tiene que ser todos ellos si tiene un gran equipo. Su objetivo es lograr la participación y la aceptación, no matar la productividad). Por ejemplo, si tiene la intención de abordar los comentarios de los usuarios el próximo sprint, unos días antes, haga que el propietario del producto lleve al equipo a almorzar y diga "Necesito que los usuarios puedan dar su opinión con un solo clic desde cualquier página" - o cualquiera que sea la necesidad de alto nivel: "Al igual que este sitio, ¿qué piensan ustedes? ¿Cómo podríamos hacer que suceda X?" Tome esa conversación y solucione algunas historias básicas para trabajar durante la planificación del sprint. Ahora tienes la idea en sus cabezas durante unos días, tienen algunas ideas en marcha y entran en la planificación del sprint sabiendo de qué hablarán y listos para compartir algunas soluciones.

Descargo de responsabilidad: sé que esto rompe un poco el scrum porque está permitiendo que los PO y las partes interesadas distraigan al equipo de la tarea. En mi experiencia, los beneficios de lograr que el equipo compre y sea dueño de la solución superan con creces el hecho de que los distraiga de la tarea por un momento. Dicho esto, es algo a tener en cuenta y controlar: si comienza a salirse de control, vuelva a enrollarlo.

Esto también puede funcionar muy bien si no es común en otras reuniones. Los lanzamientos de proyectos y la planificación de lanzamientos, por ejemplo, también son buenos lugares para iniciar estas conversaciones. Dedicar más tiempo a realizar actividades de descubrimiento y generación de ideas en sesiones de planificación más amplias, como la planificación del lanzamiento, realmente puede dar sus frutos a lo largo del proyecto.

Una última cosa: no te preocupes demasiado por el tiempo que tarda. Tienes razón al preocuparte de que no haya participación, pero si las reuniones son productivas y duran todo el día, entonces tal vez ese sea el tiempo que realmente necesite. Cuando elige horarios arbitrarios para reuniones como esa, las personas se sentirán apuradas y se saltarán discusiones valiosas que causarán problemas peores más adelante.

Trabajamos básicamente en metodología Agile y trabajo para el equipo, que es casi similar, pero un montón de control de calidad, no los desarrolladores. Antes de responder a las preguntas, algunos conceptos básicos que necesita saber sobre las personas con las que está trabajando. Si presenta algo, no espere obtener respuestas, especialmente cuando presenta algo realmente nuevo. La motivación es realmente importante para ellos, reírse un poco y ser amigable los ayuda de alguna manera a abrirse a lo que les interesa en qué parte del desarrollo, ya que no todos pueden ser expertos en todas las funcionalidades que desarrollan. ¡Así que cavar en sus mentes en el tiempo libre inicialmente te ayuda a captar sus cerebros!

Respondiendo a las preguntas que nos planteas:

1. Asegúrese de que los desarrolladores se sientan cómodos para acercarse a usted cuando lo necesiten. En realidad, puede comenzar con sesiones como "Sesiones interactivas", donde todos y cada uno de los desarrolladores hablarán sobre el tema relacionado con el proyecto en particular o puede ser algo que esté presentando, y usted asignará el tema. ¡Esto debe ser informado previamente para estar preparado sobre esos temas y hacer que todos los escuchen! ¡Pídales que preparen de 10 a 15 puntos sobre el tema dado! Cualquiera puede hacer preguntas y preguntar por las dudas y eso sería obligatorio y en esas sesiones interactivas todos tienen que abrirse y hablar lo que quieran, ya que los miembros principales de las organizaciones no estarán en esas sesiones para que tengan esa libertad. A través de estas sesiones están bien preparados con el proyecto o tema de lo que quieres,
2. Puede involucrar a los desarrolladores después de estas reuniones consecutivas entre usted y los desarrolladores antes de que se presente el proyecto. Es difícil hacer esto al principio, pero una vez que les enseñas cómo hablar, qué preguntar y qué no. ¡entonces estoy seguro de que vas a golpear a la multitud! Bueno, esto puede suceder, pero solo a través del esfuerzo que pones. Como este es un escenario real, lo que te he dado como respuesta explicativa, ¡confío en que ganarás esto!
3. De hecho, lo recomendaría para que vaya a través del siguiente enlace para PO podría hacer antes de una planificación de Sprint: http://www.cs.fsu.edu/~baker/swe1/restricted/notes/scrum.html#(8) Por favor avíseme si estas respuestas son de alguna ayuda para usted. Gracias !