post-it-gente4-scrum-lima-bbva-1920x0-c-f

Empresa ágil: ¿Cómo construimos el caso de negocio?

Hace unas semanas, un cliente que deseaba impulsar la transformación organizacional en su empresa (un banco de los tres más importantes de su país), nos dijo que necesitaba un “caso de negocio” para respaldar su propuesta ante el directorio.

No es simple establecer un caso de negocio haciendo cálculos sobre resultados que requieren, en la mayor parte de los casos, cambios culturales en la empresa. De todas maneras podemos recorrer algunas observaciones de los últimos tiempos en los que tuve la oportunidad de trabajar en entornos C-Level de grandes empresas.

La intención de este artículo es exponer algunos escenarios que ustedes puedan identificar en las organizaciones en las que trabajan para que puedan sustentar el caso de negocio de una iniciativa de cambio.

Escenario 1: Acumulación de iniciativas

Las áreas de tecnología de las grandes organizaciones, gradualmente y sin notarlo, suelen acumular iniciativas en curso que avanzan en paralelo durante meses o años. Todos ellos necesarios, sin duda.

Estos proyectos ocupan cada vez más capacidad de trabajo de ingenieros, equipos de operaciones, responsables de producto, proveedores, etc. por lo que cada vez queda menos capacidad para el resto de los proyectos, aunque sean de la mayor importancia estratégica. Solo les queda una cada vez más limitada capacidad remanente.

Una empresa que compita en un mercado nacional, regional o mundial debe seleccionar cuidadosamente los proyectos en los que se embarca (sean de tecnología o de negocio) haciendo todo lo posible por segmentarlos de manera que pueda cambiar prioridades en plazos cortos y con resultados intermedios tangibles.

Esto puede parecer una tarea imposible al principio, incluso podemos pensar que hay proyectos que no lo permiten, que los tiempos de proveedores son distintos, etc. Definitivamente no puede cambiarse esa situación de un día para el siguiente, sin embargo esto no es necesario. Solo se requiere que establezcamos como política que no comencemos nuevos proyectos que tomen, por ejemplo, más de tres meses. Si una iniciativa requiere una año, puede completarse en 4 o 5 proyectos.

Podríamos debatir: ¿Cuánto dinero nos cuesta la reacción lenta a las alternativas que nos propone el mercado? ¿Cómo estaríamos en relación a la competencia si fuésemos más rápidos que ellos en reaccionar?

Escenario 2: Silos

Comienzo con un ejemplo a pequeña escala: un responsable de realizar pruebas en software como parte del proceso de desarrollo me dijo que no daba feedback rápido, “en el momento”, al equipo de desarrollo porque tenía que documentar los defectos de la iteración anterior y eso le tomaba mucho tiempo, lo cual no era extraño puesto que el 100% de las entregas requería de feedback y ajustes.

Este es un ejemplo de lo que se llaman silos, es decir, distintas áreas de una organización en las cuales se concentra el conocimiento en un tópico determinado. El trabajo pasa de un área a otra para que cada uno haga lo suyo y siga en la cadena o que vuelva a la etapa anterior (o varios pasos atrás) en caso de que algo no fuese correcto, siempre acompañado del “documento de defectos”.

Los silos se conforman en las organizaciones que no analizar el proceso de trabajo en forma sistémica, es decir, buscando también optimizar la cadena de valor completa.

Las organizaciones maduras (finanzas, salud, seguros, etc) que están siendo pioneras en la adopción de nuevos esquemas de trabajo o de exploración de nuevos campos, optan por conformar equipos independientes y autónomos de manera que el equipo esté conformado con la suficiente diversidad de habilidades que permita llevar completamente a la práctica la idea y evaluar los resultados.

Un ejemplo son los equipos quirúrgicos estables, donde los instrumentadores, anestesistas, cirujanos e, incluso, psicólogos trabajan con un profundo conocimiento producto de años de experiencia conjunta. Hay muchos más.

Para más información sobre este tópico sugiero consultar el modelo Tukman y el trabajo de Patrick Lencioni.

Esta visión no es específica de la cirugía, de las estrategias militares, de equipos deportivos. Por ejemplo, en la industria fintech es usual tener equipos verticales para iniciativas innovadoras o estratégicas.

Podríamos debatir: ¿Cuántas oportunidades de mejora no vemos porque no están todos las personas correctas en la mesa de diseño de un producto? ¿Cuánto dinero ahorraríamos aprovechando estas oportunidades?

Escenario 3: Mejora continua (sistémica)

Continúo con con otra mirada sobre el mismo escenario anterior (Silos).

La conversación comenzó con una consulta para optimizar el proceso de reporte de los defectos en el software pues el mecanismo que estaban utilizando les tomaba mucho tiempo y esfuerzo. Requería documentar y reproducir las condiciones del defecto, captura de pantallas, confección de un documento, crear un incidente en la herramienta utilizada, adjuntar la evidencia, etc.

Investigando un poco sobre el para qué de estos artefactos, llegamos a la conclusión de que eran requeridos para la comunicación entre las dos áreas. El equipo responsable de las pruebas deseaba, genuinamente, mejorar su proceso de trabajo.

Nuevas opciones aparecen en escena cuando analizamos el problema sistémicamente, es decir, con una visión más amplia del proceso completo. En ese caso directamente eliminamos toda la tarea cambiando el mecanismo de feedback por un enfoque just-in-time por el cual la persona daba la mayoría del feedback ante consultas del desarrollador.

Un proceso de mejora continua eficaz debe tomar en cuenta, alternativamente, la versión sistémica y la local, con esta última subordinada a la sistémica.

Una de las formas de visualizar nuestro proceso (al menos la parte del sistema que está a nuestro alcance influir) es construir un value stream map. Esta visualización nos permitirá conversaciones arribar a optimizaciones globales, que no veríamos mirando solo a los subsistemas locales.

Podríamos debatir: ¿Cuánto mejor funcionará la organización si prestamos atención al proceso completo? ¿Son todos los pasos que hoy existen necesarios? ¿Cuánto dinero ahorraríamos aprovechando estas optimizaciones sistémicas?

Conclusión

Espero haber presentado algunos escenarios que pueden resultarles familiares y, por tanto, funcionar como punto de partida de conversaciones y debates.

Estoy convencido de que los marcos de trabajo ágiles o lean no sólo propician ambientes más humanos, sino también más eficaces y eficientes, desde el punto de vista de la productividad , calidad y son más adaptables (una capacidad que las empresas de hoy en día no pueden dejar de lado).

Incluso abrigo la esperanza de que estos tres modestos casos presentados les disparen muchos más, algunos específicos, otros más generales. Ojalá los muevan a generar espacios más humanos y asombrosos en las grandes organizaciones.

¡Nos vemos!

La imágen del encabezado la tomé de este post, que recomiendo leer, en relación al tema del artículo.

¿Funciona la mentalidad ágil en las grandes empresas?

Es probable que te hayas hecho esa pregunta si estás siendo parte de un proceso de cambio hacia las metodologías ágiles (o si estás decidiendo si lo intentas).

En nuestro trabajo como coaches ágiles, encontramos empresas que – luego de varios meses de trabajar arduamente en la adopción de metodologías ágiles – logran resultados en el ámbito de los equipos, aunque no muy contundentes. Incluso hemos observado mejoras importantes las cuales, luego de un tiempo, se estancan o pierden impulso.

¿A qué se debe esto? ¿A todos les pasa lo mismo? ¿Cuáles son las causas raíz?

En este artículo exploramos algunas de las posibles causas y compartimos ideas para que explores junto con tu equipo. Les adelanto los títulos:

  • No estamos implementando una metodología
  • ¿Alguien dijo “cambio”?
  • ¿Funcionará cuando se vayan los coaches ágiles?
  • La falta de calidad puede derrumbar al mejor proyecto

No estamos implementando una metodología

Hemos visto muchos proyectos de cambio hacia formas más ágiles de trabajo enfocados como una implementación en fases de una metodología. Usualmente el criterio de éxito en esos casos se relaciona con implementar Scrum en una cierta cantidad de equipos, en conseguir certificaciones, etc.

Incorporar una metodología ágil no debería ser el objetivo (mucho menos la métrica de resultado). El objetivo debería ser mejorar los resultados de la empresa, ser más eficientes y mejorar la calidad (en otras palabras, objetivos relacionados con el negocio).

Un síntoma que podemos observar cuando se da esta confusión entre medios y fines es la generación de una tensión entre el mundo ágil y el mundo no ágil dentro de la empresa. Esto expresa que no se están realizando ofrecimientos de apoyo para lograr mejores resultados sino que se está presentando una nueva forma de hacer las cosas que pretende reemplazar a la anterior.

Este enfoque:

  • provoca resistencias, ya que las personas lo sienten como un cambio que se les impone. Si en su lugar se les ofreciera una solución a sus problemas concretos, ellos mismos estarían dispuestos a incorporar las nuevas prácticas y…
  • es ineficiente, dado que pretende reemplazar todo, sin distinguir lo que funciona satisfactoriamente (y se podría conservar) de aquello que no.

En cambio, si nos enfocamos y definimos métricas de resultado, serán estos los que promuevan el interés del negocio y habiliten la expansión de la iniciativa.

Puedes probar con pequeños cambios en los procesos diseñados y puestos en práctica por la persona que los vive. Decidir acciones basándonos en intereses en lugar de posiciones también es un habilitador muy efectivo. También podemos enfocar el proceso desde la visión Improvement Kata (en Inglés) o puedes ver un video de 15 minutos aquí, en español, siempre partiendo de la condición actual hacia una nueva situación objetivo.

¿Alguien dijo “cambio”?

La gestión del cambio tiene cada vez más lugar en las iniciativas de transformación, y nos seguirá acompañando mientras nuestras culturas estén más preparadas para repetir que para crear aprendiendo. Esto último sucederá a medida que el mindset ágil se vuelva el predominante, pero mientras tanto deberemos acompañar y facilitar estos procesos.

Si una transformación no está incorporando la gestión del cambio, o no lo está haciendo de la manera adecuada, es probable que se manifiesten resistencias o bien que los esfuerzos que se realizan tengan baja efectividad. Estos hechos suelen pasar inadvertidos hasta que por su propio peso deriven en el fin de la iniciativa.

Un diferencial importante de la mentalidad ágil es que sus marcos de trabajo, valores y principios han sido pensados para abrazar el cambio.

Algunos marcos específicos son Open Agile Adoption y Lean Change Management, donde se combinan el modelo iterativo-incremental, la experimentación y el aprendizaje emergente para acompañar y potenciar los procesos de transformación.

¿Funcionará cuando se vayan los coaches ágiles?

Si se han producido cambios, obtenido resultados tangibles y ha cambiado en cierto modo el clima en la empresa ¿Quién garantiza que esos logros persistan y mejoren cuando el apoyo de los coaches disminuye?

Algo similar ocurre cuando los primeros proyectos piloto han arrojado resultados prometedores. ¿Cómo extendemos esta iniciativa el resto de los equipos? ¿Y al resto de la empresa?

Como otros cambios estratégicos, los proyectos de transformación organizacional deben ser liderados por equipos internos en la empresa. En el caso de que hubiera coaches contratados para acompañar la transformación, parte del trabajo de estos coaches debe ser el desarrollo del equipo interno, de manera que puedan continuar en el tiempo y en el resto de la empresa.

La falta de calidad puede derrumbar al mejor proyecto

Muchos equipos sacrifican calidad, casi sin darse cuenta, en pos de resultados más rápidos. Este escenario se conoce  como deuda técnica, que más temprano que tarde, cobra sus intereses.

Pensemos, por caso, en una empresa que brinda servicios de transporte. En ese caso hipotético, la calidad podría verse en el mantenimiento de sus vehículos, en unidades de pocos años de uso, en capacitación de los conductores o en el mantenimiento preventivo.

Es relativamente simple asociar pérdidas cada vez mayores por costos inesperados en el negocio, debido a la falta de atención de estos aspectos. Incluso pueden llevar a la empresa a la pérdida de posición en el mercado.

Otro ejemplo relacionado con el desarrollo de productos de software en donde la deuda técnica se manifiesta en productos difíciles de modificar confiablemente, tiempos de desarrollo cada vez más largos, numerosos defectos en las entregas, etc.

Dependiendo de la naturaleza del producto o servicio que desarrolle la empresa en la que trabajas, las técnicas de mejora y aseguramiento de calidad serán distintas y específicas. Sugerimos revisarlo con los expertos en tu organización.

En el caso del desarrollo de software, Extreme Programming (XP) integra una serie de técnicas (que evolucionan en el tiempo y varían según el contexto), siempre apoyando principios clave como flexibilidad, simpleza, feedback frecuente y otros.

¿Qué puedo hacer yo? Aportando a la transformación

La anterior fue una lista resumida de algunas causas que observamos frecuentemente como frenos a las transformaciones hacia la agilidad. Si en tu contexto notas que se manifiestan éstas u otras causas para que la iniciativa no avance, te invitamos a que busques a las personas interesadas en mejorar esa situación y lo compartas con ellas.

Finalmente, la respuesta la pregunta planteada en el título del artículo es: Si, funciona, siempre y cuando enfoquemos el cambio como equipo, basándonos en las personas y sus interacciones.

 

Agradecimientos

Quiero agradecer a Natalia Davidovich, Rodrigo Monelos y al resto de los revisores en equipo de Kleer con los que trabajo en transformación organizacional.

Las dos estimaciones

En las últimas semanas tuve la oportunidad de colaborar con un cliente en la adopción de metodologías ágiles en un proyecto corporativo de reemplazo de las aplicaciones centrales del negocio (core).

El equipo del proyecto (unas 60 personas entre desarrolladores, responsables de producto y representantes del negocio) estará trabajando los próximos tres años en la construcción y puesta en producción escalonada (afortunadamente no optaron por un big bang).

Quiero compartirles en esta entrada un aprendizaje respecto de la estimaciones necesarias en este tipo de proyectos.

¿Que pasó desde que escribí esta entrada?  (en el orden en que me llegaron estas noticias)

  • Jason Gorman escribió una entrada  el 1 de Agosto que creo explora ideas similares.
  • El genio de Martín Salías me cuestionó en privado algunas cosillas, luego debatimos un poco y llegamos a la conclusión de que estábamos más o menos de acuerdo y clarificaría algunos puntos.
  • El otro genio de Steve McConnell, que de estimaciones escribió bastante, publica un video el 30 de Julio.
  • Ron Jeffries lo responde al día siguiente, el 31 de Julio con una entrada.
  • Steve McConnell escribe una entrada en su blog, el mismo día.
  • Ron Jeffries responde, a su vez, con otra entrada.

Primera estimación: la factibilidad

Todo proyecto corporativo del rango de varios millones de dólares está sujeto a muchas decisiones estratégicas de mediano y largo plazo. El dinero no crece en los árboles y el comité ejecutivo debe tomar riesgos, debe decidir donde invierte entre muchas otras opciones igualmente importantes.

Los equipos de tecnología deben comprender y empatizar con estos riesgos si queremos una industria sana, no se trata de dos bandos, de un campo de batalla donde abunda la desconfianza mutua y, por ende, triunfa la baja productividad y el desperdicio de dinero, tiempo y motivación.

En esta etapa, la estimación de esfuerzo tiene técnicas y fines específicos, que son los de determinar la factibilidad del proyecto con base en la estimación de plazos y costos. No es extraño en estos casos encontrar fechas de finalización que, a primera vista, parecen arbitrarias.

En uno de los debates en este cliente, intentando acercar la visión del comité ejecutivo a la de los equipos de desarrollo, utilicé dos metáforas.

La primera fue la de la entrega para la temporada de ventas, por ejemplo, Navidad. Hay factores más importante que la estimación de esfuerzo en este caso, el proyecto debe estar terminado para el 15 de Diciembre, dos o tres días mas lo harían inviable.

Otra de las metáforas fue la de construcción de un edificio (¡cuando no este paralelismo!), imaginemos que estamos construyendo un edificio de 20 pisos que tiene fecha límite de inspección, luego de la cual ¡nunca podrá ser aprobado! En este caso, no hay nada más importante que esa fecha, si no termina a tiempo, de nada sirve todo el esfuerzo.

Resumen: El objetivo de la estimación en esta etapa es determinar la factibilidad del proyecto. Debemos tomar en cuenta aspectos técnicos, de arquitectura, tiempos de interacción, etc. Dentro de los parámetros de factibilidad es normal llegar a fechas de entrega y a presupuestos exactos e inamovibles, al menos en el comienzo del proyecto (* ver nota al final).

Resto de las estimaciones: el mejor producto posible

Finalmente el proyecto comienza y el equipo tiene tres años por delante para reemplazar un core de negocio, frente a un mar de incertezas y con fecha fija de entrega. Pocas situaciones me parecen más aterrorizantes en el mundo del trabajo, incluso como consultor o coach, donde podría decirse que “lo vemos desde afuera”.

En esta etapa las estimaciones tienen otro fin completamente distinto. En esta etapa el foco debe estar en llegar al plazo indicado con el mejor producto posible. Para llegar a ese objetivo el responsable de producto debe priorizar, debe decidir que funcionalidades incluye y cuales no incluye. También debe decidir como se implementan las funcionalidades incluidas.

Para todo esto, el responsable del producto necesita visibilidad del avance del proyecto (para entender que es lo que ya está terminado) y visibilidad de las posibilidades desarrollo futuro. El equipo es responsable de brindar esta información con claridad y transparencia.

Con respecto a las funcionalidades terminadas, no deben requerir ningún tipo de trabajo adicional (ya fue desarrollado, el representante del usuario final lo aprobó, ya tiene el proceso de despliegue automatizado y probado en entornos similares a producción e, idealmente, ya esta en uso en producción). Lo que se dice, terminado-terminado.

Con respecto a las posibilidades de desarrollo futuro, el equipo debe garantizar las prácticas técnicas y de equipo para que la productividad sea sostenible (prueba automatizada, código simple, etc).

Por último, el equipo debe mantener actualizadas las estimaciones de todo lo que resta desarrollar (con nivel de detalle acorde a la posición en el backlog, lo de la cima con detalle, lo de abajo, con poco detalle) de manera que el responsable de producto tenga visibilidad sobre el avance del proyecto según el plan.

En el ejemplo de la construcción del edificio de 20 pisos que mencioné en el apartado anterior, puede implicar que el responsable de proyecto decida que prefiere no terminar uno de los pisos para llegar al plazo, es mejor un edificio con 19 pisos aprobados que uno con 20 pisos que nunca podrán ser habitados (creo que es por este motivo que muchos edificios no tiene piso 13).

Resumen: El objetivo de la estimación en esta etapa es brindar información confiable al responsable de producto para priorizar las funcionalidades a incluir (y cuales excluir, sobre todo) en el proyecto, para finalizar con el mejor producto posible.

(*) Nota: ¿Son fijos los plazos y presupuestos?

No debemos olvidar que los proyectos de desarrollo de tecnología en organizaciones que se basan fuertemente en ella son inversión. Lo que puede ser fijo e inamovible ahora, cuando el proyecto comienza (con todos los riesgos) puede ser mas flexible si el proyecto demuestra que los riesgos fueron controlados y el proyecto marcha bien, está en manos del equipo de desarrollo.

Agile-Spain Open Space 2015

Foto de cierre del AOS2015

Esta semana, que termina cuanto toco tierra en Buenos Aires, he viajado más que en cualquier otra, visitado muchas culturas: canarios, madrileños, sevillanos, y asturianos.

Todo esto valió la pena pues he tenido, en el AOS2015, una inmersión de primera mano en la comunidad ágil española, vibrante y reflexiva, amable y combativa, liberal y conservadora. Única.

Las sesiones fueron muy variadas en cuanto a profundidad como en temas. Afortunadamente hubo muchas sesiones introductorias que de seguro fueron de utilidad para las personas que se acercan por primera vez a la comunidad.

Hubo tanto temas técnicos (prácticas y herramientas relacionadas con Extreme Programming) como temas relacionadas con las metodologías y marcos de trabajo. Tampoco quedaron fuera temas relacionados con las personas y las culturas organizacionales y hasta sobre la ética.

En un párrafo especial quiero mencionar una sesión sobre la importancia del aprendizaje (tema sobre el cual he visto muchas sesiones). En esta sesión se presentaron dos proyectos en funcionamiento:  y . Pueden ver aquí la documentación visual que hice durante la sesión. Les dejo una documentación visual que hice sobre la sesión:

Mi documentación de la sesión

Como siempre en este tipo de eventos tan humanos y motivantes, salí con muchas ideas nuevas y mas amigos y colegas.

Una especial mención al equipo de organizadores, estoy seguro de que todavía están durmiendo, desde el sábado por la noche.

¡El equipo!

Por último, la próxima edición sera en Santiago de Compostela, Galicia ¡por si acaso pensaban que la comida no podía mejorar!

Espero nos veamos pronto. Gracias a todos.

Continuous Integration Fest en Medellín.

IMG_20141115_120236209El sábado 15 de Noviembre, con el apoyo de Ágiles Colombia, facilité una reunión en Eafit, en Medellín, cuya intención fue acercar las herramientas de integración continua a los desarrolladores que aún no las habían utilizado, al menos configurándolas con sus propias manos.

Los resultados, para mí, fueron asombrosos. Todos los equipos (en general de dos personas cada uno) lograron poner en marcha Jenkins, conectarlo con los repositorios, algunos públicos otros privados, algunos TFS, otros Subversion, otros Git y configurar su primer “build” automatizado.

No fue obstáculo que algunos trabajaran en .NET, otros en Java, en PHP y otros en Scala. Aquellos que trabajaban en PHP se ocuparon de entender como realizar Smoke Tests (con el HTTPRequest plugin) sobre el sitio y compartieron ese conocimiento con otros.

Todo esto con muy poca colaboración de mi parte, la mayor parte del tiempo la dediqué a musicalizar con vallenatos y Beatles.

Pueden escuchar los comentarios directamente desde los protagonistas en el video que encontrarán en este álbum.

¡Un saludo!

Mis motivaciones con TDD y ATDD

Cuando pienso en (A)TDD me vienen a la cabeza dos cosas: simplicidad y reducción del desperdicio, dos cosas que son, en mi opinión, dos caras de la misma moneda.

El diseño de software, no importa como se lo mire, es un proceso complejo. El diseño, no importa de que cosa, es un proceso complejo. Nuestro cerebro no es capaz de evaluar todas las variables o grados de libertad en abstracto, como hacen los buenos jugadores de ajedrez tomando en cuenta muchas jugadas hacia adelante.

Es por esto que necesitamos concretar, eliminar grados de libertad, probar ideas.

¿Como reduce el desperdicio (A)TDD?

Evitando dedicar tiempo a construir (y probar, depurar, mantener, etc.) cosas que no necesitamos, utilizando el proceso:

    1. analizo las necesidades
    2. pienso como resolverlas
    3. decido como probar lo que construiré, con ejemplos concretos
    4. escribo una prueba que falle para el ejemplo mas simple
    5. escribo el código mas simple posible que hace pasar la prueba
    6. aprovecho oportunidades para mejorar mi código y pruebas

Veo este proceso como una suerte de embudo que me obliga a trabajar solo en lo que necesito, por ejemplo:

    • en el paso 5 escribo solo el código necesario para pasar el test
    • en el paso 4 escribo la prueba basada en el el ejemplo concreto mas simple sin resolver
    • en el paso 3 pienso en ejemplos concretos de lo que quiero lograr (no en “posibles” necesidades abstractas)
    • en el paso 2 dedico unos minutos a pensar como resolveré las funcionalidades (no comienzo a programar ciegamente)
    • en el paso 1 dedico un tiempo a entender el contexto de lo que debo hacer

Este proceso respeta dos cuestiones transversales muy importantes: se repite en ciclos cortos y la calidad no es opcional (calidad es arquitectura, rendimiento, cumplir con estándares, documentación, etc.)

 ¿La simplicidad?

Encuentro la simplicidad en los mismos puntos anteriores pues no construyo nada que no sea necesario por un paso en el proceso que mencioné antes, sumando al combo al refactoring, esa simplificación de mis artefactos que me permita no solo sostener y mejorar el ritmo de trabajo a lo largo del proyecto.

¡Nos vemos!

Coderetreat en Buenos Aires

gdcr-1

UPDATE: Sumamos a Cinchcast como sponsor (una startup estadounidense con un equipo de 10 desarrolladores en Buenos Aires). Ya esta solucionado el almuerzo, creo que habrá sorpresas. También agradecemos a Kleer, por sus oficinas.

Este año, junto con Benjamin Eidelman (aceptamos ayuda) y Ágiles Argentina, estamos organizando, el Global Day of Coderetreat en Buenos Aires.

La experiencia anterior, en el año 2011, fué muy interesante, compartimos el día con desarrolladores de todo el mundo, desde Honolulu hasta España y Japón (150 ciudades en todo el mundo). Incluso, establecimos comunicación vía Skype con algunos de los grupos.

¿Qué ocurre en un coderetreat?

Nos reunimos desarrolladores interesados en mejorar nuestras habilidades. Practicamos la resolución de varios problemas de programación, con distintos lenguajes, distintos colegas, distintos objetivos.

¿Cómo puedo participar?

Si deseas inscribirte (¡solo 18 lugares!), por favor hazlo en el Meetup del evento. También puedes visitar la página del evento en el sitio de la comunidad mundial de Coderetreat.

Si tienes ideas o propuestas, por favor usa los comentarios de Meetup, queremos mantener centralizada y visible para todos esa información.

¡Nos vemos!

Software craftsmanship en Chile Ágil

Durante la semana pasada estuve trabajando en Santiago de Chile para dar un taller de desarrollo ágil de software.

Como siempre que visito alguna ciudad, intento participar de alguna actividad de la comunidad. En este caso, Agustín Villena, Pablo Cáceres y Chile Ágil organizaron una reunión para debatir sobre Software Craftsmanship en la Universidad de las Américas.

Comenzamos por establecer los objetivos de los presentes, es decir, que debería ocurrir en esa reunión para que cada uno se fuese satisfecho.

Esos objetivos son los post-its amarillos (claro) que verán en el video que les dejo a continuación y en el que podrán ver el resumen de la sesión, cuyo resultado queda representado por los post-its púrpura.

http://www.youtube.com/watch?v=PEyUH6QZhts

Solo me resta dejarles un abrazo y un agradecimiento a la comunidad chilena, a Pablo Cáceres por facilitar este evento y a Agustin Villena y a Philippe Camacho por su hospitalidad.

Los tres caminos

51rMT69p7rL._SY344_PJlook-inside-v2,TopRight,1,0_SH20_BO1,204,203,200_Hace un tiempo terminé de leer el libro The Phoenix Project.

El libro tiene un fantástico olor (si, huelo los libros) pero, además, me gusta mucho el estilo de novela en el cual esta escrito. Describe la situación de Parts Unlimited, una empresa en la cual las tecnologías de la información están en completo descontrol. El relato es impecable y bastante creíble, de hecho, me imagino a muchas compañías en esa misma situación.

Nuestro héroe, Bill Palmer, ayudado un misterioso amigo, va descubriendo, paso a paso la forma de mejorar la situación aplicando paralelismos creíbles. En otras palabras, llega desde una situación caótica creíble a una situación muy familiar para un agilista y lo hace mediante la descripción de los tres caminos, de eso quiero hablarles hoy.

El primer camino: flujo

Este camino se propone la visión sistémica de una gerencia, una organización completa o un individuo, enfatizando el flujo de valor en sistema completo, cuidando de que optimizaciones locales no degraden el rendimiento general.

El segundo camino: realimentación

Una vez establecida la visión sistémica es necesario habilitar la mejora continua estableciendo el mecanismo de realimentación, lo mas inmediata posible para garantizar que el flujo de valor buscado en el primer camino mejora continuamente.

El tercer camino: experimentación continua y aprendizaje

El tercer camino propone un cambio cultural basado en dos conceptos: el aprendizaje continuo habilitado por la experimentación, tomando riesgos y aprendiendo de los errores y el entendimiento de que la repetición y la práctica sostenida son imprescindibles para lograr la perfección.

¿Como aplican estos principios al desarrollo de software?

Para que este artículo no sea una mera traducción de los textos cuyos originales incluyo al pie, me gustaría hacer una breve interpretación ajustada a la construcción de software, según mi experiencia.

Logramos el flujo (el primer camino) cuando priorizamos la puesta en producción continua de funcionalidades con valor para los usuarios. También garantizamos un flujo continuo y sostenible con prácticas como TDD (Tesd Driven Development), logrando maximizar la velocidad y la calidad.

Logramos la realimentación (el segundo camino) poniendo tempranamente, en el proyecto, software en manos del usuario, con calidad de producción y en lapsos breves (una semana o, mejor aún, diariamente). ńo menos importante es la participación del cliente o usuario final en el proceso de desarrollo, en la priorización de las funcionalidades y, sobre todo, en la construcción y su validación continua.

Logramos establecer la cultura del aprendizaje continuo y la práctica sostenida (el tercer camino) mediante los conceptos de Software Crafsmanship, Coding dojos, para el caso de los equipos de desarrollo multidisciplinarios. También es destacar el rol del responsable de producto para lo cual  recomiendo enfáticamente éste video de Henrik Kniberg.

Para mas detalle, pueden revisar éste y éste texto (en inglés) y, por supuesto, el Toyota production system (inglés).

TDD no es prueba, es diseño.

En una de las últimas sesiones de coaching en la cual ayudé a un equipo a experimentar TDD, escuché una de las reacciones mas usuales ante el primer paso.

Para definir el contexto, imaginen que van a escribir la famosa kata tenis y que aun no han escrito absolutamente nada de código. Una de las posibilidades es escribir esta prueba:

[Test]
public void ShouldProvideTheScorerTitle() {
var scorer = new Scorer("Federer", "Nadal");
Assert.AreEqual("Federer vs. Nadal", scorer.Title());
}

Y una de las posibilidades para el código mas simple posible que hace pasar ese test, es:

public class Scorer {
public Scorer(string jugador1, string jugador2) {
}

public string Title() {
return "Federer vs. Nadal";
}
}

La reacciones suelen ser: ¿Por qué debemos escribir ese código tan tonto ahora? ¿Por qué no creamos directamente las variables de instancia para los nombres de los dos jugadores? ¿Qué sentido tiene devolver ese texto fijo? ¡Esa prueba no tiene sentido!

Mi respuesta usual es: No tiene sentido porque no es una prueba, es una actividad, un paso, una canal por donde fluye el diseño.

¿Qué tenemos antes de empezar? Nada concreto, solo una idea de lo que tenemos que hacer y alguna estrategia de diseño que debemos aún desarrollar, entender.

Luego del primer paso tenemos: el nombre de la clase, decidimos que pasaremos los nombres de los jugadores en el constructor, que basta con pasar los nombres como string, que usaremos un método para devolver en título y que ese método retornará un string.

Lo mas importante es que tenemos todas estas decisiones antes de escribir el código de producción, solo habiendo escrito la prueba.

¿No les parece que hemos diseñado mucho en un solo paso como para preocuparnos por detalles de implementación?

Por ejemplo, ¿es razonable que un músico se obligue a escribir música de manera que cada paso tenga sentido en la versión final? Por supuesto que no, empieza a jugar con notas y melodías (a partir de alguna idea) y luego va desarrollando, en forma iterativa la versión final.

A medida que va avanzando entiende mejor como se ajustan todos los bloques, la idea va tomando forma, va entendiendo que es lo que quiere la pieza musical.

Hay otros motivos importantes por los cuales debemos escribir el código mas sencillo posible, pero hay mucho material sobre esos motivos en la red y, en todo caso, puede ser materia de una futura entrada.

Creo un requisito importante para lograr una buena práctica de TDD es entender e incorporar la idea de que no es una técnica de prueba sino una manera de diseñar software.

Nos vemos.