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:

  

• Demo cada 2 semanas y cliente siempre disponible. Pasan a ser un Must. el éxito en desarrollo de producto depende del enfoque en proporcionar valor al usuario / consumidor final por parte de todos (tanto del cliente como del equipo, al cual se está pagado con stock options). Es por eso que la métrica de proyecto de valor entregado por unidad de tiempo también pasa a ser un Must. Por el contrario, en un proyecto corto, su éxito suele depender más de la visión del cliente. Él tiene que saber qué quiere obtener en ese espacio de tiempo, por que no hay mucho margen para una gran innovación o cambios radicales (eso no quita que existan proyectos cortos en que el equipo tiene que aportar mucho en definición de producto, incluso más que el cliente).
• Historias de usuario. Pasa a ser un Must. Es muy importante tener foco en el valor aportado al usuario final o consumidor. Como se ha comentado anteriormente, en el caso del desarrollo de producto hay mucho más interés en este valor que en un proyecto de 3 meses. Asimismo este valor será de gran ayuda para priorizar el Product Backlog.
• Modelo de Dominio. Pasa a ser un Must. Es un mapa conceptual que permite tener un vocabulario común entre las personas de negocio y el equipo de desarrollo, por lo que debe estar claro y bien definido. Se elabora en la iteración 0 para dar soporte a la primera release y se va refinando cada iteración. En el caso de un proyecto corto donde sólo se utilizaba durante 3 meses era un Have por que podría bastar con el esquema de base de datos.
• La gestión de cambios de requisitos deja de ser un Have, dado que no hay que negociar desviaciones con un cliente externo. El control de los resultados del proyecto, del valor proporcionado, es una responsabilidad interna en la empresa, con lo que todos los cambios, modificaciones y adiciones de funcionalidad se entienden como necesarios.
• Move people around y propiedad colectiva del código. Pasan a ser un Must. En la construcción de producto hay que asegurar el collective ownership y no perder conocimiento si en algún momento desaparece algún miembro del equipo. En un proyecto corto esto era menos perjudicial, dado que es inferior la probabilidad de que marche alguien con un conocimiento exclusivo y muy grande del producto.
• Paso sostenido 40 horas a la semana. A corto plazo es un Have en una startup donde para aumentar su implicación el equipo incluso está pagado con stock options, con lo que puede “apretar” más para sacar la primera release. A medio/largo plazo debería ser un Must.
• Hoja de cálculo o aplicación para seguimiento del Sprint. Deja de ser un must si se utiliza un Tablero de Tareas.
• Los spikes (también llamados “balas trazadoras” o pruebas de concepto), aún sin aportar valor de negocio, son de especial importancia en el desarrollo de producto, dado que permiten desechar o validar soluciones tecnológicas (por ejemplo averiguar si un Framework va a mejorar la velocidad de desarrollo o si va a llevar a un callejón sin salida por que no soluciona una problemática), así como obtener una estimación del coste de un desarrollo masivo de aspectos concretos del producto. Es importante que un spike se realice dentro de un timebox, para forzar la toma de decisiones.
• El refactoring sin miedo pasa a ser refactoring sin piedad, dado que el equipo se juega poder construir de manera sostenida en el futuro.
• Peer reviews. Pasan a ser un Must. Dado que la empresa va a tener que vivir de este producto durante varios años y es muy posible que en siguientes iteraciones el código lo tengan que ver otras personas (en parte debido a las prácticas de Move people around y propiedad colectiva del código).
• Gestión de defectos. Pasa a ser un Must. Posiblemente ya no sea suficiente o posible resolver los defectos ASAP para olvidarse de ellos, por lo que es importante disponer de un soporte electrónico adecuado para gestionar  defectos y obtener estadísticas que permitan averiguar qué está sucediendo.
• Pruebas de rendimiento. Pasan a ser un Must.
• Métricas de proceso. Pasan de no ser especialmente relevantes en un proyecto corto a ser un have en desarrollo de producto.
• Programación en parejas. Es conveniente ir realizando esta práctica aunque sea de manera ocasional, planificando un número de horas por iteración o escoger para ello historias de usuario concretas. 

 

Otras observaciones:

• En el caso de desarrollo de producto en un entorno competitivo, es especialmente importante construir con calidad interna para tener “cintura” a la hora de hacer cambios y conseguir un paso sostenible.
• Los casos de prueba de aceptación sirven como checklist de completitud de las historias de usuario, aunque no deben de servir como excusa ni “descarga” para decir “he probado lo que había escrito, si no funciona es por que no estaban todos los tests identificados”.
• Los casos de prueba de aceptación también actúan como TDD. El hecho de escribirlos y pensar en cómo se probará una funcionalidad permite evitar la aparición de errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar en una iteración sin antes haber escrito los casos de prueba, especialmente por que es más barato escribir texto y pensar en cómo desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.
• La estimación siempre debe ser realizada por el equipo que vaya a ejecutar el proyecto. De esta manera será más realista, por tener en cuenta sus diferentes conocimientos, experiencias, fortalezas y debilidades. Recordar que como característica básica de los métodos ágiles, la estimación y planificación ágil permitirá calcular el ROI en función del tiempo y del gasto, así como saber qué cabe en cada release.

 

Artículos relacionados

• Priorización de prácticas ágiles en un proyecto corto - IX y X encuentros ágiles en Barcelona

 

Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

 

Nota del system administrator de ProyectosAgiles.org:

Si estás viendo este artículo a través del RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: http://www.proyectosagiles.org/rss.xml

Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.

 

 

Se acaba de anunciar la  Conferencia Agile-Spain 2010 (CAS2010), bajo el lema "Haciendo realidad la agilidad". CAS2010 es la primera conferencia sobre metodos ágiles en España.

Es una cita donde se encontrarán empresarios, desarrolladores, gerentes, investigadores, etc. Está enfocada principalmente a la industria de tecnologías de la información y consultoría tecnológica.

CAS2010 es una oportunidad para intercambiar experiencias y hacer contactos con otros profesionales del sector, además de examinar las últimas tendencias en el desarrollo del software ágil de mano de las figuras más representativas del panorama nacional.

A continuación aparecen los datos más relevantes:

• Fechas: 10-11 de Junio de 2010.
• Lugar: Madrid, Campus de la E.U. Informática de la U.P.M., Madrid, España.
• Keynote: Henrik Kniberg. Es el autor de “Scrum y XP desde las trincheras” y “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer y miembro de la junta directiva de la Agile Alliance.
  
• Constará de Sesiones, Talleres y presentación de Artículos.
• Tendrá lugar un panel de expertos (mesa redonda).

Se han abierto las siguientes convocatorias:

• Petición de sesiones y talleres
• Petición de contribuciones
• Patrocinio

También es posible colaborar como voluntario y aportar ideas.

El detalle de la información anterior se encuentra en la web oficial de la conferencia: http://conferencia2010.agile-spain.com.

 

 

 

En estos encuentros ágiles se elaboró un diagrama de prácticas y se hizo una priorización considerando un proyecto sin evolución posterior y de corta duración.   La priorización de las prácticas ágiles a aplicar en un proyecto puede depender de diferentes factores:

• 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.).

  Hacer clic en la imagen para ampliarla           Comentarios sobre las prácticas   A continuación se enumeran algunos de los comentarios que se hicieron en el encuentro:

• Visión compartida. Es muy importante que el equipo tengo una visión compartida de los objetivos (mediante el Product Backlog) y de las tareas a realizar (mediante el Sprint Backlog).
• Propiedad colectiva del código. Hay que erradicar la costumbre de que “esta tarea la tendrá que hacer esta persona por que fue él quien hizo esta parte del producto”. Cuanto más se tarde en erradicar, peor será. Para dar soporte a esto, existen prácticas que definen los estándares de trabajo del equipo (estándares de codificación, patrones de diseño) y prácticas de transferencia de información y conocimiento (peer reviews, pair programming, etc.).
• La inversión en Unit Testing se recupera pronto, a partir de los 2 meses.
• Aunque el cliente tenga poca disponibilidad para asistir a demostraciones (por ejemplo sólo puede hacerlo 1 vez al mes al mes), es importante hacer demostraciones internas (por ejemplo cada 15 días) para cerrar objetivos y tener estabilizado el producto.
• El Scrum Master debe detectar quienes trabajan de manera más solitaria y no son suficientemente transparentes con el trabajo que están realizando. En esta línea, se pueden fomentar las peer reviews.
• Es más barato y produce un mejor resultado hacer pruebas unitarias automatizadas que funcionales.
• En el tipo de proyecto que se trató en el encuentro (sin evolución posterior y de corta duración, no desarrollo de producto), puede no ser necesario hacer diseño funcional ni diseño técnico. Puede ser suficiente la propia documentación del código y la que proporcionan automáticamente las herramientas de desarrollo (esquema de base de datos, etc.).
• Se comentó que la calidad interna debería ser siempre alta (aunque se tratase de un proyecto sin evolución posterior y de corta duración), ya que esto facilita desarrollar incrementalmente, encima de código ya escrito, y el equipo también tiene que estar a gusto con lo que se está haciendo.
• Hubo una propuesta de no utilizar una gestión de defectos (bugs) formal. Para que no fuese necesaria, se planteó el resolverlos lo antes posible y/o gestionarlos directamente en el sprint backlog.

  Artículos relacionados

