Libro Agil : Experiencias Latinoamericanas en Metodologías Ágiles

Luis Astorquiza nos invita a enviar artículos para crear un libro con casos de éxito sobre Metodologías Ágiles.

Caratula

http://bit.ly/libroagil-2013

Aquí su invitación:

Quiero compartir con ustedes la convocatoria para la primera edición de un libro en el cual me encuentro trabajando: «Metodologías Ágiles, un nuevo paradigma que va más allá del desarrollo»

Lo considero pertinente para nuestra lista de correo, ya que la idea es recopilar experiencias formativas y de uso con éxito de metodologías ágiles en variados contextos, como lo podrían ser: Desarrollo Multimedia, Creación de Aplicaciones Móviles, Producción de Medios Digitales, Desarrollo de VideoJuegos, Construcción de Instalaciones Interactivas y otros campos, en los cuales el uso adecuado de instrumentos metodológicos se convierten en un factor de éxito y calidad para nuestros proyectos.
Este libro busca, en el contexto latinoamericano identificar experiencias de múltiples disciplinas, y aportar con las mismas, a la difusión del buen uso de estas metodologías de gran auge en nuestra comunidad académica y de investigación.Podéis acceder a en el siguiente enlace a la web de la convocatoria:  http://ingenieriamultimedia.co/libroagilLos invitamos a enviar sus artículos, el plazo está abierto hasta el 11 de noviembre de 2013.

Agradecemos mucho su amable colaboración en difundir con sus instituciones y redes, la información de esta convocatoria.
Luis Astorquiza.

Nueva Versión de la Guía Oficial de Scrum (Ahora en español) por @luchosalazarc

Post por : Lucho Salazar @luchosalazarc (uno de los traductores de la guía oficial)

Post original: http://www.gazafatonarioit.com/2013/08/nueva-version-de-la-guia-oficial-de.html

Nueva Versión de la Guía Oficial de Scrum (Ahora en español)

