8 consejos para realizar una gestión ágil de requisitos

Este post lo motivó una pregunta que me hicieron desde una empresa en la cual estaban trabajando en la renovación de su metodología. La pregunta era ¿qué libro de ingeniería de requisitos recomendarías?. La respuesta podía ser muy simple, hay muchos buenos textos que explican la ingeniería de requisitos "tradicional", pero no conozco ninguno equivalente que esté empapado del enfoque ágil.

Cuando empecé a trabajar con el enfoque ágil por el año 2000 me sorprendió ver un rechazo radical en los seguidores del agilismo (de esa época) respecto de la actividad de Análisis y del rol Analista. Pienso que esta actitud en parte estaba justificada por la poco eficaz "Fase de Análisis" (un período de tiempo en la que se concentran todas las actividades de elicitación, especificación y validación requisitos) y en la cual unas personas con un rol fijo y único, los llamados "Analistas" son los encargados de dichas actividades. Sin embargo, ni dicha actitud, ni tampoco el ímpetu por reducir la documentación deben dar pié a NO realizar gestión de requisitos. Ningún método ágil propone NO especificar qué es lo que se espera como producto, sería absurdo. Llámense Historias de Usuario o Casos de Uso, salvando sus diferencias de granuralidad y de aplicación, se trata al fin y al cabo de requisitos.

El enfoque ágil abre muchas oportunidades para el cliente y para el proveedor. Para aprovechar dichas oportunidades es el cliente quien puede (y debe) impulsar y apoyar más la aplicación de un enfoque ágil en sus proyectos.  

Sabemos que el éxito (o fracaso) de un proyecto depende en gran parte de la adecuada gestión de los requisitos. Pero no se trata de la cantidad de requisitos especificados, ni siquiera del detalle en su especificación, las claves para una ingeniería de requisitos "renovada" y eficaz las podemos obtener del enfoque ágil. Esta visión se plasma en los siguientes consejos para la gestión de requisitos desde una perspectiva ágil.

1. ¿Cuánto especificar los requisitos?

Especificar solo ”lo suficiente”. Suficiente en el sentido que, por una parte el cliente pueda validar lo que se quiere obtener  y, por otra, que el equipo ejecutor lo entienda. NO todos los requisitos necesitan el mismo nivel de detalle, para algunos puede bastar solo con su nombre para entenderlos sin mayor riesgo de equivocarse, para otros puede ser necesario una especificación más elaborada. Por otro lado, es importante que el esfuerzo invertido en especificar un requisito se “rentabilice”, ya sea porque la propia especificación, al realizarla, permita evitar defectos (en los requisitos) que llegarían a implementarse, o porque en actividades de ejecución y pruebas resulta útil dicha especificación.

Este consejo lo explico detalladamente en Gestión ágil de requisitos o ¿cuál y cuánta documentación/especificación es suficiente?

2. ¿Cuándo especificar los requisitos?

Existen dos contextos bien diferenciados en los cuales se necesita especificar requisitos:

• Para establecer un compromiso de entrega con el cliente. Aquí nos referimos a la especificación de requisitos realizada antes de iniciar TODA la implementación, incluso antes de firmar un posible contrato o acuerdo de desarrollo. En esta situación la preocupación es establecer el alcance, costo y plazo del proyecto, todo ello con un nivel de precisión aceptable. Muchas veces el propósito de este estudio es para hacer una valoración preliminar dentro de un portafolio de proyectos.

• Para explicar al equipo qué se espera como resultado de la implementación de un requisito, cómo puede darse por satisfecha su implementación. Este debería ser el nivel "suficiente" para CADA requisito y justo antes de su implementación. Es decir, si un requisito se implementará a mediano o largo plazo, probablemente todavía no es necesaria tal detalle en su especificación.

Así pues, se trata de dos situaciones bien diferentes respecto de precisión (detalle) de la especificación de requisitos. Los requisitos pueden caducar o perder prioridad a lo largo del desarrollo. Mientras más anticipadamente se detallen más riesgo tenemos de no rentabilizar el esfuerzo asociado y más obstáculos podríamos tener para la gestión de los cambios en el proyecto.

3. ¿Cómo especificar los requisitos?

Además de necesitar diferentes niveles de detalle en su especificación, los requisitos pueden ser especificados usando diferentes técnicas. Dependiendo de la relevancia o complejidad del requisito podrían incluso mezclarse diferentes técnicas, de forma complementaria o incluso solapadas. Por ejemplo, para un requisito crítico podría justificarse que tengamos una sobre-especificación.

De todas formas, respecto a dicha discriminación de los requisitos y de las técnicas para especificarlos me atrevo a sugerir una especificación mínima, la cual podría extenderse atendiendo a las particularidades de cada producto o de cada requisito. Esta especificación mínima contendría los siguientes elementos (ya sea en un formato ficha, documento o elementos gestionados en alguna herramienta de apoyo):

• Visión del producto o servicio. Incluye breve descripción, características principales, actores, modelo de negocio, productos competidores y modelo de dominio (básicamente para fijar la terminología del dominio). Esta visión está bastante alineada con el contenido de un Lean Canvas, usado para evaluar una idea de negocio. La Visión del producto o servicio podría no estar explícitamente establecida, pero la parte cliente debería asegurarse que el equipo ejecutor tenga dicho conocimiento. Si se opta por establecer la visión explícitamente en un documento, debería bastar con unas pocas páginas.
• Requisitos Funcionales. Identificación en un panel, lista o diagrama de todos los requisitos, la idea es disponer de una panorámica de los requisitos del producto o servicio. Justo antes de su implementación se necesitará además la especificación del requisito (la que sea "suficiente"). La especificación mínima para cada requisitos funcional se compone esencialmente de bocetos y escenarios (expresados ya como Pruebas de Aceptación). Lectura recomendada: "Gestión de requisitos dirigida por las Pruebas de Aceptación".
• Requisitos No funcionales. Identificación de una lista de los requisitos no funcionales generales o transversales. Los requisitos no funcionales asociados a un requisito funcional específico es mejor incluirlos en la especificación del requisito correspondiente, o al menos tener algún tipo de enlace hacia dicho requisito.

4. Orientarse hacia una solución mínima y satisfactoria

