TL; DR;
Cuál es la diferencia entre:
A) Los detalles evocados y las definiciones de alcance y los criterios de aceptación obtenidos de la "conversación sobre la historia del usuario" en curso que un equipo debe tener con el PO, los BA y las partes interesadas durante un sprint
Y
B) Desplazamiento del alcance no planificado (lo que hace que se pierda una estimación de la historia, que una historia no termine el sprint, etc.).
Más específicamente, ¿cómo evidencia el desplazamiento del alcance y la estimación/desviación del cronograma causados por A frente a B?
Historia completa
Cuento con un equipo ágil de ingenieros, diseñadores y evaluadores de control de calidad multifuncionales de front-end y back-end. Trabajamos en un flujo continuo basado en extracción de Kanban, desvinculado de una serie de ceremonias de Scrum como stand-ups, backlog grooming, retros, etc.
Recibimos la documentación del proyecto/característica del equipo ejecutivo que define el valor empresarial de alto nivel y las especificaciones de bajo nivel de detalle de un proyecto/característica deseada.
Actúo como el PO (entre otros sombreros que estoy usando), lo que significa que estoy involucrado en este alcance de nivel ejecutivo, aprendiendo la visión de la característica, la necesidad comercial y la lógica comercial más fina durante este proceso.
A continuación, el equipo inicia el desarrollo de características y divide esta documentación inicial en historias de usuarios, cada historia define una historia de tipo MVP que puede generar valor por sí misma. El equipo prepara la historia y llega a un acuerdo común. En este punto, el equipo y la PO apuntan a tener una lógica empresarial definida en un 99,99 %, pero dejan abierto el "cómo".
Cuando comienza el desarrollo, se alienta al equipo a continuar con la conversación de la historia del usuario para evocar detalles cada vez más finos con respecto a la interfaz de usuario, la experiencia de usuario y el comportamiento de la lógica comercial menor. Esto requiere conversaciones conmigo mismo, nuestro director creativo para la dirección de arte/diseño y nuestro director ejecutivo para la dirección estratégica del producto. Junto con esta conversación, está en marcha el desarrollo y la exploración de la interfaz de usuario, lo que genera conocimiento, que a su vez genera una nueva comprensión y posiblemente requisitos comerciales nuevos o modificados.
El problema con el que me encuentro es una "iteración interna" casi infinita en esta conversación de historia de usuario. El director creativo se dedica a perfeccionar la UI/UX, el director ejecutivo se dedica a perfeccionar el comportamiento comercial de la función y yo lucho por encontrar un equilibrio entre ofrecer un MVP y ofrecer una función con la que todos los interesados estén satisfechos.
Mi solución actual es cruzar esta delgada línea rompiendo la desviación principal de la historia de usuario inicial en una historia de usuario separada, al tiempo que permite que los ajustes menores de todo tipo procedan como parte de la historia de usuario existente. Este enfoque se siente bien , pero siento que podría contradecir el pensamiento ágil/esbelto. Por otra parte, creo que A) MVP con PO/aprobación de partes interesadas y B) Conversación de historia de usuario pueden ser contradictorios a su manera y que no se pueden aplicar ambos al mismo tiempo.
Parece que tienes un problema en la forma en que se escriben las historias. Las historias representan un objetivo que tiene un valor para un actor .
Si piensas en la versión de Mike Cohn de las historias de usuario: " [El actor] quiere hacer [el objetivo] para obtener [el valor] ". Si puede identificar estos tres elementos, el alcance sigue lógicamente.
La conversación que debe tener lugar en la historia del usuario es sobre la forma más sencilla o económica de llegar a ese valor entregado al actor al habilitar el objetivo .
Por ejemplo, imagine esta historia para los sitios de Stack Exchange:
Como usuario registrado quiero cambiar mi avatar para que mi avatar sea el mismo que otros sitios .
¿Cuál es la forma más simple y económica de lograr esto? Aquí es donde la discusión debe ocurrir. Debería comenzar durante la planificación y podría ser así:
Miembro A del equipo: "Podríamos agregar un nuevo formulario con una carga de archivo en la página del usuario"
Miembro del equipo B: "¿Qué hay de arrastrar y soltar una imagen de un archivo al avatar en sí?"
Miembro del equipo A: "Sí, eso es más simple, hagámoslo"
Luego, la decisión se anota en la tarjeta (o lo que sea que use para rastrear historias). Es un detalle de implementación.
Durante el desarrollo, surgen un par de problemas/oportunidades.
¿Cómo manejamos estos casos?
El elemento 1 significa que, para proporcionar el valor acordado al usuario, es necesario un trabajo adicional, en particular, en este caso, podría ser una etiqueta que explique la funcionalidad al usuario. Esto es claramente parte de la historia . Es necesario hacerlo para que la historia sea completa y valiosa. La decisión debe anotarse en la tarjeta.
El punto 2 es una idea que se obtuvo a medida que el equipo adquiría más conocimientos sobre el tema. Sí aporta valor extra, pero no es necesario para conseguir el objetivo pactado: el valor es superior al pactado. Por lo tanto, en este caso se agrega una nueva historia a la cartera de pedidos: "Como usuario registrado , quiero cambiar mi avatar mediante copiar/pegar para poder cambiarlo sin guardar un archivo local en mi sistema ".
Como puede ver, debería ser bastante fácil entender qué es "desplazamiento del alcance" y qué no. Tenga en cuenta que no existe el aumento del alcance en Agile: el aumento del alcance es un subproducto esencial de la metodología, es algo que realmente alentamos y tiene un lugar correcto, como nuevas historias.
Su situación me resulta bastante familiar (así como a muchos otros en el mundo real, sospecho).
El enfoque Agile da la bienvenida al cambio, incluso el cambio de última hora, por lo que está bien que las partes interesadas mejoren/extiendan continuamente las historias de los usuarios y agreguen más detalles o incluso nuevos requisitos. Sin embargo, como usted dice, no es fácil mantener las historias de usuarios individuales "bajo control". Una vez que una historia está en progreso, no debe cambiarse ni extenderse tanto como para invalidar las estimaciones y los planes anteriores. Sin embargo, está bien cambiar o refinar detalles más pequeños en función de los comentarios de las partes interesadas. Como usted nota, hay una fina línea de equilibrio para encontrar aquí. Pero no hay nada inherentemente poco ágil en ello; Creo que todos los equipos ágiles enfrentan este dilema todo el tiempo.
es, como usted también nota, entre la creación de documentación aprobada del proyecto/característica desde el principio, frente a la preparación continua de la historia. Siento que puede haber una brecha a nivel de organización entre el proceso ágil de su equipo y el enfoque más tradicional de otros departamentos, incluido el equipo ejecutivo.
Creo que, desde su perspectiva, parte del problema puede ser que no ven las historias de usuarios individuales que creó su equipo, solo el documento original completo, que no tiene límites claros entre las diferentes características. Por lo tanto, no perciben cuando están extendiendo "demasiado" una historia existente y están agregando una historia completamente nueva.
Puede ser útil explicarles en detalle cómo está trabajando su equipo, qué es el enfoque ágil y por qué, cuáles son sus beneficios en comparación con el enfoque tradicional de Big Specification Up Front. Y también para explicarles el problema actual desde la perspectiva de su equipo. Idealmente, podría convencerlos de que adopten historias de usuarios desde el comienzo del proceso. Eso puede hacer que sea más fácil detectar el tamaño relativo de cada historia (utilizando los comentarios del equipo de desarrollo) y evitar inflarlas demasiado.
(Esto puede ser complicado o, en el peor de los casos, incluso imposible, dependiendo de muchos factores, incluida la forma de pensar de la alta dirección, su situación y la de su equipo y el estado del departamento, la cultura organizacional, la "política", el estado de ágil transformación dentro de su organización, etc. Así que evalúelos y proceda con cautela, o no actúe en absoluto si lo considera demasiado arriesgado. Sin más detalles, es imposible dar consejos más concretos sobre esto. Excepto quizás dos:
Otro factor importante es asegurarse de que solo las historias suficientemente pequeñas entren en un sprint. Una historia en este punto debe ser lo suficientemente pequeña como para terminarla convenientemente en un solo sprint; preferiblemente no debería requerir más de unos pocos días de trabajo. Si es demasiado grande, debe dividirse en historias más pequeñas. Trabajar con historias lo suficientemente pequeñas también ayuda a controlar el "desplazamiento del alcance", ya que solo puede agregar mucho a una historia pequeña antes de notar que está comenzando a crecer demasiado, por lo que es hora de dividirla.
está bien y es completamente ágil, al menos si se hace de la manera correcta. Es decir, siempre que las partes interesadas y el equipo puedan ponerse de acuerdo sobre un conjunto de refinamientos sucesivos de una historia o épica, de modo que el equipo pueda entregar las nuevas funciones a las partes interesadas como una serie de incrementos valiosos del producto. Aprender a dividir historias en pequeños incrementos adecuados es un arte que requiere paciencia y práctica a largo plazo. Y los comentarios de usted y su equipo hacia las partes interesadas pueden ayudar mucho aquí, así como demostrarles regularmente los incrementos de productos que funcionan y que están terminados. No sé con qué frecuencia hace esto.
Intento de responder mi propia pregunta.
Mi sensación inicial es la siguiente:
Se necesitan más ejecutivos que acepten Agile: los ejecutivos están demasiado involucrados en los detalles y en los "cómo hacer" la implementación; esto crea un enfoque más vertical y basado en contratos que un enfoque iterativo basado en hipótesis.
Si el equipo hiciera un verdadero desarrollo iterativo , esto no sería un problema: el equipo evolucionaría de manera iterativa e incremental hacia la solución correcta. El equipo ejecutivo y de producto/BA debe continuar definiendo una estrategia y una visión de alto nivel, y dejar que el equipo realice la exploración comercial y de UX necesaria para llegar a la solución óptima.
Si los PO/BA hicieran verdaderas especificaciones de productos basadas en hipótesis y datos , esto no sería un problema. En su lugar, los PO/BA y el equipo ejecutivo se involucran en un diseño de funciones históricas y de "intuición", basadas en "lo que ha funcionado antes" y "lo que creo que funcionará"; esto causa
El equipo necesita conocer el negocio a un nivel mucho más profundo para poder tomar ciertas decisiones en nombre del cliente/usuario sin necesidad de tanto PO o aportes ejecutivos. Si el equipo pudiera decidir entre dos opciones de lógica empresarial en función de su conocimiento del producto, el usuario y el mercado, avanzaría hacia una verdadera autoorganización y propiedad del producto.
Responsabilidad clara del equipo : lleve al equipo a saber por qué están creando una característica de cierta manera y a asumir la responsabilidad de su éxito. Esto requiere dar a los equipos la capacidad de tomar decisiones independientes y luego medir el éxito/fracaso. Más independencia viene con más responsabilidad y rendición de cuentas.
El producto necesita un PO dedicado a tiempo completo que sea un experto en la materia y que tenga un equipo de BA y/o analistas de datos a su disposición para participar en un verdadero desarrollo basado en hipótesis e iteraciones.
En general, este es un proceso que es muy complejo y lento de implementar, sin mencionar que es riesgoso.
bernardo