12th International Conference on Agile Software Development, Madrid, Spain, 10-13 May 2011

The 12th International Conference on Agile Software Development, XP2011, is a leading international conference on agile methods in software and information systems development. XP2011 will be hosted by Universidad Politécnica de Madrid (Technical University of Madrid, UPM), in Spain. The conference brings together both industrial practitioners and researchers in the fields of information systems and software development, and examines latest theory, practical applications, and implications of agile methods.

XP2011 encourages submissions of high quality research papers, workshops, experience reports, posters, tutorials, PhD symposium papers, and lightning talks, an opportunity to share important ideas or experiences in ten minute slots. The topics of interest in the conference include, but are not restricted to, the following:

  • Adoption and diffusion of agile methods
  • Implementing agility in global software development
  • Agile Offshore and Agile Software Factories
  • Empirical studies and experiences of agile methods
  • Tools and techniques for agile development
  • Social and human aspects of agile methods
  • Organizational agility
  • SOA based systems and agile development
  • Measurement and metrics for agile projects and enterprise
  • XP evolution, new XP trends or XP proposals of update
  • Agile for IT Development
  • Agility in systems engineering and safety critical systems
  • Software and systems architecture in an agile environment
  • Legacy systems and agility
  • Agile usability
  • Management and governance aspects of agile methods
  • Implications of agile methods for industrial practice
  • Foundations and conceptual studies of agile methods
  • Implications of agile methods for research and education


More info at http://www.xp2011.org/

 

Agile Industrial Day – Madrid, Spain, November 30, 2010

Overview

The Agile Industrial Day aims to promote Agile practices in industry and to guide when and how to deploy these practices in software development. This Agile Industrial Day will be hosted by the Escuela Universitaria de Informática (University School of Computer Science) of the Universidad Politécnica de Madrid (Technical University of Madrid, UPM). It is characterized by its distinguished speakers in the agile and software engineering area. Their talks will address those key challenges and adoptions in the area from a practical perspective, and based on their experience in industrial cases. In addition, a panel to discuss ideas, challenges, and solutions will take place to attract organizations and researchers about new software development practices that software companies, developers, and project managers among others can benefit.

The main objective of this day is to bring together both industrial practitioners and researchers in the fields of information systems and software development to provide them the vision and experience of the most experts in the area. 


Programme

Time table

08:30 – 09:15

Registration

09:15 – 09:30

Opening: Welcome and introduction

09:30 – 11:00

Philippe Kruchten"Putting agility in context"

11:00 – 11:30

Coffee break

11:30 – 12:15

Alberto Pizarro“Learning agility through architecture.  Trick AND treat”

12:15 – 13:00

Juan Antonio Paz Salgado"Agile SOA integration in Telco environment"

13:00 – 15:00

Lunch

15:00 – 16:00

Alan Brown"Best Practices for Delivering Quality Solutions in a Distributed Agile Environment”

16:00 – 17:30

 Panel (moderated by Xavi Albaladejo)

 More info at https://syst.eui.upm.es/agileindustrialday

Presentación de métodos ágiles “La alternativa ágil”

La pasada semana impartí un curso de métodos ágiles (Scrum y Kanban, con unas pinceladas de Lean y XP) en el marco de los Executive Education – Custom Programs de La Salle Business Engineering School (Universidad Ramon Llull, Barcelona).

la-alternativa-agil-V5.3

A continuación aparece un enlace al Powerpoint utilizado como guía del curso, que parte de una presentación de Agile-Spain con slides específicos de proyectosagiles.org y uno de Henrik Kniberg (crisp.se):

Versión actualizada:

http://www.slideshare.net/xalbaladejo/la-alternativa-agil-v57

 

Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablero o pizarra de tareas (Scrum Taskboard) que actúa como radiador de información. A continuación se muestra cómo construirlo y un ejemplo de su uso.

Construcción del tablero

Material

  • Pizarra blanca o cartón pluma, como mínimo de 100 cm x 70 cm, marcando las áreas del tablero con cinta adhesiva de colores.
    • Idealmente, el equipo debería de disponer de una superficie el doble de grande, para poderse ver y leer bien a cierta distancia, así como tener suficiente espacio físico para hacer delante suyo la reunión diaria de sincronización (Scrum daily meeting).
    • En su defecto, se puede utilizar papelógrafo o corcho.
  • Rotuladores permanentes de color negro, rojo y verde.
  • Regla de 50 cm.

 Dimensiones 

 scrum-taskboard-dimensiones