“Ofrecer la solución más simple que sea satisfactoria para el cliente”. Este consejo está alineado con el concepto MVP (minimun viable product) de Lean Startup. Discriminar entre lo de mayor valor y lo de menor valor para el cliente, entre lo imprescindible y lo prescindible, en cada nivel: característica, requisito y escenario.

Cuando se trata de la adquisición un producto o servicio ya desarrollado nuestra ambición en cuanto a requisitos suele estar principalmente limitada solo por nuestro presupuesto :-), con lo cual podría haber una cierta relajación respecto de adquirir lo mínimo que nos sea satisfactorio. Por contraparte, si estamos en la parte del proveedor y nuestro producto o servicio entrará a competir con otros, probablemente nos veamos forzados a ir mucho más allá de una versión mínima (ver Modelo Kano). Sin embargo, cuando se trata de un desarrollo a medida que estamos solicitando a un proveedor, sin lugar a dudas debemos ser mucho más estrictos respecto del alcance, plazos y costo del proyecto, y es en esta situación en la cual es más necesaria la estrategia de la solución mínima y satisfactoria. Esto no descarta que si el resultado es exitoso probablemente se encontrará apoyo para continuar mejorándo.

Lecturas recomendadas:

• Agilismo en la economía doméstica y su extrapolación a empresas.
• Bueno, bonito y barato ¿puede conseguirse esto con un método ágil?.

5. Cubrir el rol de Product Owner

Es vital contar con un buen“Product Owner”. Scrum establece que el Product Owner es una sola persona que representa los intereses de toda la parte cliente (todos los stakeholders), que tiene autoridad en el ámbito de la parte cliente, que gestiona bien el proyecto, y que explica detalladamente al equipo lo que debe implementar. Así pues, el Product Owner ideal integra tres roles tradicionales: Cliente, Jefe de proyecto y Analista. Estoy totalmente de acuerdo con este ideal, pero tener todas estas capacidades en una sola persona es muy dificil :-). Mi recomendación es que si no se dispone de una sola persona que desempeñe adecuadamente el rol Product Owner habrá que preocuparse de encontrar a dos o más personas que de forma coordinada cubran dichos perfiles.

6. Comunicar y reforzar la Visión del producto/servicio

Promover el conocimiento de la visión del producto o servicio, no solo en la parte cliente sino especialmente en el equipo ejecutor, el cual debe conocer por qué vale la pena desarrollar el producto o servicio, cuál es el modelo de negocio asociado, qué competidores existen y en qué se diferencia nuestro producto.

Para que todos los participantes en el desarrollo puedan discriminar de forma eficaz entre unos requisitos y otros es imprescindible que conozcan la visión del producto. Así podrán decidir/entender qué requisitos deben especificarse con mayor detalle o precisión, qué requisitos deben probarse más exhaustivamente, qué requisitos deben implementarse cuanto antes o cuáles podrían incluso no llegar a implementarse sin que esto conlleve un fracaso para el proyecto.

La visión del producto o servicio puede ir cambiando durante el desarrollo (y luego durante el mantenimiento) con lo cual también es importante informar dichos cambios, incluidos aquellos asociados a la estrategia para hacer realidad la visión. Incluso aunque no existan cambios es conveniente reforzar continuamente dicha visión.

7. Gestionar los cambios en los requisitos

Los requisitos pueden cambiar durante el desarrollo o el mantenimiento de un producto. Los cambios pueden referirse a añadir, modificar e incluso eliminar requisitos, pero además, pueden existir cambios de prioridad en la implementación de los requisitos.

“Todo producto exitoso demandará mantenimiento”. Basta con que el cliente utilice un producto o servicio (lo cual es quizás es el mejor síntoma de éxito) para que solicite mejoras y nuevos requisitos. En un proceso de desarrollo incremental es natural que se generen cambios en los requisitos, primero porque precisamente favorece que aparezcan oportunamente las desviaciones de expectativas del cliente con respecto del producto o servicio resultante, y segundo, la gestión eficaz del Backlog es esencialmente el ordenamiento estratégico del trabajo pendiente para ser implementado, así pues el contenido y orden del Backlog probablemente cambiará. El cambio tradicionalmente es visto como algo negativo, sin embargo, en el enfoque ágil el cambio es algo natural, a lo cual no debería existir más resistencia que la comprensión y justificación del cambio, en lugar de ignorar o resistirse al cambio hay que gestionarlo de forma eficaz. Lectura recomendada: ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?. Encarar los cambios no significa renunciar a la gestión de alcance del proyecto, al contrario, ésta debe hacerse de forma más intensa. Lectura recomendada: Gestión de alcance en proyecto en un proyecto ágil.

Pero ¿qué conlleva el mantenimiento de la especificación de requisitos?. Básicamente debe involucrar facilidades para plantear el cambio, estudiar alternativas, prever su impacto, localizar dónde hacer el cambio, y finalmente, facilidades para hacerlo y probarlo. Además, también es útil conocer en el ámbito del cambio tanto el histórico de cambios como otros cambios que se esperan a futuro. Si bien los cambios se hacen a nivel de implementación, si contamos con una especificación de requisitos también deberemos hacer el mantenimiento de dicha especificación, actualizándola con el cambio realizado. Para facilitar el mantenimiento de la especificación es importante que sea lo más minimalista posible. Así pues, si tomamos como ejemplo el mantenimiento de una especificación como la planteada en el punto 3, los cambios esencialmente se concretarían añadiendo, modificando y/o eliminando pruebas de aceptación. Lectura recomendada: "Gestión de requisitos dirigida por las Pruebas de Aceptación".

8. Gestión de requisitos integrada en el modelo de proceso del proyecto

La gestión de requisitos no es un proceso independiente. El modelo de proceso del proyecto (por ejemplo, Cascada, Incremental, Espiral, etc.) condiciona la gestión de requisitos. Es muy importante tener conciencia del modelo de proceso elegido y según él saber cómo debe aplicarse la gestión de requisitos. Gran parte de los problemas en gestión de requisitos se derivan del modelo de proceso y/o de no integrarla adecuadamente en dicho modelo de proceso. Lectura recomendada: Modelos de proceso para desarrollo ágil.

