En Scrum, ¿deberían gestionarse tareas como la configuración del entorno de desarrollo y el desarrollo de capacidades como subtareas dentro de historias de usuarios reales?

A veces, en proyectos, necesitamos dedicar tiempo a tareas como:

1. explorar marcos y herramientas alternativas
2. aprender el marco y las herramientas seleccionadas para el proyecto
3. configurar los servidores y la infraestructura del proyecto (control de versiones, entornos de compilación, bases de datos, etc.)

Si estamos utilizando Historias de usuarios, ¿a dónde debería ir todo este trabajo?

Una opción es hacer que todos formen parte de la historia del primer usuario (por ejemplo, hacer la página de inicio para la aplicación). Otra opción es hacer un pico para estas tareas. Una tercera opción es hacer que la tarea forme parte de un Problema / Impedimento (por ejemplo, entorno de desarrollo aún no seleccionado) en lugar de una Historia de usuario.

Pensamos mucho en este problema el año pasado.

Si bien estoy de acuerdo en que debe existir un marco básico antes de que comience el proyecto, en el uso práctico puede ser parte del proyecto en sí. Entonces tienes que manejar de alguna manera.

Si bien mezclar la configuración del proyecto con las historias de los usuarios puede tener sentido, a veces nos hemos decidido por tareas simples que se pueden agregar a la cartera de pedidos del producto y obtener la misma atención que las historias de los usuarios. Sabemos que estas tareas técnicas son necesarias a veces, pero deben justificarse en cualquier caso. Si el equipo piensa que son absolutamente necesarios para lograr un determinado objetivo, serán parte de un sprint.

Es difícil decir qué funciona mejor para ti, ¡así que experimenta ! Un pico puede ser suficiente por ahora, pero creo que terminarás con el mismo problema más tarde, así que planifica con anticipación. Realice tareas que sean un marcador de posición para tales actividades. Para separar las tareas de las historias dos, las compararé rápidamente en función de mi experiencia con ellas.

Tarea: Una tarea es una necesidad técnica. Pueden ser cosas para la administración de la configuración o la configuración general del proyecto, como configurar un repositorio para confirmaciones o agregar la herramienta de revisión de código más reciente que haya visto en el proceso de desarrollo. Las tareas deben considerarse en la planificación, igual que una historia de usuario. Si el equipo puede convencer al propietario del producto de que tener la última y mejor herramienta de revisión de código aumenta el rendimiento y mejora la comunicación del equipo al eliminar sesiones de programación de pares de larga duración o revisiones de código en persona, entonces atraerá la atención del propietario del producto.

Historias : centradas solo en la perspectiva comercial, las historias siempre producen un valor visible para el cliente. La calidad interna es algo que acompaña a la producción de valor comercial.

Incluso asignamos puntos de historia a tareas y, a veces, trabajamos con ellos de la misma manera que lo haríamos con historias.

Al final, buscaría esta solución en su caso (que también podría aplicarse en general):

1. Separe la "configuración" y las cosas técnicas en tareas (cosas que no producen directamente valor comercial para el propietario del producto).
2. Tal vez haga un pico antes de la configuración del proyecto para obtener las herramientas más importantes (SCM, herramientas de desarrollo, definición de procesos, estándares de codificación, etc.)
3. Acepte que estas tareas aparecen a lo largo de la duración del proyecto y planifique esto al tener un "tipo" separado de actividades que no sean historias.

Haga lo que tenga más sentido en su empresa. Nunca dejes que la forma en que otras personas hacen las cosas sea un obstáculo para el sentido común.

Pero diré que todas estas tareas suenan como algo que debería suceder mucho antes de comenzar el desarrollo. Así que me pregunto si Scrum es incluso relevante para estas tareas. Hay algo de mantenimiento continuo, como el control de origen y las bases de datos, pero estos no deben programarse, solo deben ser cosas que suceden y afectan su velocidad.

Habrá momentos en los que tendrá que seleccionar un marco o lo que sea durante un proyecto, pero cuando digo que me refiero a un marco como nHibernate, no a un marco como .NET. En esos casos, la investigación debe ser puntiaguda y de tiempo, por no mencionar bastante corta. Intente administrarlo como si tuviera un desarrollador enfermo por un par de días.

La transferencia de conocimiento es otro proceso continuo que debe gestionarse fuera de la velocidad general de desarrollo.

Hay un nombre para tomar tantas decisiones de diseño como sea posible antes del inicio "oficial" de su proyecto. Se llama cascada. No hay nada malo con las historias de los usuarios como, "Como desarrollador, necesito seleccionar un marco, por lo que tenemos un punto de partida para el sitio web". Si eso es demasiado grande para caber en una iteración, intente desglosarlo como: "Como desarrollador, necesito implementar una página de inicio básica en Drupal, para saber si se ajusta a nuestras necesidades".

Una opción es hacer que todos formen parte de la historia del primer usuario, por ejemplo, crear la página de inicio para la aplicación.

Rompe la "historia del usuario" como concepto. ¿Qué usuario está involucrado en esto? Ninguna. Este es un trabajo que ya deberías haber hecho.

Otra opción es hacer un pico para esto.