• Priorización de prácticas ágiles en desarrollo de producto - XI encuentro ágil en Barcelona.

  Para saber más

• Agile Adoption Patters - Amr Elssamadisy
• Patterns of agile development adoption – The technical cluster – Amr Elssamadisy

  Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas. Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles:http://agile-spain.wikidot.com/quedadas-barcelona         Nota del system administrator de ProyectosAgiles.org:   Si estás viendo este artículo mediante el RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: http://www.proyectosagiles.org/rss.xml    Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.  

 

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.

Antes de ver en detalle estos skills es necesario entender una de las características principales que hace que un equipo ágil sea altamente productivo: la “potenciación del equipo”. Los miembros de un equipo ágil tienen más libertad para tomar decisiones pero también más responsabilidad, conjunta y mutua, hacia el resultado del proyecto o producto.         Notar que no todas las personas tienen que tener desarrollados todos los skills al mismo nivel, pero es necesario que haya una compensación entre los miembros del equipo para que no haya ningún déficit o exceso acusado que les impida colaborar y proporcionar el mejor resultado posible. De manera similar, estos skills serán especialmente valorados en entornos y empresas en los que se fomente una cultura de colaboración y mejora continua, mientras que pueden producir fuertes disonancias en aquellas organizaciones donde el modelo de gestión es más tradicional y jerárquico (ver el artículo El buen gestor de un equipo ágil).       Características de un equipo ágil

 

• Los miembros de un equipo ágil tienen más LIBERTAD en la manera de realizar el trabajo. Se potencia al equipo para que tome decisiones dado que sus miembros son los especialistas, los que tienen los conocimientos, habilidades y experiencias necesarios para llevar a cabo el trabajo. Los planteamientos conjuntos hacen más sencillos los proyectos, permiten mejores soluciones a partir de las sinergias de todos los miembros del equipo, a diferencia de los modelos de gestión clásicos en que las jerarquías establecen quiénes son las personas que deciden, dirigen y controlan, con lo que las soluciones que aparecen están limitadas a la capacidad de estas personas. En un entorno ágil las jerarquías se diluyen.
  
  • Los miembros de un equipo ágil establecen un objetivo común cuando entre todos deciden cuántos requisitos/objetivos son capaces de completar en una iteración. Adquieren un COMPROMISO CONJUNTO al elaborar la táctica que van a emplear para conseguir estos objetivos, identificando las tareas, asignándoselas entre ellos y autoorganizándose (ver Planificación de la iteración (Sprint planning)).
  • Entre todos identifican cuales son los impedimentos, mitigaciones y acciones de mejora a realizar que les impiden proporcionar más valor, más calidad, ser más productivos y disfrutar más del trabajo (ver Retrospectiva (Sprint Retrospective)). Sus tareas no son un pasa pelota en una cadena productiva en la que diluir su responsabilidad sobre el producto final (lo que sucede en los métodos de trabajo tradicionales), si no que todos los miembros del equipo ágil comparten la visión global del estado del proyecto respecto a los objetivos del cliente (ayudándose, por ejemplo, de la Lista de objetivos priorizada (Product Backlog) y de radiadores de información como el tablero de tareas de la iteración [Sprint Backlog]),
• El equipo es multidisciplinar. Contiene todos los roles necesarios para poder completar los objetivos de cada iteración. Cada uno realiza su aportación desde su especialidad y experiencia y se pone a disposición del resto cuando es necesario (por ejemplo en caso de que se esté finalizando la iteración y sea necesario que las personas que quedan libres colaboren en la realización de pruebas de los últimos objetivos, siguiendo las indicaciones de la persona más experimentada).