Históricamente se ha asumido que los requisitos deben estar especificados en detalle muy tempranamente, antes de la ejecución del proyecto. Esta "tradición" se explica porque al mismo tiempo se ha asumido que el modelo de proceso del proyecto debería ser en Cascada o incluso Secuencial, asi las actividades de definición y de ejecución se abordan como fases, períodos de tiempo diferentes, incluso llevadas a cabo por diferentes equipos. En un modelo de proceso ágil, el cual puede ser incremental, o iterativo e incremental, las actividades asociadas a la gestión de requisitos, para acoplarse a dicho modelo de proceso, presentan algunas novedades tales como:

• No es imprescindible identificar y detallar todos los requisitos tempranamente.
• El cliente debe estar continuamente participando en la especificación de requisitos y/o en mejoras a los requisitos ya implementados. El cliente en un enfoque tradicional concentra su participación al inicio y al final de proyecto, en uno ágil esto se distribuye a lo largo del proyecto.
• Se asume que los requisitos podrían cambiar y que hay que gestionar adecuadamente esos cambios.
• La gestión de alcance es muy continua. Se esperan cambios y ante cada cambio habrá que gestionar el alcance del proyecto.

Conclusiones

Espero que quede claro que mi recomendación global es aplicar un enfoque ágil para la gestión de requisitos :-). Si bien la gestión de requisitos no es un tema muy tratado en la literatura ágil (en dichos términos), es indudable que en cualquier desarrollo de producto o servicio la gestión de requisitos es esencial. Muchas prácticas ágiles están estrechamente relacionadas con gestión de requisitos y de otras puede derivarse una forma diferente y más eficaz de llevar a cabo la gestión de requisitos. Una importante innovación, por así decirlo, en el enfoque ágil es que la gestión de requisitos no está temporalmente aislada, no es un grupo de actividades que en un determinado momento da como resultado una especificación de requisitos. En el enfoque ágil la gestión de requisitos está integrada con la planificación y desarrollo, se realiza a lo largo de todo el proyecto, y está condicionada por el modelo de proceso, sea este incremental (incremental sin Sprints), o iterativo e incremental (incremental con Sprints).

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

Modelos de proceso para desarrollo ágil

Un modelo de proceso determina una estrategia global respecto de cómo se desarrollará un producto o servicio. El modelo de proceso ilustra qué actividades se realizarán a lo largo del tiempo. Existen diferentes modelos de proceso, desafortunadamente no hay uno que sea el mejor para todas las situaciones. En este post me centraré en tres modelos de proceso: Cascada, Incremental, e Iterativo-Incremental.

Dependiendo del dominio del proyecto (y del producto o servicio resultante) las actividades necesarias para desarrollarlo pueden ser muy diferentes. Sin embargo, podremos coincidir en que en términos generales al menos se realizarán tres actividades: Definición, Ejecución y Pruebas. La Definición se refiere al establecimiento de qué se quiere conseguir, corresponde a actividades de especificación de requisitos, análisis, etc. La Ejecución se refiere a la construcción de lo que se ha acordado en la Definición. Finalmente las Pruebas incluirían todas las actividades asociadas a la conformidad del resultado respecto de lo definido. Así pues, como sugiere la siguiente figura, explicaré los 3 modelos de proceso señalados centrándome en cómo se distribuirían en ellos estas tres actividades.

Proceso en Cascada

El proceso en cascada (Waterfall) es el modelo clásico por excelencia. En un proceso en cascada las actividades se secuencian en su orden lógico (Definición, Ejecución y Pruebas), intentando además, y si se dispone de capacidad, hacer cierto solape entre ellas. La siguiente figura muestra cómo sería un proceso en cascada.

Ventajas

• Es un modelo sencillo de entender por el cliente, aunque él suele estar más interesado en los plazos, costos y alcance del proyecto que en el proceso de desarrollo :-).
• Es cómodo para el cliente pues su participación tiende a concentrarse al principio y al final del proyecto.
• Tempranamente se puede acordar el alcance, costo y plazos del proyecto, (al finalizar la actividad de Definición). Esto está alineado con relaciones cliente-proveedor en las cuales se requiere fijar dichos elementos antes de comenzar la ejecución del proyecto.

Desventajas

• Se asume que no habrá re-trabajo ni cambios. Una vez que una actividad se termina no volvería a realizarse, ni para abordar nuevos requisitos ni para realizar correcciones de fallos.
• Las pruebas se concentran al final. En las actividades de pruebas es natural que se detecten fallos y que esto genere re-trabajo para corregirlos. Si el re-trabajo es significativo puede que no quede margen para que el proyecto termine dentro de los plazos o costos estimados. 
• Si se desempeñan roles únicos y fijos, es difícil organizar al equipo. Por ejemplo, si se termina la definición y quienes trabajaron en ella no realizan otro tipo de actividades, deberían ser asignados a otro proyecto. Pero si se genera re-trabajo o aparecen nuevos requisitos tendrían que volver al proyecto.

Cuando se planifica un proyecto siguiendo un proceso en cascada usualmente se utiliza un diagrama Gantt, en el estilo del que se muestra en la siguiente figura:

Este diagrama Gantt delata claramente un proceso en cascada por la forma escalonada en la cual se distribuyen en el tiempo las actividades. Además, en general es muy difícil acertar quién y cuando iniciará y terminará de realizar una tarea (en un diagrama Gantt todas las tareas tienen un inicio y fin que se asocian con precisión a fechas del calendario).

Una crítica adicional que le haría al proceso en cascada, y en particular a la planificación que él condiciona, es que se puede perder fácilmente el foco respecto del producto o servicio que se espera como resultado del proyecto. Al intentar cuadrar las actividades que deben realizarse, dentro de las restricciones de plazos y costos, es fácil despistarse respecto de lo que debería ser mucho más importante: que el resultado conseguido sea satisfactorio para el cliente. Terminar actividades no es una buena medida del progreso del proyecto, especialmente cuando ello no conlleva una validación con el cliente respecto del resultado que se espera del proyecto. Terminar parte del resultado y validarlo con el cliente nos puede ofrecer más garantías respecto al adecuado progreso del proyecto. 

Un proceso en cascada NO es adecuado para desarrollo ágil, pues además de todas las debilidades mencionadas, es contrario a dos valores esenciales que destaca el agilismo: responder a los cambios y medir el progreso con el producto funcionando (aunque aunque no esté terminado) en lugar de hacerlo con la documentación resultante de actividades. 

