Principios ágiles #6

Hace muuuucho tiempo comencé una serie de post sobre los principios ágiles que hay detrás del manifiesto ágil. No se por qué, dejé de escribir en el blog y la serie se interrumpió. Hoy, a lo Fronkonstoin, voy a devolver la serie a la vida hablando del sexto de ellos (esperemos que dure):

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara.

Comunicar información
¿Por qué hay gente que oculta información, que no comparte? Quizás para hacerse indispensables (como bien dice David Bonilla en su entrada sobre cajas negras). Que no os engañen, no lo son y no lo serán. Lo único que van a conseguir es aislarse de sus colegas de profesión y perderse todas las cosas buenas que hay fuera de su cubículo. Van a quedarse obsoletos.

Como decía Newton (aunque la wikipedia dice que fue Chartres):

Si he visto más lejos es porque estoy sentado sobre los hombros de gigantes

Si es bueno para Newton (vale, Chartres. Creo que se nota que soy físico) es bueno para ti.

Hay que salir, enriquecerse. Hay que aprender a ser humilde, a compartir tus conocimientos. Hay que enseñar lo que sabes y aprender lo que no sabes. Para todo esto es necesario comunicarse. No te conviertas en una caja negra.

A un equipo de desarrollo
Como he dicho ya muchas veces en anteriores posts, es importante que el cliente esté en contacto continuo con el equipo. Que sea capaz de comunicar sus objetivos y preferencias es una parte imprescindible de dicho contacto. Esto implica un nivel de compromiso por parte del cliente en el proyecto muy alto, siendo éste uno de los problemas más comunes en los equipos ágiles (al menos en los que yo conozco). Veamos un dialogo tipo:

- Hola, ¿vosotros sois ágiles?
- ¡Sí!
- ¿Cómo habéis conseguido involucrar al cliente en el ciclo de desarrollo?
- Respuesta 1: A no, eso no lo hemos conseguido.
- Respuesta 2: Nuestro cliente es interno.

Mi experiencia personal es del segundo tipo, así que tengo suerte :P Sinceramente, no se cómo resolver el primer caso :( Lo que sí que tengo claro es que, si no consigues que tu cliente se comprometa en el proyecto vas a pasarlas canutas...

Entre un equipo de desarrollo
Está claro que un equipo de desarrollo, si es sano ,debe estar en continua comunicación. Cuando se trabaja en intervalos de tiempo cortos es necesario que todo el equipo esté sincronizado de forma que se evite el trabajo duplicado. Igualmente, es muy importante que los miembros del equipo se encuentren comodos entre si, de forma que no resulte extraño que alguien pregunte cuando no sabe algo (No hay preguntas tontas ni respuestas estupidas, ya sabéis). Básicamente, es necesario que los miembros del equipo creen relaciones de confianza que ayuden el desarrollo de su trabajo (Todos trabajamos mejor con amigos alrededor ¿no? Huy, me ha salido muy piruleta esto último...).

Conversación cara a cara
Lo más eficiente no es ni usar el teléfono, ni el e-mail, ni el wave, ni el twitter, ni el skype... lo más eficiente (y por tanto lo deseable) es la comunicación cara a cara.

Pensad en la cantidad de herramientas que propone el agilismo a los equipos para que mejoren su comunicación. Desde el ¡Sienta al equipo junto! de Henrik kniberg a las reuniones diarias de Scrum sin olvidarme de algunas de las prácticas XP como la programación en parejas. Todas ellas se basan en la comunicación cara a cara, lo que debe dar una idea de su importancia.

Conclusiones
El sexto principio ágil:

• Implica un alto nivel de compromiso en el proyecto por parte del cliente
• Necesita que se den relaciones de confianza entre los miembros del equipo (incluido el cliente)
• Señala la importancia de la relación directa entre las personas

Foto de "portada": Galería de Fernando en Picasa, bajo licencia Creative Commons.

Principios Ágiles #5

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del quinto de ellos:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Construye proyectos con profesionales motivados. Dales el entorno y soporte que necesitan, y confia en ellos para que realicen el trabajo.

Profesionales motivados
Cuando una persona encuentra un nuevo trabajo su motivación inicial es bastante alta. Si tiene experiencia previa probablemente haya conseguido un trabajo que le guste con un sueldo acorde a dicha experiencia. Estará contento y querrá demostrar que vale lo que le van a pagar. Si es un junior sin experiencia querrá aprender y prosperar en su carrera profesional. ¿Qué lleva a cualquiera de estas dos personas a desmotivarse? Pues multitud de causas. Falta de dirección (visión de empresa, visión de producto, abandono por parte de la gerencia...), mala cultura empresarial (mala relación entre compañeros, infraestructura deficiente, falta apoyo al aprendizaje), etc. Imagino que todos hemos pasado por algo así en algún momento, por desgracia.
Una vez que una persona pierde la motivación es muy complicado volver a motivarla, por lo que hay que esforzarse en evitar que ocurra.
¿Cómo se puede evitar la desmotivación?
Dan Pink lo explica muy bien en esta presentación (Si aún no la habéis visto ya estáis tardando :P)
Os escribo las conclusiones para los más vagos (aunque ya os digo que mola mogollón). Básicamente cuenta que, una vez resuelto el tema salarial (está claro que es un factor importante, pero no el único) los factores que ayudan a mantener la motivación son los siguientes:

• Autonomía. Muy en sintonía con la auto-organización de los equipos ágiles ;) Hay que confiar en que el trabajador es capaz de hacer su trabajo por si mismo.
• Maestría. Para los agilistas significa buscar la excelencia técnica (Sea lo que sea eso, que ya lo veremos en futuras entradas)
• Propósito. Contribuir a algo importante. En el caso de la agilidad sería equivalente a contribuir en la mejora del negocio del cliente. Aportar valor y tal :)

Estos tres factores ayudan a mantener la motivación de un profesional (no solo los profesionales técnicos, cualquier tipo de profesional) ya que crea un entorno en el que las personas son importantes y valiosas (Ya sabéis, personas sobre procesos...).

Crear un entorno y dar el soporte necesario
Tal y como hemos visto arriba, la cultura empresarial es muy importante a la hora de mantener la motivación.
Es necesario que la empresa proporcione un ambiente que favorezca el aprendizaje, que ayude a crecer profesionalmente a sus trabajadores, que confíe en ellos para realizar su trabajo, que les proporcione una infraestructura adecuada a sus necesidades, etc. Es decir, que se dedique a eliminar impedimentos externos del día a día para que los únicos problemas que se encuentren sus trabajadores sean los propios de su trabajo (Eliminar burocracia inútil, métricas absurdas, controles exhaustivos, etc).

Confianza
Todo lo anterior se basa en la confianza. Está claro que un buen profesional sabe hacer su trabajo. No necesita un jefe todo el día detrás suya, interrumpiéndole cada 10 minutos para preguntarle qué tal lo lleva. Ese micro-control, además de desmotivar, reduce la productividad.
Sin embargo, hay que tener claro que no todo depende de área de gestión, el empleado debe responder. Como dijo el Tío Ben :

Un gran poder conlleva una gran responsabilidad

Si queremos que nuestro trabajo mejore, que se nos trate como a verdaderos profesionales y que se confíe en nosotros, debemos responder con autentica profesionalidad. Si nuestra empresa fomenta el aprendizaje debemos aprovecharlo y mejorar. Si nuestra empresa nos permite autonomía debemos comprometernos. No podemos desaprovechar las (¿pocas?) oportunidades que se nos ofrecen.

Conclusiones
El quinto principio ágil:

• Busca fomentar la confianza
• Advierte que lo importante son las personas
• Pide que se eliminen los impedimentos externos
• Implica responsabilidad y profesionalidad

NOTA: Si os interesa más el tema de la motivación de un equipo os recomiendo el libro Peopleware. Yo aún no lo he podido leer, pero José Manuel Beas lo recomendó en la reunión que tuvimos sobre principios ágiles al hablar sobre este principio. El libro se lo dejó a Alfredo Casado, que nos ha ido contando algunas de las cosillas que ha ido leyendo. La verdad es que tiene muy buena pinta :)

Foto de "portada": Galería de Fernando en Picasa, bajo licencia Creative Commons.

Principios Ágiles #4

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del cuarto de ellos:

Business people and developers must work together daily throughout the project.

La gente de negocio y los desarrolladores deben trabajar de forma conjunta diariamente a lo largo del proyecto.

¿Gente de Negocio y gente de desarrollo?

Cuando se comienza un nuevo proyecto es lógico que el equipo de desarrollo (encargado de implementar una solución) no sea experto en el negocio del cliente. Por otro lado, un experto de negocio (encargado de explicar las reglas de negocio) casi nunca se interesará por el aspecto técnico (desde luego, ninguno que yo conozca). Ambos mundos están bastante separados, al menos sobre el papel, lo que provoca que sean incapaces de entenderse. No poseen un lenguaje común.

¿Por qué trabajar juntos de forma conjunta?
Obligar a que ambos mundos trabajen juntos de forma continua provoca que la separación entre ambos se reduzca. Obviamente, el objetivo no es que un desarrollador se convierta en un experto de negocio ni viceversa. Siempre existirá una cierta separación. El objetivo es construir un lenguaje común mediante el cual ambos grupos consigan entenderse y resolver sus dudas. Actualmente en el mundo ágil, dicho lenguaje común se plasma sobre todo en las pruebas de aceptación, definidas por la gente de negocio con ayuda del equipo técnico (Si queréis saber más sobre pruebas de aceptación pasaos por la próxima reunión de Agile-Spain Madrid).
Cuando ambos grupos empiezan a colaborar se empieza a reducir la brecha que los separa. Comienza a aparecer un sentimiento de equipo y una visión global del producto.

¿Por qué diariamente?
No vale con reuniones esporádicas, debe ser un esfuerzo continuo. No vale que los grupos se reunan una vez al mes para tratar ciertos temas y que después cada uno se marche a su cubículo. Si un desarrollador se encuentra con que tiene que tomar una decisión de negocio debe acudir a los expertos de negocio para que se la resuelvan. Si un experto de negocio quiere conocer que tal va el desarrollo de una funcionalidad X debe acudir al desarrollador para que le informe. Obviamente, esta colaboración no se puede llevar a cabo sin confianza y transparencia. No me sirve de nada que los desarrolladores estén siempre disponibles para el experto de negocio pero le mientan sobre el estado del proyecto.
Este trabajo diario no es sencillo de llevar a cabo. Muchas veces los desarrolladores no queremos levantar la cabeza del ordenador. Otras muchas los expertos de negocio no tienen tiempo (ni ganas) de reunirse con los "frikis". Por eso, es necesario un compromiso por ambas partes. Si alguno de los dos no se compromete se deja de ser ágil.

Conclusiones
El cuarto principo ágil:

• Busca que la gente de  negocio y la gente técnica hablen un lenguaje común que favorezca el entendimiento.
• Refuerza el sentimiento de equipo aumentando la confianza entre sus componentes.
• Implica compromiso.
• Obliga a la transparencia.

Imagen de "portada": Galería de thinkpublic, bajo licencia Creative Commons.

Principios Ágiles #3

Después del 10º encuentro del grupo de Madrid de Agile-Spain en el que charlamos sobre los principios ágiles voy a continuar con mi serie sobre dichos principios. Hoy toca el tercero de ellos:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Entregamos software frecuentemente, desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles.

Este principio va de la mano del primero. El primer principio introduce la idea de entregas continuas de software y este tercer principio especifica un poco más como realizar dichas entregas. De forma frecuente, en iteraciones cortas, entre la semana y el mes.

¿Por qué frecuentemente?
Ya lo he hablado con anterioridad pero, en el desarrollo ágil, el feedback que aporta el cliente es muy importante tanto para llevar el proyecto a buen puerto como para mejorar el producto final. Queremos entregar software que funciona frecuentemente porque aumenta el feedback que nos aporta el cliente.

¿Por qué mejor si los periodos son lo más cortos posibles?
Porque, cuanto más pequeño sea el ciclo de desarrollo, antes le entregaremos al cliente algo que no quiere, con lo que antes nos avisará de qué es lo que realmente quiere. Ya sabéis, la movida del feedback otra vez.
Ahora bien, es fácil decirlo pero entregar software que funciona cada poco tiempo es muy difícil.

Como dice Robert C. Martin (Uncle Bob):

Takes a real man to do a one week iteration!

¡Hay que ser muy hombre para hacer iteraciones de una semana!

No es sencillo entregar software funcionando y con nuevas funcionalidades cada poco tiempo. Cuanto más corto sea el ciclo de entrega mejores deben ser nuestras prácticas de desarrollo software (¡Aupa XP!). Si, por ejemplo, tu equipo hace Scrum pero deja de lado XP es muy probable que acabe por no soportar las iteraciones cortas o, peor aún, termine entregando software que no funciona.

Conclusiones
El tercer principio ágil:

• Obliga a que se entregue software que funciona cada poco (y por poco me refiero a un mes o menos).
• Necesita acompañarse de una serie de prácticas de desarrollo (XP) para soportar las frecuentes entregas en ciclos cortos.
• Apunta que ser ágil no es sencillo. Se debe entregar software funcionando cada poco y hay que pelear por conseguirlo. Es un objetivo ambicioso, pero es necesario.

10º Encuentro Agile-Madrid. Principios Ágiles

El pasado día 1 de diciembre tuvo lugar el 10º encuentro del grupo madrileño de Agile-Spain en las instalaciones de IPSA (me tocó hacer de anfitrión/portero :D ).

El tema de la reunión era "Los Principios Ágiles detrás del Manifiesto Ágil". Parece ser que el tema interesaba porque acudimos 12 personas, entre las cuales había varias caras nuevas (Mola que siga entrando gente nueva). Personalmente me interesaba bastante conocer que pensaba el grupo sobre los principios ágiles y si sus opiniones coincidían con las mías (las cuales podéis leer en mi serie de post sobre Principios Ágiles).

Como ya os dije en el post sobre el 9º encuentro, hemos cambiado el formato de las charlas y ahora comenzamos con una pequeña presentación introductoria. Esta vez, el encargado de hacer dicha presentación era José Manuel Beas y su presentación podéis verla aquí (Esta vez no hay vídeo de la charla porque el ordenador encargado de realizar la grabación se quedó sin espacio en disco :D La próxima vez ya no nos pasa).

Tras la introducción comenzó un debate del que salieron algunas preguntas y respuestas interesantes:

• ¿Son los principios ágiles de obligado cumplimiento para ser ágil? Obviamente sí, pero siempre teniendo en cuenta que son principios, es decir, guías. Para ser ágil es necesario practicarlos, pero más importante es entenderlos.
• ¿Cómo introducir los principios en la empresa? Dado que los principios representan un cambio de mentalidad, es importante practicar con el ejemplo. Además, un enfoque "de abajo a arriba" (bottom-up) parece más sencillo que "de arriba a abajo" (top-down).
• Los principios hacen hincapié en la autogestión (Principio #11). Esto puede provocar rechazo en la empresa porque saca a relucir puestos innecesarios y obliga a la gente a redefinir su trabajo.
• ¿Es necesaria una jerarquía en la empresa? Aquí hubo bastante discordia. Aparecieron dos bandos, "Sí hay autogestión mi jerarquía puede ser plana" y "Es necesaria una jerarquía que saque a la gente de la zona cómoda (comfort zone)". Yo, personalmente, soy partidario de la primera opinión. Los principios ágiles también piden autoexigencia y responsabilidad (Principio #9) por lo que de la "comfort zone" sales tú solito. Además, creemos en las jerarquías porque las empresas que conocemos funcionan (o no) así, pero ¿Que harías si montaras tu propia empresa? Quizás un modelo ágil más plano te funcione mejor. Aún así, en este punto no hubo acuerdo.

Una vez finalizado el debate sacamos unas pequeñas conclusiones:

• Los principios ágiles marcan el camino, pero dicho camino es duro y difícil de recorrer.
• Hay que creer (sin llegar al fanatismo). Es muy importante ser apasionado para conseguir convencer a otros.
• La confianza hay que ganársela. Además, es muy fácil perderla por lo que hay que esforzarse en mantenerla.
• Hay que invertir la polaridad en las relaciones de confianza, es decir, hay que empezar a confiar en la gente. Si no confías en la gente no esperes que la gente confíe en ti.
• Hay que ser exigentes con el cliente. No se puede renunciar a los principios ágiles porque el cliente no los comparta.
• Cuando hablamos de agilismo, a veces se nos olvida que negocio y tecnología deben ir de la mano, ser uno (Principio #4).
• La confianza es fundamental en el mundo ágil. Para conseguirla es necesaria la transparencia.
• Para ser ágil debes ser autoexigente y tener coraje y confianza(en ti mismo y en los demás).

Esto fue todo. Bueno, miento un poco. También hicimos una retrospectiva en la que nos comprometimos a:

• Tener una agenda para las próximas reuniones.
• Elegir los temas de forma que haya dos reuniones "teóricas" y un taller.
• Grabar en vídeo las reuniones.
• Crear un taller de ATDD. La propuesta la hizo Agustín Yagüe y, aunque quedamos en hacerlo fuera de las reuniones, nos pareció una muy buena idea.

Si os interesa, la próxima reunión será el día 19 de Enero de 2010 y el tema a tratar será "Definition of Done (Pruebas de Aceptación Automatizadas)". La charla la llevaremos a cabo Jose Manuel Beas (se encargará de hablar de pruebas en Concordion) y yo (hablaré de pruebas en Fitnesse), así que, os esperamos en la siguiente reunión del grupo.

Principios Ágiles #2

Siguiendo con la temática de los principios ágiles, hoy voy a hablar de el segundo de ellos:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Aceptamos requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

¿Por qué se aceptan los requisitos cambiantes?
Porque es la forma más sencilla de adaptarse a la realidad. Aunque exista un contrato firmado por el cliente en el que se fija el "alcance" del proyecto, lo cierto es que los requisitos cambian. Normalmente un cliente no sabe exactamente lo que quiere. Su conocimiento va aumentando según avanza el proyecto y es así como consigue definir realmente su objetivo. Dado que es imposible que el proyecto no cambie hay que hacer algo para que ese cambio no sea doloroso. Ahí es donde entra este principio. Aceptar los requisitos cambiantes significa que, si el cliente cambia de opinión, hay que hacerle caso y se debe modificar el desarrollo (Recordad que "nuestra máxima prioridad es satisfacer al cliente"). No hay que utilizar el contrato como escudo contra el cliente. Hay que utilizar al cliente como compañero para conseguir que el contrato llegue a buen puerto. Es decir, se debe establecer una relación de confianza entre el cliente y el proveedor para aprovechar las ideas de ambos.

¿Por qué no importa que los cambios lleguen en etapas avanzadas de desarrollo?
Porque, al tener "entregas continuas y tempranas de software valioso", es sencillo introducir los cambios que pida el cliente en cualquier etapa. La obligación de entregar software funcionando en cualquier momento del desarrollo hace que la complejidad al introducir cambios sea constante a lo largo del tiempo. Para que este modelo sea mantenible es necesario que el equipo de desarrollo se preocupe de que la base de código sea de calidad (Prácticas XP). Si no se mejora la base de código de forma continua, aceptar los cambios será cada vez más complicado, faltando así a este principio.

¿Cómo aprovechar el cambio para proporcionar ventaja competitiva?
Al aceptar el cambio lo que en realidad se está haciendo es aumentar la velocidad de reacción del cliente, que puede reaccionar antes a los proyectos de la competencia. Es capaz de adaptar su producto para eliminar las ventajas del rival y crear las suyas propias (o, al menos, intentarlo).


Conclusiones

El segundo principio ágil:

• se basa en abrazar el cambio. No hay que protegerse contra el cambio.
• introduce la colaboración con el cliente. Un cliente implicado que quiere la mejor herramienta posible.
• asume ciertas prácticas en el área de desarrollo (XP).
• aumenta la velocidad de reacción del cliente ante el mercado.

Principios Ágiles #1

Cuando uno entra en esto del agilismo lo primero que le cuentan es el Manifiesto Ágil. Conocer el manifiesto ágil es importante, pero no basta con quedarse ahí. Los autores originales del manifiesto se tomaron muchas molestias para redactar los 12 principios detrás del manifiesto y es necesario que nos los tomemos tan en serio como al propio manifiesto.
He decidido dedicar un post a cada principio. Empecemos por el primero:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Nuestra prioridad más alta es satisfacer al cliente mediante entregas continuas y tempranas de software valioso.

¿Por qué la prioridad más alta?
Es importante destacar que los firmantes del manifiesto ágil tienen un objetivo por encima del resto. Además, dicho objetivo no es negociable. Siempre debe estar presente y siempre debe cumplirse. Si no se cumple es un fracaso.Dicho objetivo es satisfacer al cliente.

¿Qué significa satisfacer al cliente?
A la hora de realizar un desarrollo es importante tener un cliente que lo demande (Cuando hablo de cliente me refiero a quien demanda dicho desarrollo. Por ejemplo, un cliente puede ser el propio desarrollador que necesita una nueva librería para un proyecto más grande. No tiene porque ser siempre un cliente que firma un contrato). Si no existe el cliente no existe el desarrollo. El cliente es el leitmotiv del desarrollo. Esto, que parece tan simple, se pierde muchas veces de vista a lo largo del desarrollo, provocando que se tomen decisiones sin contar con el cliente con lo que el desarrollo se va alejando de las necesidades de dicho cliente.

¿Por qué con entregas continuas y tempranas?
Por varios motivos. Deben realizarse entregas tempranas porque es una forma de involucrar al cliente en el desarrollo (Puede validar la usabilidad del desarrollo, puede opinar sobre el entregable, etc...). A su vez, deben realizarse entregas continuas porque de esa forma se es capaz de adaptarse a lo que el cliente quiere en cada momento. Los requisitos del cliente no son inmutables, por eso, cuanto antes se le enseñe software funcionando antes se podrá modificar de acuerdo a las nuevas necesidades del cliente.
Mediante este tipo de entregas se consigue un feedback del cliente que permite que el rumbo del desarrollo siempre apunte hacía donde el cliente desea.

¿Qué es software valioso?
Es software que funciona y que hace lo que el cliente necesita. Es fácil decirlo, pero no es nada sencillo conseguirlo.
Software que hace lo que el cliente necesita se puede conseguir mediante entregas continuas y tempranas, tal y como se ha explicado antes.
Conseguir software que funcione es mucho más complicado pero es condición necesaria para conseguir la satisfacción del cliente. Esto, que puede parecer algo obvio, se suele olvidar en la mayoría de los desarrollos. La "industria del software" (clientes y proveedores) está acostumbrada a rebajar las exigencias y a permitir errores en la mayoría de los proyectos que se realizan (ya sea por los tiempos de entrega, por la pobre formación de los desarrolladores, etc). A un desarrollo hay que exigirle que funcione y en eso es en lo que se centra el agilismo, en el software que funciona. Cualquier otra cosa dejará al cliente insatisfecho. Probablemente algún bug aparezca (ya sabéis, cualquier código contiene al menos un bug) pero se debe reducir la tasa de errores al mínimo (sobre todo en las funcionalidades principales). Es cierto que no todos los desarrollos tendrán la misma calidad (Siempre habrá desarrolladores mejores y desarrolladores peores, pero eso solo puede tener influencia en el tiempo que se tarde en realizar el proyecto, en lo fácil o difícil que sea mantener dicho proyecto, etc), pero es necesario exigirnos que funcionen (Un Seat y un Ferrari funcionan, la diferencia está en el proceso de montaje, en la calidad de los materiales, etc).

Conclusiones

El primer principio ágil:

• se basa en el la satisfacción del cliente.
• muestra como obtener un feedback periódico del cliente.
• indica la necesidad de entregar lo que el cliente necesita.
• avisa de la importancia que tiene el entregar software que funciona.