Does Everything Have to Be a User Story? Ron Jeffries & Chet Hendrickson - LeadingAgile SoundNotes

Summary

En esta conversación, se discute el enfoque de gestión de proyectos ágiles, especialmente en relación con el uso de historias de usuario. Un gerente introduce la idea de que todo debe escribirse en formato de historia de usuario, lo que genera críticas sobre la rigidez de este enfoque. Se argumenta que, aunque las historias de usuario pueden ser útiles, no deberían seguir un formato tan estricto ni ser aplicadas a todas las tareas. El énfasis está en la importancia de expresar necesidades, no imponer un formato rígido para todo. También se menciona la distinción entre tareas del equipo y la responsabilidad del Product Owner.

Takeaways

• 😀 El formato de historias de usuario no debería ser rígido ni prescriptivo, ya que lo importante es la conversación y la confirmación entre las partes involucradas.
• 😀 Las historias de usuario no necesitan seguir un formato específico como 'Como [rol], quiero [acción] para [beneficio]'. Este formato puede ser útil al principio, pero no es necesario para todos los casos.
• 😀 El proceso de escritura de historias de usuario debería centrarse en expresar necesidades, no en definir cómo se harán las cosas o en imponer formatos rígidos.
• 😀 La autoorganización de los equipos de trabajo es clave, y no debería haber un dictado centralizado sobre cómo escribir las historias o sobre el enfoque a seguir.
• 😀 Los gerentes o líderes deben enfocarse en expresar lo que necesitan, no en dar instrucciones específicas sobre cómo hacer el trabajo.
• 😀 Las historias de usuario deben estar orientadas a facilitar la conversación y aclarar qué se necesita y por qué, no a imponer un formato en particular.
• 😀 En lugar de forzar un formato, se recomienda que las historias de usuario expresen lo que se quiere lograr, dejando que el equipo decida cómo alcanzarlo.
• 😀 Los gerentes que exigen un formato específico para todas las historias de usuario probablemente buscan comprender el trabajo del equipo, pero están abordando el problema de forma equivocada.
• 😀 No todo lo que hace un equipo debe estar en el backlog. Solo lo que el Product Owner quiere o necesita debe formar parte de este.
• 😀 Las tareas operativas o fuera del alcance del desarrollo, como la compra de servidores, deben gestionarse a través de otros sistemas o tableros, no necesariamente con historias de usuario dentro del marco Scrum.

Q & A

¿Por qué se menciona que el formato de las historias de usuario no es útil en este contexto?

Se menciona que el formato de las historias de usuario, como 'como administrador de base de datos quiero adquirir un servidor', no es útil porque no refleja el enfoque conversacional y la flexibilidad que se espera de las historias de usuario. El formato de historia de usuario debe ser una tarjeta de conversación y confirmación, no una receta rígida.

¿Qué significa que las historias de usuario deben ser una 'tarjeta de conversación'?

Las historias de usuario deben facilitar la comunicación entre el equipo de desarrollo y las partes interesadas. No deben ser fórmulas estrictas, sino una forma flexible de asegurar que las necesidades del usuario sean entendidas y discutidas claramente.

¿Por qué se critica el enfoque de establecer todas las tareas en un formato rígido de historia de usuario?

El enfoque se critica porque limita la agilidad y la flexibilidad del proceso de desarrollo. Si se obligan a escribir todas las tareas como historias de usuario rígidas, se pierde el foco en la colaboración y la capacidad de adaptación que la metodología ágil promueve.

¿Qué problema se menciona en relación con la autoorganización en el contexto de la gestión ágil?

El problema destacado es que si un gerente impone una estructura rígida sobre cómo deben organizarse las tareas, como obligar a todos los equipos a usar un formato específico de historias de usuario, esto va en contra del principio de autoorganización de los equipos ágiles. Los equipos deben decidir cómo abordar sus tareas de forma autónoma.

¿Qué necesita el gerente según la transcripción y cómo debería recibir esta información?

El gerente necesita tener visibilidad sobre lo que todos los departamentos están haciendo, pero debería recibir esta información de manera flexible y no rígida. En lugar de imponer un formato, debería pedir que los equipos expresen sus necesidades y lo que están trabajando, dejando que los equipos decidan cómo organizar y comunicar su trabajo.

¿Qué diferencia hay entre lo que un propietario de producto y un gerente deben proporcionar a los equipos?

El propietario de producto debe proporcionar la visión general de lo que necesita ser construido, pero sin imponer detalles específicos sobre cómo se debe hacer. En cambio, el gerente debe expresar lo que necesita en términos de resultados y necesidades, sin imponer cómo se deben cumplir esos requisitos.

¿Por qué se menciona que el formato de historia de usuario es útil como una 'rueda de entrenamiento'?

El formato de historia de usuario se menciona como una 'rueda de entrenamiento' porque es útil para los equipos nuevos en la metodología ágil para empezar a comprender y organizar su trabajo. Sin embargo, una vez que el equipo gana experiencia, deben abandonar este formato rígido y adoptar un enfoque más flexible y colaborativo.

¿Cuál es la crítica hacia la idea de que todas las tareas deben ser puestas en el backlog?

La crítica es que no todas las tareas realizadas por el equipo deben estar en el backlog. Solo las tareas relacionadas con las prioridades del propietario del producto deben estar allí. Otras tareas, como ordenar servidores, deberían ser gestionadas por otros sistemas, como un tablero Kanban, y no necesariamente tener que ser representadas como historias de usuario en el backlog.

¿Por qué no se debe aplicar la metodología Scrum en departamentos que no están directamente relacionados con el desarrollo de software?

La metodología Scrum no debe aplicarse en departamentos que no están directamente involucrados en el desarrollo de software porque no tienen los mismos ciclos y actividades que el desarrollo de productos. Por ejemplo, en el caso de ordenar servidores, ese proceso no debe seguir un enfoque Scrum, sino que debería ser gestionado con un sistema más adecuado como Kanban.

¿Cuál es la importancia de que el equipo decida cómo abordar su trabajo según la metodología ágil?

La importancia radica en que la autoorganización permite que los equipos sean más eficaces y ágiles, tomando decisiones basadas en sus conocimientos y habilidades. Al permitir que el equipo decida cómo abordar las tareas, se fomenta la innovación y se mejora la eficiencia en el proceso de desarrollo.