Proceso Incremental

Un incremento en un producto o servicio es una nueva versión generada por la terminación de un conjunto de ítems de trabajo. Un ítem puede ser un nuevo requisito, una mejora en un requisitos ya incluido, o puede ser la corrección de un fallo detectado en un versión previa.

En un proceso incremental es clave contar con una lista ordenada del trabajo pendiente dado que desde allí y siguiendo el orden establecido iremos cogiendo trabajo para llevarlo a cabo. Dicha lista ordenada se denomina Backlog. Cada vez que se identifique un nuevo ítem (de cualquier tipo) debe incluirse en el Backlog en la posición que le corresponda según los criterios aplicados (Lectura recomendada: Gestión eficaz del Backlog). Así, el Backlog es el sitio donde se gestionarán los cambios, representados por nuevos ítems, modificaciones de ítems, eliminaciones de ítems o modificación de posición de ítems en la lista. Esto se ilustra en la siguiente figura: 

La siguiente figura ilustra un proceso incremental. Los ítems se cogen del Backlog según orden y dependiendo de la capacidad del equipo podrían abordarse a la vez más de un ítem. Cada vez que se termina un ítem se tiene la posibilidad de generar una nueva versión e incluso entregarla al cliente (Continuous Delirvery), sin embargo, habría que evaluar si conviene en ese momento hacer una entrega al cliente ya que el costo asociado a pruebas y despliegue y/o la molestia que puede ocasionar al cliente pueden hacer recomendable NO hacer entregas tan frecuentes.  

Ventajas

• Las entregas al cliente pueden ser todo lo frecuente que se desee, llegando al punto de hacerlas cada vez que se termina un ítem. Esto permite hacer validaciones más frecuentes con el cliente. Además se evita acumulación de defectos entre cada versión debido a diferentes ítems y a su interferencia. Así también es más fácil detectar defectos.
• La definición de un ítem se puede postergar hasta en momento en el cual se decide abordar el ítem. Esto favorece la resistencia al cambio, pues no se necesita hacer inversión de esfuerzo con anticipación. Mientras más tiempo hay entre la definición y la ejecución de un ítem, más riesgo existe que dicha definición caduque o que el ítem pierda prioridad.
• Si el ordenamiento del Backlog es el adecuado (lo mas importante y de mayor riesgo primero, entre otros criterios disponibles), tempranamente podremos darnos cuenta cómo progresa el desarrollo, y en caso extremo podremos cancelarlo también tempranamente. 
• Durante todo el proyecto se realizan todas las actividades, con lo cual aunque los participantes sean especialistas en ciertas actividades y no realicen otras, tendrán trabajo a lo largo de todo el proyecto (pero quizás con menor intensidad por no estar concentrado).

Desventajas

• El cliente debe participar activamente a lo largo del proyecto, definiendo los ítems que se cogen desde el Backlog y probando las nuevas versiones. Esto más que una desventaja es usualmente visto como una incomodidad por el cliente, especialmente si no tiene conciencia del impacto que puede suponer su NO protagonismo en la rentabilización de su inversión en el desarrollo.

En un proceso incremental, lo ideal sería NO preestablecer el alcance y plazos, y fijar un costo por esfuerzo invertido. Es más, en determinados contextos NO es posible saber qué ítems serán abordados porque la demanda no está preestablecida. Esto ocurre en contextos de operaciones (no suele pasar en contextos de desarrollo), por ejemplo, mantenimiento cuando el producto ya está en producción, incidencias o tickets, etc. En estos casos simplemente no podemos hacer gestión de alcance, a lo más podemos tener límites para el esfuerzo invertido que de superarse lleven a renegociar o firmar un nuevo contrato.

Aún teniendo una demanda preestablecida de ítems podríamos ahorrarnos gestionar el alcance. Esto es posible si existe una relación de confianza entre el cliente y el proveedor, y se espera que a partir de una determinada versión el producto tenga madurez suficiente para entregarlo, y allí decidir si continuar o no trabajando de la misma forma, es decir, de ítem en ítem, de versión en versión. Si el cliente obliga al proveedor a comprometerse en alcance, plazos y/o costo, éste se vería  obligado a disponer de una definición y estimación para al menos los ítems más protagonistas, con lo cual perdemos en parte dicha ventaja de definición postergada. Además, en este caso, durante el proyecto también nos veríamos obligados a realizar una gestión de alcance continuamente, cada vez que se produzcan cambios en el Backlog. Lectura recomendada: Gestión de alcance en un proyecto ágil.

El método ágil Kanban propone un proceso de desarrollo incremental, y sin gestión de alcance.

Proceso Iterativo e Incremental

El proceso iterativo e incremental es un proceso incremental que tiene como complemento iteraciones (Sprints). La siguiente figura ilustra este proceso:

Ventajas

• Tiene todas las ventajas del proceso incremental.
• Usando Sprints se puede conseguir un equilibrio entre tener versiones frecuentes y no invertir demasiado esfuerzo en las actividades necesarias para generar, probar y revisar con el cliente cada versión. Así, en cada Sprint en general se incluirá un conjunto de ítems, es decir, cada nueva versión no es el resultado de un solo ítem.
• Cuando los compromisos con el cliente son poco flexibles la gestión de alcance tiende a ser obligatoria. Trabajar con Sprint permite hacer una gestión de alcance más sostenible (a ritmo constante) pues aunque el período del Sprint sea breve, ofrece cierta calma respecto de los cambios que suelen aparecer al revisar una versión. Se realizaría gestión de alcance tanto a nivel de proyecto (o entrega) como a nivel de Sprint. Para la gestión a nivel de entrega, tal como vimos en el proceso incremental, se requeriría una definición y estimación para todos los ítems, con diferente nivel de detalle, discriminando entre los más ítems más protagonistas (los primeros en cogerse desde el Backlog) y los menos. En cambio para la gestión de alcance del Sprint, idealmente éste, al arrancar, debería tener definidas en detalle los ítems que se incluyen en él.

Para potenciar estas ventajas se recomienda que los Sprints sean de la misma duración para así conseguir una cadencia, un ritmo sostenible de trabajo. Scrum sugiere que los Sprints sean de a lo más 4 semanas de duración.

Desventajas

• Al igual que en proceso incremental, el cliente tiene que participar activamente durante todo el proyecto (aunque como indiqué antes esto no debería ser una desventaja). Al usar Sprints el cliente tiene un cierto "respiro" en cuanto a la frecuencia de las revisiones de versiones, pues no se realizaría al terminar cada ítem sino que al terminar cada Sprint.  

Los métodos ágiles Scrum y Extreme Programming utilizan iteraciones (Sprints).

Conclusiones

• No existe un modelo de proceso que sea el mejor para todas las situaciones, sin embargo, en contextos donde se esperan cambios un proceso incremental es más apropiado que uno en cascada. 
• Si disfrutamos de una relación de confianza entre el cliente y el proveedor deberíamos intentar acercarnos a un proceso incremental (no iterativo), pues así no tenemos que "distraernos" en gestión de alcance, definiciones anticipadas y cálculos de estimación. 
• Cuando los compromisos con el cliente son poco flexibles un proceso iterativo e incremental es lo recomendable pues en él la gestión de alcance es protagonista, tanto a nivel de cada Sprint como del proyecto completo.
• Finalmente, es importante destacar que un mismo equipo puede ser responsable de varias líneas de trabajo, es decir, puede estar trabajando en diferentes proyectos, productos o servicios. El modelo de proceso más eficaz debe evaluarse en cada una de dichas líneas de trabajo.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com 

¿Qué es ser ágil? ¿por qué debería interesar ser ágil?

¿Qué es ser ágil?
Un primer intento por responder esta pregunta ya lo hice en un post hace unos años: Agilismo en pocas palabras. Pero viendo que el sesgo mediático hacia Scrum sigue campando a sus anchas me he animado a dedicar la primera parte de este post a reivindicar que Scrum es solo una parte del agilismo :-), y la otra parte a argumentar por qué vale la pena ser ágil.

Ser ágil conlleva el comulgar y aplicar los valores y principios del Manifiesto Ágil. Lo claro y sencillo es la comprensión de dichos valores y principios generales, lo más complicado y menos evidente es cómo constatar en acciones concretas del día a día que efectivamente se están aplicando dichos valores y principios.

Podríamos suponer que si usamos un método ágil estaremos siendo ágil. Pero, ¿qué método deberíamos usar?, podríamos elegir entre los más populares: Kanban, Lean Development, Scrum o Extreme Programming. Pero, no son todos iguales, ¿en qué se diferencian? ¿cuál es el mejor?. Tengo la impresión que estas dudas están bastante extendidas, pues recurrentemente me encuentro con la necesidad de responder a esta cuestiones :-).

Detrás de los principios ágiles y de los métodos ágiles lo que debemos identificar y conocer son Prácticas Ágiles. El método Extreme Programming (XP) presenta una lista explícita y concreta de 12 prácticas ágiles, muy estrechamente relacionadas, apoyándose unas con otras y creando sinergia en su aplicación conjunta. Kent Beck el autor de XP explica en su libro que el apelativo "Extreme" del nombre de su método se refiere a aplicar el máximo de prácticas y en la mayor intensidad posible, a ello se refería con "extrema".

Si analizamos los métodos ágiles descubriremos que existen prácticas ágiles comunes entre métodos y otras exclusivas de alguno de ellos. Pero sin lugar a dudas, si optamos por elegir un método, estaremos ignorando prácticas ágiles de otros métodos que podrían sernos útiles. Lectura recomendada: ¿Kanban o Scrum?, that is not the question. Las prácticas ágiles deben verse como oportunidades para mejorar nuestra forma de trabajo, con lo cual NO debemos centrarnos en evaluar un método ágil para aplicarlo sino que debemos evaluar qué prácticas ágiles podemos aplicar, y tal como decíamos antes, mientras más prácticas y en mayor intensidad se apliquen, más significativa será la mejora que consigamos.

Para ayudar en la comprensión de las prácticas ágiles hemos desarrollado el sitio AgileRoadmap+, un servicio gratuito que presenta una lista de 42 prácticas ágiles extraídas de los métodos ágiles más populares, presentadas de una forma genérica (para facilitar su comprensión en contextos que no son de software), y establecidas con mucha granuralidad para facilitar su selección y decisión respecto de su nivel de aplicación.

Así pues, "ser ágil" no es un todo o nada. Probablemente no podrás aplicar todas las prácticas ágiles, ni todas en su mayor intensidad. Tampoco significa que no se apliquen practicas tradicionales. La implantación de prácticas ágiles podría conllevar una evolución que al menos al empezar deba convivir con prácticas más tradicionales. Algunas prácticas tradicionales son complementarias a las prácticas ágiles, es decir, cubren necesidades de proceso no abordadas por las practicas ágiles, por ejemplo, gestión de riesgos, gestión de proveedores, prácticas específicas del contexto (asociadas a aplicación de técnicas específicas para el análisis, diseño o construcción del producto). Todo esto tampoco significa que cualquier aplicación parcial de prácticas ágiles deba considerarse como una implantación ágil. Lo realmente interesante es tener conciencia de qué prácticas ágiles se están aplicando y en qué nivel de intensidad, y qué prácticas ágiles no se están aplicando (y por qué no).

¿Por qué debería interesarnos ser ágil?
Probablemente bastaría solo con la comprensión de las prácticas ágiles para convencernos que nos conviene aplicarlas :-). Sin embargo, podemos ser más exigentes en cuanto a los argumentos que nos animen a embarcarnos en una implantación de prácticas ágiles.

Una forma sencilla y sensata de argumentar la utilidad de las prácticas ágiles es estableciendo su contribución a objetivos del ámbito candidato para la implantación. Según esto, a continuación se presenta un esquema que relaciona objetivos de mejora y prácticas ágiles (del catálogo de prácticas ágiles de AgileRoadMap+).

A nivel global los objetivos se han clasificado en tres dimensiones de mejora (identificados por su letra inicial):

• [S]atisfacción del cliente
• [P]roductividad. En el post ¿Cómo puede un enfoque ágil aumentar la productividad? explico más en detalle esta dimensión.
• [M]otivación y compromiso del equipo

En el siguiente esquema se representan con puntos las prácticas ágiles, como sectores los objetivos y en los círculos concéntricos desde adentro hacia afuera se representa el grado de contribución de los objetivos a la correspondiente práctica, así, una práctica que esté más hacia el interior contribuye de forma mayor que una práctica que se encuentra más hacia el exterior. Además, una práctica puede estar repetida en diferentes sectores cuando contribuye a diferentes objetivos.

Descarga desde este enlace una presentación en la cual poniendo el cursor sobre el punto de la práctica puede leerse su nombre. Además, con la mismos números identificativos, en este enlace está la lista de prácticas ágiles del AgileRoadmap+.

Con esta información, seleccionando los objetivos más importantes en el ámbito en el cual se hará la implantación de prácticas ágiles podemos identificar qué prácticas ágiles pueden contribuir a conseguir dichos objetivos.

El objetivo "OBJ3: Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades" está explicado en detalle en el post de este link.

En AgileRoadmap+ encontrarás además información respecto de desafíos de cada práctica y relaciones entre prácticas, lo cual te ayudará a seleccionar las prácticas ágiles con las que sería recomendable comenzar la implantación ágil.


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

Agilidad en la economía doméstica y su extrapolación en el ámbito empresarial

Me atrevería a decir que la práctica ágil más fundamental es: "Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente" (es la Práctica 01 de nuestro catálogo de prácticas ágiles Agilev-Roadmap). Esta práctica es enfatizada a través de múltiples conceptos en la bibliografía, tales como: "Diseño Simple" en Extreme Programming, MVP (Minimun Viable Product)  de Lean Startup, MMF (Minimun Markeable Features), el principio KISS (Keep it simple stupid), YAGNI (You aren't gonna need it), unos de los 7 Mudas de Lean Manufactoring, el asociado a sobreproceso, y finalmente, los 5 Why's.

Cuando examinamos el uso o aprovechamiento de los productos (también es aplicable a servicios) adquiridos en empresas nos encontramos que en muchos casos no se utilizan o aprovechan gran parte de las características ofrecidas. Esta situación podría estar razonablemente justificada cuando se debe a que dichas características menos usadas o prescindibles no han aumentado el precio/costo, o forman parte de un paquete genérico que ya tenía incluidas esas características. Sin embargo, cuando se trata de la adquisición de un producto a medida (en el cual se seleccionan explícitamente las característica que se incluirán), y cuando esas características no esenciales tienen una repercusión importante en el precio o plazos, deberíamos ser más críticos respecto del por qué incluir dichas características.

Existen tres niveles/oportunidades donde se puede garantizar que un producto se ajusta a necesidades reales:

1. Al establecer la necesidad de un producto, cuando se incluye en el portafolio y se le otorga una prioridad haciéndolo competir con el resto del proyectos.
2. Al determinar las características que se incluirán en el producto. Esta oportunidad se da en el marco de la definición del producto. Una selección de características más allá de las estrictamente necesarias conllevará más costos y/o tiempo para conseguir el producto. 
3. Al determinar el nivel de sofisticación de cada característica. El contar o no con una característica no es un todo o nada, la misma característica puede estar disponible pero en un diferente nivel de sofisticación. 

Por ejemplo, si en un sistema para gestión de espacios una necesidad que debe satisfacer es apoyar la tarea "Reservas de espacios para actividades", para esto se podrían ofrecer lo siguiente: 

• Se deben introducir los datos de la asignación (fecha-hora, espacio, actividad, etc.). Si el espacio no está disponible para la fecha-hora solicitada se muestra un mensaje y se solicita volver a intentarlo con otros datos. 
• Se muestra la planificación semanal de reservas actuales para una fecha-hora y espacio específico. Se permite reservar un espacio en una fecha-hora que está libre.
• Se deben introducir rangos de fechas-horas (y otros datos relevantes), según esto se ofrece una lista de fecha-horas y espacios disponibles, en la cual se puede seleccionar una de ellas.   

Como se observa, una misma necesidad siempre tiene alternativas en cuanto a la sofisticación de la solución. Decidir un nivel de sofisticación no tiene por qué conllevar una renuncia a un nivel superior, sino que puede ser un paso en el desarrollo incremental de la característica, es decir, que posteriormente se podría elevar su nivel de sofisticación.   

Desgraciadamente, con mucha frecuencia los productos resultantes de proyectos no consiguen rentabilizar los recursos y el tiempo invertido en ellos, o bien dicha rentabilización tarda mucho en materializarse debido a que los usuarios no son capaces de aprovechar inmediatamente todas las características ofrecidas. Por lo tanto, el producto podría haber tenido menos características, o características menos sofisticadas, o las características se podrían haber ido incorporando incrementalmente.  

Sin embargo, en el ámbito doméstico esta práctica ágil asociada a establecer una solución mínima (al menos como primera instancia) suele estar muy arraigada. Examinemos la siguiente situación ficticia:

Nos hemos comprado una casa en el campo con un gran terreno, tal como se muestra en la siguiente figura.

Nuestra familia está encantada con las expectativas que ofrece el terreno. La esposa y los niños quieren una piscina, el marido piensa en un garaje-taller y en un quincho (sitio para hacer barbacoas), también se ha mencionado hacer una pista de padel y una multicancha. Todo esto se refleja en la siguiente figura.

Esto podría ser visto como nuestro portafolio de proyectos de la familia. Ahora, supongamos que no es posible llevar a cabo todos estos proyectos domésticos por restricciones de presupuesto. Una posible estrategia sería concentrarnos solo en aquellos proyectos más prioritarios y concentrar allí toda nuestra inversión. Pensemos que la elección pudiese ser optar por los proyectos Quincho y Piscina, los cuales tienen una definición como la siguiente (precios inventados):

Estas definiciones de proyecto tienen un alto nivel en cuanto a características y conllevan además un precio alto, consideraciones de plazos de entrega y de costos de mantenimiento. Además, supongamos que el quincho, prefabricado en Alemania, y que deben adaptarse las conexiones de electricidad y tuberías a la normativa de nuestro país. Es decir, hay que realizar tareas e inversión adicional en cuestiones de adaptación. Podríamos tener el dinero e incluso estar dispuestos a asumir los plazos y otras consideraciones, sin embargo, lo normal es que el mismo fin de semana de la compra se quiera disfrutar de la nueva propiedad, por ejemplo, invitando a nuestros amigos a una barbacoa :-), y también nos gustaría ver a los niños disfrutando del buen clima refrescándose en el agua. En esta reflexión a corto plazo, como veremos, nos surgirá de forma natural la "agilidad doméstica". Básicamente activamos una dimensión adicional y siempre disponible para la evaluación de cada proyecto doméstico: la sofisticación del proyecto o de cada una de sus características, tal como se ilustra en la siguiente figura:

Probablemente en el caso del quincho rápidamente nos decidamos a comprar una barbacoa, y por parte de la piscina pensaremos en alternativas más sencillas y razonablemente económicas. Y luego, con el paso del tiempo, y según cómo vayamos observando el aprovechamiento real que hagamos de ello pensaremos en opciones más sofisticadas, las cuales podrían complementar a la opción actual o directamente podría asumirse un reemplazo de lo actual, resignándose incluso a desechar la opción previa.

Opciones con diferente nivel de sofisticación para el quincho:

Opciones con diferente nivel de sofisticación para la piscina:

Una vez que somos capaces de aceptar una opción más modesta en cuanto a características tendremos además la posibilidad de abordar a la vez otros proyectos que hubiésemos descartado (el garaje-taller, la pista de padel, o la multicancha) y para los cuales aplicaríamos la misma discriminación en cuanto a grado de sofisticación.

¿Por qué en la empresa no se aborda la selección de proyectos y el nivel de sofisticación de las características de cada uno de la misma forma como lo haríamos en nuestra economía doméstica? La respuesta sencilla es: porque en la empresas el dinero no es nuestro :-). Cuando pensamos en un nuevo coche, seguro que un Ferrari u otra marca deportiva se nos viene a la mente, sin embargo, a menos que nos sobre el dinero, no nos gastaríamos tanto en un coche. Pero podría haber otras justificaciones en las empresas para ir a soluciones más ambiciosas y probablemente menos aprovechadas, por ejemplo:

• Normalmente en cada nivel jerárquico de una empresa se compite por conseguir la máxima asignación de recursos para sus proyectos. Y luego cuando se consigue financiación siempre se gasta todo. Esto suele conllevar grandes ineficiencias pues los recursos al gastarse totalmente pueden llegar a conseguir resultados cuestionables respecto de su rentabilidad.
• A veces las empresas se ven sometidas a soluciones más ambiciosas en cuanto a características debido a que la competencia cuenta ya con una solución de alto nivel. Esto podría tener una equivalencia en el ámbito doméstico, por ejemplo, cuando por envidia con tu cuñado, el cual se ha instalado una super piscina, decides adquirir una piscina que supere la suya :-). 

Debemos promover esta práctica fundamental del enfoque ágil. Debe ser un ejercicio diario, a nivel personal y profesional. Tanto en la economía doméstica como en la de nuestra empresa, debemos conseguir rentabilizar la inversiones asociadas a  adquirir productos o servicios.


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com

¿Cómo puede un enfoque ágil aumentar la productividad?

Cuando se plantea una mejora de un proceso, se trate de un proceso de producción o mantenimiento, o un proceso asociado a un servicio, uno de los objetivos protagonistas para impulsar la iniciativa de mejora es "conseguir un aumento de la productividad", sin sacrificar la calidad, y más aun, si es posible incluso de paso aumentando la calidad.

Sin entrar en las múltiples definiciones de la palara productividad o en los términos específicos derivados de ella, para lo que sigue de este post me quedo con la acepción económica de la palabra productividad ofrecida por la RAE: "Relación entre lo producido y los medios empleados, tales como mano de obra, materiales, energía, etc. La productividad de la cadena de montaje es de doce televisores por operario y hora".


A cualquier directivo le gustaría escuchar algo al estilo de lo siguiente: "con el enfoque ágil se consigue un aumento de un 40% de la productividad". Sin embargo, en muchos contextos es muy difícil hacer una medición tan precisa como esa. Primero simplemente porque las unidades de trabajo (requisitos, indicencias, tickets, expedientes, informes, o lo que sea que el equipo de trabajo genera o atiende), no son iguales, ni siquiera uniformes, es decir, no se trata de producir televisores, o poner un ladrillo sobre otro :-). Así pues cada unidad de trabajo requiere un esfuerzo diferente. Por otra parte, tampoco es muy certero hacer una comparación entre la productividad que se tiene en un determinado momento y luego en otro, especialmente porque el contexto puede no ser comparable, por ejemplo, los equipos, la tecnología, los proyectos, los clientes, etc, probablemente no serán los mismos en ambos momentos. Además, es importante destacar que cada equipo de trabajo, y más aún, cada línea de trabajo (cada proyecto, producto o servicio) encargada a un equipo de trabajo tiene su propio contexto, el cual condicionará la mejora de productividad que se pueda conseguir en dicho contexto.


Así pues, no sería capaz de prometer un aumento concreto de productividad en un equipo de trabajo, sin embargo, puedo describir por qué un enfoque ágil, sin lugar a dudas, generará un aumento en la productividad de cualquier equipo de trabajo.Obviamente, me refiero a un aumento de productividad que no implica aumentar los resursos o el personal, ni trabajar más horas, sino que la estrategia es ahorrar esfuerzo mal invertido para aprovecharlo invirtiéndolo correctamente, o mejorar el desempeño el equipo y de sus integrantes mediante una mejor organización del trabajo.

Para argumentar la potencial contribución que el enfoque ágil puede hacer en cuanto a productividad me basaré en las prácticas ágiles catalogadas en AgileRoadmap+ una herramienta que hemos desarrollado para evaluar la aplicación de prácticas ágiles. Cada práctica constituye una oportunidad de mejora, sin embargo, su efectividad podría variar según el contexto y dependiendo de la intensidad con la que se aplica la práctica.

Por lo tanto, si nuestro objetivo es aumentar la productividad, a continuación se indican en orden de mayor a menor contribución, qué prácticas ágiles contribuyen a conseguir este objetivo, y cómo.

Práctica ágil	Cómo contribuye a aumentar la productividad
PRA01. Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente.	Cuando ni el cliente ni el equipo de trabajo estudian la posibilidad de postergar o incluso quitar elementos prescindibles en cuanto al resultado esperado se corre un alto riesgo de invertir esfuerzo en esos aspectos que probablemente no generan valor, y que además posiblemente complicarán el trabajo. Ese esfuerzo ahorrado en elementos no imprescindibles puede ser muy significativo.
PRA07. Evitar invertir esfuerzo en adelantar trabajo que no esté comprometido y/o no esté cercano a su entrega.	El esfuerzo invertido en realizar trabajo con demasiada anticipación tiene un alto riesgo de ser desperdiciado. Si el contexto es cambiante dicho trabajo puede ir perdiendo prioridad por otros trabajos que aparezcan, puede quedar obsoleto por las modificaciones que  se requieran al intentar aprovechar dicho trabajo adelantado, o incluso pueden que nunca llegue aprovecharse.
PRA28. Documentar, pero solo lo estrictamente necesario. Que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla.	La documentación se puede aprovechar durante el proceso realizado para generar el resultado, o puede llegar a aprovecharse como acompañamiento del resultado. En ambos casos podríamos llegar a rentabilizar el esfuerzo invertido en documentar.  Sin embargo, cuando no se consigue dicha rentabilización debería considerarse una reducción o eliminación de cierta documentación, ahorrando esfuerzo invertido en su elaboración.
PRA02. Abordar y entregar trabajo terminado de forma incremental.	Cuando la entrega del resultado se hace de forma incremental se tiene la oportunidad de confirmar (o no) la conveniencia de invertir esfuerzo en trabajo previsto anteriormente. Así, es más seguro avanzar hacia el resultado mitigando el riesgo de invertir esfuerzo en elementos que no aportarán valor y al mismo tiempo poder incluso reemplazarlos por otros que se descubran de mayor interés.
PRA10. Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad	Tanto a nivel de trabajo encargado a un equipo como a nivel de trabajo encargado a una persona, el hecho de estar cambiando de un trabajo a otro en corto tiempo (en el mismo día o semana) afecta negativamente el rendimiento. La supervisión y organización del trabajo, para limitar o reducir los trabajos que debe estar realizando un equipo o una persona simultáneamente puede mejorar significativamente el desempeño.
PRA20. El equipo se auto-organiza y toma las decisiones técnicas	Cuando los miembros del equipo no son proactivos y esperan siempre por instrucciones respecto de quién, cómo y cuándo se debe realizar ciertas tareas técnicas, en esta situación se corre el riesgo que se produzcan esperas que lleven al equipo a ocuparse de trabajos que quizás son menos prioritarios que aquellos por los cuales están esperando instrucciones.
PRA26. Que los integrantes del equipo puedan encargarse de diferentes tipos de actividades (ojalá de todas), aunque puedan ser especialistas en alguna(s) de ellas.	Durante un proceso es natural que se presenten situaciones en las cuales la carga de trabajo es significativamente diferente en las diferentes actividades. Un cuello de botella en una actividad puede conllevar a que los integrantes del equipo que no realizan dicha actividad deban parar para ocuparse en otros trabajos mientras se resuelve el cuello de botella. Cuando los integrantes de un equipo pueden echar una mano en cualquier actividad, se garantiza que el proceso puede recuperarse rápidamente de cualquier cuello de botella, invirtiendo esfuerzo en la actividad afectada.
PRA11. Formar equipos pequeños y procurar que mantengan sus integrantes.	En procesos que requieren un trabajo muy colaborativo, la comunicación entre los integrantes del equipo es esencial. Evidentemente en un equipo pequeño (p.e. no más de 10 integrantes) la comunicación es más fluida, especialmente cuando hay que explicar y llegar a acuerdos en reuniones.
PRA25. Que el equipo sume entre sus miembros las habilidades para abordar todas las actividades necesarias para terminar el trabajo.	Cuando el equipo no tiene algún conocimiento o habilidad entre sus miembros probablemente dependerá de otra persona o equipo (interno o externo) para poder continuar o terminar su trabajo. Los protocolos asociados a la solicitud y recepción del trabajo realizado fuera del equipo provocarán posiblemente esperas o cambios de trabajo mientras no se reciba el trabajo encargado.
PRA41. Promover que los miembros del equipo en su trabajo lleguen a conocer todas las partes del producto o servicio que han sido encargadas al equipo.	Otra situación que puede provocar una espera para continuar o terminar un trabajo es cuando en el equipos hay integrantes que tienen la exclusividad en cuanto a conocimiento y habilidades para abordar el trabajo en una parte del producto o servicio encargado al equipo.
PRA22. Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico	La comunicación cara-a-cara es el medio de comunicación más eficiente. Cuando el equipo no está co-localizado existe el riesgo que estemos invirtiendo más tiempo del necesario para tomar decisiones o comunicar ideas, especialmente cuando esto obliga a una mayor elaboración de comunicación textual. Sin embargo, no todos los actos de comunicación requieren una comunicación presencial cara-a-cada y pueden realizarse con otros medios tales como el chat, email, o incluso videoconferencia.  Es importante tener acordados claramente qué medios deben utilizarse y en qué situaciones.
PRA23. Contar con un espacio físico de trabajo que favorezca la interacción entre los miembros del equipo	El espacio de trabajo también puede ser una barrera para colaboración entre los miembros del equipo (incluso cuando está ya co-localizados). Así pues, es importante que el espacio físico adecuado complemente la co-localización del equipo.
PRA37. Establecer una disciplina de aprovechamiento de las reuniones	Esta práctica contrarresta el posible efecto negativo que puede generarse cuando un equipo no está habituado a realizar reuniones o simplemente cuando estando habituado, sus reuniones tienden a ser largas y dudosamente productivas. Debe implantarse una disciplina que asegure que las reuniones sean productivas. Uno de los aspectos claves es que cada reunión cuente con un buen moderador, que fije lo objetivos, regule las intervenciones, esté vigilante del tiempo y del progreso adecuado de la reunión, etc.
PRA12. Acotar el ámbito de trabajo de cada equipo.	En caso de productos o servicios de gran envergadura si se tiene bastante personal, lo recomendable es formar equipos encargados de ciertas áreas. Esto favorecerá la especialización del trabajo en dichas áreas pero no necesariamente en que dicha especialización recaiga en una sola persona. Con lo cual se mantiene la ventaja que no dependemos de una persona y en caso de no estar disponible se genere una espera.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com