Potencia tu equipo (4): Evita jerarquías y especialistas

¡ Oh no ! Otro post infumable sobre equipos de desarrollo… Si señores y señoras vuelvo a la carga con este tema que considero de importancia vital, no os preocupéis creo que es el último de la serie. Considero importante este tema porque si no tenemos un equipo bien estructurado lo tendremos muy difícil para tener éxito en nuestros proyectos.

En mi anterior post sobre equipos comenté que una estructuración plana y democrática era la más ágil y óptima para el desarrollo de software. Sin embargo al crecer en tamaño dicha estructura se colapsa debido a la sobrecarga de información de cada miembro del equipo. Además para explotar las ventajas de tal estructura de equipo lo mejor es que estén todos colocados en la misma sala. Esto nos lleva a un problema, ¿qué hacemos si necesitamos un equipo muy grande (más de 9)?¿Qué hacemos si no tenemos a todos lo miembros del equipo colocado? En estos casos necesitamos estructurar el equipo de forma diferente. Veamos alternativas.

La primera tentación es montar una jerarquía. Ciertamente las jerarquías disminuyen la cantidad de lineas de información que llegan a una persona, lo que permite que esta se sature menos si el equipo es grande. Desde este punto de vista los equipos organizados en jerarquías escalan bien con el tamaño. De hecho el número de lineas de comunicación crece mucho más despacio (logarítmicamente)  que con equipos planos (crecimiento lineal). Otra ventaja es que la toma de decisiones la toma el jefe, lo que permite mayor velocidad de decisión que la basada en consenso. Es la forma tradicional de organizar los equipos. Todo parece bonito pero… esta estructura ¡no es ágil! y además ¡ es frágil ! Veamos:

• Frágil. La estructura depende de las personas que son jefes de equipo. Con suerte puedes tener un jefe que sepa lo que hace y sea competente, si no tienes tanta suerte te toca un jefe que es una nulidad. Cuanto más arriba en la jerarquía esté la persona, más vital es. Un equipo plano es más robusto ya que no depende de una sola persona.
• No ágil. Cada miembro del equipo no tiene una linea de comunicación con sus compañeros sino con su jefe. Si una información necesita pasar desde una persona a otra, no puede hacerlo directamente, sino que debe pasar por al menos un jefe o más. Por cuántos intermediarios pase depende de la «distancia» entre las dos personas, si están en el mismo equipo pasan por un sólo jefe, si están en equipos organizatívamente lejanos pasa por varios intermediarios. De hecho el número máximo de intermediarios crece logarítmicamente con el tamaño del equipo mientras que en un equipo plano se mantiene constante en cero. Paradójicamente, esta estructura hace que los jefes más importantes, los que deben tomar decisiones vitales, reciben la información más anticuada y desvirtuada ya que son los que tienen siempre más intermediarios con la realidad.
• No favorece el espíritu de equipo y colaboración sino la competencia entre jefes y la «política».

Evidentemente este modelo radical de jerarquía no suele aplicarse. Es más común el tener pequeños grupos planos que están coordinados por un jefe. Esto disminuye un poco el problema pero no lo elimina por completo, sobre todo si tenemos en cuenta que los equipos planos están en la base, y que es más raro encontrar equipos planos de jefes.

Otra forma típica de estructurar un equipo es alrededor de especialistas. Se suelen tener grupos de especialistas, donde cada grupo es experto en un componente del sistema o en una tarea o actividad. La idea detrás de esto es que los especialistas son muy eficientes en realizar unas actividades en concreto, por lo tanto la forma más eficiente de organizar un equipo es que cada individuo o grupo haga lo que mejor sabe hacer, su especialidad. De esta forma el rendimiento del equipo de desarrollo será óptimo, ¿verdad? Pues no, ¡ FAIL ! Veamos el siguiente dibujo ilustrando un equipo basado en especialistas:

Especialistas

