En primer lugar, permítanme dejar en claro que soy un desarrollador de software y que estoy escribiendo esta ayuda ISO con mi deseo de agilizar la gestión de mi proyecto y obtener una aceptación para cambiar alguna requirements documentationtécnica general que sigue mi equipo. Por favor, no lo confunda con la búsqueda de asesoramiento en gestión de personas, soy consciente de que está fuera de tema en este foro.
Intentaré hacerlo simple y claro. Cuando me contrataron para mi puesto de contrato hace unos meses, me dijeron que el equipo me estaba siguiendo, Agilepero no del todo, y que estaban abiertos a avanzar más en esa dirección. Una vez que comencé, me di cuenta de que los hábitos y procedimientos de flujo de trabajo inculcados todavía son muchos waterfally que los documentos de requisitos muy completos a veces se escriben varios meses antes de que comience cualquier desarrollo. Por "integral" quiero decir que, si bien un requisito cubre una unidad funcional coherente e interrelacionada, de ninguna manera es atómica y que puede dividirse en una jerarquía de unidades de trabajo individualmente atómicas, aunque interdependientes.
Mi esperanza era que cada unidad de progreso atómica, lo que significa que no es posible dividirla en trozos más pequeños, debería tener su propio sprint/iterationdocumento de requisitos. Desde la perspectiva del desarrollo, una clara ventaja de esto es que no tengo que agarrar un documento de requisitos más amplio, lo que deja más enfoque en la tarea directa en cuestión, lo que resulta en un trabajo de mejor calidad. Es como recibir dos tareas diferentes para instalar una puerta y pintar una habitación cuando las dos se pueden dividir convenientemente en dos tareas: primero instala la puerta y luego pinta la habitación. En nuestra configuración actual, es un documento de requisitos único, lo que dificulta comprender o incluso encontrar los detalles de la tarea concreta en cuestión en un documento que abarca también otras tareas.
Hago esta pregunta para confirmar que mi idea se ajusta a la doctrina ágil oficial y que no estoy malinterpretando. ¿Los requisitos de Agile deben ser siempre los mínimos posibles o existen beneficios al agrupar varias tareas de trabajo interdependientes en un documento completo? Desde la perspectiva de mis estilos cognitivos y preferencias, tener el lado de gestión de proyectos del equipo break down the work into individual atomic tasksme permitiría tener que hacer menos gestión de proyectos yo mismo y centrar más mi atención en la codificación en lugar de estructurar incrementos hacia el objetivo final. Otra ventaja es que sería mucho más fácil dar LOE y estimaciones de finalización en una tarea de alcance más limitado que en un proyecto completo.
Referencias:
¿Dónde está la estructura de descomposición del trabajo (WBS) en Agile?
Parece que podría estar describiendo las diferencias entre un Product Backlog y un Sprint Backlog y quizás un Release Backlog en el medio.
Product Backlog- Todo lo deseado en el producto. Esta puede ser una lista finita (un PRD) o una lista viva que se agrega y se vuelve a priorizar constantemente.
Release Backlog : esto no se encuentra en las pautas básicas de scrum, sin embargo, recuerde que scrum es un marco que se puede personalizar. Una modificación común, particularmente en proyectos grandes, es dividir el proyecto en "Lanzamientos". Si el producto es tal que no se puede "enviar" en cada sprint (código heredado, integración profunda con otros sistemas, etc.). El "lanzamiento" es entonces un hito intermedio en el que el producto podría enviarse potencialmente. Los lanzamientos a menudo tendrán un tema central como "crear infraestructura central". El Release Backlog son todas las historias deseadas para un lanzamiento determinado. Los ingenieros todavía decidirían en qué orden y cómo construirlos.
Sprint Backlog : esto es lo que los desarrolladores deciden construir en un sprint determinado. Se extraen de la parte superior de la cartera de pedidos, pero es posible que no siempre extraigan el elemento superior en función de agrupaciones como historias, dependencia técnica, etc. Esto debe hacerse con el propietario del producto (gerente).
Entonces, según su pregunta, si configura lanzamientos, podría crear Release Backlogs.
Aunque no estoy seguro de que esto vaya a resolver tu problema. Por lo que ha descrito, parece que su proceso de requisitos está bastante lejos de ser ágil. Esto prácticamente neutraliza cualquier beneficio que tenga la ingeniería al operar en un modelo de sprint/iteración. El mejor equipo de desarrollo ágil del mundo no puede alcanzar el máximo rendimiento ni ofrecer un gran valor si recibe requisitos innecesarios o rígidos.
No hay nada en el enfoque ágil que especifique el tamaño de los requisitos. Scrum, que es un marco ágil, especifica que la cantidad de trabajo planificada para un sprint debe poder completarse dentro del sprint. Eso implicaría un tamaño máximo de un requisito tal que no exceda un sprint (típicamente 1-4 semanas).
Sin embargo, en la práctica, ha habido mucha discusión en la comunidad ágil sobre un tamaño apropiado para los requisitos cuando se trabaja de manera ágil. Recuerde que uno de los fundamentos de Agile es la capacidad de responder al cambio. Si desea ser capaz de responder al cambio, tener una documentación de requisitos completa y detallada se convierte en un obstáculo en lugar de una ventaja.
Un enfoque popular para los requisitos de dimensionamiento es el mnemotécnico INVEST . Esto significa
El 'Escalable' se refiere a hacer que los requisitos sean lo suficientemente pequeños para ser estimados con cierta certeza. Muchos equipos ágiles toman esto como un tamaño típico de unos pocos días-persona de esfuerzo.
Puede leer más sobre el mnemotécnico INVEST aquí
Otra consideración es el principio ágil de entregar software funcional con frecuencia. Esto sugeriría que más pequeño es mejor, ya que permitiría una entrega más frecuente.
Permítame intentar responder a su pregunta en el contexto de Scrum, que es el proceso ágil más popular.
Sí, debe tener historias de usuario en forma de pequeñas porciones verticales de funcionalidad, que describan un pequeño incremento en el valor para el usuario. Sin embargo, al leer su pregunta, parece que las siguientes aclaraciones sobre el proceso ágil de la historia del usuario ayudarán:
Las historias de usuario, tal como las escribió inicialmente el propietario del producto, no son contratos escritos ni requisitos que el software deba cumplir. Antes de la Planificación de Sprint, el Product Owner y el equipo de desarrollo se reunirán para refinar las historias priorizadas en la cartera de pedidos. Necesita cierta flexibilidad para poder ajustar la cantidad de la historia que se implementa. Historias de usuarios bien hechas: requisitos. Vea la diapositiva titulada 'Negociable'.
El Product Owner debe trabajar con el equipo de desarrollo para refinar las historias y agregar criterios de aceptación, lo que Mike Cohn llama condiciones de satisfacción .
Sin embargo, depende totalmente del equipo de desarrollo descubrir cómo implementar la historia de usuario y dividirla en tareas técnicas más pequeñas. Vea un buen ejemplo en este artículo Cómo dividir una historia de usuario en tareas .
Tob