Actualización 20130902. Ya está disponible la versión en español de la Guía Definitiva de Scrum: las reglas del juego. La encuentran en la página oficial de la Guía (https://www.scrum.org/Scrum-Guides), en la sección correspondiente a «Spanish (July 2013)«.
Cambios entre las Guías de Scrum de 2011 y 2013
La nueva versión de la guía Scrum acaba de ser publicada este 1 de agosto de2013 por sus autores. La encuentran en . Según Jeff y Ken, estos son los cambios que aparecen en la versión 2013:
1. Se adicionó una sección de Transparencia de Artefactos. Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se basan en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.
2. La planificación del Sprint es ahora un evento. Dos temas se abordan en esta: Qué puede hacerse en el Sprint y Cómo será hecho el trabajo seleccionado. Después de que el equipo de desarrollo aprovisiona los ítems del Backlog del Producto para el Sprint, el Equipo Scrum define una Meta del Sprint. La Meta del Sprint crea coherencia en el trabajo del Equipo de Desarrollo que podría no estar presente en iniciativas separadas son una meta común. Note la inclusión formal de una Meta de Sprint.
3. El Backlog del Producto es refinado en vez de preparado (groomed). Los ítems del Backlog del Producto refinado son transparentes, lo suficientemente entendidos y granulares como para servir de entrada en la Planificación del Sprint y para selección del Sprint. Los ítems del Backlog del Producto con esta transparencia se llaman “Listos”. Listo y Hecho son dos estados que refuerzan la transparencia.
4. Scrum prescribe sus eventos para crear regularidad y para minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son eventos en la forma de bloques de tiempo, de tal manera que cada evento tiene una duración máxima. Un Sprint, como evento contenedor, tiene una duración fija que no se puede acortar o alargar. Los eventos restantes pueden terminar cuando se logra el propósito del evento, asegurando que una cantidad apropiada de tiempo se consuma sin permitir desperdicios en el proceso.
5. Se refuerza la importancia del Scrum Diario como un evento de planificación. Muy a menudo se ve como un evento de estado. Cada día, el Equipo de Desarrollo debería entender cómo intenta trabajar como un equipo auto-organizado para alcanzar la Meta del Sprint y crear el Incremento previsto hacia el final del Sprint. La entrada a la reunión debería ser cómo el equipo está trabajando hacia el logro de la Meta del Sprint; la salida debería ser un plan nuevo o revisado que optimice los esfuerzos del equipo para cumplir con la Meta del Sprint. Para tal efecto, las tres preguntas se han reformulado para hacer más énfasis sobre el equipo que sobre el individuo:
   a. ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar la Meta del Sprint?
   b. ¿Qué voy a hacer hoy para ayudar al Equipo de Desarrollo a cumplir con la Meta del Sprint?
  c. ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo alcancemos la Meta del Sprint?
6. El concepto de valor se refuerza para usarse en la Revisión del Sprint. Durante la Revisión del Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que fue hecho en el Sprint. Con base en eso y en los cambios al Backlog del Producto durante el Sprint, los asistentes colaboran en las siguientes cosas que se pueden hacer para optimizar el valor.
[Hasta aquí el resumen de los cambios escrito por los autores de la guía]
Resumiendo, los cambios importantes se enfocan en 6 aspectos:
  1. Transparencia
  2. La Meta del Sprint
  3. Refinamiento y Listo
  4. Eventos en Bloques de Tiempo
  5. Reunión Diaria como evento de Planeación
  6. Valor

Algunas notas adicionales:

  • Refinement en vez Grooming,
  • Importante el énfasis de la Reunión Diaria como reunión de planeación en vez de reunión de status.
  • Las tres preguntas también superponen al equipo sobre los miembros del equipo, el todo es mayor que la suma de las partes.
  • El Valor del producto se eleva de categoría, importantísimo.
  • La Meta del Sprint, ¿cambia la definición de «hecho»? Yo creo que más bien la refuerza.

También hay un video donde los mismísimos creadores de Scrum y de la guía explican los cambios. Lo encuentran en:

Mi primera retrospectiva. La técnica del agradecimiento

Por David Moreno @damorenon

“¿Por qué no te animas a dirigir la retrospectiva interna de hoy?”, me preguntó el Scrum Master tan pronto finalizamos la ejecución del séptimo sprint, desde que trabajamos de lleno con Scrum (además de la retrospectiva que propone el framework, incluir en el sprint una segunda retrospectiva sin la presencia del Product Owner nos da la confianza de sacar a la luz aquellos aspectos que se deben mejorar, pero que pueden resultar inapropiados o incómodos de tratar delante del cliente, porque son ajenos a él). En otra época me hubiese negado a hacerlo por mi timidez para hablar en público, por más pequeño y familiar que sea, y porque durante los anteriores seis sprints el Scrum Master siempre fue el facilitador, así que ya estaba acostumbrado y/o me había hecho a la idea de que eso era labor exclusiva de él.

Sin embargo, esta vez habían algunas situaciones que me dieron el coraje suficiente para aceptar este reto pequeño y grande a la vez (aunque es solo una reunión, de ella depende que en el próximo sprint se mejore el rendimiento del equipo):

  • La comunidad ágil de mi país suele realizar actividades extra-laborales donde se comparte conocimiento y precisamente el día anterior se llevó a cabo el “Dojo de técnicas de retrospectivas”, siendo yo el único Team Member que tuvo la oportunidad de asistir. Era la ocasión perfecta para llevar a la práctica lo que se aprende en este tipo de espacios (esto fue en gran parte lo que motivó al Scrum Master a dejar la retrospectiva en mis manos).
  • Más que compañeros de trabajo, mi equipo es un grupo de amigos haciendo lo que más les gusta (¡software!) y que a pesar de que toda su vida han trabajado con metodologías tradicionales, le creyó a Scrum ciegamente desde el momento en que el Scrum Master lo propuso (el proyecto había iniciado con un modelo en cascada y por cosas del destino, se tuvo que cambiar al gerente de proyectos por el actual Scrum Master, quien decidió “aventurarse” con el proyecto en las metodologías ágiles), así que sentía mucha tranquilidad para dirigirme a ellos con una nueva propuesta, sabiendo que no se iban a oponer.
  • Con el paso de los sprints queda claro que la retrospectiva es del equipo y para el equipo, luego más que dirigir e indicar lo que se debe hacer en la reunión, comprendí que debía asumir un rol de moderador pasivo, tomando participación activa únicamente cuando debía opinar como Team Member.

Dada la madurez que se ha alcanzado como equipo (no hay personas conflictivas, sino personas motivadas, comprometidas, respetuosas y transparentes tanto en lo laboral como en lo humano), no fue difícil escoger la técnica que experimentaríamos: “Los agradecimientos”. Según esta técnica, un Team Member resalta, reconoce o como su nombre lo indica, agradece a otro Team Member en particular, y con nombre propio, por la ayuda o colaboración concreta y desinteresada que le brindó mientras realizaba alguna de las tareas del Kanban.

Al iniciar la retrospectiva, anuncié a los participantes que habría una sorpresa al final de la misma, algo simple y que nunca se había intentado. Las expresiones de curiosidad e interés no se hicieron esperar. Después de discutir y consolidar las columnas de post-its en la pared con las cosas buenas y malas del sprint y las cosas por mejorar (como se ha hecho en todas las retrospectivas anteriores, solo que en esta ocasión alguien diferente la moderaba), finalmente se reveló la anunciada sorpresa: incluir una cuarta columna de post-its con agradecimientos. No había terminado de explicar la técnica en cuestión, cuando un Team Member exclamó: “¡qué buena idea!, ¡es algo que nos hace sentir bien a todos como personas y como profesionales!”.

Tomando la iniciativa, los primeros post-its de agradecimiento para la cuarta columna que propuse fueron:

  • Gracias compañero Miguel por recibir la llamada del Product Owner, quien me buscaba mientras realizaba otra tarea que no podía suspender hasta terminarla”.
  • Gracias compañero Guillermo por ayudarme a esclarecer un conflicto que apareció en el código durante la sincronización contra el SVN”.

De manera inmediata, cada Team Member escribió un agradecimiento, y solo uno, pues desafortunadamente ya se había agotado el tiempo destinado para la reunión (¡timebox!). Sin embargo, los post-its aparentemente “insignificantes” que se escribieron fueron tan poderosos y tuvieron un impacto tal, que todos los asistentes salieron de la sala con una sensación de bienestar indescriptible, como si se hubiesen inyectado algo que los mantuvo con un muy buen estado de ánimo y disposición por el resto del día. A pesar de que se trabajó en las mismas tres columnas (lo bueno, lo malo y por mejorar), la cuarta columna dio la impresión de haber hecho la retrospectiva por primera vez. Se evidenció una diferencia amplia entre esta y las anteriores reuniones (que ya se volvían monótonas).

Indiscutiblemente fue una experiencia enriquecedora tanto para la productividad, como para la calidad y la felicidad del equipo. Cabe destacar el papel del Scrum Master, una persona que no solo predica, también aplica. El simple hecho de tomar el rol de un Team Member más confiándole la reunión a otro Team Member y de haber formado un equipo abierto a nuevas ideas, es una clara demostración de los valores de Scrum puestos en práctica.