La estimación ágil de proyectos, puntos-historia y velocidad

Uno de los temas más recurrentes, y que causa más dolores de cabeza es la estimación de proyectos. Trataré de explicar mi visión al utilizar una posible técnica: la estimación por puntos-historia utilizado típicamente en algunas de las metodologías ágiles.

Dejamos aparte por ahora el nirvana de no tener que estimar. Si ya has conseguido no tener la necesidad de estimar, enhorabuena, tus comentarios sobre el proceso serán bienvenidos :) A los demás: todo llegará ;)

Supongamos que en un determinado momento nos llega un proyecto, una visión, y nos hacen la pregunta del millón ¿para cuando estará? y sobre todo, ¿cuanto va a costar?
Es entonces cuando el equipo suspira, mira al techo, y tras asegurar que lo que vas a dar es una estimación aproximada, se pone a trabajar. Porque tus estimaciones las hará el equipo que va a hacer el trabajo, ¿verdad? ^_^

Historias de Usuario: Colaboración,
planificación, y requisitos. 

1) Obtención de las historias de usuario del proyecto

  Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero, ¿aproximada? Ten en cuenta que nunca nunca nunca se puede definir un alcance de un proyecto de manera cerrada y completa. Así que no merece la pena intentarlo. Hay que hacerse el suficiente detalle por si alguien necesita calcular el ROI o la inversión a realizar aproximado. Pero también hay que hacer ver que sabemos que va a haber cambios que imposibilitan la certeza absoluta. Y que desconocemos el el inicio de un proyecto, el alcance real. Recordad el cono de incertumbre.
 Con una visión de proyecto necesitamos hacer dos cosas: un Inception para bajarla a tierra y empezar a crear visión compartida. Y los talleres de historias de usuario que sean necesarios para generar un backlog con el que gestionar el alcance del proyecto. En este punto debes valorar el tiempo invertido en detallarlas. Es más importante lograr el máximo despliegue de historias que profundidad en cada una. Una gran técnica son los mapas de producto.

2) Aplicar la vara de medir del equipo

Planning poker

 Ahora debemos medir lo que queremos construir para saber cuando podemos terminarlo. No podemos decir el tiempo que podremos hacer en una carrera, si no sabemos la longitud de la misma. Asignar puntos en realidad no es estimar una historia, es solo medirla. Establecer el acuerdo por el que el equipo decide qué tamaño tiene. Esta es la razón por la que posteriormente las velocidades no son comparables entre equipos, simplemente porque cada equipo tiene su propia vara de medir. Y es subjetiva.
 ¿Te puedes equivocar asignando tamaños? Sí, pero NO. :) En realidad no importa mucho si te puedes equivocar o no. Lo importante es que seguro que te equivocas siempre de la misma manera, y eso nos dará predecibillidad. Asignar tamaños relativos nos ayuda a acertar por comparación, de manera que no nos hace falta demasiado detalle en cada elemento para relativizarlo unos respecto de otros.
 En mi experiencia funciona mejor crear una escala de tamaños de historia de usuarios relativa, ordenándolas de mayor a menor, y posteriormente asignándoles los puntos del "planing poker". Ver historia a historia, de una en una, y asignándole tamaños individualmente, genera reuniones tediosas y donde perdemos la visión comparativa entre historias.

3) Estimar la velocidad

 Es en este momento cuando realmente hacemos una estimación, respondiendo a la pregunta: ¿a qué velocidad avanzará este equipo en este proyecto? Esta es la verdadera piedra angular de la estimación y que nos dará como resultado una posible planificación temporal.
 La situación ideal se da en un equipo que tiene históricos anteriores. Guardamos las velocidades anteriores de los proyectos, y si el proyecto se da en condiciones parecidas, ¡la velocidad anterior la podemos proyectar al futuro!
 Cuando no tenemos históricos, es cuando realmente hacemos una estimación compleja. ¿cuantas historias de las definidas anteriormente creemos que podemos hacer por sprint? ¿vamos a ir más rápido o más lento construyendo el software? El equipo debe calcular cuanto será capaz de hacer por sprint, para estimar la velocidad. Juega siempre con un rango, una estimación pesimista y otra optimista. Es más fácil así dejar claro que es una estimación, y que puede tener un error.

