Historias de usuarios y mucha negociación sobre qué es esencial y qué es peluche.
Mucha negociación.
También un montón de ida y vuelta en la arquitectura. Scrum requiere una arquitectura estable y probada. Sin embargo, siempre hay actualizaciones y mejoras. ¿Cómo encajan esos con la cartera de pedidos? Es una gran cantidad de maniobras políticas entre el propietario del producto, la gente de tecnología y (hasta cierto punto) los usuarios/compradores.
El proceso es intrínsecamente no lineal.
Es más como la cristalización. Tienes una solución, comienzas a escribir historias, tienes una visión tecnológica, tienes un equipo con ciertas habilidades y experiencia.
Cualquiera de estas características puede servir como un "núcleo" para decidir qué entra en la acumulación y en qué orden. Eventualmente, algo se convierte en el núcleo y la mezcla cristaliza. A veces el costo o el cronograma o los riesgos son inaceptables, por lo que se calienta nuevamente, se encuentra otro núcleo y se ve si se cristaliza aceptablemente alrededor de ese nuevo núcleo.
La recristalización ocurre después de cada sprint, por cierto, por lo que es aún menos lineal.
Editar. "arquitectura probada estable".
Pregunta: ¿Quién paga por aprender la nueva arquitectura?
Respuesta: Ja, ja. No hay una buena respuesta. Así que ten cuidado con la cantidad de aprendizaje arquitectónico que haces mientras tienes carreras de desarrollo.
Si no tiene una arquitectura en funcionamiento que (a) funcione, y (b) pueda ser articulada por casi todos en el equipo, va a dedicar tiempo a ensamblar esa arquitectura.
¿Cuánto le cuesta a su primer sprint el tiempo y el costo de crear una arquitectura?
Tienes que incorporar el desarrollo de la arquitectura en el primer sprint, lo que retrasa las cosas.
Digamos que decide implementar una pila LAMP. No sabes si unificar PHP, Perl o Python. Entonces escoges uno. Como Python. Y prometes el primer sprint en cuatro semanas. Así que trabajas durante 3 semanas luchando con los módulos y frameworks add-one de kabillion. Después de 3 semanas, piensas que tienes una pila de tecnología en funcionamiento, pero no tienes el sprint prometido.
¿Se retrasa?Si es así, todos preguntan si tienes el ritmo correcto y comienzas a duplicar el tiempo para todos los demás sprints.
¿No entregan nada? Si es así, ¿para qué sirve sprints si no tienes nada al final excepto la infraestructura?
Puede cambiar, modificar y mejorar la infraestructura, en piezas manejables. Pero construir una nueva arquitectura, probar las piezas, capacitar a todos y desarrollar mejores prácticas lleva tiempo. Mucho de eso. Y ese tiempo no debería, en realidad, ser cobrado como tiempo de carrera creando un producto entregado. Eso es tiempo de sobrecarga.
Editar. Estampación.
Regla 1. Los procesos ágiles no usan muchas herramientas y procesos complejos. Es por eso que dije que el proceso es mucha "negociación". Lo que te hace productivo.
Regla 2. No lo piense demasiado. Solo hazlo.
La mayoría de la gente dice que, de la manera más fuerte posible, utilice tarjetas de papel de 5 "x8" y péguelas a la pared. Seriamente. Sin herramientas. Solo papel simple, marcadores, cinta y espacio en blanco de la pared.
leyeron: http://www.agilemodeling.com/artifacts/userStory.htm
Se puede utilizar una hoja de cálculo para recopilar historias de usuario (y epopeyas - historias que tienen que ser descompuesto). Puede agregar columnas de complejidad (puntos de historia), costo, prioridad y lanzamiento, y usarlas para la administración de proyectos.
Utilizamos casos de uso (no historias de usuarios) pero las herramientas son las mismas. Un caso de uso es, en cierto modo, una historia de usuario con más detalles por adelantado. Pero el nombre del caso de uso puede resumir cómo un actor interactúa con un sistema; la interacción generalmente puede resumirse con nombres claros y simples y un verbo, que se parece mucho a una historia de usuario.
Las hojas de cálculo parecen útiles porque puede reorganizar las filas al final de cada sprint. Puede hacer recuentos y sumas simples para calcular cuánto costará cada característica y cuándo llegarán.
No uso una hoja de cálculo porque, a pesar de la ostentación de GUI, me resulta un poco engorroso. Sentiría que es necesario escribir un extractor de hoja de cálculo que convertiría la acumulación de un archivo Org de Open Office en ReStructuredText (RST). Prefiero RST - marcado de texto sin formato - sobre hojas de cálculo.
Esto es todo negociación prolongada. Todo cambia como resultado de cada conversación. Ese es el punto de un método Ágil. Sprint rápido seguido de negociación sobre la dirección del próximo sprint.
Nuestra cartera de pedidos es un gran documento RST. Publicamos toda nuestra documentación usando Sphinx y es muy, muy simple escribir atrasos, casos de uso, arquitectura, diseño, etc., en el marcado RST.
Nuestros sprints son simplemente secciones de un gran árbol de documentos. Están decorados con algunos campos de texto interpretados de propósito especial para los aspectos subjetivos, como la fecha de finalización estimada y el estado (en proceso, publicado).
Voy a cerrar esta pregunta como fuera de tema porque no se trata de programación. –