¡Y se viene el Agile Open Lima VI!

Por si no lo saben, el próximo domingo 26 de Agosto se viene el VI Agile Open Lima, asi que por si no te has apuntado ya te estas demorando demasiado :), este evento es peculiar pues por primera vez se hace en domingo y en las afueras de Lima (si, aun mas lejos que Surco o La Molina) concretamente en Ñaña en la sede de Universidad Peruana Union, lo cual permitirá realizar algunos juegos agiles al aire libre. Para esta ocasión estoy proponiendo las siguientes sesiones:

 Estoy muy entusiasmado con estas sesiones, llevo varios meses probando la versión Beta de Team Foundation Service, y me ha sorprendido gratamente sus capacidades para llevar a cabo integramente la gestion del Ciclo de Vida de las Aplicaciones, desde la toma de requerimientos y gestion del Backlog hasta la automatización del despliegue (y por supuesto haciendo la Build en la nube), si creías que TFS es solo un “source safe mas potente”… esto te hara pensar ;).

Sobre la segunda charla, intentare replicar un estilo “reality show” que pude ver en acción por parte del maestro Angel Medinilla en el Agile Open Spain del 2009, compartiendo las experiencias que hayamos tenido trabajando con equipos distribuidos, ya sea como cliente o como proveedor, en un momento en que el desarrollo de proyectos offshore esta creciendo en nuestro país, sera algo muy interesante para ver como mejoramos nuestra forma de desarrollar esta clase de proyectos desde un enfoque agil.

Así pues cuento con ustedes en este nuevo Agile Open Lima y en particular con sus votos para poder llevar a cabo estas sesiones :), ¡nos vemos en Ñaña!!.

_DSC8580.jpg IMG_5890.jpg _DSC8807.jpg

¿Flexibles, puristas o simplemente … Agiles?

He estado pensando en escribir este post desde hace unas semanas cuando empecé una reflexión sobre que tan rígidos somos (o debemos ser) al intentar aplicar metodologías agiles, y todo empezó con este dialogo con un amigo que trabaja fuera de Perú:
Amigo: tudo bem?
Yo: tranqui…tratando de introducir Scrum por aqui…
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio…. y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y… usan planning poker para estimar?
Amigo: no idea….
hay jefes de proyecto en varios niveles….no se como hacen sus pronosticos del tiempo.
Yo: pero … hacen retrospectivas?

Amigo: no tengo vision global

Yo: me refiero, retrospectivas a nivel de equipo
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm…. entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno… antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso… todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible….o como lo quieras llamar, para un purista, no aplica
Yo: pero… alguna vez el equipo hizo retrospectiva? veamos… hay cosas en q si puedes ceder y cosas en que no…las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de “nada interrumpe” al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace… eran del jp con el cliente, ahora… tu puedes indicar cuanto t puede tomar….y en base a eso el jp… trata de decir si va o no va… o si va, cuanto les va a costar.
Yo: veamos…. se negocia el orden del backlog y siempre hay repriorizaciones…
Amigo: para eso esta el jp
Yo: veamos… tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo… pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace…etc
el jp, del jp de desarrollo, seria el scrumMaster… mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint… este permanece inamobible?
Amigo: todo depende del jp de desarrollo….el evalua en que casos se pueden hacer cambios
Yo: uhmm… los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio….
Amigo: no hay nada q hacer…. q eres un purista

Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.

Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar “Scrum” en un proyecto:

  1. Queda bien de cara al mercado decir que se usa
  2. Hay una necesidad de mejorar la manera de hacer software (problemas de tiempos, alcance, calidad o todo junto)
  3. Se escucho en alguna conferencia y se decidió ir por ello, o algún “guru” que paso por ahí lo recomendó
  4. Se desea mejorar la organización y se pensó que Scrum seria un buen componente dentro de ese proceso

No conozco mas detalles, pero si bien cualquiera de esas razones puede llevar a la situación planteada, solo las “pares” dan un punto de partida razonable, pero aun así son incompletas si no tienen como base el asumir la “filosofía” detrás del Manifiesto Agil, y se paso directamente a querer implementar la “metodologia” y luego a “adaptarla”.

Adaptar… interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba “uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización”, lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de “equipos autoorganizados” o “propiedad colectiva” del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.

Como es evidente, poco de eso ha sido tomado en cuenta en esta implementación de Scrum, quedando solo las iteraciones, pero lo peor es que no ha sido asimilado por el Equipo, el cual puede llegar a ver todo lo demás como “purista”, y si, caer en el purismo a rajatabla es un riesgo, por lo cual hay cosas que se pueden ajustar en cierto punto como el mapeo de roles a algo mas cercano a la realidad organizacional,

Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos… Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo… lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar “baby steps” como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.

Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de “nada interrumpe el  Sprint”.

Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo “compre” la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible…. lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara “scrum flexible”.