4) Planificar

Índice de mi formación en Historias de Usuario.

 NO todo en esta vida, ni en los proyectos, son historias de usuario. NO intentes hacer que lo sean. A veces ;) hay que realizar formaciones, instalaciones de entornos, hacer spikes, etc. Hay que tenerlas en cuenta para calcular la fecha final, por si hay que sumar al tiempo de desarrollo, obviamente.
 Dada la velocidad y el tamaño del proyecto podemos hacer una simple regla de tres para conocer una posible planificación, entre la velocidad optimista y pesimista. Número de puntos totales dividido por la velocidad por iteración = número de iteraciones. Sumando imprevistos y cualquier cuestión que quede fuera de historias de usuario, tendremos nuestra primera aproximación al proyecto.

5) Asumir la realidad

 Esta es la parte más difícil de todo el proceso. Deja que el proyecto/producto evolucione y adáptate a los que vaya sucediendo.
 ¿el proyecto marcha a menos velocidad de la estimada? Calcula los nuevos costes, ¿son aceptables? ¿debes cortar en el alcance?
 ¿Surgen problemas que no habías previsto? Actualiza lo que vaya a afectar a la velocidad. ¿o necesitas nuevos perfiles? Actualiza el coste... compara la velocidad real con la planificada continuamente.

 En definitiva, no dejes que tu maravilloso plan arruine la realidad. Haz un chequeo a nivel global tras cada iteración, y no caigas en el optimismo de "ya mejoraremos" si tu gráfica de burn-down te dice que no hay tutía.

6 tendencias para el 2013 en "Project Management"

Me he quedado con una sensación rara tras leer este artículo del ESI. Y realmente no sabía muy bien por qué, creo que no lo llego a entender del todo :\. Así que he decidido que iba a escribir las tendencias que yo veo en la gestión de proyectos alrededor de mi, y posteriormente compararlas:

Mis predicción de tendencias en gestión de proyectos para este año (y "ad infinitum") son:

• Las organizaciones se darán cuenta que no vale con tener líderes (expertos, PMs, ScMs,...), sino que hay que crear verdaderos equipos.
• Algunas organizaciones triunfarán con la implantación de Agile, y se comerán a las que no consigan adaptarse. Otras fallarán, indudablemente.
• Desaparecerá la "responsabilidad individual" de la gestión de proyectos: habrá que equipos, que simplemente, sepan -aprendan- lo que tienen que hacer para lograr el éxito.
• Las PMOs desaparecerán para ceder el control de los procesos a la gente que realmente sabe de ellos, los que lo ejecutan. Existirán comunidades de práctica mejorándolos.
• Los grandes proyectos plantean retos únicos que son cada vez más difíciles de superar. Sí. Debes contar con las armas adecuadas: gente motivada :)
• Los "gestores de proyecto" irán dando paso paulatinamente a "facilitadores de valor para la organización". Se verá el sistema, no cada proyecto peleando por "los recursos", no habrá que gestionar  un portfolio, solo sumar valor.

No sé parecen mucho a las del ESI. Pero con eso me quedaría más tranquilo. Y además, se empiezan a ver alrededor.

Próximos talleres en Pamplona: Lean/kanban y Retrospectivas

ACTUALIZACIÓN FEB. 2013: Cursos de Lean/Kanban en San Sebastian y Madrid.

En Noviembre hemos organizado junto con CEIN dos diferentes talleres, de una mañana de duración, sobre temáticas ágiles.

Taller Lean/Kanban
El primer taller se realizará el 9 de Noviembre, sobre Kanban. Veremos cuales son los conceptos que podemos aplicar de esta metodología de manera práctica. Hablaremos sobre los principios ágiles y Lean, realizaremos una simulación, dibujaremos nuestro panel kanban... todo en 6 intensas horas de aprendizaje y experiencia.
Puedes encontrar más información e inscripciones en la web de CEIN.

Taller de retrospectivas eficientes
El segundo taller es el día 28 de Noviembre y girará alrededor de las retrospectivas y la mejora continua de los equipos. Veremos técnicas y tácticas para esta reunión tan importante en los equipos ágiles. Se tratará de aprender nuevas maneras de realizar retros, mejorar la efectividad de las mismas, y comprender la importancia de generar aprendizaje de manera constante en los equipos.
Puedes encontrar más información e inscripciones en la web de CEIN.

Personas y retrospectivas en la CAS2011

Dentro de unos días será la Conferencia Agile-spain 2011, y si os acercais por allá podreis disfrutar de una seguro fabulosa conferencia. Yo estaré en un par de sesiones:

La primera será la titulada "Equipos autoorganizados, ¿deberíamos haber estudiado psicología?", que copresento junto a mi compañera Olatz Zamora. Intentaremos contar nuestras experiencias de estos últimos años en la creación y gestión de equipos. Nuestra impresión es que conseguir equipos autoorganizados es difícil, y sin embargo no hay demasiada literatura en el mundo ágil sobre ello.

La segunda sesión será un taller sobre retrospectivas. Básicamente será el taller del AOS2011, pero algo ampliado, y con más tranquilidad para desarrollarlo.

Espero veros por allí... si estas no os interesan, os aseguro que hay muchísimas cosas más interesantes! :)

Mi "elevator pitch" del agilismo

Si solo dispusiese de unos segundos para explicar los beneficios de sumarse al agilismo, diría algo parecido a esto: 

La clave con el agilismo es proporcionar el marco adecuado para que los trabajadores puedan demostrar todo su potencial. La gestión por control permite un trabajo tan bueno como lo es el que ordena y controla (o menos!). El cambio de paradigma hacia lo ágil permite multiplicar la potencialidad de los equipos al multiplicar las de sus integrantes.

 Para dejar que un equipo madure, debes permitirles fallar y que encuentren su propio camino. Las metodologías ágiles fomentan el fallo temprano, para minimizar riesgos. 

 Además, los principios ágiles fomentan la creatividad (personas sobre procesos), la búsqueda de resultados (software que funciona sobre documentación) , la mejora continua y la excelencia (responder al cambio sobre seguimiento del plan) y la orientación al cliente (colaboración sobre negociación).

Visión del desarrollo ágil de software

Me liaron para dar una charla en The Mêlée (yo encantado, claro), y me propusieron hablar desde mi experiencia con metodologías ágiles. Así que lo que intenté finalmente es exponer mis razones para considerar las metodologías ágiles, y cuales son las partes que más valoro actualmente.
Os escribo un pequeño resumen, y podeis encontrar alguna explicación más en la documentación adjunta en slideshare (desarrollo ágil de software). Mis tres razones básicas por las que he llegado al convencimiento de que las metodologías ágiles son las más adecuadas para desarrollar software son las siguientes:

1. El axioma Equipo = Producto
2. El software es un juego coaborativo, de comunicación y finito
3. El desarrollo de software se realiza sobre un sistema complejo

El primer punto fue el que empezó realmente a hacerme plantearme mi manera de pensar en este mundo del software. Yo debía hacer equipos capaces y sobresalientes, más que proyectos y productos. Ese cambio de responsabilidad, me implicaba centrarme más en las personas con las que trabajaba.

En ese momento, el manifiesto ágil encajó perfectamente en mi cabeza. Mi conclusión es que el objetivo principal es entregar valor al cliente, obviamente bajo la perspectiva de paso sostenible. Y los valores que he ido adquiriendo son:

• Colaboración: búsqueda de la visión compartida
• Mejora continua, sin descanso, y adaptándonos al cambio.
• Autoorganización de los equipos, obtener lo mejor cada persona.
• La Calidad es incuestionable.
• Las buenas prácticas son indispensables, pero cuidado que a veces nos hacen perder el objetivo.
• El camino de la mejora de gestión y técnico deben ir unidos.

Desarrollo ágil de software

View more documents from Jose Ramón Díaz

Peligro, las herramientas te cambian de objetivo

Generalmente buscamos en las herramientas que empezamos a utilizar la respuesta a un problema. Tenemos una necesidad que queremos cubrir, y creemos que una determinada herramienta la cubre: necesidad de llevar el control de incidencias, necesidad de orden en el desarrollo, necesidad de comunicarnos,...

Generalmente estas herramientas acaban fagocitándonos y cambiandonos el objetivo que queríamos alcanzar con ellas. Nos olvidamos de nuestra necesidad inicial, y alimentamos al monstruo en que se convierten.

En vez de minimizar las incidencias, nos quedamos satisfechos con que estas estén en la herramienta de control. En vez de procurar aprender a desarrollar software, nos quedamos tranquilos sabiendo que seguimos los pasos de una metodología -herramienta- que nos dicen que es buena. En vez de hablar, nos comunicamos por messenger o por correo electrónico.

¿cuando ha sido la última vez que pensaste que las herramientas te dominaban?

Retrospectivas: Busca necesidades y no problemas

Cuando planteamos problemas en una retrospectiva, generalmente tenemos una idea ya prefijada de las causas que los pueden estar produciendo. Esto nos lleva a plantear muchas veces la lo que creemos que es la solución como el propio problema o impedimento a solucionar que tenemos.

Sin embargo, creo que hay que llevar a las retrospectivas la verdadera necesidad que tenemos, aquello que si lo conseguimos, podremos hacer mejor nuestro trabajo. Esa necesidad es la que debe ser compartida con el equipo, para entre todos, buscar sus causas posibles de que no suceda.

En un sistema complejo como un desarrollo de software (Management 3.0), la causa-efecto no es linear. Las cosas que suceden pueden tener más de una causa, y por tanto no siempre las mismas causas desencadenan los mismos efectos. Esta complejidad añade más valor a analizar los problemas por el equipo, con más visión que sólo la de una persona. Si planteas tu necesidad al equipo que no puedes conseguir, es más facil averiguar las causas de manera colaborativa.

En resumen, podrías plantear situaciones ideales en vez de problemas. Y averiguar cómo llegar a esa situación, eliminando las causas que te lo impiden. ¿no favorecería esto el aprendizaje y la visión compartida, al establecer la meta antes que el camino?

Me gustaría compartir además algunas ideas que he ido obteniendo a lo largo de unas cuantas retrospectivas (algo más de dos años, al menos una cada 15 días,...):

• Piensa siempre lo primero que el problema es sistémico, no de las personas. Soluciona primero el sistema, generalmente éste limita a las personas.
• No evites los conflictos, genera un ambiente donde sea sano que florezcan.
• Plantea las necesidades a resolver, no lo que pensamos que son las causas. Esto también ayuda a la eliminación de la figura del "culpable"
• Aprende técnicas de retrospectivas y conoce cuando se debe aplicar cada una. Ayudan, y mucho.
• El brainstorming es la técnica más conocida y peor implementada. Pon reglas claras desde el principio para hacerlo bien: elimina las críticas que impiden una verdadera libertad de ideas.
• Siempre obtén acciones de las retrospectivas, o no serán retrospectivas, solo "reunión de desahogo". Que no vienen mal de vez en cuando, pero esas, con una cerveza en la mano mucho mejor.

Presentación: "Agilismo como proceso de Innovación"

Os comparto la presentación utilizada en la Feria #KreaBidasoa. Expresé las ideas de mi anterior post: Agilismo como proceso de Innovación, terminando con una pequeña introducción a Scrum.

Agiles como proceso de Innovación

View more presentations from Jose Ramón Díaz

Equipos autogestionados y liderazgo... ¿oxímoron?

27/Nov/2018: Paso por aquí 7 años después ^_^ ya que escribo un post sobre liderazgo mucho más actualizado. No ha llovido nada desde entonces... además, se completa con este sobre Sociocracia 3.0 y cómo permite el liderazgo desde la autoridad distribuida. (Qué es la sociocracia y Toma de decisiones razonada)

En la búsqueda del equipo perfecto, me preguntaba si la autogestión en un equipo y el liderazgo son cuestiones contrapuestas. Jorge me decía que pueden parecer por falta de comprensión de la palabra liderazgo, y JMBeas le ha dedicado un post, hablando más del liderazgo individual.

Mi pequeño tweet iba más bien por otro lado. A un equipo autogestionado le considero así, por que son capaces de organizarse cómo hacer su propio trabajo entre ellos. Pero cuando dentro de un equipo hay un líder, en cierta manera creo que se pierde la verdadera autoorganización. Se rompe un principio de igualdad que considero básico entre los miembros del equipo, para llegar a ser un equipo de alto rendimiento.

Considero que si hay un líder claro en un equipo, este no es un equipo de alto rendimiento. Pero atención, creo que para llegar a ser un equipo de alto rendimiento autogestionado, es casi imprescidible pasar por la figura de un líder. Precisamente hoy A. Medinilla lo ha explicado genial en un hilo de agile-spain.

La democracia está sobrevalorada, lo importante es la unanimidad.

Esta frase, que creo haber leído a Jim McCarthy (pero que ahora no soy capaz de encontrar la referencia), me parece que da alguna clave importante a la hora de evaluar equipos. Si un equipo no es capaz de tomar decisiones por unanimidad prácticamente siempre, quedarán personas sin ver satisfechas sus expectativas. Aquel equipo que resuelve por unanimidad sus problemas, es un equipo unido, y alineado con una visión compartida.

Cuando existe un líder dentro del equipo, apostaría que algunos miembros de los equipos siempre aceptan decisiones suyas, sin hacerlas propias. ¿es entonces un equipo autogestionado, o uno con "jefes", pero internos en el equipo?

En una charla sobre liderazgo en equipos interfuncionales, pregunté al ponente si no podía existir equipos sin esa figura de líderes. Su respuesta es que sí, cuando se juntan un grupo de personas, por propia voluntad, y todos expertos y con mucha experiencia en su campo de actuación, con un objetivo claro. Estoy bastante de acuerdo. Si para ser experto se necesitan al menos 10 años, ¿cuantos equipos tienes preparados para una verdadera autogestión?

Por último, dos notas rápidas. Un coach en un equipo, no es lo mismo que un líder, por que ayuda al equipo, pero nadie le sigue. Y ojo, que puede haber equipos sin líderes, pero que ni sepan autogestionarse ni mucho menos sean de alto rendimiento :)

Agilismo a nivel táctico

Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

• Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.


• Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...


• Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.

Un saludo a mis colegas de Biko, que sé que me leen ;)

Equipos, equipos, equipos,... y luego ágil

El ideal de los equipos autoorganizados, es eso, casi siempre -me temo-, un ideal. En mi personal investigación sobre el tema de los equipos de alto rendimiento (¿alguna vez habeis participado en uno? - la sensación es "diferente"-) estoy trabajando en dos areas principalmente:

1) La organización de las personas como equipo. Es decir, ¿qué diferencia un grupo de personas trabajando juntas, de un equipo? En esta linea, estoy otra vez releyendo el libro "Software for your Head". Libro difícil de leer donde los haya, pero que da la impresión de esconder un tesoro oculto entre sus páginas.

Las mecánicas de un equipo de alto rendimiento ¿se pueden reproducir, inducir, insertar en cualquier grupo de personas con un objetivo común? La charla de Jim McCarthy en Agiles2008, me parece interesantísima.

Por otro lado, me pregunto si el equipo autoorganizado no es una quimera. Por ejemplo, asistí a una charla sobre "Tácticas para liderar equipos interfuncionales", dónde el ponente dijo que no puede haber equipo autoorganizados sin lider, excepto en casos dónde todos los componentes del equipo son expertos en la materia en la que trabajan. Así que esta idea refuerza la labor del ScrumMaster como lider-y coach- dentro de un equipo que utilice Scrum.

2) Elevar el nivel de las personas de cada equipo. A mayor nivel personal y técnico de cada individuo, el equipo ganará exponencialmente comunicación, colaboración, y por tanto, velocidad de desarrollo.

"Oh, you want to be an artist? A great artist?" "Yes" "That's easy! Become a great human being and then paint."

Supongo que aplica lo mismo a un gran desarrollador.

No se puede ser un gran equipo de desarrollo ágil, sin ser antes un gran equipo.

Conferencia Agile-Spain 2010 (CAS2010)

Hoy tengo una gran noticia. Ya se ha dado el pistoletazo de salida para la primera conferencia sobre Ágiles en España. En Agile-Spain la estamos organizando: CAS2010.
En la web podeis encontrar toda la información necesaria. En estos momentos están abiertos los procesos para la selección de sesiones, contribuiciones y talleres. Cualquier planteamiento relacionado con las prácticas y metodologías ágiles es bien recibido para poder plantear una charla, donde podamos compartir experiencias.

Conferencia Agile-Spain 2010

Contaremos además con la más que interesante visita de Henrik Kniberg.

Henrik Kniberg será el orador principal de la conferencia. Henrik es autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.

No te lo pierdas, las inscripciones se abrirán próximamente. Y si te seleccionan como ponente para una sesión, podrás asistir gratuitamente a la conferencia ;)

Libro de TDD en castellano

El primer libro sobre Desarrollo Guiado por las Pruebas (TDD) en castellano acaba de ver la luz. Carlos Ble junto a algunos colaboradores ha editado un libro más que recomendable para cualquiera que esté interesado en esta metodología de desarrollo, o en las metodologías ágiles en general.
Es un libro que además aporta conocimientos generales de diseño basado en objetos, o metodologías ágiles. Hace un repaso con ejemplos de cómo desarrollar con TDD, e introduce el desarrollo guiado por las pruebas de aceptación (ATDD).
Sin duda un libro que debes descargar, es de libre distribución, y estudiar con profundidad. Seguro que aún mejor si se lo compras o le haces una pequeña donación :), que merece la pena. Yo he tenido el placer de poder seguir el proceso de creación del libro como pequeño revisor, y el material creado por Carlos es muy bueno, espero impaciente su próximo libro ;)

• Diseño Ágil con TDD

Aprovecho para recordaros la existencia del grupo de TDD en castellano!

Charla sobre desarrollo de software ágil (2)

Aquí os dejo la charla que di el otro día en la Navarparty, junto con una breve descripción de lo que conté, sin entrar en detalles. Teneis el video disponible en la web de la Navarparty.

Desarrollo Agil

View more presentations from jrramon.

[2] Generalmente se presentan los típicos problemas en el desarrollo de software, en los que caemos una y otra vez, como razones para cambiar a lo ágil: clientes insatisfechos, equipos quemados, calidad insuficiente, fechas nunca alcanzadas,...
[3] pero aquí prefiero dar dos razones por las que creo que las metodologías ágiles se adaptan mejor.
[4] Por que creo que primero, el producto es equivalente al equipo que lo ha creado, y que el producto de un gestor de proyectos es crear un equipo, y que
[5] el software es un juego colaborativo. [6] Estos dos libros inciden en estas ideas.
[7] Así que ahora debemos elegir el nuevo camino, tomar la pastilla azul que ofrecieron a Neo (jope, ¿o era la roja?).
[8] Las metodologías ágiles más comunes fueron creadas en los 90,
[9] pero el manifiesto ágil les dio el espaldarazo definitivo.
[10-15] El manifiesto ágil condensan en cuatro frases los conocimientos y experiencias en gestión de proyectos de software de algunos de los mayores expertos en este mundo.
[16-22] Y los principios que se desprenden de ellos son las bases de estas metodologías.
[23] ¿cómo podemos llevar al terreno práctico estas ideas?
[24] Aplicando por ejemplo este esquema metodológico (como ejemplo, no olvidemos que hay muchas metodologías ágiles), que actua a nivel técnico, sobre el ecosistema software (prácticas de XP) , a nivel de gestión de proyecto (Scrum), y a nivel organizativo (aplicando los principios de Lean).
[25-35] XP nos da herramientas para garantizar una buena calidad e integridad de los desarrollos (TDD, Integración continua, Pair programming) , pero no debemos olvidar que puede ser tomada como una metodología de gestión completa. Lean nos da unos principios que buscan mejorar la organización en todos sus niveles. Y Scrum, la metodología "de moda", nos da el framework para gestionar los proyectos centrándonos en la entrega de valor al cliente y la mejora continua.
[37] Dos palabras básicas para ser ágiles: confianza y colaboración.
[38] ¡No olvides visitar agile-spain!

http://najaraba.blogspot.com/2008/02/el-producto-es-el-equipo.html
http://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566
http://alistair.cockburn.us/Software+development+as+a+cooperative+game
http://agilemanifesto.org/
http://www.extremeprogramming.org/
http://www.proyectosagiles.org/que-es-scrum
http://poppendieck.com/
http://www.agile-spain.com

Charla sobre ágiles en la Navarparty

Este viernes, 25 de Septiembre de 2009, 17:30, estaré en la Navarparty, en Pamplona, dando una charla introductoria a las metodologías ágiles.

Las conferencias son de libre acceso para todo el público y se realizarán como el año pasado en la sala 04 (Fernando Remacha) del Edificio del Sario, anexo al Pabellon deportivo de la UPNA donde se celebra la Navarparty 7 (ver mapa )

Programa de charlas

La charla va a ser de introducción, contaré los principios ágiles, un poco de historia y algo de Scrum, lo típico para explicar en qué consisten, y por qué creo en estas metodologías. :)
Agradezco a la organización su confianza con su invitación, y espero veros por allí!

¿somos ingenieros los del software?

Seguro que ya te has enterado del revuelo que se ha armado con el artículo en IEEE de Tom diMarco, sobre su cambio de parecer con el control y métricas en los proyectos de software.

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no. [*]

Yo no creo que sea un cambio en el parecer de Tom, no tienes más que leer PeopleWare escrito 20 años más tarde que el tema de control y métricas en los proyectos de software, para darte cuenta de su evolución.
El post que más me ha gustado sobre este tema ha sido el de Juan Palacios, y coincido en gran medida con lo que explica en él. El verdadero bombazo ha sido otro post de coding horror, preguntando si la ingeniería del software está muerta, y entronca con el nuevo movimiento que defiende al mundo del desarrollo de software como "artesanía". No sé, quizás debería ser una ciencia experimental -Conocimiento ordenado y, generalmente experimentado, de las cosas- de manera que vayamos aprendiendo posibilidades de hacer bien las cosas...
Cuando salía de la carrera, siempre recalcaba que no era informático, si no -ingeniero- informático. Ahora, aunque esté mal visto, siempre digo que me gusta programar, pero que hay que saber las bases matemáticas y conceptuales necesarias para hacerlo bien. La respuesta a esto muchas veces suele ser: "¿pero los ingenieros seguís programando tras 10 años de experiencia? (sic)

• La ingeniería entendida como un conjunto de procesos plausibles y realizables para solventar un problema, no existe -todavía!- en la informática. Algunos pensaron que CMMI-5 lograba eso, pero se equivocaron.
• La ingeniería civil trasladada al control de proyectos de software no es lo adecuado para todos los proyectos. El "rebote" de las metodologías ágiles así lo confirman.
• Las métricas están sobrevaloradas en los proyectos de software, y sus equipos. Forman parte de una burocracia que genera poco valor cuando se abusa.
  
• No se trata -o no debería tratarse- de una guerra entre bandos. Somos niños con un juguete nuevo, y cada uno cree que se usa de una manera diferente. Debemos aprender.
• Hay una parte de "juego cooperativo", de "problemas sociológicos" que se ha olvidado en la gestión de proyectos tradicional.
• Las metodologías ágiles resuelven algunos problemas, pero no tardarán en salirles puntos débiles, debemos auncar esfuerzos para seguir mejorando.

Finalmente, cada proyecto es diferente. No solo por que el resultado deba ser diferente, si no por que se va a realizar con equipos diferentes. Quizás todos los proyectos del mismo tipo podrías gestionarlos igual, pero nunca gestiones igual equipos diferentes. Debes estudiar personas, perfiles, intereses,... y eso es dificilmente medible. Ignoro si CMMi, por ejemplo, tiene un area de trabajo sobre este tema, la creación de verdaderos equipos de trabajo. Un libro sorprendente en este area, que me recomendó Mario, es Software for your head. Se supone que habla de desarrollo de software, y "solo" ¡de gestión de equipos!

PD: Seguiré con mis posts sobre Lean que prometí, pero ha sido una temporada dura!

Equipos vs. personas

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

No hablamos de programar, es del cliente!

Estaba echando un vistazo a la metodología ágil EVO (Evolutionary Project Management), una metodología no muy conocida por estos lares, creada por Tom Gilb. Básicamente contiene todos los principios recogidos en el manifiesto, pero llama la atención que esta metodología data de 1980. Es curioso como nos olvidamos, o se sumergen en el olvido, cuestiones que en su momento habrían sido de los más innovador. Es curioso como Scrum se ha tragado el resto de metodologías.
Por lo que veo, esta metodología va algo más alla de Scrum y XP y trata el negocio como un sistema completo. Es más probable que se asemeje un enfoque Lean, tratando de dar valor desde la concepción de un proyecto, gestionando temas que se salen de la parte de desarrollo puro para entrar en la gestión del negocio.
EVO se basa en 10 principios, con la idea general de los principios de las metodologías ágiles. El que me ha llamado la atención, me ha gustado, es:

Evo is holistic systems engineering - all necessary aspects of the system must be complete and correct - and delivered to a real stakeholder environment - it is not only about programming - it is about customer satisfaction.

No se trata de programar! si no de proporcionar valor al cliente. Muchas veces este es un punto dificil de transmitir a los desarrolladores; cuando nos gusta programar generalmente perdemos el enfoque en el cliente, y hacemos cosas complejas cuando no son necesarias por que son bonitas, o cuestiones que dejamos "a medias" por que son aburridas.
Tener en mente siempre al cliente, siempre - en cada linea de código- es muy duro. Pero sería realmente provechoso, realmente reduciríamos los desperdicios de nuestro proyecto. Muchas veces los desarrolladores se limitan a hacer lo que dicen las especificaciones, o lo que les pasa el analista, y sin embargo deberían tener también la visión del cliente. Exactamente igual que todo el resto del equipo.

La web de Gilb, que no conocía, me parece que tiene documentos bastante dignos de investigar, por si os interesa... ;)

Agile-spain

El sábado me fui a Madrid a la "refundación" del grupo agile-spain. Este grupo intenta promover las metodologías ágiles de desarrollo en España, un elemento de la ingeniería del software poco practicado por estos lares. La reunión fue realmente amena, y podeis vernos en acción en unas cuantas foticos que Xavier Quesada ha colgado.

De Reunión refundacional

Ciertamente compartíamos la idea de que estas metodologías son un paso adelante en la mejora del mundo del desarrollo de software, y estuvimos mirando pasos a dar para reforzar la comunidad y dar a conocer esta faceta en la que otros paises nos llevan un par de años de ventaja. Así que nos podeis ver en la fotos jugando con los post-it, sacando y priorizando ideas. Pronto contaremos con más detalle qué se nos ocurrio, así que no olvides suscribirte a agile-spain, y sobre todo ¡a la comunidad!
Para ponerte en contacto con la comunidad agile-spain lo mejor es que te des de alta en el grupo de Google en el que comentamos cualquier tema relacionado.

Actualizacion: Una verdadera exposición de los hechos, por Jose M. Beas