tag:blogger.com,1999:blog-2328925255230238869.post8154168207395960281..comments2024-03-25T01:27:46.822+01:00Comments on Blog de un apóstol de Scrum y Kanban: ¿Sprinta el equipo o el producto?Alexander Menzinskyhttp://www.blogger.com/profile/05273164033669386910noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2328925255230238869.post-24131973162338528932018-07-18T16:24:57.656+02:002018-07-18T16:24:57.656+02:00Hola Edu,
Si lo piensas con perspectiva desde fue...Hola Edu,<br /><br />Si lo piensas con perspectiva desde fuera, un equipo, digamos de cinco personas, debería de poder hacer mucho trabajo en digamos 2 semanas, quiero decir que un PBI tiene que ser muy grande para que no se pueda hacer en un sprint. Pero ocurre, en nuestras realidades y con las infraestructuras que tenemos hay ocasiones en las que un PBI no cabe en un sprint y hay que hacerlo en dos sprints o más. Mientras el PBI sea una excepción, está bien, las excepciones confirman la regla.<br /><br />Yo aconsejaría construir este tipo de PBI de tal manera que a final del primer sprint se pudiera enseñar algo a los interesados de manera que nos permita obtener su feedback, aunque no entreguemos nada. Una estrategia en este sentido es la división de un PBI por "happy flow", en el primer sprint construyes la solución como si todo fuera bien y sin excepciones, a final de sprint le enseñas al usuario como quedará para poder obtener su feedback, y en el segundo sprint incluyes feedback de valor y las excepciones.<br /><br />Equipos maduros implica estar en empresas maduras, empresas que trabajan con arquitectura ágil como microservicios pro ejemplo, y con cultura DevOps con una pipeline de despliegue continuo donde el ciclo de llevar a producción sea cortísimo. En ese ambiente, cuando todos los ciclos son cortos, los PBIs son pequeños.<br /><br />Para mi lo importante es la mentalidad que hay detrás, si los equipos se esfuerzan en dividir en PBIs pequeños aprenderán y acelerarán, ese es el objetivo, las excepciones ocurrirán y no son más que eso, excepciones.<br /><br />Gracias por escribir, un abrazo,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-14167876751389913492018-07-18T09:57:42.758+02:002018-07-18T09:57:42.758+02:00Hola Alexander. Estoy de acuerdo. Las historias de...Hola Alexander. Estoy de acuerdo. Las historias de usuario o los pbi deben tener un tamaño adecuado para entrar en un sprint, y eso forma parte de nuestras buenas prácticas. Pero y ¿cuando no se puede? Mi ejemplo: recientemente hemos tenido que realizar unos cambios buscando mejorar el rendimiento en la aplicación, eso nos ha llevado a un cambio en el core que mínimo nos lleva 2 sprints (actualmente estamos en el segundo). Normalmente desplegamos o por lo menos entregamos incremento potencialmente desplegable al final de cada sprint, pero también se dan estos casos en los que al final del sprint (en este caso, el primero de los dos) el cambio estaba a medias, y no encontraba una forma lógica y aprovechable de romper el pbi para poder generar algo potencialmente entregable, es decir desde nuestra experiencia el pbi era indivisible. Esto se da en la realidad, o ¿que hacen los equipos maduros para que no se de? ;-)Eduhttps://www.blogger.com/profile/04422768233018767206noreply@blogger.com