project management - microsoft - Melé. Tratar con historias de baja prioridad que introducirán cambios en la arquitectura
microsoft project scrum (6)
El problema es, ¿y si esta historia introduce un enorme cambio de arquitectura en nuestra solución? Por ejemplo, desde una aplicación independiente, tendrá que ir a la arquitectura cliente-servidor, debido a esta historia solamente.
No creo que su ejemplo sea realista, tal característica debe ser de alguna manera parte de la visión del producto, no puede descubrir tal cambio en la última historia menos importante, debe tenerse en cuenta en algún momento antes del último sprint. Y la última historia. En otras palabras, estoy de acuerdo con @fuzzy y @Eric aquí:
- Si la historia no es importante y es arriesgada, es muy probable que nunca se implemente.
- Si la historia es importante y es arriesgada, es muy probable que no sea una prioridad tan baja (es decir, una prioridad errónea).
Hoy en la universidad tuvimos un ejercicio de práctica Scrum (simulando todo el proceso de creación de una solución de software) y se me ocurrió un problema que no podía entender.
Digamos que hemos definido nuestras historias y les damos una prioridad adecuada. Y hay una historia con muy poca prioridad ... tal vez se hará en uno de los últimos sprints.
El problema es, ¿y si esta historia introduce un enorme cambio de arquitectura en el diseño de nuestra solución? Por ejemplo, desde una aplicación independiente, tendrá que ir a la arquitectura cliente-servidor, debido a esta historia solamente.
Desde mi punto de vista: ¿no es natural marcar de alguna manera qué historias deben hacerse (en algún momento en particular), cuáles son críticas para hacer, pero no es crítico cuándo, entonces el equipo debe tener En mente y tomar mejores decisiones diseñando su solución. ¿O cómo estás lidiando con este problema? Si es un problema.
¡Gracias por adelantado! Y disculpe mi pregunta probablemente coja.
Esto parece ser una pregunta del último momento responsable .
Si todos los involucrados están seguros de que esto es un requisito y afectará a la arquitectura, ponerlo en el último sprint es imprudente.
Un caso más probable es que puede ser requerido. Si ajusta su diseño para acomodarlo antes, está manteniendo esa complejidad a través de múltiples sprints para admitir una función que nunca se puede agregar. (Los requisitos del negocio cambian.)
Con un diseño flexible y desacoplado (como el que se desarrolló a través de TDD ), es posible mantener el costo del cambio en un tiempo relativamente estable.
Porque dijiste:
hecho en uno de los últimos sprints, tal vez .
Tiendo a estar de acuerdo con la paleta difusa (y +1 de mi parte).
Sin embargo, si hay algo que sabe que tendrá que hacer, pero se colocó hacia el final, simplemente está en el lugar equivocado si pudiera tener un gran impacto arquitectónico.
Puede dividir la tarea en análisis e implementación, con un análisis (de impacto) que suceda muy temprano para determinar si realmente habrá un impacto arquitectónico, y luego la implementación se programará de manera apropiada según el resultado del análisis.
Si bien la prioridad es principalmente una función del deseo del cliente, no es completamente el caso. Puede haber algunos aspectos técnicos que son elementos que el equipo determina que se deben hacer antes. Por ejemplo, seleccionar un ORM puede significar poco para el cliente, pero puede ser una decisión de diseño importante desde la perspectiva del equipo.
Hemos tenido estas cosas que aparecen un par de veces en mi proyecto actual que involucra un CMS donde las cuestiones como la internacionalización debían abordarse antes, pero esto no fue necesariamente un acierto, ya que hubo cambios más tarde, como incorporar el software de otra compañía para manejar algunos de la traducción que puede afectar algunos de nuestros códigos.
EDITAR: El Cuadrante de la deuda técnica también puede ser útil para analizar este tipo de riesgos para ver en qué se está metiendo si es deliberado obtener el gran golpe de la deuda al final.
Si se debe hacer y va a implicar un gran cambio en la arquitectura, entonces probablemente no debería ser de baja prioridad.
La única vez que puedo ver que se debe clasificar como de baja prioridad es si es aceptable soltarlo por completo o si es aceptable mantenerlo a raya incluso si costará mucho más en el futuro (digamos que el producto debe termine y salga por la puerta para que pueda haber más fondos para más adelante en el futuro)
en el mundo real con $$$ en la línea, las cosas que tienen baja prioridad probablemente nunca se harán. Y si tienen un factor de alto riesgo que en el mundo real significa aún más $$$ en riesgo y baja prioridad, no se hará con seguridad. En su caso, si sabe que se hará con seguridad, en sus sesiones de diseño solo asegúrese de que sus diseños se adapten fácilmente a los cambios necesarios con el menor esfuerzo posible en la historia actual.