La distribución de zonas se ha realizado de la siguiente manera:

  • En la parte superior se dispone una fila específica para tareas no planificadas, aquellas que no son parte de los requisitos/objetivos de la iteración pero que es necesario hacer de manera urgente (errores en producción, urgencias del cliente, etc.). De esta manera podremos visualizar cuanto somos de reactivos en lugar de planificados dentro de la iteración.
  • A continuación hay una fila reservada para la mejora continua, donde se podrán las tareas fruto de retrospectivas anteriores y que queremos que realizar en esta iteración. Sólo pondremos aquí aquellas tareas que no sean asociables a un objetivo propio de la iteración.
  • Se ha dejado más espacio para la columna de tareas no iniciadas, de manera que quepan todas las que se identifican en la reunión de planificación de la iteración (sprint planning). Notar que el espacio para tareas en curso es menor, dado que deberían ser las mínimas posibles para favorecer el flujo eliminando el multitasking. Similarmente, el número de objetivos abiertos en curso (WIP, Work In Progress) debería ser el mínimo posible y ser resueltos de arriba a abajo, según la prioridad indicada en el Product Backlog.
  • La zona de impedimentos está destinada a la lista de obstáculos que pueden impedir que el equipo avance, que consiga los objetivos de la iteración o del proyecto, u otros riesgos que requieren una atención especial. Es conveniente indicar quien es el responsable de su solución (un miembro del propio equipo o el Facilitador (Scrum Master), dado que es una de sus principales atribuciones). Se gestionan de manera similar a las tareas (pendientes, en curso, hechos).
  • La zona de retrospectiva servirá para ir anotando durante la iteración los aspectos que están funcionado bien (+, Pluses) así como los problemas que vamos identificando (Δ, Deltas).
  • En la zona libre de la derecha situaremos, encima, información propia del proyecto y, debajo, información propia de la iteración (explicado más adelante).

Resultado de la construcción

 scrum-taskboard-carton-pluma

Las ventajas de utilizar como base el cartón pluma son:

  • Su poco peso, lo cual permite llevar el tablero fácilmente desde la zona de trabajo del equipo a una sala para, por ejemplo, hacer la reunión de planificación de iteración (sprint planning).
  • Su modularidad, que permite adaptarlo a diferentes tamaños de equipo (las dimensiones del tablero de este ejemplo son las adecuadas para un equipo de 5 personas). Además de existir formatos de tamaño mayor e inferior, si es necesario en nuestro proyecto, podemos utilizar varios tableros y disponerlos uno al lado de otro, cambiar su orientación (horizontal-vertical), etc.

El tablero como radiador de la información de referencia para el equipo

