Los días 6 y 7 de Mayo de este año 2009 en Miami (Florida, EE.UU.) tendrá lugar la Conferencia de Kanban y Lean 2009, lo que será el primer evento internacional sobre el sistema Kanban y Lean aplicada al desarrollo de software.
El sistema Kanban de TPS (Sistema de Producción Toyota) es una de las herramientas del pensamiento Lean que nos permite gestionar de manera ajustada al ciclo de producción y evolución de productos. Recientemente, esta filosofía ha ido ganando mucha sinergia con el desarrollo de software, principalmente por la propagación de metodologías ágiles, que en cierto modo, es un excelente punto de partida para la practica de conceptos inherentes al Pensamiento Lean.
Este evento tendrá importantes nombres de la comunidad internacional de Lean y Ágil como Dean Leffingwell, Alan Shalloway y David Anderson. Y Brasil será representado por un orador de peso, porque se trata de Alisson Vale, Director de Phidelis Tecnología y uno de los pioneros en el Brasil sobre la adopción de Ágil y Lean en su practica diaria del desarrollo de software.
Hice una muy interesante entrevista con él acerca de su experiencia con Lean y con el propio sistema Kanban, el resultado fue una entrevista muy esclarecedora y motivadora para la adopción de este modelo de los escenarios que sean apropiados.
Kanban en acción
Manoel Pimentel – Alisson explíquenos rápidamente lo que es Kanban y la forma en que se esta aplicando en la industria del software hoy en día.
Alisson Vale - Bueno, en primer lugar, permítanme tratar de contextualizar esta técnica dentro de TPS. El sistema de Toyota está centrado en la eliminación de desperdicio. La estrategia central es crear un flujo unitario que une los procesos y las operaciones y dejar en claro las pérdidas. De esta manera estimula el proceso de mejora continua. De hecho, siempre hay flujo en cualquier proceso, por mas que sea caótico. El secreto es hacer que el flujo sea más ajustado a fin de que la menor cantidad de inventario sea procesada por el sistema en un momento dado. Una forma de hacer un flujo de trabajo más ajustado es que la relación entre las operaciones dependientes se encuentre limitada por acuerdos bien definidos, que estipulan quién hace qué y cuándo. Un sistema Pull hace esto, lo que permite la circulación como consecuencia de ello. El trabajo se pasa de una operación a otra de modo que la operación cliente señalice para la operación que la precede (proveedor) que esta lista para el próximo trabajo. El Kanban es esta señalización.
La técnica de Kanban comenzó a ser utilizada en el desarrollo de software con la introducción de los métodos ágiles. Se utiliza una tabla con tarjetas y post-its para señalizar el estado de los trabajos en curso. Cuando el equipo mueve, por ejemplo, una tarjeta para el área de “completo” en el cuadro, ella señaliza al demandante (el propietario del producto, en el caso de Scrum, por ejemplo) que esta listo para el próximo trabajo. Esto permite la creación de flujo dentro de una iteración y evita que la demanda sea empujada al equipo en grandes lotes. Este es un ejemplo de un sistema Pull. Pero en términos Lean, un sistema Pull puede utilizarse para mejorar los procesos de modo general. Y puede ir mas allá del Framework más simplificado de Scrum y, por lo tanto, ayudar a un equipo de proyecto a crear sustentabilidad de la labor que realiza.
En 2006, David Anderson publico un articulo llamado Kanban en Acción en el que se indica el método que utilizo en Corbis para garantizar las actividades de sustentabilidad que no puede seguir el sistema de iteraciones sugerido por el abordaje ágil tradicional. Es necesario mantener el producto diariamente, ya que evolucionó quincenalmente.
En este enfoque se amplió el uso del cuadro Kanban con el fin de representar el ciclo de vida de un elemento de trabajo dentro del proceso utilizado. Lo que antes era solo 3 columnas (pendientes, en curso y terminado) se ha convertido en un instrumento de representación de toda la cadena de valor, lo que permite la creación de un autentico sistema Pull. Esto se hizo mediante el establecimiento de limites para los diferentes tipos de actividad (errores, mantenimiento, análisis, diseño, etc.) y mediante la definición de reglas simples que definen el acuerdo de trasladar estos temas en toda la cadena de valor. El efecto de este enfoque es limitar el trabajo en curso (lo que llamamos trabajo en proceso (WIP)) y el equilibrio de la capacidad contra la demanda. Desde entonces, se ha utilizado el nombre KSE (Kanban for Sustaining Engineering) para describir este enfoque y hemos observado que un numero cada vez mayor de personas en todo el mundo que ha estado utilizando y obteniendo buenos resultados en diversos escenarios. Hoy en día la comunidad interesada ya cuenta con mas de quinientos miembros y un gran movimiento sobre el asunto.
Ágil para desarrollar, caótico para mantener
Manoel Pimentel – Lean y ágil tienen una sinergia histórica y practica muy fuerte, ¿cómo es la relación entre estos dos paradigmas en su opinión?.
Alisson Vale – No es fácil para las personas saber donde empieza una y termina otra. Lean y ágil a menudo se confunden. De hecho, existe una fuerte interrelación entre estos paradigmas. Hay varios rasgos Lean en ágil y los dos paradigmas son complementarios de alguna forma. En mi opinión, seria muy difícil adoptar Lean en desarrollo de software si todavía estuviéramos trabajando en el modelo de cascada. Fueron las técnicas Ágiles las que nos permitieron la aplicación de conceptos Lean fundamentales como valor de flujo, la mejora continua, cadencia y otros. Lo que creo que es limitada es la idea de que ágil, en forma Scrum + XP, representa la mejor y tal vez la única forma de aplicar Lean para el desarrollo de software. Este enfoque es un excelente punto de partida, pero si el paradigma Lean se entiende plenamente durante el proceso, hay una buena probabilidad de que este enfoque sufra una serie de cambios en el mediano y largo plazo.
Manoel Pimentel – ¿Por que?.
Alisson Vale – Porque en Lean se tiene en cuenta todo lo que esta fuera de la trinchera de un proyecto. El paradigma ágil es sobre el software y las personas que lo hacen. Lean es acerca de la empresa o negocio en su conjunto. Un ejemplo de esta relación se produce en las empresas con una gran base de clientes en un mercado en el que cada jugador tiene un modo potencialmente diferente de operar. Estas empresas tienen una gran demanda para sustentarse. Sustentar significa implantar, personalizar, configurar, dar apoyo, solución de problemas de emergencia, la asistencia a los usuarios, hacer el despliegue, la formación y cualquier otro esfuerzo que sea necesario para permitir el uso del producto por su cliente. Scrum + XP es un excelente modelo para el desarrollo de productos, peor no son métodos bien indicados para el mantenimiento de productos. Esta limitación conduce a muchas empresas a separar sus procesos de desarrollo. Ellos terminan siendo ágiles para desarrollar, pero caóticos para mantener. Y siempre tienes que hacer las dos cosas al mismo tiempo y con la mejor sincronización posible. Existe una relación sistémica entre estos dos modelos de operaciones, cuando no están sincronizados. Se pierde la ganancia global y esto afecta a su calidad y la productividad. Esta es un área que hasta entonces no era muy bien cubierta por el paradigma ágil. Lean y KSE mas específicamente, puede contribuir mucho a ello. Desarrollo ágil se trata sobre la generación de valor, y mantenimiento es saber hacer frente a los desperdicios. Toda la actividad de mantenimiento en el área de software, es esencialmente desperdicios en términos de Lean, y es esencial que nos ocupemos de los desperdicios en ciertos escenarios. Esta es una de las razones por las que el KSE es también aplicable a los proyectos que no son ágiles. KSE ayudara a agilizar al proyecto un poco más en el tiempo. El flujo generado mostrara las perdidas y eso va a dirigir a las personas a saber cuando, donde y por que cada una de las técnicas ágiles debe aplicarse.
El caos de la cascada y la ayuda de Kanban
Manoel Pimentel – Al representar en un Kanban todas las fases de procesos u operaciones, ¿no estamos fomentando el uso de un modelo de cascada en nuestro ambiente? ¿O cree que se puede aplicar y adoptar los beneficios con Lean, incluso en entornos es cascada?.
Alisson Vale – Desde Lean, uno de los grandes problemas del modelo de cascada es el exceso de inventario que el modelo lleva a producir. Cuando se produce una serie de documentos con las especificaciones de requisitos Up front, que se inyectan en grandes cantidades en el sistema, se genera inventario de trabajo no concluido. Cuando estos documentos tienen modelos UML, se inyecta mas inventario y todavía no se ha producido nada en términos de valor para el cliente. En grandes empresas de software, el problema se agrava debido a las medidas de eficiencia utilizadas. Un analista se mide por la cantidad y la calidad de los análisis que él hace, no por la cantidad y calidad de software que ayuda a construir. Del mismo modo ocurre en las áreas de Test. La eficacia de los testers se mide por la cantidad de pruebas que hacen y por el tiempo que dedican a estas actividades. En la medida en que los analistas, diseñadores y testers van a estar ociosos ellos van siendo asignados a otros proyectos, produciendo mas de inventario que se acumula en las manos del equipo de desarrollo (que suele ser compartido entre varios proyectos). Con mucho trabajo y poco tiempo, las cuestiones de calidad serán las primeras en quedar en segundo plano. Con menos calidad, las informes de error volverán de los testers. Más errores a corregir, menos tiempo para procesar el resto del inventario que esta parado. El día disminuye y las noches van gradualmente aumentando. El resto de la historia ya la sabemos. Es la falacia de las “Fabricas de Software”.
En resumen, cuanto más eficientes son los analistas y testers, más inventario se produce y más presión sobre los desarrolladores y menos eficiente es el sistema en su conjunto. Esta practica lleva a las empresas a un modelo donde se estimula la creación de “óptimos locales”. Según la Teoría de Restricciones (TOC), óptimos locales no solo NO contribuirán a un todo óptimo, sino que la mayoría de las veces lo impiden. La única manera de evitar el caos es la adopción de largos leadtimes (muchos meses o años), procesos altamente controlados y burocráticos y una gran nomina de pago para hacer frente a las actividades que no agregan valor al producto final. Así esta es una de las formas en que Lean y TOC explican la ineficiencia del modelo de cascada.
En cuanto a Kanban, no dirige a un determinado paradigma. Solo Viabiliza el flujo. Hay equipos que representan el ciclo de vida linealmente: análisis, diseño, codificación y las pruebas en secuencia. Y trabajan con personal especializado en cada una de estas etapas. El Kanban se utiliza para hacer que el registro pase a través de todas estas etapas y salga del sistema como software funcional. Es decir, incluso utilizando etapas, este equipo consigue entregar software funcional con frecuencia, tanto como un equipo ágil. Pero la cuestión fundamental es que el Kanban limitara el WIP y permitirá el flujo, haciendo que el equipo reproduzca ese ciclo en horas o en días en lugar de meses. Si este equipo trabaja así es porque por alguna razón o no puede hacer el camino de la Agilidad, o prefiere esta manera. Cualquiera que sea la razón, el Kanban será muy útil en este contexto, puede incluso abrir la puerta al proceso de mejora continua apunte a las practicas ágiles apropiadas de conformidad con la necesidad de reducir los desperdicios evidenciados.
El hecho de que usted tiene un proceso bien definido, no significa que usted esta dejando de ser ágil. Usted puede tener un proceso muy bien mapeado y permanecer ágil. El Kanban no interfiere en como se hacen las cosas, solo ayuda a mantener el flujo de creación de software compatible con la capacidad del equipo en producirlo. Esto puede ser de gran ayuda para equipos ágiles que han superado las dificultades que tienen dentro del ciclo iterativo. Además, si tienen un proceso completamente caótico, el KSE puede ser la forma más sencilla de salir del caos y empezar a trabajar con alguna organización. Él le ayudara a establecer un punto de partida para la mejora continua de los procesos existentes, y no partir de un modelo genérico instalado en una realidad diferente de la suya.
Manoel Pimentel - Una de las grandes visiones que Lean ha traído al mercado fue poder visualizar el tiempo de valor agregado (work time) y el tiempo perdido (waste time) para cada actividad, que en el caso de desarrollo de sistemas este tiempo de pérdida está estrechamente relacionado con el tiempo de espera que la demanda adolece entre una actividad y otra. Entonces dada esa visión, ¿cómo puede esto representarse en un sistema Kanban?.
Alisson Vale - El tiempo de espera para que una demanda salga de un estado a otro no es necesariamente una perdida. La perdida se produce no solo por el tiempo que se necesita para ser trasladado en el Kanban, sino principalmente por el tiempo que permanece en WIP sin que haya una actividad de valor añadido que la coloque en el camino de salida. Reducir los plazos (Lead time) solo será bueno si la calidad no se modifica o si fuera mejorada. Entonces no tiene sentido tratar de reducir el tiempo del ciclo a cualquier costo. La multi-tarea, por ejemplo, representa pérdida directa. Si estás trabajando en más de una demanda al mismo tiempo, o si se interrumpe una demanda para inicial otra de mas emergencia, su WIP aumenta. Mucho WIP afecta el flujo y el tiempo de ciclo, y por consiguiente, la eficacia global del sistema. En Kanban nosotros conseguimos acompañar la cantidad de inventario que esta en WIP, pero eso no es lo que lo hace eficaz. Lo que hace que el modelo sea interesante es que los límites están fijados. Para que algo entre en el sistema, algo tiene que salir. Es ese trade-off lo que lo hace centrarse en mantener el enfoque en lo que es más importante en ese momento, pues cualquier cosa menos importante estará ocupando un espacio valioso en su sistema. En resumen, el Kanban pone en evidencia no solo las perdidas generadas por el exceso de inventario, sino que principalmente impide que ellas aparezcan.
Lean en el día a día
Manoel Pimentel - Cuéntanos un poco acerca de tu experiencia con Lean y ágil en su día a día. ¿Cómo fue que Lean ganó espacio en su contexto?.
Alisson Vale - Empezamos a trabajar con ágil en la empresa en 2004. Desde entonces nos vamos adaptando a las dificultades para tratar de hacer frente a la complejidad que es el desarrollo de software. Utilizamos XP para desarrollar nuestro producto y el resultado fue genial. Comenzamos, sin embargo, a tener dificultades a medida que el producto comenzó a introducirse en el mercado y la cartera de clientes creció. En ese momento, tratamos de adoptar Scrum, pero no funcionaba bien. Scrum mejoró nuestra capacidad de evolucionar el producto, pero afectó de manera negativa nuestra capacidad para mantener el producto. Y no fue culpa del Scrum, fue nuestra culpa no haber interpretado sus hipótesis y haber insistido en utilizarlo en un escenario para el que no fue concebido. Hemos intentado varias estrategias sugeridas para tratar con el mantenimiento: diferentes equipos, porcentaje de tiempo asignado, considerar las actividades de mantenimiento en las estimaciones. Nada de esto funcionó bien. En 2007, comenzamos a estudiar el modelo Kanban que David Anderson estaba proponiendo y nos identificamos con aquello. Parecía tener sentido dentro de nuestro contexto. Me tomo un tiempo para entender como operar con el nuevo modelo.
En 2008, todas las operaciones de la empresa comenzaron a ser integradas en torno a los nuevos conceptos. El proceso fue mapeado, el cuadro Kanban se modifico para representar el proceso y el sistema Pull se fue estabilizando de a poco. Como el Kanban representa toda nuestra cadena de valor, la puesta en funcionamiento de las tarjetas en la pared empezó a molestar, ya que eran muchas operaciones todos los días y eso comenzó a incomodar al equipo. En el segundo semestre de 2008, desarrollamos una herramienta electrónica para el control visual para sustituir el Kanban en la pared. Esto nos llevo a eliminar una gran cantidad de desperdicio generado por el control visual manual. También nos dio mucha más información precisa para la gestión. Hoy en día, tenemos varias métricas importantes (como cycle time y porcentual de desperdicio), que se muestran en tiempo real para el equipo en un cuadro electrónico.
Resolver el problema operacional como el sistema Pull fue como colocar la punta de los pies en el mundo Lean. Las cosas comienzan a llegar mucho más claras una vez que llegamos a saber formular las preguntas correctas (incluso si usted todavía no sabe las respuestas). Lean todavía es un aprendizaje para nosotros, pero va influenciando cada vez en la manera de ejecutar todas nuestras operaciones y la dirección en la que hemos planeado. A medida que vamos absorbiendo los conceptos de Lean, la distinción va siendo mas clara con respecto a Ágil. Un ejemplo es la forma de abordar la mejora continua. El Kaizen, en términos Lean, es "atemporal", es decir, el proceso de mejora continua obtenido con una cultura Lean es mucho más amplio que la simple aplicación y el seguimiento de reuniones periódicas. Tenemos que ir mas allá de los métodos ágiles para incorporar plenamente el paradigma Lean.
Manoel Pimentel - Comente un poco sobre los resultados que en su empresa está obteniendo mediante la aplicación de ideas Lean y Kanban.
Alisson Vale - En el corto plazo, el modelo genera un aumento en su capacidad de observación. Esto es valioso porque es lo que influencia el proceso de mejora continua. Actualmente nos encontramos en un momento en el que se están reuniendo y evaluando los resultados de operación del nuevo modelo, y esto se está preparando para definir las estrategias a largo plazo que generen resultados más profundos. Por ejemplo, una de las cosas que aprendí a observar es que el flujo se inhibe cuando hay mucha variabilidad en las operaciones, y la fuerza negativa que esas variaciones imponen a su resultado final aumentan cuando el nivel de abstracción necesaria para llevar a cabo este tipo de operaciones aumenta. Esto ayuda a justificar la alta inversión en diseño de software, por ejemplo, que es una actividad de alta abstracción. Técnicas como TDD, DDD y patrones de diseño, además de dar condiciones de mantenimiento al producto, ayudan a contener esta variabilidad, por tanto, ayudan a nivelar el flujo, reducir los plazos y aumentar la eficiencia global del proyecto.
El principal resultado de corto plazo que estamos teniendo es que el modelo permite aprender de manera eficaz el arte de seleccionar la cosa cierta en que se necesita trabajar en un momento dado, es decir, le ayuda a evitar la creación de desperdicio trabajando en las cosas que no son importantes en ese momento del tiempo. Esta es una de las razones por las que las iteraciones frecuentes son utilizadas en KSE. Las iteraciones no se adaptan bien a las actividades de mantenimiento porque no se ocupan correctamente del carácter imprevisible de tales actividades. Un backlog de mantenimiento no se adapta a iteraciones con timebox cuando hay un gran esfuerzo para el mantenimiento y cuando ese mantenimiento se realiza por el mismo equipo que seguirá trabajando para desarrollar el producto. Las iteraciones funcionaran bien por el contrario, cuando se tiene poco o ningún esfuerzo de mantenimiento, o cuando se están comenzando nuevos proyectos.
Otro beneficio importante es el ajuste de la demanda. Sus clientes siempre piden más de lo que pueden hacer. No hay como intervenir en ello cuando se tiene una relación “ágil” de confianza mutua con sus clientes. Y cuando usted tiene varios clientes independientes, siempre están compitiendo indirectamente por la asignación de recursos que usted tiene. Cuando usted consigue atender bien lo que es más importante, los clientes aprenden naturalmente a su ritmo y se irán ajustando a este ritmo. De hecho, se abre la mano de cosas menos importantes para obtener aquellas que son más importantes. Eso no significa que estas cosas no se harán, significa que solo se realizarán cuando en realidad sean importantes. Éste es el mecanismo que permite la relación de confianza mutua y el alcance abierto tan necesario como para el modelo en un entorno flexible para la competitividad y los intereses divergentes.
La conferencia
Manoel Pimentel – Cuéntanos un poco ¿cómo será su discurso en el evento y que tipo de temas se abordaran?.
Alisson Vale – Mi discurso, si se confirma, está claro, porque aun depende de una cierta cantidad de inscriptos para viabilizar mi ida, será, básicamente, sobre nuestra experiencia en la adopción del modelo. Hay muchas maneras de implementar un KSE. Creo que es importante que la gente sepa como pueden aplicarse de forma diferente en diferentes escenarios. Mi escenario es muy similar a miles de empresas que por ahí necesitan mantener grandes ERP, con una amplia variedad de escenarios y realidades de negocio y mano de obra limitada. Lean, KSE y el modelo Ágil juntos pueden proporcionar un camino a seguir para estas empresas. Prácticamente todo lo que hacemos es de alguna manera representado en el conjunto de herramientas que usamos (todas de código abierto o desarrollado internamente). Y este será el enfoque: como organizar nuestro proceso y como las herramientas se han acoplado para sustentarlo. Se hará hincapié en el Kanban Board electrónica que será la base para demostrar como estamos aplicando los conceptos en nuestro ambiente.
Manoel Pimentel – ¿Cuál es su expectativa para el evento en su conjunto?
Alisson Vale – El evento reunirá a los principales nombres que están trabajando con KSE y Lean en el ámbito de software hoy en Europa y EE.UU.. Será un aprendizaje para todos. Además de discursos, tenemos un día completo de Open Spaces para debates y otros momentos con keynotes de primera línea. El evento es apto no sólo para aquellos que quieran ampliar su abanico de posibilidades de formación o consultoría ágil, sino sobre todo para aquellos que pasan por los problemas que esta comunidad esta tratando de resolver. Un tema que será muy discutido es cómo escalar ágil para grandes proyectos o para grandes empresas. Lo que esta siendo discutido en ese área, es un modelo alternativo del Scrum de Scrum, que hoy es el mas indicado en la comunidad ágil. Hay mucha controversia sobre el significado de este modelo en términos de Lean y creo que es saludable como comunidad, que siempre estemos desafiando nuestros pre-conceptos acerca de las practicas que defendemos sobre la base del feedback del mercado.
Manoel Pimentel – ¿Hay expectativa de formar una nueva comunidad en el Brasil sobre este asunto?.
Alisson Vale – Quiero que esto ocurra. Creo que el modelo KSE se ajusta perfectamente dentro de los valores y los principios del Manifiesto Ágil. Las personas que valoran más las prácticas que los principios tal vez no pueden calificarse como “ágiles”, ya que es posible usarlos en algunos escenarios que las metodologías ágiles no recomiendan como escenarios de alta especialización de los miembros del equipo, diseño up-front, documentación mas intensa, la ausencia de iteraciones y otras. Pero es importante saber diferenciar los escenarios para lo cual KSE puede ser aplicado y sus fundamentos. El mérito de KSE está en proporcionar las condiciones para aquellos que no pueden renunciar a ciertas limitaciones prácticas de su propia realidad, y aun así todavía quiero empezar a trabajar de inmediato hacia el Manifiesto. La realidad es que las metodologías ágiles más utilizadas actualmente tienen dificultad de dar las condiciones de transición para el modelo ágil. Si no esta siguiendo el Manifiesto, los métodos actuales sugieren casi un nuevo comienzo. El KSE puede ser el punto de partida que estos equipos precisan para empezar a avanzar hacia él. Creo, por tanto, que hay muchas personas que necesitan de este tipo de respuesta. Es un modelo que puede traer mas empresas a este nuevo paradigma y potenciar la fuerza de la industria del software en su conjunto. Por otra parte, los proyectos Scrum también pueden beneficiarse de este enfoque por medio de la optimización del trabajo que sucede dentro de los sprints.
En este momento, estoy escribiendo un articulo en portugués con los principales elementos de este enfoque y, por tanto, permitir que la gente discuta mas sobre ello aquí en Brasil. Incluso para los que leen en inglés, todavía la información sobre KSE están muy dispersas en blogs, podcasts y listas de discusión, y no es fácil reunirlas con el fin de entender el modelo con una mayor profundidad. Ya existe un libro sobre el tema, pero podemos hacer más. Una lista en Yahoo Grupos esta abierta a los interesados, pero las discusiones aun no han comenzado. Creo que cuando libere el material, los debates comenzarán a salir con más naturalidad.
Manoel Pimentel – Y finalmente, ¿qué consejo, o mensaje de aliento, o mensaje de advertencia le daría para el gestor que está interesado en mejorar su proceso de desarrollo de software a través de Lean o de ágil?.
Alisson Vale – El mensaje es que no creo que sea posible disociar más las cuestiones de la ingeniería (o craftmanship) de las cuestiones gerenciales y económicas cuando se trata del desarrollo de software. Las cuestiones técnicas afectan de forma significativa a las cuestiones no técnicas y viceversa. Es ahí que Lean y ágil tiene su papel complementario. Parece que el secreto no es sólo saber equilibrar las dos cosas, sino saber cómo una cosa puede influir en otra positiva o negativamente. El “Diseño para Testiabilidad”, por ejemplo, parece ser un factor esencial para aumentar, o incluso viabilizar el potencial de rentabilidad de los productos de software de hoy. Esta es una cuestión muy técnica. Además, el ritmo sostenible, la colaboración, control de variabilidad y el control de los plazos son conceptos de gestión importantes que afectan directamente al modelo, el ritmo y la calidad de lo que se produce. Por lo tanto, unir la naturaleza de todas las cuestiones en una sola, unificando su propósito parece ser el mejor camino a seguir por ahora.
