archivo

Archivo de la etiqueta: Lean

En los enfoques clásicos se trabaja en procesos en donde los entregables finales: catálogo de requisitos, análisis, diseño, construcción, etc… tratan sobre un producto completo, ¿existe sobreproducción?.

Si se entiende que se ha contratado el desarrollo de un software en base a unas especificaciones de partida (un alcance), un coste y unos plazos y que se ha decidido que la metodología de desarrollo sea esa, no deberíamos hablar de sobreproducción: se ha hecho lo que se ha contratado.

Otra cosa es que buena parte del trabajo realizado sea efectivo y no lo digo porque crea más o menos en este tipo de enfoques (que ya sabéis que no, pero sin cerrar la puerta a que en proyectos concretos sea la solución más válida), sino porque la propia naturaleza de los proyectos de desarrollo de software y nuestra propia experiencia nos demuestra que trabajar con la hipótesis de que los requisitos van a ser estables, es algo más utópico que real.

Esto quiere decir que si nos cambian requisitos (modificación, eliminación o adición) en cualquier momento (incluso haciéndolo bien y adaptando el alcance), se debería producir una modificación en cadena del conjunto de entregables y elementos de proceso.

¿Hay sobreproducción? Ya dije antes que desde una perspectiva a alto nivel no, pero si lo miramos a una escala de mayor detalle sí que hay un trabajo excedente que se ha realizado y que después lo mismo no se ejecuta o como consecuencia de modificaciones de otras funcionalidades también requiere cambios.

Desde este punto de vista un enfoque clásico se convierte en ineficiente conforme se van rompiendo las premisas iniciales de estabilidad.

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Tu reputación, tus alianzas, la búsqueda de la oportunidad y tu adaptación a los precios de mercado resultan fundamentales para ser competitivo en un ecosistema tan difícil como es el de los servicios de desarrollo de software o el de sus productos.

Una vez conseguido el contrato, si el mismo se encuentra dentro de unos parámetros razonables de alcance y precio, existirá probabilidad de conseguir beneficios si hay un buen entendimiento con el cliente, en el que se repartan responsabilidades y se conozcan las reglas del juego y si se es productivo (existen, todos los sabemos, infinidad de circunstancias que pueden complicar un proyecto, lo que he hecho es señalar un contexto que, de entrada, puede ser favorable).

Ser competitivo y poder sobrevivir de manera adecuada incluso en períodos de escasez requiere la adopción de una serie de medidas, una de ellas es evitar el despilfarro, entendiéndose éste como todo gasto totalmente innecesario y con bajas expectativas de retorno, siendo su gravedad proporcional al importe y a su posible carácter estructural.

Dentro del ámbito de un proyecto, el despilfarro (generalmente provocado por el cliente, pero en muchos casos alentado por el proveedor) se centrará en el desarrollo de funcionalidades innecesarias, en añadir complejidad adicional, en reinventar la rueda, en la pérdida de un ritmo de desarrollo y en la falta de intención. También lo podremos encontrar en procesos que no se adaptan a la naturaleza del producto a desarrollar y que provoca la generación de entregables sin utilidad real para el proyecto.

A más alto nivel, una organización despilfarra cuando contrata proyectos de desarrollo o productos que no necesita o para procesos que, por su inestabilidad, sería aconsejable esperar tiempos mejores. También se tira el dinero cuando se contratan servicios con un nivel de calidad o servicio superior al que se necesita, esto es equivalente a comprar mucha más comida de la que necesita y a llenar semanalmente el cubo de basura con todo lo que se ha echado a perder o llenar un almacén con más materia prima de la que se necesita incurriendo en los siguientes costes: gasto de almacenamiento y gasto por la materia prima adicional (que se puede deteriorar por el paso del tiempo).

Ese despilfarro se termina convirtiendo en estructural en el momento en que esos sistemas o productos se convierten con más o menos éxito en herramientas de trabajo, lo que obliga a seguir invirtiendo en ellos.

Este crecimiento sin orden y sin medida, basado en la suposición de que cada vez se va a tener más presupuesto, termina por colapsar en el momento en que se interrumpe ese flujo de dinero, que provocará que el mantenimiento y soporte para muchas de esas aplicaciones o productos sea precario o inexistente.

En períodos de abundancia parece que todo vale y nada importa, pero cuando las cosas no van bien, te acuerdas de cada céntimo de euro que has tirado o que tienes comprometido en proyectos, productos o servicios prescindibles. No se trata de mirar por el dinero exclusivamente cuando todo va mal, ya que lo mismo es demasiado tarde, sino de saber qué se está haciendo cuando se tiene éxito.

Veamos una posible implementación Scrum-dominante. Dentro del flujo de trabajo que se defina en un tablero Scrum, supongamos que se definen un conjunto de fases tan simple como: Sin iniciar, en construcción, testing y finalizada, y para una o más de ellas se establece un límite de tareas abiertas de manera que si se alcanza el límite ninguna tarea más puede entrar en esa fase, lo que hace que los esfuerzos se deban enfocar en eliminar ese cuello de botella: deben salir tareas para que puedan entrar otras. De esa manera se pretende detectar problemas lo más próximo posible a su origen para tratar de resolverlos lo antes posible (filosofía lean).

Veamos ahora una posible implementación Kanban-dominante. En este caso, el sprint está abierto, pueden ir entrando nuevas tareas siempre y cuando no se sobrepase el WIP definido.

Llegado un punto (se puede denominar punto de ajuste) tendremos que ir cerrando la iteración, lo que obligará a centrarnos en aquellas tareas en ejecución que se consideren más prioritarias, lo que implicará que determinadas tareas ya iniciadas pasen a ser trabajadas en futuros sprints. Ese punto de ajuste deberá realizarse con suficiente antelación porque de lo contrario puede haber un mayor número de tareas que queden abiertas y/o que dentro de las que ya se ha comenzado a trabajar haya algunas prioritarias que queden sin ser atendidas.

Hemos visto dos posibles implementaciones, en función de que se pretenda que predomine Scrum o Kanban. También existen otras en las que pueden convivir ambas estrategias, una de ellas puede consistir en que el sprint se realice según las prácticas de Scrum y por otro lado, tener reservada cierta capacidad del equipo de trabajo para resolver incidencias u otro tipo de peticiones que tengan que ser atendidas con urgencia sin alterar los compromisos adquiridos en la iteración (pila de sprint).

Esta capacidad se regiría por prioridades y limitando el WIP.

Esta última implementación me parece muy interesante y es bastante efectiva. Puedes empezar a practicarla sin definir WIP (aunque ya no estaríamos aplicando Kanban) y más adelante empezar a ajustar límites en determinadas tareas del flujo.

Realmente podemos llevarnos horas, días, semanas, meses, discutiendo sobre si la aplicación de una determinada estrategia, enfoque o práctica es adecuada, pero solo se tratará de especulación, muchas hipótesis e ideas.

¿Es humo? Para mi el humo tiene mucho más que ver con hipótesis que solo han tenido en cuenta aspectos teóricos u opiniones personales que no se han contrastado, al menos, con la realidad del contexto en el que se quieren aplicar. Si, por lo menos, las ideas se sustentan en un análisis objetivo, yo no lo llamaría humo, pero no dejan de ser hipótesis sin validar.

Lo queramos llamar humo o no, se trata de mucho tiempo invertido en establecer un conjunto de ideas que lo mismo la realidad se encarga de demostrar que son equivocadas.

Ese tiempo invertido puede suponer dinero (siempre lo es aunque no te suponga un gasto directo), pérdida de oportunidad y/o dificultad de adaptación al cambio si has desarrollado un producto prácticamente finalista.

La idea que tienen los product owners o los responsables funcionales del software que quieren no es más que algo abstracto, es más, hasta que el producto empiece a materializarse y cobrar una cierta entidad es más acertado decir que su idea inicial es lo que creen que quieren porque hasta que no se empiece a experimentar no saldrán a la superficie comportamientos y funcionalidades deseados pero que estaban ocultos o el caso contrario, comportamientos y funcionalidades que se creían efectivos y útiles y que no son ninguna de esas dos cosas.

De ahí la conveniencia de aplicar desarrollo iterativo incremental y con más razón en aquellos casos donde el sistema se prevea complejo y/o los responsables funcionales no terminen de verlo claro.

Pero desarrollo iterativo incremental es una idea muy general, si definimos ciclos largos hemos fraccionado algo el problema pero probablemente será insuficiente y será mayor la cantidad de desperdicio generado.

También es cuestión de enfoque, mejor siempre partir de soluciones simples consolidadas y validadas para a partir de ahí crecer hacia otras más complejas.

¿Se trata de obtener una versión rápida a toda costa? Versión rápida a toda costa es algo demasiado general, sí que resulta interesante cuanto antes obtener un feedback del usuario pero también que el desperdicio generado sea el menor posible (por lo que los ciclos de desarrollo deben hacerse con intención, de no hacerse así estaremos haciendo desarrollo por permutación y eso tiene un coste importante) y que no perdamos de vista que para seguir generando nuevas versiones es necesario que las modificaciones a realizar sobre el producto se puedan hacer en unos plazos razonables, por lo que en el momento en el que la deuda técnica supere unos determinados umbrales perderemos esa capacidad de respuesta rápida o por lo menos no tan rápida, efectiva y económica como sería deseable.

Tal vez al principio consideres que lo más importante es desarrollar una versión aunque sea prototípica para verificar si el producto va por el camino deseado y que determinados factores como la calidad del código son secundarios. Al final es algo que tendrás que valorar tú en base al contexto en el que estás desarrollando.

El principio Lean de cero defectos es un objetivo que en el desarrollo de software puede resultar quimérico pero que no por ello se debe perder de vista el hecho de que cuantos menos defectos lleguen a producción o fases sucesivas del desarrollo, más calidad tendrá el software y más barata será su corrección.

Siempre hay que evaluar qué tipo de software se está desarrollando y cuál es el contexto económico y/o temporal en el que nos estamos moviendo, esto nos dará una idea de hasta dónde se puede llegar.

Ahora bien, no todos los defectos son iguales. Llegado el momento tendrás que tomar la decisión de si pasas una versión a producción con una serie de errores conocidos y/o con un determinado nivel de rigurosidad de las pruebas. ¿Por qué no los corrijo todos ahora? Pues porque puede darse el caso de que el coste de retrasar la puesta en producción sea mayor que los beneficios que tiene la corrección de los defectos.

Esto hace que su subsanación se aplace y cuando esto se hace sucede que muchos de esos defectos considerados (acertadamente o no) poco trascendentes no terminen por arreglarse nunca.

¿Es esto positivo? Depende de los defectos y depende del valor ganado en cada iteración mediante la realización de otro tipo de tareas: evolución del producción, corrección de otras incidencias, etc…