No está mal.

La tercera opción es hacer que la tarea forme parte de un problema (p. Ej., Entorno de desarrollo aún no seleccionado) en lugar de una historia de usuario.

Casi lo mismo que un pico en lo que respecta a la planificación y los gastos generales.

La configuración no es una historia de usuario.

Es lo que debe tener en su lugar incluso antes de comenzar este proyecto.

Realmente no puede comenzar el proyecto a menos que tenga el marco / herramienta y los servidores configurados y listos para funcionar.

Soy consciente de que muchas organizaciones realmente no existen hasta después de la firma del contrato. También soy consciente de que muchas organizaciones no eligen una tecnología hasta después de la firma del contrato. Todas estas son cosas ineficientes que están fuera de las historias de los usuarios.

En el trabajo utilizamos una tarea para preparar el medio ambiente. Puede ser confuso para algunas personas, pero la tarea que utilizamos es muy parecida a la tarea de una historia de usuario. La tarea no pertenece a una historia de usuario, pero se estima en horas y debe ser acordada por el propietario del producto para completarla en un sprint en particular.

También utilizamos la tarea para trabajos de arquitectura que no tienen un valor comercial "aparente" pero que agregan calidad al producto, particularmente para un producto existente con una base de código grande.

Es posible que no se apliquen en su entorno de trabajo, pero funcionó bien para nosotros.

Creo que estás mezclando dos cosas independientes. Una historia de usuario no debe incluir ningún detalle técnico.

La elección del marco, la configuración de repositorios y servidores, y otras tareas, debe ir a la iteración inicial.

Fui a un curso de Scrum recientemente y el instructor me sugirió que se usara un sprint especial llamado Sprint 0 para resolver exactamente este tipo de problemas. Hubo personas en el curso con diversos grados de experiencia en Scrum y casi todas las personas con experiencia estuvieron de acuerdo, diciendo que hicieron lo mismo. En algunos casos, las compañías utilizaron Sprint 0 para evaluar el proyecto y decidieron si era factible o no.

Para alguien nuevo en la metodología Scrum como yo, parece una solución fantástica porque lo mantiene libre de historias de usuarios y de todos los demás aspectos de un sprint normal, como los comentarios de los usuarios.

Como Sprint 0 es el mismo período de tiempo que tus otros sprints, actúa como una forma de asegurarte de que no pases demasiado tiempo configurando las cosas porque siempre se pueden ajustar más tarde. El punto principal es llegar a un estado en el que realmente pueda comenzar a desarrollar el producto.

en explorar 2-3 marco / herramienta alternativo

A veces esto puede suceder si tiene un requisito especial, tiene que hacer un POC para elegir la mejor herramienta para resolver el requisito. Para esto es para lo que Spike es porque, sin saber qué marco utilizará, lo más probable es que no pueda estimar la historia y almacenar sin una estimación no se puede planificar y dividir en tareas.

luego, al aprender el marco que seleccionamos para el proyecto

Bien. Esto es bastante peligroso. Cuando el cliente le paga por un SW, espera que usted sea un profesional que ya sepa cómo usar sus herramientas. El cliente no le paga por el aprendizaje o el enfoque de desarrollo de prueba / falla. Es responsabilidad del desarrollador aprender nuevas herramientas en su tiempo libre o en un tiempo asignado especial pagado por su empleado y no por el cliente. Gastar dinero del cliente para aprender sin informar al cliente no es profesional.

Si realmente tiene que usar algo especial (por ejemplo, alguna API del cliente o herramienta seleccionada por el cliente) que nunca usó antes, debe informarle al cliente que el precio se incrementará con el tiempo necesario para aprender a usar la API. Tal vez el cliente cambie de opinión si el aumento de precio será demasiado grande.

Claro, no me refiero a una situación en la que deba buscar algún problema nuevo en particular en el marco que ha utilizado muchas veces. Me refiero a la situación en la que comienzas a usar una nueva API o marco sin pasar un tiempo significativo (fuera del proyecto) para aprender.

Si viola esto, será visible en su velocidad de todos modos porque entregará una cantidad muy pequeña de valor comercial por iteración. Si el cliente no conoce la razón, probablemente cancele el proyecto.

Esto sigue siendo válido en el caso de proyectos internos: debe informar a su gerente / empresa sobre el tiempo necesario para aprender una nueva API o herramienta. Por lo general, tiene consecuencias muy malas si el gerente cuenta con su productividad normal y su productividad es solo una fracción debido a la nueva API que está tratando de aprender durante sus tareas. Obviamente, eso es aún peor si algunas personas de ventas calculan con una productividad normal cuando firman un contrato con el cliente.

sobre la configuración de los servidores (SVN, bases de datos, etc.)

Esa es su infraestructura y costos internos. Cuando comience el proyecto, se espera que tenga su infraestructura preparada. Configurar su entorno de desarrollo no tiene valor para el cliente y no debe formar parte de ningún indicador relacionado con el proyecto, por ejemplo, la velocidad en Scrum. Vi esto implementado como una iteración especial previa al proyecto utilizada solo para configurar el entorno, crear infraestructura básica, etc.