Fuente de la imagen: https://es.ign.com/rogue-one-una-historia-de-star-wars/112679/feature/ubicando-a-darth-vader-entre-el-episodio-iii-y-rogue-one
Como saben acostumbro a revisar permanentemente la Red Social LinkedIn. Cada vez más encuentro contenido de mucho interés, como por ejemplo los que genera nuestro colaborador el Doctor John Atkinson Abutridy (pueden conocerlo en este link: https://www.gestionenti.com/post/quieres-aprender-inteligencia-artificial-con-peras-y-manzanas ).
Por lo tanto no me sorprendió encontrar un comentario del Doctor Javier Garzás a quien sigo hace un tiempo (son muy recomendables sus vídeos donde “trata” de compartir un contenido valioso sobre agilidad en dos minutos). Como siempre sus comentarios son muy directos y contundentes (se puede estar de acuerdo o no pero es muy difícil quedar indiferente), razón por la cual los invito a conocerlo:
El comentario, compartido por José Ignacio Pérez de la Rosa es el siguiente: “¿Un Product Backlog con más de 100 ítems? Bienvenidos al Lado Oscuro, considerando que, a ojo, esos 100 ítems llevarían muuuuuchos Sprints terminados...
Me cuenta nuestra Ms NoBody protagonista de hoy que tienen en su empresa un Product Backlog con unas 700 «cosas» (supuestamente Historias de Usuario).
Y que a la vez tienen un gran problema con los usuarios, porque cuando ven las funcionalidades implementadas en el producto (y las ven cada muchos meses) … rechazan la mayoría.
Y, por el problema anterior, nuestra Ms NoBody entiende que hay que trabajar aún más y más en detallar, revisar, priorizar, pulir, etc. (venga a echarles horas y horas), ese Product Backlog.
¿Qué os dice la anterior situación querid@s Rebeldes Ágiles? Pues sí, efectivamente, que estamos frente a un caso de Cascadermitis o síndrome del ciclo de vida en cascada autoimpuesto (también llamado Lado Oscuro). A ver, una de las grandes debilidades del modelo cascada estaba en las grandes especificaciones de requisitos que se hacían de manera predictiva pensando que, dentro de mucho, una vez implementadas, eso sería lo que querría el cliente… y luego era que no. Que no quería eso (incluso aunque lo hubiera pedido).
Cuando tienes un Backlog gigante, por mucho Jira que tengas, y por mucho que le llames Historias a lo que hay dentro… estás exactamente en el caso anterior.
Es obvio decir que a Backlog más grande más «historias» habrá ahí abajo del Backlog que de implementarse se implementarán dentro de mucho (dicho desde otro punto de vista, un caso claro de desperdicio por tiempos de espera).
¿Y cuál fue la solución Ágil a todo esto? Pues tirar del viejo principio que nos enseñó la programación… el usuario sabe lo que quiere cuando lo ve. Entonces que lo vea, y que lo vea antes y de manera muy frecuente y que lo vea en producto real (no papel).
Y de ahí lo de escribe poco y habla más con el usuario y enséñale cosas operativas.
Y de ahí lo del ciclo de vida iterativo e incremental, y el working software (va post), y todo eso.
Hay que crear conversaciones frecuentes con el usuario, no Backlogs gigantes en Jira que nos fuercen a lo contrario. Los Backlog gigantes os llevan por el Lado Oscuro. Os desenfocan del verdadero problema, os hace centraros en perfeccionar un Backlog repleto de cosas que probablemente el cliente no quiera en vez de centraros en detectar lo que realmente el cliente quiere, hablando con él a la vez que se le enseñan versiones (muchas versiones). De hecho… ¿no se creó en concepto de historia de usuario para conversar con los usuarios? Pues claro que sí. Entonces… ¿para qué creáis Backlog gigantes que provocan hablar menos con el usuario? No olvidemos que cada Historia es “una promesa de conversación”.
Espero que les haya gustado.
Comments