El tablero es un radiador de información,  difunde el estado actual de la iteración (actualizado en la reunión diaria de sincronización (Scrum daily meeting), por lo que debe estar visible desde los puestos de trabajo del equipo con sólo hacer un movimiento de cabeza. También es especialmente útil en las reuniones que realizamos durante la iteración,  por lo que en él ponemos aquella información que queramos  consultar fácilmente cuando tengamos conversaciones delante del tablero:

  • La leyenda con el nombre de los miembros del equipo, su código de colores, fotos.
  • Información general del proyecto
    • La definición de hecho, que nos servirá como base inicial para hacer el despiece de objetivos de la iteración en tareas durante la reunión de Planificación de la iteración (Sprint planning).
    • La lista de objetivos priorizada del proyecto (Product Backlog).
    • Modelos del producto que se está desarrollando, a los que referirnos cuando expliquemos algo a los demás. De esta manera todos los miembros del equipo tendrán una misma visión, les sirvirá de apoyo cuando comuniquen cosas y ayudará a que utilicen una misma nomenclatura. Típicamente: diagrama de entidades del dominio, procesos o bloques funcionales e integraciones, etc.
    • Indicadores del proyecto: Product Backlog Burndown Chart, tendencias de defectos, etc.
  • Información propia de la iteración
  • Cualquier otra información que nos interese tener muy a mano.

scrum-taskboard-planificacion-iteracion-inicio

Planificación de la iteración (Sprint Planning)

Durante la reunión de planificación de la iteración, se va incorporando al tablero siguiente información:

  • En la columna de la izquierda se irán situando los objetivos de producto (Product Backlog Items) que el equipo se compromete a completar en la iteración, ordenados por prioridad para el cliente (Product Owner). Estos objetivos se pueden redactar, por ejemplo en formato de historias de usuario o, simplemente, con un título y un detalle (preferiblemente que indique qué pruebas se van a realizar para demostrar que el objetivo está conseguido).
  • A la derecha de cada objetivo se pondrán, en la columna “pendientes”, las tareas necesarias para poder completarlo, indicando las horas estimadas para su resolución, que iremos actualizando en las reuniones diarias de sincronización (Scrum daily meetings).
  • En su zona específica, dispondremos las tareas de mejora continua que se han derivado de la retrospectiva de la iteración anterior, que queremos resolver durante esta iteración y que, por tanto, consumirán tiempo de alguna persona.

De esta manera visualizaremos todos los tipos de tareas en que trabajan los miembros del equipo.

 scrum-taskboard-planificacion-iteracion-final

Ejecución de la iteración

    • Ponemos en color rosa las nuevas tareas que vayan apareciendo, sean:
        • Tareas  asociadas a objetivos / requisitos / historias de usuario que no fueron identificadas en la reunión de planificación de la iteración.
      • Tareas inesperadas y no asociadas a objetivos pero que exigen nuestra resolución dentro de la propia iteración (en la zona “no planificado”).
        • De esta manera podremos obtener métricas de trabajo no planificado [2] y en la retrospectiva revisaremos cuáles son las tareas que han aparecido de color rosa, lo cual nos permitirá saber, por ejemplo, si es que tenemos que mejorar nuestra definición de hecho o bien si tenemos que reflexionar y realizar alguna acción para intentar minimizar tareas no previstas.
    • Marcamos con un gomet rojo los objetivos y/o las tareas con más riesgos, aquellos que queremos tener controlados con más atención.
    • Cuando suceda alguna cosa que queramos comentar en la retrospectiva, la ponemos en su zona específica, en función de que sea una cosa que se está haciendo bien y se quiere recordar para memorizar y/o incluir como buena práctica (+, Plus) o bien una cosa una cosa a mejorar (Δ, Delta).
    • Ponemos los impedimentos, riesgos o cualquier otra cosa crítica que se tenga que ir resolviendo en la zona a tal efecto, especialmente las acciones a realizar que están fuera del alcance del equipo y que sean para el Facilitador (Scrum Master). Los gestionamos de la misma manera que cualquier otra tarea, poniéndolos como pendientes, en curso o hechos.
  • Podemos poner en otro color, por ejemplo en azul, los objetivos de la iteración siguiente que iniciamos en la iteración actual, para saber que estamos avanzando, pero también para no perder el foco en que lo primero que tenemos que completar son los comprometidos para la iteración. De esta manera podremos obtener métricas de trabajo avanzado [2] y reflexionar en la retrospectiva.

[Los colores aquí indicados para objetivos de la iteración (ítems del Product Backlog) y para las tareas son orientativos y se pueden ampliar en función de otros aspectos que queramos señalizar de manera especial (ítems de temas diferentes, tareas de corrección de errores, etc.)].

 scrum-taskboad-ejecucion-iteracion

Trucos (sólo si es necesario)

  • Utilizar una marca específica para las tareas más prioritarias (reservar el color rojo para indicar problemas o riesgos).
  • Poner colores diferentes en función del tipo de tarea (análisis/diseño, construcción, errores).
  • Poner 1 punto negro por cada día que una tarea se retrasa, para que el equipo vea si hay algún peligro y para poder reflexionar en la retrospectiva.
  • Poner 1 punto naranja cada vez que un objetivo/tarea se reabre por que no pasa las pruebas / control de calidad / aceptación y vuelve «hacia atrás».
  • Sólo mover tareas a «Hechas» en la reunión diaria de sincronización, para que todo el mundo sea conciente del avance. Para ello, cuando alguien acaba una tarea, la marca como «hecha» pero no la mueve.
  • Una vez acabada una tarea, si es necesario que otra persona haga control de calidad (peer review y/o pruebas), se puede marcar la tarea indicando «Revisar», por ejemplo con un post-it más pequeño. Se puede utilizar el siguiente convenio: un gomet a la izquierda para identificar a quien “hará” y otro a la derecha para identificar a quien “revisará».
    • Notar que la marca «Revisar» es equivalente a tener un estado de tareas (columna) llamado Revisar, por lo que evita crear una “tarea Y” específica para hacer el control de calidad de la “tarea X” o tener una columna específica de “Revisar”, especialmente si este estado no es  aplicable a la mayoría de tareas. Sin embargo, se podría utilizar alguno de estos sistemas de control si se considera necesario, por ejemplo si el 80% de las tareas necesita revisión.
  • Poner un número en las tareas para indicar el orden.
  • Poner en las tareas el ID o nombre abreviado de la historia de usuario (por si se caen).
  • Tener una zona de Parking para los siguientes objetivos si no caben en el tablero o para tareas que el equipo va detectando que sería necesario hacer antes de finalizar la iteración pero que todavía no han sido clasificadas en objetivos.

Material para trabajar con el taskboard

A continuación aparece el material utilizado para crear este taskboard pequeño realizado en cartón pluma. Idealmente, el equipo debería de disponer de una superficie el doble de grande (para poderse ver y leer bien a cierta distancia) y entonces utilizar formatos de post-it  algo mayores.

  • Post-its rectangulares: 13 x 7,5 cm,
    • 2 paquetes color amarillo
    • 1 paquetes color azul (o verde)
    • 1 paquete color rosa (o naranja)
  • Post-its cuadrados, 7,5 x 7,5 cm, a ser posible: super sticky
    • 4 paquetes color amarillo
    • 2 paquetes color verde
    • 2 paquetes color naranja
    • 1 paquete color lila
    • 1 paquete color rosa (o rojo)
    • 1 paquete color azul
  • Post-its pequeños 5 x 4 Etiquetas post-its (2,5 x 7 cm), en 2 o 3 colores diferentes.
    • 6 paquetes color amarillo.
    • 1 paquete color rosa (o naranja)
    • 1 paquete color azul (o verde)
  • Cinta adhesiva transparente.
  • Cinta adhesiva  de color o negra, 3M Temflex 1500 o TESA 4204.
  • Tijeras.
  • Gomets pequeños para asignación de 7 personas: 7 colores + rojo = 8 colores. Si es un tablero de corcho: marcas/papelitos de colores y chinchetas.
  • Rotuladores normales: negro, rojo, verde, azul.
  • Rotuladores de pizarra blanca: negro, rojo, verde, azul.
  • Borrador de pizarra blanca.
  • Caja donde guardar todo el material anterior.

Agradecimientos

Me gustaría agradecer a las siguientes personas las ideas y consejos que me han ido proporcionando en estos años de uso de tableros de Scrum:

scrum-task-board

¿Quién es responsable de la calidad?

(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)




El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.

Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:

  • La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
  • La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar  por el Product Owner.
  • La calidad interna no suele poder ser verificable directamente por el Product Owner.

Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.

Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.

Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum  Master guía al Product Owner y al equipo para conseguir que:

  • El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
  • El equipo cumpla con la definición  de hecho que ha sido consensuada con el cliente.
  • El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
  • El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración.
  • Similarmente, el Scrum Master debe hacer recapacitar al Product Owner si quiere rebajar la calidad a cambio de conseguir objetivos en fechas determinadas (lo cual produciría defectos en el producto una vez entregado, ralentizaría después la velocidad del equipo y tiene el riesgo de mala imagen respecto a los consumidores/clientes/usuarios). Si finalmente es necesario hacer esto, el Scrum Master tiene que hacer que esta decisión se tome al nivel más alto posible y que sea visible. Con posterioridad a la toma de esta decisión, el Scrum Master debe ser capaz de demostrar, si es necesario, las consecuencias de haber rebajado la calidad mediante gráficos de tendencias de velocidad y defectos, así como explicar sus causas objetivas (menos testing, menos refactoring, …) [1].

Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.

 

Enlaces relacionados

Referencias

 [1] Succeeding with Agile: Software Development Using Scrum – Mike Cohn.

 

Abierta la inscripción a la Conferencia Agile-Spain 2010, 10 y 11 de Junio

 

Ya es posible inscribirse en la Conferencia Agile-Spain 2010, que tendrá lugar en Madrid el 10 y 11 de Junio.

Conferencia Agile Spain 2010

El programa es de lo más interesante (incluye un KeyNote de Henrik Kniberg) y el precio es muy ajustado, gracias a los patrocinadores: 95 euros la entrada, cosa que permite escoger entre 26 sesiones, y hasta 8 talleres de entre 50 y 200 euros. Ángel Medinilla y Xavier Albaladejo seremos los ponentes del taller de retrospectivas ágiles.

Esta conferencia es el fruto del esfuerzo de un equipo humano excepcional y entregado, que con una enorme ilusión ha dedicado muchas horas personales y ha robado horas al sueño para que podamos tener esta primera conferencia sobre métodos ágiles en España: Jorge Uriarte, José Ramón Díaz, Carmen Vidal, Ricardo Roldán, Harald Messemer, Vicenç García, Ángel Medinilla, Carlos Ble, Gustavo Cebrian, Rodrigo Corral, Xavier Quesada y yo mismo, que junto con Agustín Yagüe y Juan Gutiérrez hemos compartido el rol de Product Owners entre otras muchas tareas. Por cierto, todavía queda trabajo por hacer, así que los voluntarios son bienvenidos 🙂

Comentar que esta ha sido una experiencia muy enriquecedora, tanto por lo que he aprendido de estas personas como por el tipo de gestión realizado (una adaptación de Scrum para poder trabajar como equipo distribuido por todo el país) así como por el producto (nunca había trabajado en la organización de una conferencia).

Aunque este proyecto me ha impedido publicar artículos en estos últimos meses, pronto espero disponer de tiempo para ello. ¿Cuándo?, después de la conferencia 🙂
 

Priorización de prácticas ágiles en desarrollo de producto – XI encuentro ágil en Barcelona

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

priorizacion-practicas-agiles-producto

 

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, cómo debe comportarse el sistema (o BDD, Behaviour Driven Development),  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

 

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: /wordpress/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.

Conferencia Agile-Spain 2010, Madrid, 10 y 11 de Junio – «Haciendo realidad la agilidad»

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.

conferencia-agile-spain-2010 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.

 

 

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

 

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
 
 priorizacion-practicas-agiles-proyecto-corto
 
 

 
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.
 
 
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: /wordpress/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.
 

 

Skills en un equipo ágil

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.
 skills-equipo-agil-scrum

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 AUTONOMÍA 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 en cascada / 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.

Los conflictos en un equipo que está trabajando con los mismos objetivos y con responsabilidad mutua son naturales (sus miembros tienen distintas experiencias, conocimientos, ver complejidad en proyectos) y necesarios (para obtener la mejor solución posible fruto de sus sinergias y mejorar de manera continua). Bajo este planteamiento, es muy importante que cuando una persona discrepe de alguna decisión o sienta que la actitud de otra impide que el equipo sea productivo, se sienta con suficiente libertad y confianza como para mostrar su punto de vista a la(s) otra(s) tan pronto como sea posible, en lugar de hacer hipótesis erróneas por falta de información, fomentar rumorología no constructiva o dejar los problemas sin resolver hasta aceptarlos como endémicos.

Dicho esto, es muy importante que esta comunicación y feedback se realice utilizando el mejor canal posible, preferiblemente cara a cara (por video-conferencia o por teléfono), antes que utilizar el texto (chat o email, que si además expone a la otra persona al juicio de muchas otras en copia, implica esfuerzos de autojustificación y autodefensa que restan al avance del proyecto). La comunicación verbal, además de ser más ágil por obtener información de manera más fluida, permite escuchar y entender mejor las razones del otro, evita malas interpretaciones y facilita conocer las emociones del otro. En este punto es importante no formular preguntas de manera acusatoria y ni hacer juicios. El objetivo no es buscar culpables, sino llegar a consensos que permitan aportar más valor al proyecto, ser más productivos y mejorar el proceso de trabajo.

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 la capacidad 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:
 –  Orientarse a proporcionar el máximo valor en el mínimo tiempo.
 –  Favorecer la colaboración en el equipo para conseguir las mejores sinergias posibles
 –  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 review)), 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 realmente es necesario ofrecerla). 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, por contra, 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 mejorLos 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 

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