¿Qué es el Daily Scrum Meeting?
Es un meeting diario de todos los miembros activos del equipo.
¿Quienes participan?
Solamente miembros del equipo. Para que la reunión sea productiva cada miembro del equipo debe participar activamente. Managers y otras personas pueden participar solamente como oyentes.
¿Cuál es el objetivo de la reunión?
El objetivo es tener un punto de inspección/comunicación/coordinación entre los miembros del equipo. El objetivo no es reportarse ante un supervisor, el objetivo es que cada miembro del equipo habla brevemente de las tareas que realizó, realiza y los problemas que encontró.
¿Cuál es el horario y duración de la reunión?
La reunión puede programarse a cualquier hora del día pero las mañanas es más recomendable. La duración de esta reunión es de máximo 15 minutos. Si hay necesidad de seguir hablando se debe programar una reunión separada solo con los miembros del equipo interesados en el tema.
¿Alguien preside o dirige la reunión? ¿Un team leader por ejemplo?
Esta reunión es participativa y no de reporte, por tanto todos los miembros del equipo deben participar dando sus opiniones. Si puede ser de ayuda que alguien ayude a mantener el orden de quien habla cuando o que verifique que la duración no exceda los 15 minutos.
¿Cómo ayudan los managers en este meeting?
De dos formas: primero, asegurándose que el equipo tenga el lugar y espacio para reunirse y segundo, ayudando a resolver las dudas, bloqueos y/o problemas que fueron expuestos en la reunión.
¿Hay algún formato a seguir para esta reunión?
La bibliografía de referencia recomienda hacer tres preguntas: ¿Qué hiciste ayer? ¿Qué harás hoy? ¿Hay algo que bloque tu trabajo? Sin embargo en la práctica cada equipo es libre de escoger las preguntas. Lo importante es que cada miembro del equipo pueda en un corto tiempo hablar de su trabajo, el estado del mismo y su impacto en el trabajo del resto de los miembros del equipo.
Thursday, October 27, 2011
Tuesday, October 25, 2011
Proyecto casa de los Simpsons
Los estudiantes de la Maestría de Ing. de Software de la Universidad Gabriel René Moreno trabajaron el fin de semana pasado en un ejercicio grupal que consistia en realizar una réplica de la casa de los Simpsons, esta foto ejemplifica los resultados alcanzados:
Fotografias adicionales y una presentación preparada por este grupo pueden encontrarse en los siguientes links:
https://picasaweb.google.com/107712459507918881105/SETheSimpsonSHuse
http://www.slideshare.net/timoteoPonce/model-making-simpsons-house
Y este es un link a las fotos que otro de los grupos amablemente compartio en Picasa:
https://picasaweb.google.com/113911593465885757955/SCRUM?locked=true&feat=email
Y esta es su presentacion en SlideShare http://www.slideshare.net/mianmilo/casa-de-los-simpson-10027129
Luis Antonio escribió en su blog acerca de este proyecto http://ryuchananything.blogspot.com/2011/11/casa-de-los-simpson-framework-scrum.html
Estas fotografias corresponde a un tercer grupo de trabajo:
Y cuya presentación se encuentra en el siguiente link http://www.slideshare.net/ebbicita/proyecto-casa-de-los-simpsons
Este video corresponde a un cuarto grupo (el equipo de Diego porque siempre hay un Diego en cada equipo :))
https://docs.google.com/leaf?id=0B0yvfg6mi1NKMmNkMTU4MmYtNDA0NC00YjJkLWIyNDktYzY3MGY1YTljMzY1&hl=en_US&pli=1
Del grupo de Diego también están estas presentaciones http://www.slideshare.net/diegozalles/proyecto-maestria
Y finalmente este es el link a la presentación del grupo de Roberto Carlos (no el cantante sino el ingeniero :))
http://www.slideshare.net/rhunoja/proyecto-casa-de-los-simpson
Fotografias adicionales y una presentación preparada por este grupo pueden encontrarse en los siguientes links:https://picasaweb.google.com/107712459507918881105/SETheSimpsonSHuse
http://www.slideshare.net/timoteoPonce/model-making-simpsons-house
Y este es un link a las fotos que otro de los grupos amablemente compartio en Picasa:
https://picasaweb.google.com/113911593465885757955/SCRUM?locked=true&feat=email
Y esta es su presentacion en SlideShare http://www.slideshare.net/mianmilo/casa-de-los-simpson-10027129
Luis Antonio escribió en su blog acerca de este proyecto http://ryuchananything.blogspot.com/2011/11/casa-de-los-simpson-framework-scrum.html
Estas fotografias corresponde a un tercer grupo de trabajo:
Y cuya presentación se encuentra en el siguiente link http://www.slideshare.net/ebbicita/proyecto-casa-de-los-simpsons
Este video corresponde a un cuarto grupo (el equipo de Diego porque siempre hay un Diego en cada equipo :))
https://docs.google.com/leaf?id=0B0yvfg6mi1NKMmNkMTU4MmYtNDA0NC00YjJkLWIyNDktYzY3MGY1YTljMzY1&hl=en_US&pli=1
Del grupo de Diego también están estas presentaciones http://www.slideshare.net/diegozalles/proyecto-maestria
Y finalmente este es el link a la presentación del grupo de Roberto Carlos (no el cantante sino el ingeniero :))
http://www.slideshare.net/rhunoja/proyecto-casa-de-los-simpson
Saturday, October 15, 2011
Definición de Exito para un Producto
James Shore hizo una presentación excelente en Agiles 2011 en la cual puntualizo su visión de éxito para un producto software, en resumen James puntualizaba que un producto tiene exito cuando tres variables convergen: el negocio, la tecnología y la satisfacción pesonal.
El negocio se refiere concretamente a que el producto pueda sea rentable en un horizonte razonable de tiempo, es decir construir algo para un mercado que lo consuma y que además sea sostenible. Esta variable implica dinero que se invierte en un producto y que debe necesariamente retornar de alguna manera para justificar la inversion.
La segunda variable tiene que ver con que no basta con que un producto se venda bien, tiene que ser tecnologicamente sólido como para permitirle evolucionar rapidamente o adaptarse a nuevos requerimientos. Aqui la arquitectura flexible y las buenas prácticas de ingeniería (XP) son claves asi como también el fuerte compromiso del equipo con la calidad.
La tercera variable es la satisfación de la gente que trabaja haciendo el producto, esta satisfacción debe traducirse en éxito personal (no solo económico). La idea es simple, individuos satisfechos y motivados se consideran así mismos exitosos y estan dispuestos a trabajar en una versión aún mejorada del producto.
Algo que James puntualizó también es que las tres variables son de igual importancia y esa creo es la clave del asunto. No tener o tener muy poco de cualquiera de estas tres dimensiones comprometera el producto a corto o mediano plazo.
Bolivianos en Agiles 2011
Once compatriotas asistimos a Agiles 2011 en Buenos Aires, fue una asistencia record que esperemos vaya en ascenso para la siguiente version del evento.
En la foto de izquiera a derecha Gabriela Espinoza, Juan Banda, Victor Hugo Rodriguez, Patricia Calderon, Israel Antezana, Marco Alba Lopez, Pablo Azero y Gonzalo Solano. No aparecieron para la foto Steven Rojas, Juan Pablo Soliz y Hugo Siles.
Friday, October 7, 2011
Reflexiones despues de rendir el examen PMI-ACP (Agile Certified Practitioner)
Hoy por la mañana di el examen PMI-ACP y con la memoria aun fresca me animo a compartir algunas cosas que me parecieron bastante interesantes de este examen:
1. Las preguntas del examen están bien formuladas y bien redactadas, no dan mucho lugar a malas interpretaciones y son bastante objetivas.
2. Muchas de las preguntas están relacionadas con Scrum, con los roles, ceremonias y artefactos.
3. Sin embargo hay otras preguntas que hablan de aspectos más generales de Agile y del manifiesto agil.
4. Encontré muy pocas preguntas relacionadas a Lean y Kanban y solo unas cuantas que hablaban de Agile Earned Value.
5. Retrospectives es otro tópico sobre el cual tampoco encontré muchas preguntas pero las pocas que habían estaban bien relacionadas a la bibliografía recomendada por el PMI.
6. XP si estuvo presente y fuerte, varias preguntas respecto a TDD, integración continua, pair programing, collective code ownership, etc.
7. Los aspectos suaves de coaching los vi en muy pocas preguntas, lo cual es una lástima porque el libro Agile Coaching de Lyssa Atkins es un referente fundamental.
Me animo también a priorizar un poco la lista de libros de bibliografía que recomienda el PMI, desde luego esta es una opinión bien personal mía:
1. The Art of Agile Development, James Shore
2. Agile Project Management with Scrum, Ken Schwaber
3. The Software Project Manager's Bridge to Agility, Michele Sliger
4. User Stories Applied: For Agile Software Development, Mike Cohn
5. Agile Estimating and Planning, Mike Cohn
6. Coaching Agile Teams, Lyssa Adkins
7. Becoming Agile:...in an imperfect world, Greg Smith
8. Agile Retrospectives: Making Good Teams Great, Esther Derby
9. Agile Project Management: Creating Innovative Products, Jim Highsmith
10. Agile Software Development: The Cooperative Game, Alistair Cockburn
11. Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway
Finalmente un recurso que me resulto muy valioso a la hora de prepararse fueron los exámenes de prueba que AgileExam tiene en su sitio www.agileexams.com
1. Las preguntas del examen están bien formuladas y bien redactadas, no dan mucho lugar a malas interpretaciones y son bastante objetivas.
2. Muchas de las preguntas están relacionadas con Scrum, con los roles, ceremonias y artefactos.
3. Sin embargo hay otras preguntas que hablan de aspectos más generales de Agile y del manifiesto agil.
4. Encontré muy pocas preguntas relacionadas a Lean y Kanban y solo unas cuantas que hablaban de Agile Earned Value.
5. Retrospectives es otro tópico sobre el cual tampoco encontré muchas preguntas pero las pocas que habían estaban bien relacionadas a la bibliografía recomendada por el PMI.
6. XP si estuvo presente y fuerte, varias preguntas respecto a TDD, integración continua, pair programing, collective code ownership, etc.
7. Los aspectos suaves de coaching los vi en muy pocas preguntas, lo cual es una lástima porque el libro Agile Coaching de Lyssa Atkins es un referente fundamental.
Me animo también a priorizar un poco la lista de libros de bibliografía que recomienda el PMI, desde luego esta es una opinión bien personal mía:
1. The Art of Agile Development, James Shore
2. Agile Project Management with Scrum, Ken Schwaber
3. The Software Project Manager's Bridge to Agility, Michele Sliger
4. User Stories Applied: For Agile Software Development, Mike Cohn
5. Agile Estimating and Planning, Mike Cohn
6. Coaching Agile Teams, Lyssa Adkins
7. Becoming Agile:...in an imperfect world, Greg Smith
8. Agile Retrospectives: Making Good Teams Great, Esther Derby
9. Agile Project Management: Creating Innovative Products, Jim Highsmith
10. Agile Software Development: The Cooperative Game, Alistair Cockburn
11. Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway
Finalmente un recurso que me resulto muy valioso a la hora de prepararse fueron los exámenes de prueba que AgileExam tiene en su sitio www.agileexams.com
Thursday, October 6, 2011
De como introducir Scrum creando un grass root movement
La introduccion de Scrum dentro de cualquier organizacion tiene varias compliaciones iniciales y de mantenimiento que en muchas oportunidad hacen que este proceso se trunque o no se lleve a buen termino. Uno de los problemas iniciales proviene del desconocimiento que todavia existe en la comunidad acerca de lo que es agil en general. Si esta corriente de pensamiento todavia no es conocida menos aun lo son los potenciales beneficios que pueda traer.
Un primer paso es el proceso de acercamiento en que la gente dentro de una empresa comienza a enterarse de agil y en particular de Scrum. En esta etapa generalmente quien hace el rol de evangelizador menciona que Scrum aportara grandes beneficios y satisfaccion al cliente. En este momento es cuando los genrente escuchan el discurso pro Scrum, sacan la calculadora y dicen wow, "esto es una maravilla, me voy a ahorrar un monton de dinero, todos a hacer Srum ya!"
Si uno tiene la suerte (en realidad la mala suerte) de que esto pase su empresa el siguiente problema al que se enfrentara es algo a lo que yo llamo "Scrum por mandato". Scrum es en esencia una forma de pensar y de trabajar en equipo, nada de lo cual puede ser dictado, medido y exigido en su cumplimiento. Generalmente las cosas que vienen por imposicion limitan el pensamiento creativo y eventualmente se desarticulan en cuanto la presion de quien las impuso es aliviada.
Hace falta algo que se pegue mas al "suelo" y no flote en las esferas de la gerencia. Algo que venga por conocimiento y que sea colectivo y propio de la gente que efectivamente contruye a un proyecto y que ve en Scrum una oportunidad para hacer su trabajo mas ameno y productivo. Encontre una imagen (logo de una banda rockera) que ilustra el sentido de este post.
Como se ve en la imagen el pasto "grass" va creciendo pero no se desprende del suelo con el viento, puede incluso ser cortado y parcialmente arrancado pero seguir ahi y volvera a crecer. Similarmente Scrum puede ser cambiado, criticado, sacudido, podado pero eventualmente continua.
Para lo anterior es esencial tener raices "roots" que hagan que la gente cree firmemente en algo y este despuesta a seguir creyendo en que de alguna forma va hacer que funcione dentro de su entorno. Este grupo de creyentes conversos o no conversos son la clave del "grass root movement".
Cual es mi consejo final? Si Usted es un gerente, no importe creyentes, formelos y deles libertad de experimentar con Scrum, suena loco pero con un poco de suerte y honestidad los beneficios seran grandes.
Si esta del otro lado de la cerca (ingenieros y pueblo en general) piense en que hermoso seria ser parte de un movimiento que creo la diferencia en su entorno y en su profesion.
Un primer paso es el proceso de acercamiento en que la gente dentro de una empresa comienza a enterarse de agil y en particular de Scrum. En esta etapa generalmente quien hace el rol de evangelizador menciona que Scrum aportara grandes beneficios y satisfaccion al cliente. En este momento es cuando los genrente escuchan el discurso pro Scrum, sacan la calculadora y dicen wow, "esto es una maravilla, me voy a ahorrar un monton de dinero, todos a hacer Srum ya!"
Si uno tiene la suerte (en realidad la mala suerte) de que esto pase su empresa el siguiente problema al que se enfrentara es algo a lo que yo llamo "Scrum por mandato". Scrum es en esencia una forma de pensar y de trabajar en equipo, nada de lo cual puede ser dictado, medido y exigido en su cumplimiento. Generalmente las cosas que vienen por imposicion limitan el pensamiento creativo y eventualmente se desarticulan en cuanto la presion de quien las impuso es aliviada.
Hace falta algo que se pegue mas al "suelo" y no flote en las esferas de la gerencia. Algo que venga por conocimiento y que sea colectivo y propio de la gente que efectivamente contruye a un proyecto y que ve en Scrum una oportunidad para hacer su trabajo mas ameno y productivo. Encontre una imagen (logo de una banda rockera) que ilustra el sentido de este post.
Como se ve en la imagen el pasto "grass" va creciendo pero no se desprende del suelo con el viento, puede incluso ser cortado y parcialmente arrancado pero seguir ahi y volvera a crecer. Similarmente Scrum puede ser cambiado, criticado, sacudido, podado pero eventualmente continua.
Para lo anterior es esencial tener raices "roots" que hagan que la gente cree firmemente en algo y este despuesta a seguir creyendo en que de alguna forma va hacer que funcione dentro de su entorno. Este grupo de creyentes conversos o no conversos son la clave del "grass root movement".
Cual es mi consejo final? Si Usted es un gerente, no importe creyentes, formelos y deles libertad de experimentar con Scrum, suena loco pero con un poco de suerte y honestidad los beneficios seran grandes.
Si esta del otro lado de la cerca (ingenieros y pueblo en general) piense en que hermoso seria ser parte de un movimiento que creo la diferencia en su entorno y en su profesion.
Subscribe to:
Posts (Atom)