La nefasta obsesión por “entregar valor al cliente”

Y uno al leer el título podría pensar que se esta incurriendo en un desprecio hacia el cliente que nos ha encargado el desarrollo de un software, pero nada más lejos de la realidad, la reflexión viene a algo que aun sigue siendo mal entendido por quienes estamos involucrados en el desarrollo de software.

No cuento nada nuevo que tradicionalmente (modelo “cascada”) el desarrollo de software tiene un historial de fracasos totales o parciales, ya sea en funcionalidad incompleta, sobrecostos de tiempo y dinero, lo cual lleva como consecuencia en que los aun medianamente exitosos tengan la presión por conseguir entregar “lo que se pide” “a tiempo”, y claro muchas veces sin importar el “cómo” que es a lo que nos lleva el título de este post, el cómo la obsesión por entregar algo que el cliente pueda usar hace que se pierda la perspectiva global del problema.

Y el problema (deuda técnica) ya es conocido: métodos de más de 400 líneas de código, código muerto y/o duplicado, lo cual deriva en poca mantenibilidad, bugs como consecuencia de la extensión de la funcionalidad, pobre performance, etc; síntomas que hacen que el que hereda un código desee ir corriendo tras el que hizo el código originalmente, (y un cliente pagando resignado los costos de implementar un parche o una mejora menor).

En este punto se nos podría decir que esto ocurre porque el equipo de desarrollo no aplicó un buen patrón de diseño, que no siguió los principios S.O.L.I.D., lo cual si bien tiene algo de cierto no es sino la segunda capa de un problema mayor que veremos en breve.

Se pensaría que con la irrupción de las metodologías ágiles la situación ha estado cambiando, pero no, la realidad no es tan hermosa, pues si bien ahora tenemos más visibilidad sobre los elementos (historias de usuario) que se están desarrollando no debemos de olvidar que las metodologías imponen un proceso de priorización, en el cual lamentablemente las historias funcionales (si, las que “dan valor”) toman precedencia siempre sobre las técnicas, las cuales tienen que rogar para hacerse un lugar en el sprint o en el flujo del Kanban, y muchas veces nunca logran entrar por la sencilla razón de que “no hay como justificar ante el cliente algo que no se ve que le reporte valor”. Así pues, se cumple con la entrega de funcionalidad continuamente, pero seguimos acumulando deuda técnica pues, a pesar de seguir perfectamente el proceso, sólo nos estamos enfocando en entregar un software que funcione sin fijarnos en qué es lo que hay detrás de este software que se entregó perfectamente en plazos pues lo importante es que funcione, ¿no? ¿qué hay deuda técnica? tranquilos, eso lo solucionamos con una refactorización circunstancial (léase: arreglamos cuando podamos y no nos quite mucho tiempo).

Recomiendo leer este interesante articulo de Lucas Ontivero donde nos cuenta como las cosas han seguido yendo mal en el lado técnico a pesar del agilísimo.

Adicionalmente tenemos el factor del QA (Quality Assurance), uno podría creer que en empresas grandes este equipo tendría una visión integral de la calidad del producto, lo cual debería incluir tanto la verificación de la mantenibilidad y calidad del código como de la validación de la arquitectura, pero no, al parecer su visión va sólo al lado funcional, o sea a lo “visible” del gráfico anterior, siendo que temas como la mantenibilidad “lo ve el equipo de desarrollo”, así pues por un lado se exige un cumplimiento funcional (muchas veces sin entender las razones por las que “la gente de desarrollo” opto por implementar de una manera diferente a como QA lo pensaba) estricto pero por otro lado se omite la validación de la calidad de lo técnico, pues claro… no es lo que ve el cliente de manera directa, por más que este sea el que luego tenga que pagar los “intereses” de la deuda técnica(*). No se ustedes pero si un equipo que se supone se encarga de la “calidad” durante el ciclo de desarrollo ignora la parte técnica de la implementación (¿alguien dijo auditorías?) , le esta haciendo un flaco favor al proyecto y al cliente.

Así pues mucho del problema viene dado por la importancia que se le quiere dar al elemento técnico del proyecto, el cual viene tradicionalmente es relegado por debajo del administrativo, siendo que muchos profesionales hacen gala de haber tocado muy poco los elementos correspondientes a la programación en su formación profesional, lo cual en mi opinión generalmente (he conocido excepciones) ocasiona que no se sepa (debido a que a veces no se entiende) el impacto de una decisión técnica que se tome en cualquier etapa del desarrollo, razón por la cual prime el componente funcional/visible a la hora de definir prioridades en el desarrollo.

