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?

23

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

explorar marcos y herramientas alternativas
aprender el marco y las herramientas seleccionadas para el proyecto
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.

— Asim Ghaffar
fuente

He cambiado un poco la pregunta para hacerlo más claro ... la pregunta ahora tiene subtareas dentro de historias de usuarios reales en lugar de historias

— Asim Ghaffar

12

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):

Separe la "configuración" y las cosas técnicas en tareas (cosas que no producen directamente valor comercial para el propietario del producto).
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.)
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.

— malta
fuente

Entonces, lo que llama TASK es básicamente un elemento de trabajo como User story o Bug? .. No es TASK como en las tareas dentro de las historias de usuario, por ejemplo, código, prueba, implementación, etc.

— Asim Ghaffar

2

Sí para distinguir entre los que llamamos subtareas de historias "Actividades".

— malte

Lo que llama Tarea es básicamente un problema según MSF para Agile 5.0

— Asim Ghaffar

Si hace referencia a esta descripción aquí: msdn.microsoft.com/en-us/library/dd997897.aspx : podría llamarlo un problema como se describió allí, creo que sería adecuado. Así que esa sería su opción número 3.

— Malte

2

El punto 3 "Aceptar que estas tareas aparecen durante la duración del proyecto" es especialmente importante. El proceso unificado ágil tiene una gran imagen que lo demuestra: i.stack.imgur.com/CUVFI.jpg . Tenga en cuenta que la disciplina de "medio ambiente" nunca desaparece realmente. También tenga en cuenta que la mayor parte del trabajo del entorno es por adelantado. Entonces, si de repente descubres que estás haciendo mucho trabajo de medio ambiente en una fase posterior, puede que algo salga mal.

— Michael

4

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.

— pdr
fuente

cuando dije framework ... era como si fuéramos para JSF o Spring ... o cuando dije herramienta ... era como si fuéramos para Jboss o Glassfish ...

— Asim Ghaffar

1

No sé a qué te refieres con "mucho antes de que comiences el desarrollo" ... cuando el proyecto comience, no deberías correr 1 comenzar lo antes posible, por ejemplo, dentro de las 2 semanas de la fecha de inicio del proyecto ... y en el sprint 1 hay una codificación real.

— Asim Ghaffar

1

@AsimGhaffar: No creo que deba, no. Si comienza a codificar antes de tomar decisiones como qué servidor de aplicaciones usar, tomará al menos una decisión que requiera que reescriba la mayor parte de ese código. Y no puedo imaginar comenzar un proyecto hoy en día sin configurar el control de fuente. Quiero decir, si tienes desarrolladores sentados, encuentra algo productivo para hacer, como prototipos. Pero no vaya directamente al proyecto hasta que haya tomado las decisiones clave.

— pdr

"no debería correr 1 inicio lo antes posible, por ejemplo, dentro de las 2 semanas de la fecha de inicio del proyecto". Correcto. Eso significa que su entorno está configurado y listo para funcionar. Ya está capacitado para usar las herramientas, hacer compilaciones e implementaciones. Si aún no está capacitado en estas cosas y el entorno no está configurado, entonces no está listo para comenzar.

— S.Lott

@ S.Lott hmm, pensé que uno adquiere las habilidades requeridas EN EL TRABAJO, es decir, mientras trabaja en el proyecto y no existe un requisito previo de herramienta de aprendizaje para el sprint 1.

— Asim Ghaffar

2

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".

— Karl Bielefeldt
fuente

1

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.

— S.Lott
fuente

el problema no es el mismo que Spike. Piense en el problema como un elemento de trabajo programado en el sprint normal pero no tiene puntos de historia. Ejemplo de problema: SVN no está seleccionado. Estoy tomando prestado el problema de MSF para Agile 5.0

— Asim Ghaffar

"El problema no es lo mismo un pico". Para las definiciones de las palabras, tienes razón. Pero cuando piensa en planificar un trabajo adicional antes del sprint 1, no importa si lo llama un problema o un pico. Elegir uno. Tirar una moneda. Cabezas

— S.Lott

Nuevamente, me refería al problema de programación junto con las historias dentro de Sprint 1, no antes de Sprint 1. Entonces, para Sprint 1, digamos que elegimos 2 historias de usuarios y 1 problema. Sin embargo, no hay puntos de historia para Issue. Spike será antes del sprint 1 ..

— Asim Ghaffar

Pico o problema no importa. Todo es trabajo que no forma parte de una historia de usuario. Todo es trabajo que debe hacerse antes del primer sprint. Puedes llamarlo un pico o un problema, lo que sea que te haga feliz. Pero es no una historia de usuario.

— S.Lott

1

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.

— Chris Chou
fuente

0

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.

— BЈовић
fuente

tiene razón y no estoy sugiriendo incluirlos en la descripción de la historia ... lo que quise decir era tener tareas como "instalar MySQL", "evaluar el marco" como parte de la primera historia real del usuario ... es decir, como usuario que quiero una página de inicio para tener acceso rápido a funciones esenciales.

— Asim Ghaffar

@AsimGhaffar Eso se puede hacer en la iteración inicial. No como una historia de usuario, ya que los usuarios no necesitan saber (ni les debe importar) qué tecnología usó para satisfacer sus necesidades.

— Bћовић

0

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.

— Stuart Leyland-Cole
fuente

3

Citando a Alistair Cockburn , tengo el presentimiento de que alguien estaba presionado sobre su uso de Scrum cuando hizo algo que no tenía un valor comercial obvio al principio, e inventó "¡Oh, ese fue Sprint Zero!" para alejar a los campesinos con los picos de su puerta.

— Asim Ghaffar

0

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.

— Ladislav Mrnka
fuente

Estamos en el desarrollo de productos, no en proyectos de clientes :).

— Asim Ghaffar

Okay. En tal caso, debe seguir por separado el tiempo dedicado al aprendizaje y la infraestructura para ver qué gastos generales tiene. Ocultar este tiempo dentro de las tareas corromperá la visibilidad de su proceso de desarrollo.

— Ladislav Mrnka