Metodología XP - Los 15 principios

Hace tiempo que quería escribir algo sobre XP (eXtreme Programming). Y es que todo el mundo está emocionado con las metodologías ágiles, principalmente Scrum. Pero para entender los problemas de Scrum y sus ventajas en función del tipo de proyecto (ya he comentado esto otras veces), hay que entender la historia de las metodologías ágiles.

Y qué mejor forma de empezar, que recordando los principios básicos de XP (hablo de eXtreme Programming, la metodología ágil antecesora de las actuales).

La metodología XP comenzó oficialmente con el libro de Kent Beck de 1999, aunque ya llevaba al menos uno o dos años oyéndose por la red. Ya existía un brote ágil que terminaría de catalizar a partir del año 2000.

El propio Martin Fowler, en su blog nos habla en un artículo de los 15 principios de XP. Vamos a revisarlos.

Tenemos los 5 principios fundamentales:

• Rapid Feedback
• Assume Simplicity
• Incremental Change
• Embracing Change
• Quality Work

Aunque existen otros 10 principios adicionales, hasta conformar los 15 principios ágiles:

• Teach Learning
• Small Initial Investment
• Play to Win
• Concrete Experiments
• Open, honest Communication
• Work with people's instincts - not against them
• Accepted Responsibility
• Local Adaptation
• Travel Light
• Honest Measurement

Si os fijáis, estos principios serían anteriores incluso al manifiesto ágil, surgido a raíz de la reunión que convocó Kent Beck y que dio origen a dicho manifiesto. Kent Beck fue el autor, 2 años antes del manifiesto ágil del libro "Extreme Programming Explained".

El resto, como se suele decir, es historia.

Estimación basada en tallas de ropa

Hoy voy a hablar de una forma de estimar el tamaño del software, que en realidad no es más que una variante de un viejo conocido: el uso de las cartas en el planning poker. Estas cartas, suelen estar numeradas utilizando la conocida serie de Fibonacci:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100...

Sin embargo, hay más. Y aunque quizás no se usen tanto, la estimación basada en tallas de ropa (o "t-shirt estimation"), también existe. En concreto, es popular por ejemplo entre grupos de trabajo de Microsoft, entre otros.

Ventajas

Por supuesto, esta forma de estimación presenta varias ventajas:

• Más fácil de imaginar incrementos de forma cualitativa.
• Más fácil de comunicar las estimaciones al product owner. Los usuarios finales pueden más fácilmente asimilar que las estimaciones y por tanto los desarrollos, son de magnitud diferente.
• Facilita la estimación ágil en grupos menos experimentados.

Inconvenientes

Y ahora, pasemos a ver los inconvenientes:

• Más difícil de mapear los incrementos de forma cuantitativa. El paso entre tallas pequeñas parece ser similar al paso entre tallas grandes. Sin embargo, la estimación ágil basada en la serie de Fibonacci se parece más a la realidad, ya que las diferencias entre estimaciones pequeñas son mucho menores que el salto entre las estimaciones más grandes. Es decir, la estimación en tallas de ropa sugiere erróneamente que los escalones son iguales, cuando no es así.
• Conforme los grupos de trabajo son más experimentados, es mejor pasar a otros tipos de estimación ágil.
• Es complejo intercambiar estimaciones con otros grupos ágiles, ya que su uso no está tan extendido.

Mi consejo es usar las tallas de ropa como una referencia de trabajo, y mapear, como indican varios autores, cada talla con un número de la tradicional serie de cartas de póker (o Fibonacci). De esta forma, se pueden aprovechar las ventajas y evitar los inconvenientes antes mencionados. Con el tiempo, de todas formas, lo ideal es que los equipos de trabajo acaben estimando directamente con los números y acaben abandonando las tallas de ropa.

Fuentes:
http://qeworks.com/t-shirt-estimation-in-agile/
http://tech.mindcandy.com/2011/06/t-shirt-sizes-in-story-estimation/
http://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes

Cuidado con las estimaciones ágiles

Hoy os voy a traer un caso real. En estos tiempos en las que las metodologías ágiles están en todas partes, es el momento de reflexionar el qué queremos, pero sobre todo, qué necesitan nuestros clientes.

En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:

- [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
- [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
- [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.

En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.

¿Y tú ...qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?

Programación eXtrema (XP)

EXtreme Programming (en adelante, XP), al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software.

Las buenas prácticas de XP

XP establece unas serie de buenas prácticas entre las que encontraremos:

• Planning Game: Este método de estimación de la siguiente iteración.
• Entregas pequeñas: pequeñas e iterativas, las entregas en XP permiten la construcción y despliegue de forma rápida.
• Metáfora: produce una descripción simple y entendida por todos de lo que hay que construir. De esta forma, se guía a los desarrolladores sin entrar en complejos documentos funcionales. La metáfora es fácil de comprender por el cliente y el equipo, y proporciona suficiente información para guiar la arquitectura del proyecto.
• Programación estándar: Los programadores escribirán el código fuente de acuerdo con estándares de programación y buenas prácticas que favorezcan la comunicación. En este sentido, la buena práctica no tiene que malinterpretarse y generar una gran cantidad de documentación sobre cómo escribir código fuente.

La metáfora: ventajas

• La metáfora ayuda a entender los elementos básicos y sus relaciones
• Mediante ejemplos, es posible completar la definición funcional sin entrar en compleja documentación.
• Proporciona una visión de la arquitectura, sin entrar en el detalle.
• Establece un mecanismo sencillo de elaborar el producto y comunicar los objetivos.

La metáfora: inconvenientes

• Por desgracia, una metáfora no da detalles y profundidad a la explicación de lo que hay que construir.
• Los ejemplos asociados a la metáfora, pueden ser confusos, y no deben ser tomados de forma literal.
• La metáfora, no es realmente una arquitectura.
• La metáfora, no es sólo para los programadores, clientes o jefes de proyecto.

SEPG North America 2013

Hoy he recibido un correo de notificación del CMMI Institute, recordando la celebración de un interesante evento que tendrá lugar en Pittsburg el próximo 1 y 2 de Octubre de 2013. Nada menos que el SEPG North America 2013, un evento anual (bueno, vale, hay otros similares en Europa y Asia, también anuales), donde se tratarán temas candentes y de actualidad como por ejemplo:
- Kanban y CMMi
- Flexibilidad Agile: cómo CMMi hará que Agile sobreviva y se fortalezca.
- Implementación ágil de CMMi
- Métricas.
- Desarrollo de Software seguro con Secure by Design for CMMI-DEV
- Microsoft IT Data Management Maturity
...y más.

Me parece muy interesante el esfuerzo por simplificar y acercar CMMI al movimiento ágil, y en general, al resto de iniciativas y tendencias actuales en el desarrollo de software. Espero que sean muy interesantes, y aunque no creo que esté presente, espero poder acceder al material de los eventos y poder estudiarlos. Algunas de las conferencias prometen bastante.

Aunque ya os he puesto más arriba el enlace principal al evento, os adjunto otro par de enlaces directos a:
- Agenda: Conferencias y ponentes.
- Acerca de: ¿Qué son las conferencias SEPG?

Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.

En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.

¿Porqué a los usuarios no les gusta el desarrollo ágil?

Parece que los de ITWorld se han dado cuenta de algo que hace tiempo que vengo diciendo y que por otro lado, no es más que lo que muchos venimos observando: que las metodologías ágiles están en un punto muerto, están en crisis. Y no porque estén mal, sino porque el excesivo bombo y platillo que se ha hecho en los últimos tiempos, han hecho que se usen para todo. Sólo falta que sirvan para lavar la ropa.

Hace poco, leía un artículo de ITWorld con un título similar a este que amigo lector, estás leyendo. Y es que el problema es que por un lado, hay que entender que las metodologías ágiles han subido como la espuma sobre todo por un motivo fundamental: gustan a los programadores. Pero al final, quienes han de pagar las facturas son los usuarios y los usuarios no ven con buenos ojos unas metodologías que presentan para ellos varios problemas:

 

Los usuarios no entienden las metodologías ágiles

Se usan metáforas complejas, conceptos muy novedosos y alejados del mundo de los clientes. El tener que participar para la revisión del producto final en cada iteración, puede ser demasiado para un cliente ocupado que por otro lado, ya ha gastado demasiado en un producto que nunca termina de estar.
El término ágil en en sí mismo contradictorio, ya que no siempre implica rapidez. En muchos proyectos, se prefiere abandonar términos y palabras de moda como "ágil" o "scrum", para centrarse en conceptos más simples y cercanos al cliente.

Los usuarios quieren saber cuánto les va a costar el software.

Claro, desde el punto de vista de los programadores, es distinto. Los programadores quieren hacer un software perfecto, que requiera el mínimo mantenimiento, y que acierte al 100% con la funcionalidad deseada. Y si esto es a costa de entregar las cosas más tarde (obviamente, el tiempo se invierte en realizar iteraciones que nos permitan hacer software cada vez más cercano a lo que querían los usuarios), no pasa nada. Pero el tiempo es dinero. Y el precio final, hay que conocerlo. Los clientes suelen funcionar con presupuestos. No tienen el dinero en un cajón y tampoco lo tienen detenido. Cuesta mucho esfuerzo para un cliente presupuestar el dinero requerido para ciertos proyectos, por lo que ahora no sirve volver al consejo de dirección y decirles: "oye, necesitamos más dinero pero no os preocupéis, porque quedan pocas iteraciones y creemos que terminaremos pronto".

Los usuarios gustan de lo predecible.

A los usuarios les gusta saber no sólo lo que les va a costar el software. Además quieren saber cuándo va a estar disponible, y mucha más información del producto y proyecto final. Que sea difícil de predecir, no deja de ser algo que es problema de los informáticos, no de los usuarios.

Al hablar de iteraciones, los usuarios ven desorganización

En ocasiones, la sensación del usuario es que los informáticos se han rendido a los caprichos de los clientes. "Nos adaptamos a los cambios", decimos. Pero los clientes ven desorganización y falta de control. Y ojo, no nos obsesionemos con que esto no es así. Yo no digo que sea así. Lo importante es que el cliente sí que lo ve así. Y con esto tenemos un problema (unos cuantos ya en este artículo).

Los usuarios quieren ver el final

La sensación que percibe el cliente es que las metodologías ágiles llevan a proyectos sin final. Al no existir una fecha cerrada de entrega, sólo tienen claro que se les va a entregar un producto que sigue los requisitos (al menos, eso les hemos vendido durante muchas iteraciones). Pero no saben cuándo. Y necesitan ver el final. Porque muchas veces, cuando tenemos una fecha planificada y nos retrasamos, el cliente se puede poner nervioso. Pero si estamos iterando, aunque nosotros como informáticos entendemos que nos estamos "acercando progresivamente" al producto final...resulta que el cliente no lo ve así. Es posible, muy posible que lo que el cliente vea es un "retraso iterativo", es decir, se están haciendo cambios, y más cambios, pero la fecha se sigue escapando de las manos.
"¿No eran esto metodologías ágiles? ¿No se supone que tendría que haber terminado esto ya?"

Los usuarios quieren control

Las metodologías ágiles son buenas en entregar cosas, pero el usuario quiere el control, no dejárselo a los programadores. La percepción del cliente es que por mucho que se le involucre en la revisión de historias de usuario que entran en cada iteración, y en la revisión del producto final de dicha iteración...su control es escaso. Y lo que es peor, hay una falsa sensación de control que se confunde con exceso de poder. El usuario tiene el poder de moldear el producto final...aunque esto le lleve a dar bandazos funcionales que en el fondo, no son el control. Porque el cliente no entiende como control añadir y quitar funciones.

¿Estamos ante el fin de las metodologías ágiles? Pues no lo creo. Yo llevo usando y conviviendo con ellas desde 1999. El problema es que han pasado de grandes promesas a grandes decepciones. Se puso demasiado énfasis y demasiadas esperanzas en las que prometían ser las grandes balas de plata del siglo 21. Y no han resuelto nada de lo que prometieron. Por supuesto, en los proyectos y clientes que encajan, las metodologías ágiles suponen una ventaja.

¿Qué podemos hacer con los usuarios? Pues como hemos visto en este artículo, los usuarios, el cliente, pueden no entender o incluso ser poco receptivos a las metodologías ágiles. Y es nuestra obligación RESPETARLOS. Sí, no podemos pedir respeto para nuestra profesión, y luego tratar de imponer cosas al cliente, faltándole al respeto. Tenemos que solventar estos problemas con el usuario a base de:

• Disciplina
• Uso consistente y coherente de buenas prácticas
• Educación
• No agobiar al cliente con conceptos ágiles. Usar terminología adaptada al cliente. Somos nosotros los que debemos esforzarnos en hablar su lenguaje, NO AL REVES.
• Formación
• Introducción progresiva de las técnicas ágiles, aun cuando los proyectos no usen metodologías 100% ágiles.
• Flexibilidad. Si el cliente no encaja técnicas ágiles, buscar sustitutos adecuados (sin obsesionarnos con si son ágiles o no, solamente en que sean adecuados al proyecto/cliente).

Sólo así lograremos credibilidad con nuestros clientes y éxito en nuestros proyectos.

El tamaño importa

He leído recientemente en algún blog, sobre la forma adecuada de medir el tamaño del software, y que ésta, debe ser contraria a la que se usa en construcción de casas.

Vaya con la maldita manía de que como se supone que el software y las casas son distintos (según algunos, radicalmente opuestos), pues las formas de trabajar, medir, etc, deben serlo también. Esto ya es incluso un caldo de cultivo para los defensores del "agilismo porque sí", ya que como una casa se hace por fases, y esto se asimila a un método de desarrollo en cascada, está claro que eso es algo obsoleto y por tanto, la forma de trabajar en el software ha de ser distinta. Interesante, pero absurda conclusión.

Para medir el tamaño del software, podremos usar Puntos Función (PF), o cualquier otra medida. En la construcción de casas, esa medida no es válida, claro está.

Tambien se suele afirmar que en la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido (valor). Aquí sí que tienen ventaja las metodologías ágiles, ya que se centran en el valor incorporado en cada iteración.

Creo que tenemos un problema. Somos nosotros, los desarrolladores, los que pretendemos que nos paguen por esfuerzo. No es que sea la medida habitual: es lo que habitualmente pretendemos. Los clientes no quieren saber si nos costó 1000 ó 1050 horas hacer su programa de facturación, o su sistema de control de fábrica. El cliente quiere saber lo que realmente necesita para su negocio que es:

• Fecha: ¿Cuándo estará el software disponible? ¿Cuándo podrá integrarlo con otros productos? ¿Cuándo tendrá que tener lista la formación para su personal? ¿Cuándo tienen que estar disponibles los responsables de sistemas para su puesta en marcha? ¿Llegará el producto a tiempo para hacer lo que tiene comprometido por contrato en una fecha concreta?
• Coste: ¿Cuánto dinero va a costar? ¿Se puede pagar a plazos? Los clientes no tienen un baúl como en los dibujos animados lleno de dinero. El dinero en las empresas, no suele estar disponible en todo momento. Depende de la facturación, de si toca o no pagar impuestos, etc. Muchas empresas necesitan pedir un préstamo para acometer pagos, incluso los previstos.
• Calidad: ¿se cumplirán las necesidades y requisitos establecidos? ¿estarán todas las normas obligatorias recogidas? ¿Hay criterios de calidad adicionales que aporten valor (usabilidad, etc)?

Si os fijáis, estos factores son significativos. El negocio del cliente es directamente dependiente de estos factores. Un pequeño cambio en cualquiera de los tres, y podemos hacer que la empresa del cliente se arruine, y sus trabajadores acaben en la calle. Y esto sirve para todo, no solo para el software.

El coste, por otro lado, estará marcado por el mercado. Habrá productos, que si no sabemos desarrollarlos por un coste inferior al precio de mercado, tendremos un problema. Aquí está la clave: ser competitivos.

¿Entonces porqué esa manía de medir el software en esfuerzo? Pues porque es lo único que nos importa, en un entorno todavía inmaduro que parece no querer ver más allá y no involucrarse en satisfacer al cliente.

Se está huyendo de dos premisas, muy integradas culturalmente en otros sectores, pero que parece que en el software nos negamos a asimilar:

• Compromiso. Los acuerdos se hacen mediante contratos. Y los contratos están para cumplirlos.
• Disciplina/Ingeniería: debemos tener las herramientas y procesos adecuados para estimar y reestimar progresivamente si vamos a terminar en fecha y con el coste pactado. Y por supuesto, con la calidad pactada como mínimo.

Se oye hablar de que las casas se venden por metro cuadrado, y que esto no es válido para el software, ya que las casas siguen un método industrial (supuestamente radicalmente diferente del desarrollo software). De nuevo, otra falacia interesada.

Las casas, si se fabrican iguales, costarán un precio similar. El problema no es el método, sino que los materiales, mano de obra, etc., están muy estandarizados en la construcción de casas. Pero siempre existirán casas hechas a medida, con piezas no estándar, y que costarán un ojo de la cara (es decir, su precio por metro cuadrado, se dispara). De todas formas, si nos fijamos en las casas estándar normales...¿habéis comprado alguna casa? ¿Os habéis fijado que en mismo edificio de casas, donde dos de ellas supuestamente deberían ser iguales...no han salido igual? ¿Verdad que todas las casas no salen con los mismos fallos? ¿Verdad que si medís los metros cuadrados de todas las viviendas...ninguna cumple exactamente con lo que dicen los planos?

Por tanto, llegamos a la conclusión de que las casas no son iguales, no se construyen iguales (sencillamente porque es imposible), y se requiere una ingeniería detrás para poder conocer cuándo podrán estar terminadas, y cuánto dinero van a costar. Eso se hace con planificación y gestión. ¿Por qué no hacemos lo mismo con el software? ¿Porqué seguimos renegando de los métodos de ingeniería, pero no estamos dispuestos a que dejen de llamarnos ingenieros?

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: "una metodología no es un equipo de fútbol, ni un partido político, ni una religión". Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua
• <Pon aquí tu práctica/metodología/marco de trabajo>

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

"Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento."

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: "metodologías", "prácticas", "marcos de trabajo"...llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo "indecisos patológicos" o "charlatanes del depende". Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un "depende" (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un "ser superior" que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan...o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer...respecto a qué?

En fin...excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

Kanban Avanzado

Hoy os voy a dejar un regalo especial. Tengo el placer de leer de vez en cuando un blog muy interesante, y hoy veo que hoy merece la pena simplemente enlazar unos cuantos posts de lo que yo llamaría "Kanban Avanzado".

La autora, Teodora Bozheva, nos deja unas cuantas perlas. Que las disfrutéis:

Primeros pasos: Kanban en organización tradicional
Kanban para la gestión del portfolio de proyectos.
Si no lo ves, no lo puedes controlar (Gestión Kanban)
Kanban: una solución para la crisis.

Teodora, y ahora...¿qué puedo hacer yo para superar esto? Je je, un cordial saludo.

La obsesión por el éxito

En general, tenemos el problema de que no estamos dispuestos a aplicarnos a nosotros lo que exigimos a los demás.

No es la primera vez que oigo que en un proyecto con metodología ágil, el analista técnico o programador se queja de que el diseño funcional que le entregan no está 100% cerrado al inicio del sprint.

Es decir, ¿sólo usamos el agilismo de cara al cliente o al jefe de turno? ¿No estamos dispuestos a aceptar también los cambios en los documentos de otros compañeros? Hemos de superar el hecho natural de que los demás también se equivocan, aceptar los cambios y gestionarlos como tales, no como un problema al que se asigna un culpable.

Sólo cuando estemos dispuestos a aceptar que el trabajo en equipo tiene estas cosas, podremos realmente llevar adelante proyectos con éxito. Porque el éxito no significa "sin problemas". Significa superarlos, y poner los medios para que no se produzcan, no buscar los culpables para que no nos señalen con el dedo.

Nota: esta entrada está más o menos sacada de un comentario mío en LinkedIn, en respuesta al excelente artículo "El Oportunismo del Agilismo".

Kanban para novatos

La meodología Kanban, cada día se presenta más y más como posible sucesora de Scrum en el rol de abanderada del Agilismo.

La metodología de desarrollo Kanban (Kanban Software Development) está basada en la metodología de fabricación industrial del mismo nombre. Para saber de sus orígenes, y ver cómo ha acabado implantándose en el mundo del desarrollo de software, hay muchas fuentes. Una que he encontrado bastante válida es: http://www.monografias.com/trabajos7/elka/elka.shtml

Orientación visual

El sistema Kanban, orientado al desarrollo de software, está fuertemente ligado al uso del tablero o pizarra Kanban. Vamos a ver en qué consiste.

La pizarra Kanban contiene las tareas que tenemos que desarrollar. La pizarra está estructurada por columnas, que identifican cada una a los distintos estados por los que puede pasar (más o menos secuencialmente), la tarea:

• Solicitada
• Asignada
• En desarrollo
• En pruebas
• Completada

Se podría pensar en más estados: validada por el usuario, implementada en producción, etc. Lo importante aquí es el aspecto visual, ya que las distintas tarjetas (una por tarea), siguen de izquierda a derecha en la pizarra, los estados. El aspecto de la pizarra sería tal que así:

Limitar el trabajo en curso

Otro aspecto fundamental del Kanban es mantener acotado dentro de unos límites, el trabajo "en curso". La pizarra ayuda mediante su gestión visual. Además, hay dos conceptos importantes:

• No podemos comenzar una nueva tarea hasta que la anterior la hayamos terminado.
• El número máximo de trabajo en curso tiene un límite, que es nuestra capacidad por ciclo o iteración.

Métricas Kanban

Me ha parecido interesante esta mención que hace Javier Garzas en su blog, y es que hay que medir, aunque seamos ágiles y usemos Kanban. En este caso, al menos, recogeremos por cada tarea:

• Fecha y hora de inicio
• Fecha y hora de fin
• Tiempo real invertido

Como además, tendremos la estimación inicial para la tarea, con los datos anteriores ya tenemos la desviación respecto a lo estimado.

El tiempo promedio para completar una tarea, es también importante y a veces conocido como "tiempo de ciclo", ya que es el ciclo medio que nos cuesta pasar una tarea de izquierda a derecha de la pizarra hasta que cogemos una nueva.

Y nada más, que si os animáis, podéis usar esta metodología. Como podéis ver, es muy simple, y tiene muy pocas reglas o normas a seguir.

AOS2012 - Agile Inception (2 de 2)

Pues nada, he aquí la segunda parte de la descripción de este método.
Antes de seguir, recordar la principal bibliografía, que es el magnífico libro "The Agile Samurai" de Jonathan Rasmusson, de donde además son algunas imágenes.

Nos habíamos quedado en el anterior post repasando las 5 primeras actividades o juegos. Pasemos a los 5 siguientes. Recordad que podéis encontrar un resumen del AOS 2012 y un indice de las ponencias a que asistí en este enlace.

6.Mostrar la solución 

• Presentar una solución técnica
• Revisar riesgos
• Establecer dimensiones
• Establecer resultados del producto
• Establecer claramente lo que va a costar
• Utilizar lenguaje visual
• Establecer expectativas de las áreas con más riesgo
• Obtener compromiso con la solución técnica planteada

7.Despierto por la noche

• Determinar los riesgos del proyecto
• ¿Qué nos quita el sueño?
• Hablar de los riesgos es bueno
• Debe participar el equipo: compartir los riesgos es aún mejor
• Clasificar los riesgos en dos categorías: Los que merece la pena preocuparse por ellos (probables o graves), y el resto
• Llegado el caso, antes de perder la calma, echar mano de la oración de la serenidad:

8.Medir el tamaño 

• Se trata de dar una estimación de orden de magnitud: un mes, dos, seis meses o un año
• Utilizar técnicas de estimación ágiles
• Presentar al cliente la estimación y una planificación a muy alto nivel. No se establecen compromisos en cuanto a plazos.
• Pensar en pequeño
• Dar expectativas de tamaño

9.¿Cuál va a ser el resultado?

 En este punto, hay que establecer prioridades entre las principales restricciones del proyecto:

• Alcance
• Presupuesto
• Tiempo
• Calidad
• Otros

 Recordar dos reglas fundamentales:

• No pueden ser todas prioritarias (no todas son #1)
• No puede haber dos al mismo nivel de prioridad

10.¿Cuál va a ser el coste?

•  Llegados a este punto, mediante los juegos anteriores tenemos la visión y el plan
• Debemos finalmente mostrar el coste y esfuerzo necesarios, recursos, etc.
• Detallar nuestro equipo (roles, responsabilidades, nombres, etc.)
• Aclarar quién va a ser la voz del cliente, el responsable de filtrar y focalizar las peticiones de los stakeholders.
• El resultado será algo como:

El resultado final

El resultado de esta actividad participativa será un documento o material en el que habrán quedado identificados:

• Qué se va a construir y porqué
• Qué amenaza al proyecto: riesgos y retos principales a afrontar
• Cuáles son los obstáculos a resolver
• Quiénes van a ser nuestros “vecinos”
• Qué aspecto tiene nuestra solución
• Tamaño que va a tener
• Dónde estamos dispuestos a ser flexibles y adaptables
• Duración y coste aproximados

Conclusión

Esta actividad, que explicada así puede parecer un poco "de juguete", en realidad consigue de una forma dinámica y participativa, que se encuentren y se pongan en común posturas normalmente opuestas como son las del equipo técnico/funcional, y el cliente. El hecho de ser participativa, y enfocarse en pequeñas actividades, aligera el proceso y permite que algo tan complejo y tedioso como identificar las necesidades del cliente y establecer una visión global del producto a construir, es ameno y en cierto modo, hasta divertido.

Por lo demás, recomendar el libro "Agile Samurai", que aunque en algunos momentos puede parecer "más de lo mismo" en el mundo ágl, tiene algunas perlas que lo salvan de cualquier quema.

AOS2012 - Agile Inception (1 de 2)

Y he aquí como descubrí el método de Inception: en el AOS (Agile Open Space) que tuvo lugar en Zaragoza el pasado mes de Junio de 2012. Si quieres ver mi reseña de otras  charlas del AOS 2012, tienes un índice aquí.

¿Qué es Agile Inception?

Es una colección de ejercicios prácticos, que realizados en una o varias sesiones con el cliente, pretende establecer una visión clara y suficientemente detallada del producto a construir. Los ejercicios son:

• ¿Porqué estamos aquí?
• Charla de ascensor
• Caja de producto
• La NO lista
• Conoce a los vecinos
• Mostrar la solución
• Despierto por la noche
• Medir el tamaño
• ¿Cuál va a ser el resultado?
• ¿Cuál va a ser el coste?

1. ¿Porqué estamos aquí?

Se trata de conocer el verdadero motivo de construir el producto software. Una vez conocido el por qué, seremos capaces de:

• Tomar mejores decisiones
• Gestionar mejor las restricciones
• Presentar mejores soluciones a los problemas

Técnica 1: Ves y mira tú mismo

Tratar de conocer de primera mano la problemática y necesidad que lleva a construir el producto.

Mediante empatía, cuestionarios, trabajo con el cliente, etc.

Técnica 2: Descubre la intención del responsable

• Es una frase concisa y simple que resume la intención del responsable (cliente) y que resume el propósito del proyecto
• El propósito del ejercicio es que el grupo hable de lo que piensan que es el motivo que les ha llevado ahí.

2. Charla de ascensor

El objetivo es condensar en unas pocas frases, la esencia de la idea del producto.

El nombre “Elevator pitch” viene de: ¿cómo venderías tu producto a la persona que puede financiártelo, si te la encontraras en el ascensor?

El enfoque es que sólo se dispone del tiempo que tarda el ascensor en recorrer los pisos.

¿Qué aporta?

• Claridad
• Fuerza al equipo a pensar en el cliente
• Va al grano 

3. Caja de producto

Este ejercicio consiste en crear una caja para el producto, como si éste fuera a ser vendido en una estantería de una tienda.

Pasos:

• Paso 1: Brainstorming de los beneficios del producto
• Paso 2: Crear un Slogan
• Paso 3: Diseñar la caja

4. La NO lista

Al definir un producto, es tan importante decir qué estará en el alcance, como qué no estará dentro del alcance. Es una lista visual

5. Conoce a los vecinos

Objetivo: identificar los distintos roles con los que se va a interactuar durante el proyecto.

Actividades:

• Paso 1: Brainstorming. El grupo trata de identificar todas aquellos grupos o roles con los que creemos que vamos a interactuar antes de la puesta en producción del producto.
• Paso 2: Contactos. Crear una lista de contactos para poner caras a los grupos o roles anteriores.
• Paso 3: Comunidades. Identificar, de los anteriores, los contactos con los que más nos vamos a relacionar. Éstos formarán la comunidad principal de vecinos. El resto, irán en un grupo aparte.

Para ver la segunda parte de este post, haz clic aquí.

AOS2012 - Más referencias

AOS2012 sigue coleando. Me pasa mi compañero José Antonio Herrero un nuevo link del excelente blog de Ujue Agudo.

Me ha encantado confirmar que allí sigue estando EL MAESTRO Alan Cooper entre los grandes. (Si aún no has leído "The Inmates are running the Asylum", no sé a qué esperas):

Alan Cooper (@MrAlanCooper)
cooper.com
Un histórico referente para los UX (autor del libro “Presos de la tecnología”) aplicando agile.

AOS2012 - Una mirada atrás

Hola, esta entrada no es más que un compendio de diversas entradas que he ido creando, como resumen de las charlas a las que asistí en el pasado evento  Agile Open Space 2012, en Zaragoza.

He aquí el resumen:

1. Extender el virus ágil
2. Técnicas para el trabajo en remoto
3. Gestión del código heredado
4. Inception (1 de 2)
5. Inception (2 de 2)

Como no pude asistir a todas, pero sí lo hicieron algunos de mis compañeros, mi reto es que me ayuden a preparar resúmenes de sus charlas. Como no me gustan los resúmenes en plan transcripción, les reto a que aporten sus opiniones, que no sólo digan lo que se dijo, sino lo que pensaron, las pegas que durante la charla, o después de la charla, vino a sus mentes. Es decir, las reflexiones del día después.

¿Que qué fue el AOS?

Fué un evento, en el que se trataron temas de metodologías ágiles en el mundo del desarrollo del software principalmente. Con casi 300 asistentes, se puede considerar todo un éxito de asistencia y participación.
El formato era variopinto: había charlas, coloquios, exposiciones, actividades participativas, talleres, etc. Todo comenzó el viernes 22 por la tarde, en que se decidieron los temas, y continuó durante todo el sábado (desde las 9 de la mañana, hasta la tarde/noche)

¿Esto del Open Space qué es?

Es una forma de organizar eventos que es autoorganizativa. Los propios participantes se presentan y postulan sesiones que se apuntan en un tablón. Los participantes votan por las más interesantes, y de esa forma se organizan las salas y horarios. Así se consiguen realizar las charlas más interesantes, y se descartan las menos votadas. Tal y como dice Juan Quijano en su blog de GenBetaDev:

"este sistema debería ser caótico y que no se debería poder llegar a ningún resultado coherente. En cambio los resultados demuestran que esto no es así. En poco más de una hora, estaban definidas todas las charlas, asignadas a una sala y a un horario..... Por un efecto de imitación y de forma vírica, se consiguió cosas que parecían imposibles. Como dejar un restaurante al completo en absoluto silencio, en unos pocos segundos. Y los comensales que no eran parte del evento, preguntar asombrados (después de realizar el anuncio que requirió el silencio)"

Otra descripción del Open Space, en palabras de David Bonilla en su blog:
"...no existe una agenda fija, sino que cualquiera puede proponer los temas que le parezcan interesantes para debatir y son los propios asistentes los que deciden, con sus votos, sobre qué se hablará durante el evento"

¿Y cuáles fueron las conclusiones?

• Temas avanzados pero también hubo temas sencillos e introductorios para personas noveles en el mundo ágil.
• Ambiente participativo y ágil (cómo no)
• Oportunidad única de conocer los temas directamente de las personas que los conocen de primera mano.
• Oportunidad única de tratar los temas en charlas abiertas y distendidas, donde todos pueden aportar ideas y conceptos.
• Todo un ejemplo de motivación y ganas de compartir
• Excelente organización, en un marco único, el edificio Seminario, facilitado por el Ayuntamiento de Zaragoza.
• Posibilidad de aprender y compartir no sólo con desarrolladores. En este evento participan activamente psicólogos, expertos en User Experience, diseñadores, gente de marketing y RRHH, etc.

Para finalizar, adjunto unos links que tan pacientemente ha recopilado Visi Serrano, una de las ponentes en su Blog (no sé si hay un recopilatorio mejor de links, ya me perdonaréis pero el mejor que he encontrado ha sido el de Visi):

Links:

• Agile Open Space 2012: estuvimos allí. Por Juan Quijano (@jc_quijano)
• No me gustan los jefes, no quiero ser jefe. Por Mario Nunes (@Mariotux)
• ¡A por ellos, oeeee!. Por @francho_lab
• En el blog de Roberto Miñana: Técnicas de trabajo remoto y Extender el virus ágil
• Un open más open. Por @tolivern
• Más fotos del #aos_2012. Por Milla Digital Zaragoza.

Otras entradas relacionadas:

• Metodologías Ágiles y Coaching por @Joserra_Diaz

http://najaraba.blogspot.com.es/2012/02/metodologias-agiles-y-coaching.htmlç

• Psicología y Scrum: desarrollo ágil de equipos

1ª parte: http://uvedevisi.blogspot.com.es/2012/02/psicologia-y-scrum-desarrollo-agil-de.html
2ª parte: http://uvedevisi.blogspot.com.es/2012/03/psicologia-y-scrum-desarrollo-agil-de.html

• Soluciones integradas de Project Management y Agile:

http://www.slideshare.net/Uve1971/project-management-and-agile-solutions

AOS2012 Gestión del código heredado

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.

Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Una de las primeras charlas a las que asistí era la de cómo enfrentarnos al código heredado. La verdad es que el propio ponente (Pablo Bouzada), ya se me ha adelantado (claro, para eso es su ponencia), y lo ha dejado todo escrito en su blog. La verdad que fue una gran exposición, y se nota que domina el tema.

De todas formas, me gustaría que:
1º- Leyérais tranquilamente el blog original y
2º - Me permitiérais añadir aquí unos comentarios.

La verdad es que aunque interesante, el fondo del artículo no es nada novedoso. Básicamente nos indica que  todo ha de ser gestionado, y que los riesgos han de gestionarse también. Y en este caso, se trata de gestionar la transición para tomar el control de un proyecto heredado.

Mucho más interesante que el artículo en sí, me interesa el detalle de que si bien hasta ahora éramos simplemente ágiles, y rechazábamos procesos de gestión, nos empezamos a dar cuenta de que realmente la gestión es necesaria. No podemos ser tan ágiles como para decir: "Ok, me acaban de meter en un proyecto con código heredado, y como soy ágil, me pongo a picar y ya está".

Es precisamente el hecho de considerar necesaria la gestión, lo que me sorprende. Por fin somos ágiles...¡y gestionamos! Pues enhorabuena.

Pero no se trata de gestionar al tuntun, ni de meter el mega-proceso de gestión PMBOK que nos permita abordar con el 100% de garantías el proyecto. Se trata simplemente de abordarlo de forma lógica y ordenada, y con el mayor grado de agilidad posible. Aquí es donde Pablo Bouzada tras revisar otros métodos, acaba proponiendo uno más simple:

1. Qué: Identificar qué tengo (a qué me enfrento)
2. Cuánto: identificar el alcance.
3. Cómo: preparar una estrategia para abordarlo, en especial creando una red de seguridad (test funcionales, UAT, unitarios,etc) que me permitan realizar cambios con cierta seguridad. Establecer un límite en dichos test (no se puede cubrir todo), relacionado con el alcance anterior.
4. Cuándo: establecer una priodidad de las tareas, que me permita planificarme.
5. Trabajar, ya por fin, con una cierta seguridad.

Otro punto interesante que surgió en la charla, estaba relacionado con algunos puntos que se producen en el mundo real:

• ANS: ¿Has heredado un proyecto con Acuerdos de Nivel de Servicio? Pues lo tienes muy mal. Primero tienes que atender al contrato con el cliente, y luego, solo luego, podrás atender el proceso descrito. Por supuesto, lo ideal es poder tratar abiertamente esto con el cliente, y convencerle de que nuestra vida se puede volver un infierno si no nos da un período para poder aplicar nuestros 5 puntos anteriores. Sin embargo, el cliente ya tiene un contrato, y nada le obliga a hacer nuestra vida más fácil.
• Compromisos: ¿Y si hay una fecha de entrega asociada al proyecto heredado? Aquí se supone que hemos heredado un proyecto sin entregar. La parte buena, es que al no estar en producción, no tenemos el call-center echando humo con clientes quejándose de incidencias. La parte mala, es que seguramente habrá una fecha en que ese proyecto heredado se deberá entregar. De nuevo, para acometer convenientemente los 5 puntos anteriores, es vital contar con la comprensión y el compromiso del cliente.

Voy a hacer un inciso. Y es que efectivamente, como se comentó en la charla AOS2012 sobre este tema, "el primer interesado en que el proyecto salga bien, es el cliente". Ok. De acuerdo, pero debo apuntar: "el cliente, lo primero en que está interesado es en NO PERDER DINERO". En algún caso, el cliente preferirá denunciarme y no pagarme (al menos no pierde dinero), que concederme de forma gratuita, el tiempo necesario para que usando los 5 pasos anteriores, pueda tomar las riendas del proyecto en condiciones.

¿Cómo? ¿Que el cliente prefiere no tener su producto? Pues no sería la primera vez que se da el caso. Por desgracia, en las metodologías ágiles, damos por sentadas dos premisas que al parecer nadie se detiene a comprobar:

1. El cliente se involucra en el proyecto, y está dispuesto a dedicar el tiempo necesario para lograr el éxito del proyecto.
2. El cliente desea el producto final, y está dispuesto a ese fin, sin escatimar en gastos.

Pues es posible, en algún caso, que no ocurra así. El éxito a cualquier coste, y menos en los tiempos que corren, no se lo pueden permitir todos los clientes. Y hemos de tener en cuenta, que en las empresas, quienes nos contratan han de reportar "hacia arriba" con el avance del proyecto y su coste.

Y no quiero decir, por supuesto, que en el mundo real las metodologías ágiles no sirvan (como parecen afirmar muchos). Lo que simplemente quiero decir, es que NO PODEMOS DAR TODO POR SUPUESTO. Todo tiene un límite, incluso la paciencia y el dinero de nuestro cliente.

Y vuelvo al tema tras el inciso. Los 5 puntos anteriores, el proceso mencionado, hay que aplicarlo. Pero hay que hacerlo dentro de los límites y plazos que tengamos, y haciendo partícipe al cliente. El cliente, debe tener visibilidad de porqué estamos refactorizando, metiendo test unitarios, etc. etc.

Y aquí me permito añadir un problema adicional (es lo que tiene el mundo real, que no es simple y maravilloso, sino retorcidamente complejo):

• ¿Qué ocurre si heredamos el código...no de otra empresa sino de otro empleado? ¿Somos lo bastante honestos para decirle al cliente que necesitamos dedicar tiempo a "protegernos" de la chapuza que le habíamos hecho hasta ahora? Muchos pensarán: "claro que sí, el cliente lo va a entender". Es posible. Otros dirán "No, mejor lo hacemos sin que se entere el cliente, porque seguramente el cliente prefiera no seguir gastando dinero en alguien que ya le ha traicionado en su confianza".

En fin. Disfrutad de este gran artículo original de Pablo Bouzada, y sobre todo...suerte con los proyectos heredados.

AOS2012 Técnicas para el trabajo en remoto

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.


Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Introducción.

Esta charla estaba enfocada a tratar las herramientas, ventajas e inconvenientes de trabajar en remoto. Y no me refiero simplemente a equipos distribuidos. Me refiero a cuando un trabajador hace su actividad prácticamente al 100% de forma remota. Puede ser desde su casa, desde una oficina alquilada, etc. Lo que sí se ha de dar es que la mayor parte del tiempo, se encuentre en distinta ubicación géográfica respecto al resto del equipo (y respecto al cliente, claro).

Recomendaciones a seguir.

Vamos a ver algunas recomendaciones, que los asistentes nos hicieron para que si nos encontrábamos asistiendo en un trabajo de forma remota, se mitigaran los posibles problemas que pudieran surgir.

• Es importante pasar las primeras fechas del proyecto, o la primera etapa, de forma presencial con el resto del equipo. Esto es muy adecuado de cara a mitigar la sensación de alejamiento posterior, y además, potencia el sentimiento personal de equipo entre los integrantes, facilitando su conexión y complicidad. El hecho de cultivar las relaciones humanas al principio, facilita enormemente el trabajo posterior.
• Mantener un contacto personal periódico. Además de al inicio, es recomendable un contacto personal periódico con el resto del equipo. Por ejemplo, 1 vez al mes.
• Mantener unificada toda la información relacionada con el proyecto, incluidos todos los correos electrónicos: tanto los intercambiados con el cliente, como los internos del proyecto. Esto facilita el poder hacer seguimiento de conversaciones o reuniones en las que no hemos podido estar al encontrarnos en remoto.
• Utilizar una herramienta de comunicación  o chat en grupo que permita establecer charlas instantáneas en grupo, hacer comentarios, etc. Es importante no dejar fuera de las conversaciones a la persona desplazada, ya que se establecen lagunas en la conversación, que a la larga, afectan gravemente el rendimiento del trabajo.
• Pair programming. Se habla de entorno a un 50 o 60% de trabajo siguiendo esta técnica.
• Peer Review. Revisiones cruzadas de código.
• Cultura de informar siempre lo que se está haciendo, al resto del grupo.
• Cultura de estar informados en todo momento de lo hablado en reuniones, y de las conversaciones del resto del grupo.
• Si se trabaja con auriculares, tener en cuenta que las conversaciones o reuniones en remoto no son como las presenciales. Cuando hablan 2 o más personas, tratar de seguir la conversación es muy complejo en remoto. Es por ello importante respetar los turnos, tratar de no mantener conversaciones paralelas, etc.
• Es importante contar con alguna herramienta de control de presencia, que nos permita identificar si la persona remota está online, y al revés: que él pueda ver si el resto del equipo está conectado, o se ha ido a tomar un café (de nuevo aquí ayuda el char simple tipo "café. vuelvo en 10 minutos").

Herramientas

A continuación, comentamos algunas de las herramientas que se trataron en el evento.

• Join.me
• Terminal Server
• Team Viewer
• Lync
• Kanban Flow

Ventajas

• Por supuesto, una ventaja es la posibilidad de tener un horario completamente flexible. Nos podemos levantar a la hora deseada, lo mismo al acostarnos, etc, etc.
• Propiedad colectiva del código
• Ahorro de costes
• Facilidad de atender sobre-esfuerzos en el proyecto
• Facilidad de conciliar vida familiar, de viajar, etc.

Inconvenientes

• Dificultad de mantener conversaciones o charlas en grupo a través de auriculares.
• Riesgo de perder información (conversaciones, chats, correos, etc.)
• Riesgo de aburrimiento (en el evento agile salió la frase "acabas viviendo y trabajando con el mismo pijama con el que te acostaste la noche anterior")
• Riesgo de falta de compromiso
• Riesgo de pérdida de relaciones humanas con el resto del equipo
• Problemas con horarios (distintas costumbres, distintos países) y concurrencia
• Dificultad de atender reuniones con el cliente, u otros eventos que requieran la presencia física.

AOS2012 Extender el virus ágil

Bueno, ya ha pasado el Agile Open Space (AOS 2012 en Zaragoza, España). La verdad es que ha sido una experiencia magnífica. Una excelente organización, y una gran oportunidad de compartir conocimientos y experiencias, tanto de la mano de los ponentes, como a través de las charlas de pasillo con los distintos asistentes. Si queréis leer sobre otras charlas, he preparado un índice de mis entradas aquí.

La primera charla a la que asistí era la de extender el tema ágil dentro de la propia empresa de cada uno.

Para empezar, se nos introdujo un libro con una serie de prácticas a seguir que permitan llevar a cabo  esta extensión del agilismo. El ponente, Alberto Gualis, nos fue desgranando estas pequeñas perlas:

• Se útil
• Facilita tus reuniones
• Examina tus normas
• Se puntual
• Estructura tus interacciones
• Anuncia tu intención
• “Gamifica” tus reuniones
• Conduce experimentos con frecuencia
• Gestiona visualmente
• Inspecciona frecuentemente
• Se entrenado
• Gestiona tus límites
• Socializay extiende libros
• Pon atención explícita
• Abre el espacio
• Se jugetón

Al final, de lo que se trata es de hacer "ágil" fuera del propio desarrollo de software.
Algunos de los logros que se pueden obtener cuando el agilismo llega a otros ámbitos, son:

• Rapidez para sacar conclusiones
• Aumento de la motivación (diversión)

Una buena forma de empezar, es haciendo retrospectivas (insisto, en nuestro ámbito, no sólo en desarrollo de software). Y por supuesto, habrá algunas palabras que tendremos que evitar, para que el agilismo no se encuentre con obstáculos:

• Cambio. La gente no quiere cambio. Bastantes cambios e indeterminaciones genera ya nuestro trabajo diario. Por eso no hay que hablar de cambio. No se busca cambiar (como tal). Lo que se busca es mejorar. Y  todo el mundo quiere mejorar, ¿no?
• Nombres como Scrum, Kanban, y nombres propios/específicos de metodologías en general. De lo que se trata es de evitar que se rechace el agilismo desde el inicio. La gente puede verse resistente a la metodología "RJAB347", ya que puede percibirse como algo muy friki o exclusivo, una moda que genera inseguridad. Sin embargo, conceptos más generales como Mejora Continua, es más fácil que sean vistas con buenos ojos.

Además, hemos de dar seguridad tanto a los responsables como al resto de miembros de la empresa. La mejor forma de hacerlo es midiendo. Pero midiendo cosas sencillas.

Rolling Wave Planning

Mientras estaba preparando una formación en Microsoft Project para jefes de proyecto, he recordado este término. La verdad es que la expresión en inglés, si la conocía, no la recordaba. Ésta es una técnica de planificación, vieja conocida, que algunos habrán oído también nombrar como "planificación progresiva". Para mí, éste último era el término con el que la había aprendido. También la encontraréis como "planificación gradual".

En el PMBOK, está referida como "planificación continua con detalle incremental"

¿En qué consiste? Vamos a verlo.

Esta técnica se traduce en preparar una planificación como siempre, a alto nivel, pero a la hora de bajar al detalle de tareas del plan, lo haremos sólo para la primera fase del proyecto, la que tengamos que llevar a cabo de forma inmediata.

Por ejemplo, supongamos que hacemos un Project con las típicas fases (no entremos de momento en interacciones) de: "requisitos", "diseño", "desarrollo", "pruebas", "implantación". Esta técnica consistiría en dejar solamente detallada la primera fase, la de requisitos. Conforme nos encontráramos con el fin de los requisitos, actualizaríamos el detalle de la fase de diseño. Antes de terminar el diseño, tendríamos previsto el detalle de la fase de desarrollo...y así sucesivamente.

Se podría aplicar a otros ciclos de vida: por ejemplo en desarrollos ágiles, sería posible dar más detalle a las historias de usuario de las primeras 2 o 3 iteraciones, y dejar el detalle de las siguientes iteraciones para más adelante. En realidad, esta técnica está recomendada por muchos seguidores de las metodologías ágiles. De hecho, la planificación iterativa permite beneficiarse del conocimiento obtenido tras cada fase, ajustando mucho más el detalle de las fases siguientes, de forma progresiva.

Las ventajas:

- Me ahorro proporcionar detalle de las tareas para las que todavía no tengo suficiente visibilidad.
- Centro mis esfuerzos en el corto plazo, lo que me permite proporcionar una planificación mucho más ajustada a los equipos que están "en las trincheras" (y para los cuales, el "medio y largo plazo", no es más que un obstáculo, una preocupación futura).
- Proporcionan una forma de unificar los conceptos ágiles, con las metodologías tradicionales.

Inconvenientes:

- Sin proporcionar suficiente detalle a las fases o iteraciones futuras, es posible que la estimación global, y por tanto la planificación, no se ajuste a la realidad.
- Con ello, es difícil proporcionar una visión realista de los plazos, costes y esfuerzos totales o a largo plazo.

Al principio del post he puesto imagen que creo que muestra el concepto. Ojo, porque la imagen muestra una forma de llevarlo a cabo, dando un detalle menor conforme la fase que describimos se aleja en el tiempo (menos detalle conforme nos alejamos del momento actual). Mi aproximación en el ejemplo ha sido menos incremental: yo propongo detallar la fase actual, y dejar todas las demás fases con un detalle menor, pero igualado entre ellas.

Al final, todo dependerá del grado de detalle que necesitemos, y sobre todo, de la necesidad que tengamos de detalle a la hora de dar la estimación global.