Afortunadamente hay caminos de solución, uno de ellos es tratar de entender qué es lo que ha derivado en la creación del Manifesto for Software Craftsmanship como una evolución del Manifiesto Agile (esto lo explica muy bien Edson en esta presentación); y por otro lado, dentro del marco de las metodologías ágiles, reconocer de manera visible el rol que deben de jugar los componentes técnicos, en ese sentido me sorprendió muy gratamente como en su reciente conferencia “Lean from the Trenches” Henrik Kniberg indicó claramente cómo dentro de su proceso ágil (basado en Kanban) había reservado, dentro de su tablero, el espacio necesario para las historias técnicas, de esta manera

Es que como Henrik dijo, en un mundo ideal sólo habría historias de negocio, pero no estamos en un mundo ideal, los problemas técnicos existen y no podemos pretender seguir ignorándolos, o creer ingenuamente que efectivamente lo “solucionaremos después”, o ya en el lado extremo seguir en la ilusión de que cualquier programador podrá implementar algo si le damos una especificación funcional completa y detallada.

Entonces, regresando al título de este post, creo que debe de quedar claro que no es que no tengamos como meta el entregar funcionalidad y software, sino también validar el cómo llegamos a ese entregable, procurando (entre otras cosas):

  • Dar el espacio a las historias técnicas cuando corresponda, y no relegándolas a cuando “haya tiempo”.
  • Sospechar del programador que defiende una mala implementación con un “pero funciona”.
  • Ser consciente de los riesgos que significa ir por el camino rápido en aras de entregar la funcionalidad pedida.
  • Que todo el equipo (y no sólo el que implementa) sea consciente de lo que hay en la implementación (arquitectura, algoritmos, etc) y de como eso condiciona los tiempos de desarrollo, especialmente cuando se trata de agregar una nueva funcionalidad.
  • Valorar el factor técnico, procurar la mejora de las habilidades técnicas de los desarrolladores: mentorship, revisión por pares, dojos, etc.

Claro que mucho de esto tendría que ir de la mano con un reconocimiento dentro de las organizaciones al rol que juegan las TI en su crecimiento como negocio, pero por ese lado la cosa esta bien complicada.

(*) Se entiende como “intereses” de la deuda técnica al hecho de que conforme pasa el tiempo será más difícil corregir las malas decisiones o malas implementaciones de código, ya sea porque el desarrollador que implementó algo de manera críptica ya no se encuentra en el equipo, porque nueva funcionalidad superpuesta generó más dependencias o simplemente porque por el tiempo que pasó ya es más difícil acordarse el porque se tomó esa decisión que “parecía buena en su momento”.

TFS con Kanban….ahora se podra


Durante un tiempo he estado siguiendo entusiastamente las metodologias agiles, y recientemente he practicado algo de Kanban, y si bien me han terminado gustando algunos de sus enfoques me he sentido frustrado por la impedancia entre el hecho de que el backlog se manejara por un lado usando un Excel y por otro la visibilidad de las tareas en progreso (WIP: Work in progress)unicamente mediante postit’s en la pizarra.

Si a esto le sumas el hecho de que el TFS solo se usa como repositorio de código fuente y no como la herramienta de ALM que es la decepción es mayor, pero en este caso se puede entender los reparos si es que no se incluye de entrada un soporte para el modelo Kanban, como si que lo incluye para CMMI y SCRUM.

Al parecer esto va a cambiar pues gracias a Ulises me vengo a enterar de que en CodePlex los Visual Studio ALM Rangers estan desarrollando la Practical Kanban Guidance con Team Foundation Server y Visual Studio, dentro de este proyecto (para TFS 2010 y el inminente TFS 2012) se incluye la nueva plantilla Microsoft Kanban 1.0 Process Template así que con esto se abre un nuevo capitulo para consolidar el uso de TFS en las diversas metodologías ágiles, tratando de demostrar que su uso incrementa (y no reduce) el ancho de banda en la comunicación del equipo.

Queda ver si es posible usarlo desde la nube via TFS Preview

Finde Agil con Windows 7

Como ya habia comentado nuestro amigo blogger (y MVP!) El Bruno fue elegido para ser anfitrion de una de las fiestas de lanzamiento de Windows 7, asi que el dia elegido fue el pasado viernes 23, el lugar… su nuevo piso alla cerca al final de la Linea 3 del Metro Ligero.

La gracia de estas fiestas es que Microsoft envia al anfitrion una caja con diversos accesorios para la fiesta:

Se sabia que en otras cajas se enviaron globos y vasos o posavasos, en este caso lo que hubo fueron servilletas, y otras cosas como este poster que muestra Bruno:

Pero claro, el componente estrella del envio es el Windows 7 Steve Ballmer Edition, lo cual como podemos ver no era ninguna leyenda urbana:

Invitados sorprendidos por lo que envia Microsoft:

Bolsas de recuerdo:

Bruno no dejo la ocasion de mostrarnos el fierro que hasta hace poco tenia online a Elbruno.com el cual temporalmente se encuentra en alojado en Geeks.ms

En fin, una simpatica reunion, con mucho frikismo y conversa medio tecnica donde solo falto una instalacion de Windows 7, la cual espero acometer en una semana luego de haberla probado en maquinas virtuales. Mil gracias a Bruno y familia por la hospitalidad de esa noche…. ahhh y visiten su blog, claro esta.

Lamentablemente tuve que irme temprano (12:30 + viaje de hora y media) pues el sabado me tenia que ir al Agile Open Spain 2009 en la Escuela Universitaria de Informatica de la Universidad Politectnica de Madrid, como le he estado cogiendo interes al tema de las metodologias agiles y especialmente a SCRUM, era para mis imprescindible tener que ir.

Por razones de la fiesta ya comentada, no pude asistir a la reunion preparatoria del viernes, pues no se trataba de la usual serie de conferencias decididas “desde arriba”, no, es viernes sirvio para que se propusieran ideas para sesiones y que los propios participantes eligieran cuales se realizarian… o no, el resultado lo podemos ver en la siguiente foto, este panel sirvio ademas como guia para saber a que sesion ir:

Mi interes se orientaba a ver el tema Agil dentro de las organizaciones y asi como las reticencias al cambio, en ese sentido las sesiones de Jorge Uriarte (“CMMI & Agile”) y Angel Medinilla (“Es muy dificil”) fueron muy utiles ya que la experiencia comentada por los diversos asistentes dieron muchas pistas sobre como introducir procesos agiles y como vencer la resistencia de las organizaciones, aun en las que se han metido en procesos CMMI, ya que Agile y CMMI no son totalmente incompatibles (a pesar de algunas dificultades), pero siempre y cuando la adopcion de una certificacion venga dada por el interes de mejorar los procesos y no solo porque quede bien de cara al mercado tener dicho estatus, situacion ultima que parece no es nada rara de cara a lo dicho en las sesiones.

Correspondio a Leo Antoli el dirigir la sesion “Ser cliente no es facil”, donde se pudo ver ambas caras de la moneda, de clientes que no son capaces de encontrar proveedores confiables que hagan uso de practicas agiles, y por otro lado proveedores agiles que se ven enfrentados a pliegos “cerrados” o desconfianza del responsable de aprobacion de compras. El camino de conciliacion es duro, pero es posible y se basa sobre todo en generar confianza y luego flexibilidad buscando nuevas formas de contratacion que vayan mas alla del pliego cerrado.

Llegados a este punto debo indicar que como se ve habia 4 sesiones en simultaneo, y que la sesiones mas que una conferencia tenian el formato de debate dirigido, lo cual ayudo mucho a compartir experiencias, el problema viene dado cuando una sesion tiene demasiados asistentes por lo que algunas personas se quedaron paradas, y no fue tan posible promover la participacion.

Luego del almuerzo, asisti a la charla dedicada a kanban metodologia que entra con la controversia de que seria lo que reemplace a Scrum, la charla de Xavier Quesada logro el objetivo de dejarnos con la curiosidad y cuestionamientos a esta propuesta, por lo que le dedicare un post aparte.

Y para terminar tocaba una sesion sobre offshore y proyectos internacionales, tema que vista mi experiencia africana no dejaba de serme de particular interes, nuevamente tuvimos a Angel Medinilla como moderador invitando a quienes habiamos tenido experiencia con esta clase de proyectos a contar lo mas relevante de estas experiencias, la conclusion es que hay factores adicionales que se tienen que tener en cuenta para esta clase de proyectos, ser consciente de ellos y que los problemas usuales (malas especificaciones, retrasos, etc) de un proyecto “normal” tambien pueden aparecer por lo que se debe de tener cuidado de que los costes ocultos no se terminen comiendo los supuestos ahorros; una cosa que Angel se cuido de hacernos recordar es que se debe dedicar un tiempo al arranque del proyecto desde el punto de vista de las comunicaciones: tecnologia, horarios, facilidades, “protocolo”, es que ya luego en marcha es peor.

En resumen, una excelente jornada, un formato agil (aunque suene redundante) que ha motivado a quienes asistimos a seguir investigando y a difundir estas formas de trabajar, a ver si esto continua.