project-management - tareas - scrum

Rompiendo la primera historia de usuario de un proyecto en tareas (5)

Estoy comenzando un nuevo proyecto desde cero y he escrito User Stores para describir cómo un usuario determinado interactuará con el sistema. Pero estoy teniendo problemas para entender cómo dividir la primera historia de usuario en tareas sin que la primera se convierta en una epopeya.

Por ejemplo, si estuviera construyendo un automóvil y la primera historia de usuario decía algo así como "Como conductor, me gustaría poder cambiar la dirección del movimiento para no golpear las cosas", eso implicaría que un usuario interfaz (volante), pero también movimiento (ruedas) y todo lo necesario para unirlas (eje, marco, varillaje, etc.). Al final, esa primera historia de usuario siempre parece representar aproximadamente el 40% del proyecto porque implica mucho sobre la arquitectura subyacente.

¿Cómo se rompen las historias de los usuarios de un nuevo proyecto de modo que el primero no se convierta en una epopeya que represente toda su arquitectura subyacente?

Cuando comenzamos los proyectos con un estilo de administración de Scrum, el primer conjunto de tareas siempre fue amplio, o como usted lo describe: épico. Eso es inevitable, el marco de cualquier proyecto suele ser la parte más importante, más grande y que consume mucho tiempo, pero es compatible con el resto del proyecto. Con el fin de reducir la escala de la abrumadora cantidad de lo que hay que hacer, ver si puede enumerar las partes MÁS esenciales. Luego, trabaje en la definición de esas tareas como puntos de partida. Por lo tanto, tiene algunas tareas como puntos de partida para un comienzo amplio. Espero que tenga sentido!

Es posible que desee considerar su historia como una porción vertical del sistema. Una historia puede (y con frecuencia lo hará) tocar componentes en todas las capas arquitectónicas del sistema. Por lo tanto, es posible que desee pensar en sus tareas ya que el trabajo debe hacerse en cada uno de los componentes que toca su historia .

Por ejemplo, supongamos que tiene una historia como. Para poder seguir fácilmente los tweets de mis amigos, como usuario registrado, quiero seguir automáticamente todos mis contactos de Gmail que tienen cuentas de Twitter.

Para lograr esto, deberá pasar a través de la capa UI, capa de servicio, persistir algunos datos en la capa de datos y realizar una llamada API a twitter y gmail.

Tus tareas pueden ser:

Agrega una opción al menú
Agregar una nueva pantalla de autenticación de Gmail
Agregar una pantalla de autenticación de Twitter
Agregar una pantalla de selección de contacto
Agregue un controlador que llame a su capa de servicio
Escribe un nuevo servicio que haga el trabajo
Guardar contactos en la base de datos
Modifique su servicio existente de llamadas a la API de Gmail para obtener contactos
Agregue un servicio de llamadas de Twitter API para seguir los contactos seleccionados

Allí: son 9 tareas posibles allí mismo. Ahora, como regla general, desea que sus tareas tarden aproximadamente 1/2 día a 2 días, con un sesgo hacia un día (mejor práctica, para el tamaño). Dependiendo de la dificultad, puede dividir estas tareas aún más, o combinar algunas si son dos fáciles (quizás los dos servicios de llamadas API sean tan simples que solo tendría que modificar los servicios API externos ).

En cualquier caso, este es un esbozo de cómo romper las historias.

EDITAR:

En respuesta a más preguntas que recibí sobre el tema de dividir las historias en tareas, escribí una publicación de blog sobre ella y me gustaría compartirla aquí. Elaboré los pasos necesarios para romper la historia. El enlace está here .

He llegado a una encrucijada con este problema en el pasado. Se supone que las historias de los usuarios deben estar aisladas para que pueda hacerlas sin ninguna otra historia, en el orden que sea, etc. Pero me pareció que hacer que eso sucediera simplemente hizo que todo fuera más complicado. Para mí, esto formaba parte del manifiesto ágil "Individuos e interacciones sobre procesos y herramientas", o al menos mi interpretación de él.

El objetivo final es enviar. Y para enviar tienes que construir, y para construir tienes que dejar de jugar con el scrum y solo hacer las cosas y asegurarte de rastrearlo.

Entonces, lo que hicimos fue romper una regla cardinal de historias e hicimos algunas historias tecnológicas como "crear un esquema preliminar". También declaramos que algunas historias dependían de otras, y notamos eso en el reverso de la tarjeta de la historia.

Al final, sentí que este tipo de historias eran pocas y distantes, y la dificultad de la alternativa justificaba la excepción.

La historia que implemente al principio se puede refinar con el tiempo. No necesita pensar que cada historia tiene que ser la versión final que el usuario va a utilizar.

Por ejemplo, en un proyecto reciente tuvimos que desarrollar una aplicación que implicaba indexar varios sitios web, y compararlos con los filtros creados por los usuarios, y finalmente alertar al usuario de las coincidencias (por ejemplo, alerta de google con esteroides).

Si lo miras desde una perspectiva, solo hay una historia: "Como usuario, quiero recibir alertas de páginas coincidentes". Pero míralo desde otra perspectiva de "cuáles son los riesgos que queremos mitigar". El primer riesgo era que los usuarios no obtendrían visitas relevantes o mejores en comparación con las alertas de Google. El segundo riesgo fue aprender la tecnología para construir esto.

Así que nuestra primera historia de usuario fue simplemente "Como usuario quiero éxitos relevantes", luego creamos solo el algoritmo de coincidencia de aciertos en un conjunto de páginas codificadas y filtros codificados para algunos de los primeros usuarios y recibimos sus comentarios.

En realidad, puede haber un poco de ida y vuelta aquí con múltiples historias más pequeñas para capturar el aprendizaje como "Como usuario quiero que se dé más prioridad a las coincidencias en la URL", etc. estas historias provienen de los comentarios a medida que iteramos sobre qué los primeros usuarios consideran "hits relevantes".

A continuación, lo ampliamos a "Como usuario, quiero hits de sitios web específicos" y creamos la arquitectura de indexación para rastrear los sitios especificados por el usuario y hacemos clic en eso.

La tercera historia fue "Como usuario, quiero definir mis propios filtros", y creamos esta parte del sistema.

De esta manera, pudimos construir la arquitectura pieza por pieza. Durante la mayor parte de la parte inicial, solo los usuarios tempranos podían usar el sistema, y muchos datos estaban codificados, etc.

Después de un punto, los primeros usuarios podrían usar el sistema por completo. Luego agregamos historias para permitir que los nuevos usuarios se registren y lo abrieron al público.

Para abreviar, la historia que implemente primero podría implementar solo una pequeña parte de la historia final, codificar y anclar todo lo demás. Y luego puede iterar en él a lo largo del tiempo hasta que obtenga la historia que realmente podría lanzar al público.

Una historia de usuario describe what mientras que una tarea es más sobre how .

No existe una fórmula perfecta, simplemente agregue cualquier tarea que describa how se implementará, documentará o probará la historia del usuario.
Tenga en cuenta que una tarea debe calcularse en horas, por lo que debe intentar escalar y detallar las tareas según corresponda.

Si siente que tiene demasiadas tareas para una historia (incluso si tiene tareas de 1-8 horas de duración), entonces tal vez debería considerar volver a escribir su historia de usuario, en primer lugar, porque probablemente sea demasiado compleja.

Buena suerte