Como se puede observar, cada iteración (un período tan corto como 2, 3 o 4 semanas) exige una fuerte colaboración entre los miembros del equipo, dado que adquieren una RESPONSABILIDAD COMPARTIDA (respecto a los objetivos con que se comprometen como equipo en la iteración y a las decisiones que toman) Y MUTUA (de unos respecto a otros). Si uno falla, pueden fallar todos.   Esto les obliga a CONVERGER, a que los conflictos y las tomas de decisiones sean productivos. Es preciso llegar a consensos en los que nadie sienta que algo se está haciendo mal (si alguien lo siente así, debe proponer alternativas) [Notar que no es necesario que todos estén de acuerdo, basta con que haya suficientes personas de acuerdo y que el resto sea capaz de “vivir con ello”]. Para conseguirlo se utilizan procesos de tomas de decisión participativas (con propuesta y evaluación conjunta de alternativas, o bien entre todos convinienen delegar en miembros específicos) que permiten que los acuerdos sean más duraderos, dado que todo el equipo los hace suyos y se compromete.     Skills de un miembro de equipo ágil   Los skills de un miembro de un equipo ágil se pueden clasificar en varios grupos, según se basen en aportar valor al producto que desarrolla (calidad), en lacapacidad de colaborar con el resto de miembros del equipo o en la capacidad de mejorar, a nivel técnico y humano.   La productividad y la innovación son el resultado de: 1-     Orientarse a proporcionar el máximo valor en el mínimo tiempo. 2-     Favorecer la colaboración en el equipo para conseguir las mejores sinergias posibles 3-     Mejorar continuamente la manera de trabajar.   Veamos cuáles son estos grupos de skills en más detalle:   Inteligencia de negocio - Orientación a producir valor   El miembro del equipo ágil tiene que estar orientado a producir con CALIDAD, tiene que saber compaginar los siguientes aspectos:

• Interés por entender el producto o negocio para el que trabaja. Se preocupa por proporcionar valor al usuario final o consumidor.
• Tener una visión a medio plazo de los objetivos a conseguir (facilitada, por ejemplo, por la Lista de objetivos priorizada (Product Backlog), tener proactividad (ser capaz de detectar oportunidades y anticipar riesgos) y aún así (y dado que el foco está en proporcionar resultados tangibles cada iteración):
  
  • Buscar la simplicidad y la utilidad, conseguir la mejor solución utilizando sólo el esfuerzo necesario y no trabajar en futuribles que quizás no lleguen nunca o cambien.
  • Seguir el principio de Pareto (20/80). En las tareas que realiza, buscar el máximo retorno de inversión al esfuerzo dedicado en cada momento, balanceando valor respecto a coste.
  • En línea con el principio de fluir en el proyecto (en que el equipo minimiza el número de objetivos en curso, WIP), el miembro de un equipo ágil acaba tareas y no deja temas abiertos, de manera que se minimizan los cambios de contexto, aumentando la productividad y avanzando en el proyecto.
• Pasión y orgullo por el trabajo que se realiza, ser exigente con la calidad técnica, disciplinado y metódico, para que el producto pueda crecer de manera sostenida.

Inteligencia emocional – Capacidad de trabajar en equipo   El miembro del equipo ágil tiene que favorecer la COMUNICACIÓN y para ello tener las siguientes aptitudes:

• Transparencia en las tareas que realiza y su estado, para que el resto del equipo tenga la información necesaria (por ejemplo en las reuniones diarias de sincronización (Scrum daily meetings) o en las retrospectivas), que todos puedan colaborar y ayudarse a conseguir los objetivos de la iteración, evitando también que se realicen esfuerzos innecesarios.
• Franqueza con el cliente sobre la situación del proyecto (especialmente en las demostraciones (Sprint demostrations)), para que pueda tomar decisiones basadas en lo que realmente está hecho y en la velocidad del equipo.
• No hacerse dueño de conocimiento, si no compartirlo y ser capaz para enseñar.
• Escucha activa, entender lo que le están explicando
• Observar, escuchar, preguntar mucho y reparafrasear para entender las las necesidades, motivaciones y sentimientos de los otros, ponerse en su lugar antes de dar la propia opinión (si es realmente necesario que la demos). Es decir, evitar juzgar inmediatamente al otro y tener empatía.

El miembro del equipo ágil tiene que saber respetar las opiniones de los otros y para ello tener las siguientes aptitudes:

• Confianza en los demás miembros del equipo, creer que serán capaces de realizar sus tareas, sin necesidad de estar controlándolos, recordar siempre que todos están actuando con la mejor voluntad posible, y tener paciencia. Esta confianza se ve facilitada por la compartición de conocimiento que se produce en las reuniones de alta productividad que el equipo al completo realiza en las actividades de Scrum, las cuales necesitan de la transparencia indicada anteriormente.
• Consensuar, ser capaz de negociar un ganar/ganar, no imponer su criterio. Ser honesto y sincero, no engañar o aprovecharse de los otros (sean clientes, gestores o miembros del equipo).
• Educación, buenas maneras, dando su opinión sin atacar ni acusar (simplemente hablando de los hechos que le han sucedido), tranquilo, no irascible, afable y con sentido del humor, para no vivir en tensión constante y compartir momentos de relajación con el resto del equipo.

  Inteligencia vital – Capacidad de mejorar   El miembro del equipo ágil es capaz de conjugar el progreso técnico y el humano, tiene afán por APRENDER nuevas formas de trabajar y de relacionarse, y para ello tener las siguientes aptitudes:

• Humildad, evitar la prepotencia (que no es necesaria, la valía se demuestra realizando un trabajo excelente, el reconocimiento es una consecuencia que debe llegar por sí solo), tener una mente abierta a escuchar ideas diferentes de otros y flexibilidad para probar nuevas cosas.
• Capacidad de autocrítica, reconocer equivocaciones y tomarlas como oportunidades de mejora. Similarmente, no buscar culpables cuando se cometen errores, si no ver entre todos cómo mejorar el proceso de trabajo.
• Capacidad de reflexión e inconformismo productivo, cuando algo no funciona ser capaz de cuestionar cómo se están haciendo las cosas. Tener valores, ética, integridad, coraje para tomar decisiones y hacer “lo que se tiene que hacer” (o no hacer lo que no se tiene que hacer), aunque sea más difícil (asumiendo riesgos controlados).Para ello necesita ser asertivo en los mensajes, hablar de manera clara, objetiva, ser franco (con compañeros, gestores y clientes) sobre los problemas que hay y proponer alternativas mejores.
• Creatividad, intuición, capaz de desaprender e innovar aportando nuevas ideas tanto en el producto como en la manera de trabajar.
• Como se ha mencionado anteriormente, tiene que ser capaz de disfrutar en el camino, realizarse en su trabajo (son muchas horas a la semana como para que no sea así), aprendiendo, creando, superando retos, progresando y contagiando entusiasmo al resto del equipo.
• Evitar estar en sobreesfuerzo continuo, tener como objetivo no trabajar más de 40 horas a la semana (en caso contrario, cuando sea necesario un sobreesfuerzo, no va a haber de donde sacar, sin contar con que la calidad del trabajo se degrada cuando se alarga demasiadas horas) y dedicar el tiempo restante a actividades personales, familiares, ocio, formarse, otros proyectos, … Es necesario disponer de tiempo para crecer a nivel personal y profesional, para alcanzar un equilibrio y tener estos pilares vitales afianzados.

  Es más difícil, pero es mejor
  Los skills anteriores se pueden entender como un marco de referencia sobre el que reflexionar, con el cual poder identificar nuestras carencias (y las carencias que los demás ven en nosotros), para gradualmente ir madurando hacia un enfoque ágil que haga más sencillo proporcionar más valor a nuestros clientes así como disfrutar más de nuestro trabajo y de nuestra vida.       Para saber más
 

• Otras características del equipo en Scrum.
• El buen gestor de un equipo ágil.
• El manifiesto ágil.
• Valores de Scrum: Compromiso, franqueza, foco, respeto, coraje.
• Valores de eXtreme Programming: comunicación, feedback, simplicidad, coraje.
• Prácticas de eXtreme Programming.
• Principios de Lean Software Development.
• Collaboration Explained: Facilitation Skills for Software Project Leaders - Jean Tabaka.
• Culturas innovadoras 2.0, libro de Juan Carrión.

  “Es más difícil, pero es mejor” es una frase que pronuncia frecuentemente Ángel Medinilla.

 

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.

La presentación que se utilizó se encuentra aquí: http://www.slideshare.net/alexisroque/agile-development-ecosystem         Objetivo de un ecosistema ágil   El objetivo de un ecosistema ágil es que todo fluya para poder proporcionar resultados y productividad. Un ecosistema de herramientas da soporte a una metodología determinada y a sus prácticas; en el caso de las metodologías ágiles, especialmente es un soporte a la realización de tareas de manera eficiente basándose en la comunicación entre todos los actores [1].   Por ello, el ecosistema ágil debe ser:

• Un canal de comunicación entre los miembros del equipo y también con el cliente.
  
  • Un repositorio de información.
  • Una agenda / planificador que permita monitorizar / hacer seguimiento.
  • Accesible remotamente y a la vez tangible, que casi se pueda tocar físicamente.
• Aceptado por el equipo, que perciba su beneficio.
  
  • Con la entrada de datos muy automatizada.
  • Que facilite el aprendizaje del equipo, que vaya mejorando en su manera de trabajar [2].

  La participación del cliente   La participación del cliente es especialmente importante cuando se trabaja con metodologías ágiles. Por ello es importante considerar cómo este actor puede interactuar con él:

• Consultando el estado de los objetivos/requisitos, burndowns, e incluso creando los objetivos/requisitos.
• Se puede asignar tareas al cliente como, por ejemplo, que suba al gestor de contenidos información relevante del proyecto.

  El jardinero del ecosistema   Puede ser necesaria una figura que se encargue de mantener suficientemente pulcro el ecosistema, especialmente es complejo por que existen muchos módulos, algunos sin integración automática. Esta persona se encarga de:

• Estructurar la información.
• Quitar ruido.

Para reducir su labor al mínimo, es recomendable que existan procedimientos de trabajo con el ecosistema y guías de uso de las herramientas.   Este jardinero del ecosistema, entre otras cosas, puede ser la misma persona que se encarga de recoger las retrospectivas de cada proyecto y difundir sus conclusiones poniéndolas en un Wiki global, o bien quien se encargue de avisar a quienes no están reportando las horas de trabajo pendiente (que permiten crear el burndown).     Ejemplo de ecosistema ágil   En el encuentro se presentó el siguiente ecosistema:   Tipo de Herramienta Producto Observaciones Content Management Server ActiveCollab Ficheros binarios (documentos, imágenes) Wiki ActiveCollab Versionado, comentarios, discusión, etiquetas, búsquedas. Sirve también como repositorio de lecciones aprendidas. Project Management ActiveCollab   Issue Management ActiveCollab   Software Configuration Management Subversion Está desligado de ActiveCollab. La trazabilidad se mantiene de manera manual. Continuous Integration Server Maven   Communication Booster Gmail + GTalk Twitter o Jammer   Demo / Preproduction Server     Sprint Backlog GoogleDocs Con burndowns. ActiveCollab es fácil de desplegar (incluso existe el formato ASP). Da un buen resultado (Pareto 80/20). Sus principales problemas son:

• Wiki y calendario limitados.
• No dispone de una visión multiproyecto.
• Hay un Wiki por proyecto. Esto impide disponer de un repositorio de lecciones aprendidas (ni gestión del conocimiento) para toda la organización si no es haciendo una copia manual de las lecciones de cada proyecto hacia un Wiki corporativo.
• No es Open Source.
• No hay charting.
• No es un tablero de tareas físico, con lo que se pierden los efectos de radiador de información y psicológico de ir moviendo las tareas a estado “hecho”.

Se propusieron otras herramientas, en función de la tecnología de desarrollo y el precio de las herramientas: Redmine, Jira + Confluence + Greenhopper, Team Foundation Server (Microsoft).     Twitter / Jammer

• Se utiliza para toda la empresa, para solicitar ayuda (por ejemplo indicar en qué estás atascado) y/o que fluya información de interés. Incluso se plantean incentivos para quien realice el mejor post. El problema es que como gestor de conocimiento es limitado. Una alternativa es utilizar una delicious como gestor de conocimiento con Twitter como push.
• Por otro lado, es muy necesario tener disciplina en lo que se escribe y no hacer ruido. Para ello ayuda que los gestores y jefes de proyecto estén suscritos J
• NO se utiliza para comunicarse dentro de las tareas propias de un equipo. Los miembros del equipo deben ser capaces de comunicarse de manera más directa, especialmente si están co-localizados.
• Jammer dispone de un Niko Calendar. Dentro de la empresa se considera “obligado” empezar el día indicando cual es tu estado de ánimo, para que si tienes algún problema otra persona se de cuenta, pueda interesarse por ti y ayudarte.

  Inconvenientes para la implantación de un sistema   Finalmente se mencionó que el principal inconveniente para la implantación de un sistema es, como siempre, el cambio en la manera de trabajar, que implica formación en el sistema y perseguir su uso. Una vez implantado, hay que ir mejorando el sistema.     Artículos relacionados

• [1] Individuos e interacciones más que procesos y herramientas, ver el manifiesto ágil.
• [2] Ver los trucos para la elaboración del tablero de tareas.

  Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas. Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona