En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

A continuación se muestran las principales diferencias en la priorización de prácticas:

• El tipo de proyecto, respecto a si no va a tener evolución posterior, o bien si se trata del desarrollo de un producto.
• Su tamaño (esfuerzo necesario a realizar), su complejidad, el número de personas implicadas.
• El conocimiento de la tecnología y del dominio (tipo de negocio) por parte del equipo.
• El conocimiento del proceso de trabajo.
• El conocimiento entre los miembros del equipo, si han trabajado anteriormente juntos.
• El tipo de aspecto a mejorar dentro del proyecto (calidad, tiempos de entrega, productividad, etc.).

 

Es este artículo se muestra una visión de cuáles podrían ser los skills de un miembro de equipo ágil. Se han agrupado según estén relacionados con la orientación a producir valor para el receptor final del producto, con la capacidad de trabajar en equipo o con la capacidad de mejorar.

 

En este encuentro Alexis Roqué de <Undefined> explicó su ecosistema ágil. Se hizo hincapié en el ecosistema como soporte a la comunicación entre los actores que participan en un proyecto (incluyendo al cliente), en la necesidad de un jardinero del ecosistema (en función de su complejidad) y en lo interesante que puede ser disponer de un buen sistema de gestión y push de conocimiento a nivel de empresa. Finalmente se subrayó que un cambio en la manera de trabajar siempre implica formación, perseguir e ir mejorando.

Autor: Jesús Iglesias

Xavier Albaladejo me ha pedido que publique aquí uno de mis últimos artículos, así que aquí os lo transcribo tal cual. Espero que os sea de utilidad.

El proyecto

El pasado mes de mayo comenzamos el desarrollo de un nuevo proyecto que ha terminado recientemente, al menos la primera fase del mismo. Partimos casi de cero, los requisitos eran muy básicos y poco documentados, pero parte del equipo teníamos en la cabeza exactamente lo que teníamos que hacer. De hecho era plasmar en una única aplicación todo nuestro trabajo de los últimos cuatro años.

En el proyecto participaron dos equipos de desarrollo en localizaciones diferentes: uno en Valencia, de 6 personas, y otro en Madrid, en el que llegaron a trabajar más de 30. Ninguna de estas casi 40 personas tenía disponibilidad completa para este proyecto sino que hubo que redistribuir toda la carga de trabajo para, con el mismo equipo, asumir un nuevo proyecto de cinco meses de duración. Salió bastante bien .

En la parte tecnológica teníamos otro grave problema: desde Madrid desarrollaban en .NET y desde Valencia en PHP.

Scrum

Desde el principio nadie tuvo dudas: Scrum era la mejor metodología posible para cumplir los plazos que nos habían impuesto.

Planteamos sprints de dos semanas y reuniones diarias de sincronización ("dailys") a las 10 de la mañana de alrededor de 10 minutos. Como Scrum Master se quedó uno de nuestros project managers y como product owner otro del departamento de operaciones. La mayoría nos habíamos leído ya el Scrum desde las trincheras, pero una cosa es la teoría y otra muy diferente la práctica, y ahí casi nadie teníamos experiencia.

No trataré en este artículo de enseñaros Scrum, no soy un experto, como mucho un poco “evangelizador” , simplemente trataré de explicar mis sensaciones tras cinco meses de Scrum intensivo.

Autor: Jordi Salvat i Alabart

(Esta es la traducción al castellano de mi blogpost http://jordionsoftware.blogspot.com/2009/10/simple-metrics-for-scrum.html)

Al terminar mi charla en la Barcelona PHP Conference recibí varias preguntas sobre las métricas que utilizamos: como construimos nuestros gráficos de burn-down, etc.

Esto es lo que estamos haciendo a día de hoy. Es una mezcla de ideas de "Scrum and XP from the Trenches", "Agile Estimation and Planning" [1], y las nuestras propias:

En este encuentro se presentaron dos tipos de retrospectivas, a las que se llamaron “Express” (para iteraciones cortas, de 2-3 semanas) y “full equipe” (para iteraciones de 1 mes, releases, fin de proyecto o empresa).

• Nuestros clientes, que reciben un mejor servicio.
• Los trabajadores (nosotros), que podemos realizarnos profesionalmente en nuestro trabajo y que disfrutamos más.

“El expendedor” es un juego de 75 minutos para equipos a los que se explica por primera vez Scrum. Permite que hagan una simulación de creación de la lista de objetivos priorizada (Product backlog) y de ejecución del propio proceso de Scrum, de manera que puedan compararlo con el desarrollo tradicional (en cascada/waterfall), comprobando cuáles son los principales beneficios de Scrum, especialmente los referidos a alineamiento con las expectativas del cliente, flexibilidad y retorno anticipado de inversión.

Todo ello construyendo un expendedor con papel, tijeras, cinta adhesiva y globos.

 

 

Puedes bajarte las reglas del juego y las tarjetas de objetivos de cada equipo a partir del siguiente enlace. El tamaño del fichero es unos 250 Kb. 

 

Autor: Xavier Albaladejo

Revisor: João Gama

Scrum es un conjunto de prácticas especialmente combinadas para dar soporte a la creación de productos innovadores y enfocar el trabajo del equipo en producir valor directo para el cliente final. El uso regular de estas prácticas (entregas frecuentes priorizadas por valor, potenciación del equipo de trabajo, mejora continua de producto y de proceso, etc.) permite que los cambios dentro de un proyecto sean aceptados de manera natural y proporciona al cliente margen para flexibilidad e innovación así como productividad y calidad.

Las metodologías tradicionales ya mencionaban las prácticas y conceptos utilizados en Scrum, llegando a utilizarlos en mayor o menor medida y prometiendo también un mejor resultado en los proyectos. Pero una cosa es reconocer que estas prácticas son buenas y otra muy diferente es actuar en consecuencia [1], es decir, utilizar todas estas prácticas situándolas en el centro del proceso.