Académique Documents
Professionnel Documents
Culture Documents
oficinaproyectosinformatica.blogspot.com
Resumen Se ha dicho que los mtodos de desarrollo de software giles, como por ejemplo Scrum, tienen serias dificultades para escalar a equipos de desarrollo grandes a escala organizacional. La tcnica de las reuniones Scrum de Scrum es la que permite escalar el enfoque Scrum para grandes equipos de proyecto a escala corporativa, esta tcnica. En este artculo se discute cuantos equipos Scrum necesitamos para un proyecto dado, que especialistas deben integrar cada equipo Scrum, quienes asisten a la reunin Scrum de Scrum, como se escalan los puntos tratados, frecuencia de estas reuniones y la agenda. Introduccin Se ha dicho que los mtodos de desarrollo de software gil y Scrum, son ideales para proyectos desarrollados por equipos multidisciplinarios de pocas personas y localizados en la misma oficina. Sin embargo, cada vez se observan ms ejemplos de grandes compaas utilizando Scrum en proyectos de gran escala, con equipos de proyectos integrados por decenas y hasta cientos de desarrolladores. La tcnica de las reuniones Scrum de Scrum permite escalar el enfoque Scrum para grandes equipos de proyecto, consiste en dividir un equipo de muchas personas en diferentes equipos Scrum, para luego utilizar reuniones Scrum de Scrum para coordinarlos. A cada reunin de Scrum de Scrum asiste uno o dos integrantes de cada equipo. Cuntos equipos Scrum se necesitan? Considerando que el tamao recomendado de un equipo Scrum debe estar entre 5 y 9 participantes, cuando se tienen 10 o ms integrantes, la solucin es dividir a un gran equipo en subequipos, manteniendo la regla de entre 5 y 9 participantes. Cada equipo deber tener un Scrum Master, su propia lista de
Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)
objetivos y caractersticas (Backlog) y ser atendido por un dueo de producto (Product Owner). Qu roles de desarrollo de software integran cada equipo de desarrollo Scrum? No es una buena prctica dividir los equipos por componentes o especializados por tecnologa, por ejemplo desarrollo de Base de datos, desarrollo de aplicaciones, equipo de pruebas, etc. En su lugar, la buena prctica es crear equipos multifuncionales, cada uno capaz de desarrollar y probar una caracterstica (Feature) del producto, en todos los componentes y capas involucrados. Por ende, el equipo deber incluir desarrolladores de todas las capas involucradas, analistas funcionales, analistas de pruebas, etc. Deben distribuirse por igual los niveles de experiencia y conocimiento del negocio (Know-How), con la intencin que cada equipo sea capaz de tomar una historia del Backlog y transformarla en un producto. Quienes asisten a la reunin Scrum de Scrum? Cada equipo designa a uno de sus integrantes para asistir a la reunin Scrum de Scrum. Es buena prctica que sea un participante tcnico (Desarrollador o Tester), y no el dueo de producto o Scrum Master. No necesariamente tiene que ser siempre la misma persona, sino que puede rotar segn la etapa del proyecto y quien est en mejor posicin para contribuir con la reunin. Al principio del proyecto deberan enviarse a personal tcnico o diseo de usuario, mientras que al final debera enviarse a personal que est ejecutando las pruebas. Si el nmero de equipos Scrum es pequeo, pueden asistir hasta dos personas por equipo, por ejemplo un participante tcnico y el Scrum Master. Escalamiento de las reuniones Scrum de Scrum Cuando los proyectos son grandes, las reuniones Scrum de Scrum se pueden escalar en mltiples niveles. Por ejemplo, supongamos que se tienen 49 equipos Scrum de 7 personas cada uno. Por cada equipo se selecciona a una persona a asistir a reuniones Scrum de Scrum, de esta forma, se conforman 7 reuniones con 7 participantes cada una. Por cada uno de estos equipos se puede
Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)
escalar a 3 equipos y estos a su vez a un equipo directivo. Bajo este ejemplo se tendran 4 niveles. Frecuencia de las reuniones Scrum de Scrum Las reuniones Scrum de Scrum deben ser frecuentes, pudiendo considerar inclusive la frecuencia diaria o tres veces a la semana (por ejemplo los lunes, mircoles y jueves). Se recomienda que tenga la misma duracin de la reunin diaria (15 minutos). Tal como indica Mike Cohn, miembro de la junta directiva del Scrum Alliance (Ver aqu), es aconsejable reservar 30 minutos adicionales para resolucin de problemas y consultas de informacin que surjan de la reunin, dado que si bien a nivel de equipo Scrum se pueden dejar asuntos por resolver en reuniones sucesivas, en las Scrum de Scrum debe buscarse resolucin inmediata y as evitar programar muchas reuniones con las mismas personas. Ver artculo completo de Mike Cohn en:
http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting
Agenda La agenda de las reuniones Scrum de Scrum debera ser similar a la de los Scrums diarios, realizando algunos ajustes, dado que en la reunin no estn los equipos completos sino representantes de cada equipo. A cada integrante del Scrum de Scrum, que a su vez representa cada uno a un equipo, se le pregunta lo siguiente: Qu actividades ejecutado tu equipo desde la ltima reunin? Qu actividades realizar tu equipo antes de la prxima reunin? (Prximos pasos). Existen impedimentos en tu equipo? Existe alguna actividad a ejecutar prximamente por tu equipo que interfiera o afecte de alguna forma el trabajo de otro equipo? Al igual que las reuniones diarias (Daily Scrum), la intencin es que la exposicin de cada integrante sea breve e ir al grano. Los problemas se pueden mencionar, no se buscan soluciones hasta que cada integrante ha hecho su exposicin.
Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)
Una vez finalizada se realiza la segunda parte de la reunin, en la cual los participantes discutirn los problemas o situaciones planteadas, o puntos tratados en reuniones previas que an no se han cerrado. El equipo mantendr un Backlog de Scrum de Scrum, el cual es anlogo a lo que se llamara una lista de issues en proyectos tradicionales. Es un simple listado con asuntos que los participantes necesitan tomar accin sobre ellos o hacer seguimiento por alguna razn. Pueden incluirse issues de otros grupos Scrum de Scrum pero que este equipo necesita ser notificado de la resolucin. A diferencia de cada equipo Scrum, el grupo Scrum de Scrum no realiza planificaciones de iteracin ni revisiones de Backlogs, cada miembro del grupo es simplemente un participante del grupo al que pertenece, con la intencin de coordinar actividades entre grupos Scrum. Cada iteracin puede traer consigo un conjunto de participantes diferentes en las reuniones Scrum de Scrum. Quien asume los compromisos y la responsabilidad que el proyecto avance es cada equipo Scrum individual, el grupo Scrum de Scrum no tiene responsabilidades directivas. Conclusin Lo dicho anteriormente puede significar que existan personas que necesiten asistir a dos o ms reuniones Scrum de Scrum, sin embargo, la experiencia indica que la tcnica escala muy bien dado que los participantes claves estn involucrados en las reuniones y la informacin fluye hacia los niveles ejecutores ms rpido y con menos interferencia en la comunicacin. Y qu hay de usted, Ha aplicado alguna vez el enfoque Scrum a proyectos grandes?, Ha utilizado las reuniones Scrum de Scrum?, Cul ha sido su experiencia?, Que agregara a lo propuesto en este artculo?. Le invitamos a visitar el blog la Oficina de Proyectos de Informtica y dejar sus comentarios:
http://oficinaproyectosinformatica.blogspot.com/2012/09/scrum-grandes-proyectos-reunion.html
Desarrollo gil, Scrum y Test Driven Development Los 5 valores de la programacin extrema
http://oficinaproyectosinformatica.blogspot.com/2012/11/los-5-valores-de-la-programacion.html
Test Driven Development (TDD): 9 retos para su implementacin y cmo hacerles frente
http://oficinaproyectosinformatica.blogspot.com/2012/11/test-driven-development-tdd-9-retos.html
Gestin de desarrollo de software Errores comunes en el desarrollo de Bases de datos: Segunda Parte
http://oficinaproyectosinformatica.blogspot.com/2012/11/errores-comunes-en-el-desarrollode_21.html
Algunas prcticas de desarrollo de aplicaciones web para asegurar calidad, mantenibilidad, escalabilidad y seguridad
http://oficinaproyectosinformatica.blogspot.com/2012/08/algunas-practicas-de-desarrollo-de.html
Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnologa de informacin (TI)
http://oficinaproyectosinformatica.blogspot.com/2012/08/acciones-preventivas-para-evitar.html Copyright La Oficina de Proyectos de Informtica (http://oficinaproyectosinformatica.blogspot.com)
Las preguntas que debe hacer al encargarse de un proyecto de Tecnologa de Informacin (TI) en ejecucin
http://oficinaproyectosinformatica.blogspot.com/2012/08/las-preguntas-que-debe-al-hacersecargo.html
Otros temas Habilidades interpersonales cada vez ms demandadas en los profesionales de Tecnologas de Informacin
http://oficinaproyectosinformatica.blogspot.com/2012/10/habilidades-interpersonales-mas.html
El patrocinador (Sponsor) del proyecto: Rol que debe asumir y lo que no debe hacer
http://oficinaproyectosinformatica.blogspot.com/2012/08/el-patrocinador-sponsor-del-proyecto.html
Acciones preventivas para evitar retraso y retrabajo en proyectos de tecnologa de informacin (TI)
http://oficinaproyectosinformatica.blogspot.com/2012/08/acciones-preventivas-para-evitar.html
Las preguntas que debe hacer al encargarse de un proyecto de Tecnologa de Informacin (TI) en ejecucin
http://oficinaproyectosinformatica.blogspot.com/2012/08/las-preguntas-que-debe-al-hacersecargo.html