Jeff tuvo un gran webinar organizado por SmartBear el pasado jueves. Si te lo perdiste, aquí está el enlace a la webinar archivado y las diapositivas. Recibimos cientos de preguntas de la audiencia, y SmartBear envió quince de ellas, pronto las publicarán todas en su página web, pero hemos pensado en darte una muestra de un par de ellas. Si has visto el seminario web y quieres conocer a fondo las ideas de Jeff sobre el Scrum, puedes inscribirte en nuestros cursos Scum Master de marzo o abril, que están al caer.
¿Qué tamaño de equipo es "demasiado pequeño" para scrum?
Cero es la respuesta rápida. Hemos visto Scrum de tres de dos e incluso de una persona. Pero para la mayoría de los equipos la regla de 7 más o menos dos es el camino a seguir. Suele haber suficientes miembros del equipo para permitir la funcionalidad cruzada, pero no demasiados para dificultar la comunicación y el intercambio. El problema más común que veo es que los equipos son demasiado grandes. Si tienes un equipo de más de 9 personas, es que es demasiado grande. Y los estudios demuestran que un equipo de 5 personas avanza más rápido que uno de 7.
¿Cómo se gestiona la propiedad del producto y los clientes en el equipo con un software de retractilado en el que hay una gran variedad de tipos de clientes con necesidades distintas?
Entrenamos a todas nuestras empresas de riesgo en el desarrollo de "personas", que son arquetipos de usuarios para el producto. Product Owners debería seguir nuestro curso Product Owner para profundizar en este tema.
Tiene que haber una "visión" del producto. Ahora bien, puede haber distintos tipos de clientes (personas) que compren el producto por necesidades diferentes, pero tiene que haber una persona que dé prioridad a todas las necesidades de los distintos clientes. ¿Es más importante implementar X función para un determinado tipo de cliente, o Y función para otro?
No pueden tener la misma prioridad. Si el producto es lo suficientemente grande como para tener varios equipos y varios propietarios del producto, sigue siendo necesario que haya un Jefe Product Owner que pueda resolver las cuestiones de prioridad entre el equipo de propietarios del producto. Recomiendo encarecidamente que, incluso en los grandes proyectos, haya en última instancia un único backlog organizado por orden de prioridad. La razón de ello es que todo el grupo debe centrarse en los elementos de máxima prioridad, en lugar de dispersar sus esfuerzos en cualquier característica que consideren importante, en lugar de en lo que el propietario del producto y los clientes consideran importante.
Leer el Estudio de caso de Citrix Online para ver cómo priorizar los lanzamientos de una cartera de productos a nivel empresarial. Este es otro tema tratado en detalle en nuestro curso Product Owner.
Ese curso Product Owner se celebrará en Boston del 31 de mayo al 1 de junio.
Spanish 
English 
French