Como se ve desde que una historia de usuario se extrae del product backlog hasta que se completa y reporta un valor al cliente (y dinero para nosotros), ésta pasa por… ¡un montón de intermediarios! Cada intermediario (especialista) de nuevo añade un posible punto de encolamiento («el otro equipo está tardando mucho en darme trabajo, yo no tengo la culpa….») y de malentendidos («pero suponíamos que la interfaz entre el componente A y el componente B era así, no nos la explicásteis bien»). El hecho de que cada grupo sólo entienda de su especialidad agrava los problemas, ya que provoca entre otras cosas:

• Cada uno intenta optimizar el proceso global y el código desde el punto de vista de su especialidad sin tener en cuenta el objetivo global. Esto produce optimizaciones locales que no son eficientes. Por ejemplo un desarrollador puede decidir escribir código sin pruebas rigurosas, lo que optimiza su trabajo (acaba antes) pero genera un problema en el equipo de control de calidad.
• Crea rivalidades y evita el espíritu de equipo. Cada grupo tiende a ver a los demás como «tontos» que no entienden su trabajo (especialidad).
• No se produce una diseminación del conocimiento entre los distintos empleados. Cada uno se queda «encasillado» en su especialidad para siempre.
• No hay un feedback rápido ante problemas. Un problema introducido por un equipo puede no ser detectado hasta que llega a otro equipo, potencialmente alejado.
• Como normalmente los equipos de especialistas no colaboran entre si, se necesita la figura de un coordinador.
• Normalmente llega a una utilización ineficiente de las personas. No todas las «historias de usuario» tienen que necesitar de todos los especialistas. Si en un momento dado sólo hay historias de usuario que necesitan a los especialistas A, C y D, el especialista B se quedará desasignado. Esto es una consecuencia obvia de usar especialistas, los especialistas no son siempre asignables y pueden llevar a una utilización ineficiente de los recursos.
• El efecto «patata caliente» y «tu la llevas». Se suele echar las culpas a los demás equipos y pasarle el marrón al siguiente. Esto es debido a que cada grupo de especialistas no comparte una meta común con los otros grupos y además son incapaces de ver el proyecto en su conjunto, con tal de que su trozo esté terminado no les importa que el producto en global esté mal (la culpa será de los otros, mi parte está bien).

Como hemos visto la jerarquía y la organización en grupos de especialistas genera intermediarios y colas que son fuente de múltiples problemas. Por cada intermediario se produce un retraso, con lo que la información llegará más anticuada al receptor. Por cada intermediario hay una cierta de corrupción de la información y malentendidos, con lo que la información se perderá por el camino y lo que llegue al receptor no puede no ser lo suficientemente veraz o preciso. Si encima cada intermediario tarda una cantidad diferente y no predecible de tiempo en procesar la información se producirán encolamientos. Si quieres un equipo ágil, evita intermediarios. Las colas son también fuentes de ineficiencias. Por cada cola tenemos trabajo a medio hacer, parado que no genera valor. Por cada cola se retrasa el feedback, haciendo que un montón de posibles defectos y problemas estén escondidos, a la espera de aparecer en el momento más inoportuno y cuando todo el mundo está ya «en otra cosa». Si quieres ser lean debes evitar las colas.

Lo más eficiente es organizar los equipos grandes de forma que se minimicen el número de intermediarios y colas. Para esto tenemos dos armas: la autogestión y los equipos multidisciplinares. Veamos algunos consejos generales en este sentido:

• Organiza en equipos planos colocados en la misma sala a toda la gente que necesite comunicarse con mucha frecuencia y responder ágilmente. Equipos que no deban interaccionar tan a menudo pueden estar en otras salas o en centros remotos.
• Cada equipo debe ser multidisciplinar, debe tener varios especialistas. Además estos especialistas irán enseñando sus tareas a los demás miembros del equipo. Esto genera una transición gradual de especialistas a técnicos multidisciplinares y un mejor espíritu de equipo.
• Cada equipo debe tender a la autogestión, tanto de sus cometidos como a la interacción con otros equipos. Esto evita la figura del coordinador y aunque tengamos un coordinador su actuación no sea tan vital.
• Para coordinar varios equipos cada equipo puede nombrar a uno de sus miembros como representante. Este nombramiento puede rotar con el tiempo. Todos los representantes de todos los grupos se organizan de forma democrática y se reúnen periódicamente para discutir temas de organización.
• Cada equipo es responsable por entero de la entrega de la tarea que tiene encomendada. No se debe responsabilizar a individuos. Esto genera una meta común y une al equipo.
• De la misma manera todos los equipos son responsables del éxito o fracaso del proyecto en su conjunto.
• Mantén los miembros de un mismo equipo juntos durante mucho tiempo, de esta forma se conocerán entre si y su coordinación crecerá.
• De vez en cuando ofrece la posibilidad a los miembros de un equipo para cambiarse a otro equipo. Asi no se quemarán ni se cansarán del mismo ambiente y tendrás un nivel adicional de diseminación de información.

Si implementamos estos consejos podemos montar un equipo estructurado en base a «feature teams». En este tipo de estructura cada grupo o «feature team» se encarga de realizar una historia de usuario. Veamos el siguiente dibujo:

Feature Teams

Como vemos eliminamos las colas. Cada equipo es multidisciplinar y tiene su propio Product Owner. De esta forma es capaz de coger una historia de usuario e implementarla sin necesidad de pasar por otros grupos. Como cada equipo es plano, éste se comporta de forma ágil y rápida. En la figura hay cuatro equipos, cada uno de ellos en su propia sala. Los equipo que pertenecen a «Color Features» están en el mismo edificio porque cogen historias de usuario que tienen bastante relación entre si, son funcionalmente próximas, por lo tanto los dos equipos necesitan comunicación ágil y por lo tanto proximidad. De la misma manera «Alpha Features» está en otro centro de trabajo y se estructura de forma similar. El uso de autogestión y representantes de equipos disminuye mucho la necesidad de coordinadores. Sin embargo siempre es bueno es tener varios scrum masters itinerantes o coachers que se dediquen a resolver dudas,  aconsejen a los equipos, desatasquen potenciales problemas globales o arbitren en disputas «irresolubles». Estos «coachers» no serían coordinadores sino facilitadores y maestros. Tampoco es mala práctica que además del representante de equipo se reúnan periódicamente los product owners de cada grupo para mantener una linea de coherencia estratégica del producto.

Un hecho interesante es que como cada historia de usuario requiere de varias tareas o componentes para ser completadas, cada grupo debe trabajar sobre distintas áreas de código. Esto hace que todos los grupos tengan una responsabilidad compartida sobre todos los componentes de código de la aplicación. De esta forma a todos los grupos le convienen que todos los componentes de código estén hechos con una calidad y mantenibilidad decentes, porque te puede tocar usarlos o modificarlos para la siguiente historia de usuario. Contrasten este efecto con lo que ocurría con los especialistas, cada especialista sólo se preocupa de su componente y no de los demás. El hecho de que varios grupos modifiquen simultáneamente las mismas zonas de código nos genera un problema de gestión. Este problema se soluciona con varias prácticas del agilismo:

• Pair programming. Para aumentar la calidad del código (revisión continua) y la diseminación de la información (enseñanza mutua entre los miembros de la pareja).
• Repositorio de código con control de versiones y concurrencia optimista. Es vital que el sistema de control de versiones de código no bloquee los ficheros. Si los bloqueara se producirían encolamientos entre dos grupos que necesitan modificar el mismo componente de código.
• TDD. Para mantener una suite de pruebas que te permita tocar el código de otro sin miedo a romperlo y no darte cuenta.
• Integración continua. Para integrar de forma continua los cambios de los distintos grupos, disminuir la probabilidad de conflictos, y agilizar la fusión de versiones en caso de que los hubiera.

Finalmente, todo esto funciona porque los miembros de tu proyecto que necesitan una comunicación más rápida y ágil son los que están implementando una misma historia de usuario. Dos personas implementando dos historias de usuario distintas no tienen tanto acoplamiento y necesidad de intercomunicación como dos personas que están trabajando sobre la misma historia de usuario. De hecho el acoplamiento entre dos «feature teams» se produce sobre todo a través de la base de  código compartido. En este caso dicho acoplamiento se puede optimizar mediante TDD e integración continua con lo cual no es necesario una intercomunicación tan frecuente. Dicho esto aprovecho para introducir una práctica muy necesaria en este escenario, pero tenida por no ágil: la documentación. Como vemos la comunicación se realizará de forma más intensa por código entre dos «feature teams» distintos, por lo que además del TDD y la integración continua es necesario reforzar el grado de legibilidad del código, y eso se hace precisamente con una buena documentación. Recordad que el agilismo no prohíbe la documentación, sólo dice que documentes lo justo y necesario. En proyectos grandes, la cantidad de documentación justa y necesaria es mucho mayor que en un proyecto pequeño. Si no vas a implementar TDD, integración continua y no vas a mantener una buena documentación, tus «feature teams» no podrán coordinarse con efectividad y tu proyecto fracasará.

Como conclusión: es posible gestionar proyectos grandes usando agilismo aunque nuestro equipo se muy grande o esté distribuido. Ciertamente no es el caso óptimo pero la realidad manda. Para afrontar esto hay que estructurar tu proyecto en múltiples equipos pequeños, colocados en la misma sala, multidisciplinares y autogestionados, donde cada equipo implementa una historia completa de usuario detrás de otra. Como sacrificio podemos hacer que cada equipo pueda estar en su propio centro de trabajo, pero la menor interacción entre dos «feature teams» hacen que el TDD, la integración continua y la documentación sean vitales. Como prácticas a evitar están la de estructurar en grupos de especialistas y minimizar el grado de jerarquía.

Read Full Post »

Potencia tu equipo (2): Potencia a tu gente

Continúo con la serie de post dedicado a la definición de equipos de desarrollos ágiles. En el anterior post hice un repaso general de malas prácticas y dinámicas sociales negativas que generan éstas. En éste veremos más en detalle los valores y características que debe tener un miembro del equipo para que éste sea eficaz.

Montar un equipo agile es más que incrementar la frecuencia de feedback, disminuir la burocracia y otras buenas prácticas. Lo más indispensable de todo es simplemente contar con la gente adecuada. No se trata de que simplemente pongamos un jefe de proyecto «buena gente» o de que tengamos programadores de alto nivel, sino de que todos los miembros del equipo, desde el primero hasta el último, jefes, técnicos y gerentes, compartan unos mismos valores y capacidades. Si hay una fracción significativa de los miembros del equipo que no cumplen ésto, simplemente fracasarás en tu intento de implantar el agilismo, uses las prácticas que uses.

El agilismo, en el fondo, propone un metaproceso capaz de adaptar el proceso de desarrollo en si, tanto a los cambios externos como a los errores detectados, con el fin de hacerlo cada vez más eficiente. Por lo tanto no nos vale con contar con gente capaz de seguir un proceso de desarrollo, sino que además deben ser capaces de mejorarlo de forma continua.  Ésto es vital, ya que aunque empecemos con un mal proceso, a través de la mejora continua podremos llegar a uno bueno. Si en cambio, empezamos con un proceso eficaz, y no tenemos capacidad de adaptación y mejora continua, simplemente ocurrirá que tarde o temprano nuestro entorno cambie y nuestro proceso ya no sea eficaz en el nuevo entorno, aunque lo fuera en el antiguo. Cada una de los valores que presentaré a continuación tienen pues como objetivo último, el capacitar a la organización para realizar una mejora continua del proceso de desarrollo, y adaptarlo a cambios en el entorno. Para cada uno de ellos indicaré ejemplos positivos y negativos:

• Capacidad de aprender las habilidades necesarias para el trabajo. Una persona que tiene esta capacidad puede aprender por si mismo y de forma suficientemente rápida. En el extremo malo nos encontramos con personas que no quieren aprender, o sólo aprenden si reciben cursos. Esta habilidad es vital para poder adaptarse a nuevas tecnologías, métodos y circunstancias de forma rápida y eficaz.
• Capacidad de detectar errores y problemas. La persona capaz de oler los problemas e ineficiencias, no solo en el código, sino en el proceso de desarrollo, son muy valiosas. Nos permiten reaccionar rápidamente para arreglar problemas, incluso antes de que estos produzcan daños. En el extremo malo encontramos personas que simplemente hacen sus tareas sin darse cuenta de los problemas, aunque se produzcan delante de sus narices ¿Alguien sabe leer una traza de una excepción?
• Aprender de los errores. Equivocarse no es malo, lo malo es equivocarte y no aprender de ello, equivocarse una y otra vez en lo mismo. Ésto es propio de zombis no de personas.
• Capacidad para enseñar a los demás. Esto es fundamental sobre todo en los roles de más responsabilidad. Un rasgo importante de un jefe eficaz y de un buen compañero es saber enseñar a los demás a hacer las cosas bien y a mejorar. Esto nos permite absorber a gente sin experiencia o incluso con malos hábitos y convertirlos en miembros del equipo productivos, te permite mejorar no a ti, sino a la gente que te rodea.
• Capacidad de cuestionar las cosas de forma racional, incluyendo los modelos mentales ya establecidos. De esta forma simplemente seremos capaces de no quedarnos ciegos con modas y modelos mentales preconcebidos, impidiéndonos ver nuevas posibilidades y haciéndonos vulnerables al marketing. Ya hablé de esto en mi primer post.
• Jugador de equipo. Los proyectos son realizados por equipos, no por individuos. Se necesita gente que mire por el conjunto del equipo y no solo por sus propios intereses, ignorando las necesidades del conjunto. Actitudes típicas tales como «el marrón es tuyo» o «balones fuera» son propias de gente egoísta y totalmente prohibidas en un equipo ágil. Todos deben colaborar para conseguir el objetivo común. Si no que se lo digan a algún que otro equipo de fútbol.
• Iniciativa para ejercer todas las capacidades anteriores de motu propio sin necesidad de que alguien te lo ordene. Si no tienes iniciativa, a lo máximo que llegarás es a ser un burócrata que «hace su trabajo según el procedimiento», y eso con suerte. Esto es totalmente opuesto a la filosofía agile.
• Motivación. Este factor es muy frágil y no depende totalmente de la persona, sino de su entorno. Si los compañeros juegan en equipo, los proyectos tienen éxito, aprendes y ganas un sueldo digno, tu motivación sube.

Aprovecho ahora para definir el termino calidad referida a una persona. Cuanto más y mejor cumpla una persona los valores y capacidades definidos anteriormente, diré de ella que tiene más calidad. No penséis que me refiero a su calidad como ser humano, sino a su calidad como miembro de un equipo que cobra por hacer un trabajo. Tampoco penséis que la calidad depende sobre todo de la experiencia o titulación de esa persona. Pensad que es mucho mejor contratar a alguien sin experiencia pero con capacidad de aprender y jugar en equipo, que a alguien de mucha experiencia sin estos valores. El primero aprenderá sobre la marcha, y cuanto más listo y experto sea, más rápido aprenderá, pero aunque no sea el más inteligente terminará aprendiendo. Por el contrario es muy negativo tener a un super experto pero que no juega en equipo, que no enseña a los demás, no colabora y echa siempre balones fuera.

Es importante detectar si la gente que ya tenemos cumplen estos valores, y si no los cumplen, diagnosticar por qué no. Tal vez sólo están inmersos en una dinámica negativa y no conocen otra cosa, pero pueden llegar a mejorar. O en el peor de los casos simplemente esa persona es incapaz de mejorar, en cuyo caso es mejor prescindir de ella.

Algunos estaréis pensando lo mismo que yo: en muchas empresas la política de contratación y RRHH es totalmente diferente, se basa en criterios como el sueldo, la apariencia o simplemente el azar. Todo esto forma parte de la dinámica negativa que comenté en el post anterior. En cualquier caso, nunca he visto a ninguna empresa completar los proyectos con éxito con este enfoque, aunque sí ganar dinero (usando prácticas poco éticas).

Por último sed indulgentes conmigo y permitid que me flipe un poco 😉 A continuación mostraré un gráfico sobre cómo evoluciona la productividad de un equipo en función de la calidad media de sus miembros. Por supuesto es un gráfico totalmente subjetivo y basado en mi experiencia. Para hacer uno objetivo tendríamos que poder tomar métricas sobre productividad del equipo y sobre la calidad de una persona, cosa que en si sería una tarea muy compleja. Sin embargo tras muchos años uno coge un feeling sobre como funcionan las cosas. Sin más preámbulos allá va:

Productividad en función de la Calidad Humana

Como veis tiene dos lineas: la del sentido común, y la que me dice mi experiencia. En la primera todo va como esperado, el aumento de productividad del equipo es lineal con respecto a la calidad de sus miembros. Sin embargo mi experiencia me dice que esto no es real. Si os fijáis en la otra serie, la productividad aumenta mucho más rápido en función de la calidad del equipo. Tal vez sea una aumento exponencial, ¡ o mayor ! Incluso puede llegar a producirse un efecto de discontinuidad: una persona de alta calidad será capaz de solucionar problemas que una persona de baja calidad sea incapaz de resolver, produciéndose en este caso un aumento infinito de la productividad (discontinuidad).

Como conclusión: si queréis montar un equipo eficaz, el primer paso es contar con la gente adecuada, mientras no consigais esto, no os molesteis en intentar otra cosa. Al fin y al cabo el proceso de desarrollo lo implementan y ejecutan personas, si éstas no son capaces, el proceso fracasará.

Read Full Post »

A veces menos es más; proyectos más baratos con lean development

En el anterior post introduje uno de los fundamentos de las metodologías ágiles, el aumentar la frecuencia del feedback para mejorar el control del proyecto y su adaptabilidad a los cambios. En este post hablaré de otro principio fundamental en el agilismo, el lean development (desarrollo esbelto, pero no traduciré el término).

Para ser más competitivos muchas empresas deciden disminuir costes en sus proyectos. Su objetivo suele ser o bien obtener mayor margen de beneficio o bien ofertar más barato que la competencia. Existen muchas formas de hacer ésto. Algunas muy típicas son: pagar menos a los empleados, usar empleados de menor cualificación, llevarte la producción a lugares donde los empleados cobran menos, o la más cañí de todas, hacer muchas horas extras gratis. Estos métodos son muy eficientes en algunas industrias tales como cortar madera, extraer carbón o servir cervezas a los turistas, sin embargo, son bastante ineficaces para tareas como el desarrollo de software. Lo que nosotros sabemos, y muchos gestores de proyecto no, es que construir software es una tarea intelectual compleja que necesita de profesionales cualificados y altamente motivados. El bajarles el sueldo o hacerles hacer horas extra hacen que tu equipo quede exhausto y se desmotive volviéndose menos productivo.

¿Cómo conseguir que el coste de tu proyecto se reduzca sin sacrificar la calidad de éste? Es muy simple, elimina todo el waste de tu proyecto. Waste, que significa desperdicio, es una palabra técnica para referirse a cualquier actividad, trabajo o tiempo muerto que no tenga un efecto positivo en la productividad de tu proceso de desarrollo. Básicamente consiste en detectar cualquier cosa que haga que tu proceso sea menos eficiente y eliminarlo. La idea es realmente simple pero más difícil de hacer que de decir.

Veamos primero fuentes de waste típicas en el desarrollo de software:

• Tareas innecesarias. Cualquier tarea que no aporta valor al producto ni aumenta la productividad ni su calidad. En esta categoría tenemos típicamente: la funcionalidad que el cliente no pidió, la clase que programaste por si acaso y como no, la excesiva burocracia. Ojo, me refiero a la excesiva burocracia. Según el nivel de auditoria, transparencia ante el cliente, calidad, trazabilidad y eliminación de riesgo que tengamos, el nivel de burocracia esencial para un proyecto puede ser más o menos alta.
• Baja calidad. La baja calidad te obliga a hacer y rehacer una tarea varias veces hasta que su calidad sea aceptable. Por ejemplo implementamos una funcionalidad, esta no es aceptada en pruebas, hay que arreglarla, no vuelve a pasar las pruebas, etc. Cuanto antes lo hagamos bien menos trabajo haremos. Por ello el aseguramiento de la calidad también va a eliminar waste y hacer el proyecto más rentable a largo plazo. De aquí el posicionamiento del TDD como una práctica esencial.
• Falta de automatismos y herramientas. Algunas tareas necesarias pueden ser costosas de hacer o simplemente la velocidad a la que se hacen es crítica. Ejemplos: compilar, probar, integrar, desplegar, pases de entorno, etc. Para realizar estas tareas críticas hay que implantar herramientas y procedimientos automatizados como un compilador, IDE, JUnit (para probar y hacer TDD por ejemplo), maven y servidores de integración continua.
• Tiempos muertos. Cualquier intervalo de tiempo en el que alguno o todos lo miembros del equipo no hacen nada. El que un miembro de tu equipo no haga nada significa que le estás pagando por nada. Normalmente esto se produce por una ineficiencia en el proceso de desarrollo, relacionado o no con una tarea innecesaria. Hay que detectar esas ineficiencias y corregirlas. Si no detectamos ninguna deficiencia, y realmente tenemos a alguien que está ocioso de forma continuada, tal vez debamos echarlo del equipo. Quizás tenemos demasiados desarrolladores o a lo mejor es un gestor o coordinador que realmente no tiene nada que gestionar o coordinar.

¿Cómo llevamos todo esto a la práctica? Una forma sencilla de implantar la filosofía lean es aplicar los principios YAGNI (You Aren’t Going to Need It) y KISS (Keep It Simple, you Stupid). Cada vez que vayamos a realizar una tarea debemos tener una evidencia fuerte de que es totalmente necesaria, en caso contrario invocando el principio YAGNI, no la hacemos. Típico es el caso de la funcionalidad que nadie está seguro que el cliente realmente quiere pero es «chula» o la clase de utilidad con métodos que están ahí por «si acaso».

El principio KISS se basa en hacer que las cosas que funcionen, lo hagan de la forma más simple posible, si nos podemos ahorrar una línea de código sin dañar la calidad lo hacemos. O como dijo un conocido sabio: «Hazlo todo tan simple como sea posible, pero no más simple». Según este principio cualquier complicación introducida en el sistema debe estar justificada de forma objetiva por un aumento de la calidad y/o disminución de costes de mantenimiento y desarrollo. ¿Cuántas veces hemos oído a un arquitecto decir «pues usaremos un patrón de diseño X combinado con el patrón Y mientras hacemos el pino» simplemente para implementar una funcionalidad trivial? A esta complicación innecesaria, la llamo programación barroca. En muchos proyectos existe esta programación barroca simplemente porque el arquitecto necesita reafirmar su valía y mostrar todos sus conocimientos, o tal vez para impresionar al cliente. Quizás esa gran consultora de renombre necesita pasarle una gran factura al cliente y sólo lo puede justificar haciendo una arquitectura realmente impresionante pero totalmente innecesaria e inútil. Huyamos de las complicaciones innecesarias, cuanto más simple sea un sistema antes lo terminaremos y más barato será de mantener.

Si os habéis dado cuenta, con KISS y YAGNI se elimina todo el waste que tenga que ver con tareas o generación de artefactos innecesarios. Sin embargo dejan de lado una fuente importante de waste, los tiempos muertos innecesarios. Dichos tiempos muertos son producidos por deficiencias en la forma de trabajar desde un punto de vista estructural. A estos puntos, donde se forman esperas y atascos de trabajo, se les denomina cuellos de botella; hay que detectarlos lo antes posible y eliminarlos. Por ejemplo, podemos tener al equipo de desarrollo parado mucho tiempo, en espera de que el proceso de pase al entorno de pruebas se complete y puedan probar. Tal vez necesitamos un entorno de pruebas con más capacidad, o quizás adoptar integración continua, o tal vez poner a los desarrolladores con el siguiente lote de trabajo mientras el pase sigue su curso, etc. Para eliminar los cuellos de botella normalmente hay o que automatizar alguna tarea, o que reestructurar la forma de trabajar o simplemente aumentar los recursos necesarios para la tarea que conforma el cuello de botella. Lo importante es detectarlos a tiempo y poder analizarlos, para ello la filosofía lean nos propone analizar el proceso de desarrollo frecuentemente en busca de ineficacias. Éste es el mismo concepto que vimos en el post anterior, aumentar la frecuencia de feedback para tener un ciclo de control más eficiente. En general ésto se suele hacer mediante varias prácticas propuestas por el movimiento agile. Por ejemplo en SCRUM tenemos:

• El daily scrum. Nos permite detectar atascos en el proceso de desarrollo y empezar a tomar medidas al respecto inmediatamente.
• La retrospectiva de fin de sprint, aquí puede salir a la luz cuellos de botella detectados durante el sprint con el fin de eliminarlos para el siguiente
• La retrospectiva de fin de proyecto. Podemos detectar aquí cuellos de botellas que han persistido durante todo el proyecto y buscar soluciones para el siguiente.

Como vemos volvemos a usar los ciclos de control anidados pero esta vez para mejorar y optimizar de forma empírica nuestros procesos. Otra forma de mejorar, si nuestra organización tiene un nivel de madurez muy alto, es mediante métricas, análisis de colas y simulación. Hablaré más de esto en mis posts relacionados con kanban, pero realmente lo más importante es empezar a usar técnicas, sencillas y eficaces, como las propuestas por SCRUM.

Nota. Si por ahí veis el siguiente palabro: kaizen o mejora continua, que sepáis que se refiere a esta práctica de vigilar continuamente el proceso de desarrollo, detectar deficiencias y mejorarlo.

Las metodologías ágiles incluyen, de forma integral, YAGNI y KISS como buenas prácticas básicas. De hecho todos sus procesos, ya sea si usamos XP, SCRUM o simplemente TDD están imbuidas de esta filosofía. De esta forma se elimina el waste y se produce una mejora continua del proceso de desarrollo con lo que se puede considerar al movimiento agile como un caso de lean aplicado al software.

Realmente yo no termino de distinguir entre el lean y el agile. Ciertamente pienso que son lo mismo pero visto desde dos puntos de vista distintos. El lean se originó en la industria automovilística con lo cual supongo que se usará éste término cuando se quiere orientar la discusión a prácticas industriales. Yo creo que el agile se originó en parte al adoptar la filosofía lean dentro de la industria del software y adaptarla a las necesidades de ésta. De todas formas yo personalmente los uso como sinónimos.

Read Full Post »