viernes, 27 de octubre de 2017

¿Desarrollo Incremental implica Especificación Incremental? ¿Debería implicarlo?


Muchas veces he visto cómo se plantea el modelo de proceso (la estrategia global de desarrollo) como el principal elemento que diferencia a una metodología tradicional (asociándola a un modelo Waterfall, en cascada) y a una ágil (asociándola a un modelo iterativo e incremental). Puede que esto valga como comparación ultra-simplificada del Enfoque Tradicional versus el Enfoque Ágil, pero al hacerlo se incurre en varios errores. Primero, si bien el modelo de proceso es importante, no lo es todo, hay muchos otros aspectos diferenciadores entre ambos enfoques. Segundo, todos los métodos ágiles proponen un modelo de proceso incremental, pero no todos requieren que también sea iterativo. Scrum y Extreme Programming son claramente iterativos (utilizan Sprints) e incrementales, sin embargo, Kanban, por ejemplo, es solo incremental. Y en tercer lugar, y a propósito de lo que comentaré en este post, un proceso incremental NO solo lo es respecto de la construcción del producto, sino que también puede/debe serlo en su especificación.
En la figura A se observa una representación temporal de esfuerzo dedicado a especificación de requisitos (R) y a construcción (C) en lo que sería un modelo de proceso secuencial. En este modelo de proceso todo se especifica en detalle antes de comenzar a construirse, y no se pretende hacer ninguna entrega parcial hasta que no esté todo construido.


Rational Unified Process (RUP) es en desarrollo de software la metodología tradicional de referencia. RUP utiliza un modelo de proceso iterativo e incremental pero no por eso es una metodología ágil. En gran medida la clasificación de "Tradicional" para RUP yo se la otorgo porque la mayor parte de la especificación se hace de forma anticipada (con o sin iteraciones), durante la llamada Fase de Elaboración, en la cual se realiza en detalle la especificación de requisitos, análisis y diseño del sistema, para posteriormente, en la Fase de Construcción abordar iterativamente la construcción del producto. Como se muestra en la figura B lo que hace RUP diferente respecto de un enfoque secuencial es realizar la construcción de forma iterativa. Esto permite detectar posibles defectos de especificación u otros cambios necesarios al evaluar el resultado de cada iteración, sin embargo, la mayor parte del esfuerzo de especificación se concentra en la Fase de Elaboración. Según lo anterior, la siguiente imagen ilustra un proceso como el de RUP, con especificación anticipada y posterior construcción iterativa (considerando además una situación ideal en la cual no hay re-trabajo o cambios en cuanto a requisitos durante la construcción).

¿Pero es esta estrategia de desarrollo a su vez incremental? Scrum define que el resultado de un Sprint (iteración) debería ser una versión potencialmente entregable de un producto, debería ser un incremento del producto tal que en algún momento puede llegar a ser una entrega parcial que se pase al cliente para que la utilice. Según esto, realizar iteraciones no necesariamente es conseguir incrementos del producto. Así pues, como se observa en la figura B, aunque en la Fase de Elaboración de RUP se pueda especificar en iteraciones, éstas nunca darán como resultado un incremento del producto. Solo durante la Fase de Construcción de RUP se tendría la posibilidad de conseguir incrementos del producto puesto que en cada iteración se obtendrían requisitos implementados. Sin embargo, el planteamiento de RUP contempla solo una entrega total al finalizar la Fase de Transición (después de la Fase de Construcción). Lectura recomentada: Desarrollo Iterativo versus Incremental ... o ¿cuál es la mejor estrategia para pintar la Mona Lisa?.

Concentrar la mayor parte de la especificación del sistema al inicio está alineado con el establecimiento de un contrato a Precio-Fijo, ya que antes de comenzar la construcción se puede así conseguir un presupuesto que fije alcance, plazo y precio. Sin embargo, como ocurre en muchos proyectos, cuando el grado de incertidumbre es alto, por mucho tiempo que se le dedique a una especificación anticipada, esta no será eficaz pues se prevé que de todos modos habrá cambios durante el proyecto. Los cambios obligarán a rehacer especificaciones o simplemente descartarlas por obsoletas o por decidir posteriormente no implementarlas.

Mi impresión, por lo que he observado en empresas que dicen usar un Enfoque Ágil, es que su proceso se parece bastante al de RUP ilustrado en la figura B. La especificación detallada mayoritariamente la hacen anticipadamente, junto a la firma del contrato. Es decir, al menos en este aspecto siguen siendo tradicionales :-).

¿Pero es factible que la especificación también se realice de forma incremental? ¿Es factible un desarrollo incremental que incluya también una especificación incremental? ¿Sería esto compatible  con una adecuada gestión de alcance y/o un contrato del tipo precio-fijo?

La respuesta es sí, es factible hacer una especificación incremental y alinearla con un proceso de construcción incremental. Para esto debemos diferenciar entre "identificar" requisitos y "especificarlos en detalle". Si queremos gestionar el alcance de de un proyecto es vital que tengamos identificados los requisitos involucrados en dicho alcance (al menos la mayoría y entre ellos los más importantes). Pero identificar un requisito es ponerle un nombre y poco más. Lo que sucede es que tenemos la natural tendencia a especificar anticipadamente un requisito porque queremos tener estimaciones que nos permita establecer el alcance y acordar un compromiso, no es porque lo necesitamos ya para implementar cada requisito. La especificación detallada de un requisito se podría postergar en extremo hasta el instante justo antes de comenzar a implementarlo.

Veamos dos alternativas factibles de desarrollo incremental que incluye también especificación incremental. En la Figura C se presenta un proceso en el cual al comienzo y por un breve período se realiza una identificación de los requisitos (su nombre y poco más), por eso este bloque inicial R tiene un color menos intenso. Después de esta breve identificación de requisitos se hace un ordenamiento estratégico de ellos, el cual corresponderá con su orden de implementación. A continuación, los requisitos que se implementarán primero se especifican en detalle y luego se implementan. Si además, este primer conjunto de requisitos tiene una orientación MVP (Mínimo Producto Viable) con su implementación podríamos ya tener una primera entrega parcial (primera realease). A partir de ahí, y posiblemente con ciertos espacios entre nuevos desarrollos de incrementos, se continuaría con el desarrollo del resto de requisitos en ciclos cortos de especificación detallada y construcción.

Pero ¿cómo podríamos firmar un contrato y gestionar el alcance durante el desarrollo si no tenemos una especificación detallada de los requisitos al inicio?. Si el equipo ejecutor tiene experiencia en cuanto a la solución que debe implementar no debería tener inconvenientes en realizar buenas estimaciones contando solo con requisitos identificados (sin mayor especificación). Pero si en el equipo no tiene dicha experiencia, lo cual incrementa la incertidumbre, aún así tendremos siempre tres apoyos respecto de las estimaciones. Primero, si hemos hecho un ordenamiento estratégico de los requisitos, probablemente los de mayor valor y/o riesgo serán los primeros en implementarse, pues entonces éstos serán inmediatamente especificados en detalle y se podrá tener un estimación más argumentada para ellos al inicio del desarrollo. Segundo, en situaciones de incertidumbre respecto de la estimación si se realizan estimaciones normales (ni pesimistas ni optimistas), probablemente las sub-estimaciones se compensarán globalmente con las sobre-estimaciones, habría que tener demasiada mala suerte para que todas la estimaciones resulten estar por debajo de lo real :-). Tercero, en un caso puntual de imposibilidad para poder asignar una estimación a un requisito por inexperiencia técnica para implementarlo o poca claridad respecto a su definición, se puede hacer algún prototipo que ayude a reducir esa incertidumbre y poder dar una estimación.

Una variación del modelo de proceso mostrado en la Figura C, más extrema en cuanto a la especificación incremental, se muestra en la Figura D. En este caso, con o sin una estrategia MVP, se realizan Sprints más cortos y se solapa la construcción del Sprint actual con la especificación detallada de lo que se implementará en el siguiente Sprint. Esto se hace hasta conseguir una primera release. A partir de allí se podría seguir con dicho solapamiento, o realizar Sprints no continuos según el ritmo posterior de desarrollo o mantenimiento que requiera el producto. 


Lo importante es tener en cuenta que existen alternativas y variantes sobre ellas. La elección del modelo de proceso debe estar basada en el contexto de desarrollo de cada producto. Las ventajas de los modelos iterativos e incrementales (y que además incluyen especificación incremental) son mucho mayores cuando el contexto nos hace prever cambios durante el desarrollo. Lectura recomendada: Modelos de proceso para desarrollo ágil.


Patricio Letelier




jueves, 29 de junio de 2017

Tableros kanban en dos niveles: desde pedidos de una pizzería a gestión de portafolio

Advierto que este post no va de cómo se cocinan los proyectos :-), sino de unas interesantes analogías entre la gestión de pedidos en una pizzería y un portafolio de proyectos respecto de trabajar con tableros kanban sincronizados, en este caso tableros en dos niveles, un kanban general (pedidos de pizzas o portafolio de proyectos) y otro kanban detallado (pizzas y trabajo dentro de un proyecto).

Arranquemos con el ejemplo de la pizzería donde se reciben pedidos de pizzas. Un pedido puede incluir una o más pizzas de diferente tipo y tamaño (por ejemplo, pedido del Sr. Pérez: 2 margaritas medianas y una cuatro estaciones grande). Supongamos que en el trabajo de la pizzería para atención de sus clientes se identifican las siguientes actividades: Tomar Pedido, Preparar Masa, Añadir Ingredientes, Hornear, Armar Pedido y Entregar. El siguiente tablero kanban podría servir para visualizar el estado del trabajo.


Pero la pregunta clave es ¿qué ítems son los que aparecen en el kanban? ¿Representan los pedidos de pizzas o cada una de las pizzas de los pedidos?. Hay algunas columnas que delatan que el trabajo se hace a nivel de pedido (por ejemplo: Tomar "Pedido" o Entregar "Pedido") y otras en las que el trabajo se hace a nivel de pizzas (por ejemplo, Añadir Ingredientes). Claramente hay dos perspectivas del proceso, de cara al cliente es importante saber cómo va la elaboración de su pedido como un todo, y desde el punto de vista del trabajo interno de la pizzería lo que se manejan son pizzas. Entonces las alternativas de ítems a utilizar en nuestro tablero kanban serían: Pedidos, Pizzas (de un pedido) o incluso Pedidos y Pizzas (ambos tipos de ítems). Veamos las ventajas e inconvenientes de cada alternativa:

  • Ítems=Pedidos: Es más sencillo conocer el estado del pedido. Es más fácil la gestión de información pues siempre habrá menos pedidos que pizzas con lo cual el tablero tendrá menos ítems. Sin embargo, físicamente todas las pizzas del pedido deberían estar en la misma actividad a la vez (en la actividad que esté su Pedido) o tener algún truco para indicar que un pedido está en más de una actividad.
  • Ítems=Pizzas: Puede ser más difícil de gestionar el pedido pues las pizzas como ítems podrían estar en diferentes actividades, pero deben entregarse todas en conjunto (y calientes :-) ). Además, podemos llegar a tener muchos ítems en el tablero.
  • Ítems=Pedidos y Pizzas: Podría pensarse como una solución más detallada que combina algunas ventajas de las dos anteriores y aparentemenre reduciría sus inconvenientes, pero puede ser peor esta alternativa porque hay que gestionar dos típos de ítems a la vez y conjuntamente (el ítem Pedido y sus ítems Pizzas).

Probablemente ninguna de las alternativas anteriores resultará del todo cómoda pues lo que hay detrás de esta situación es que estamos mezclando dos niveles de trabajo (Pedidos y Pizzas incluidas en los pedidos). El trabajo y la gestión de ambos debe estar coordinado pero probablemente es más sencillo y fácil de gestionar si se representan estos dos niveles como dos tableros kanban coordinados. La siguiente figura muestra un ejemplo de lo que podrían ser estos dos tableros kanban.


Como en el kanban detallado tendremos pizzas de diferentes pedidos, deberíamos contar con un mecanismo para diferenciar los ítems e identificar fácilmente cuáles son de un mismo pedido (por ejemplo, con colores o etiquetas). En cualquier caso, y ya poniéndonos en terreno, sea cual sean los tableros e ítems utilizados, las pizzas en la cadena de producción normalmente se acompañan del ticket del pedido durante todo el proceso, y son los encargados quienes van verificando el avance en conjunto de todas las pizzas del pedido.

Una vez explicada la situación de la pizzería, llevémoslo al contexto de un portafolio de proyectos. En organizaciones con un cierto grado de madurez en la gestión de sus proyectos es normal que tengan definido un flujo de trabajo para sus proyectos, que incluya estados tales como: Propuesto, En Evaluación, En Ejecución, Cerrado, etc.. Los nombres y el detalle de estado pueden obviamente ser diferentes. Sin embargo, estos estados corresponderían con las columnas del tablero kanban que ilustraría el estado de los proyectos (el estado del portafolio de proyectos), es decir, sería un equivalente a los pedidos de la pizzería. Y además, la columna "En Ejecución" estaría detallada en otro(s) tablero(s) kanban que representarían el estado de ejecución de cada uno de los ítems en los proyectos. Por ejemplo, si fuera un proyecto de desarrollo de software el tablero kanban detallado (el equivalente al de las pizzas) contendría ítems del tipo Nuevo Requisito, Mejora o Corrección de fallo, y las actividades serían del tipo Especificación, Programación, Pruebas, etc. Así, en algún momento los ítems de un proyecto se terminan y el proyecto como un todo (en el kanban de proyectos) saldría del estado "En ejecución" pasando al siguiente estado en el kanban de portafolio. Tal como en el caso de las pizzas, los ítems de cada proyecto deberían poder distinguirse o filtrarse fácilmente (para evitar tener un kanban para cada proyecto).



Patricio Letelier

www.tuneupprocess.com 

sábado, 10 de junio de 2017

Sprints, "welcome to the real world" ...

Un Sprint es un contenedor/agrupador de ítems de trabajo que se implementan en un período de tiempo. El uso de Sprints se ha convertido casi en sinónimo de estar aplicando Scrum. Pero Scrum es bastante más que el solo concepto de Sprint. Además, el modelo de proceso iterativo e incremental no es una exclusividad de Scrum, también está presente en otros métodos ágiles, aunque en lugar de Sprint se utilizan el término Iteración. Incluso RUP, una metodología tradicional, sigue un proceso iterativo e incremental claramente basado en iteraciones. También se suele contraponer Scrum y Kanban en cuanto a usar o no usar Sprints. Vistos como métodos, Kanban no cuenta con el concepto de Sprint, y Scrum en su propuesta original no dispone de un tablero para visualizar el estado del trabajo (tablero kanban). Sin embargo, desde la perspectiva de prácticas ágiles, el uso de dicho tablero es fundamental siempre, y el uso (opcional) de Sprints es un excelente complemento para la organización del trabajo (lecturas recomendadas: ¿Kanban o Scrum?: that is not the question y Tableros kanban. Parte II: Diseño de tablero kanban para aplicarlo con Scrum).

En este post me centraré en ilustrar algunas variantes del concepto de Sprint en su aplicación en diferentes contextos de trabajo. Tener presente estas variantes es muy importante para hacer una buena adaptación metodológica al contexto de trabajo. Sin embargo, tampoco habría que desestimar la opción "cero", que sería simplemente NO usar Sprints :-). Pero de aquí en adelante en este post asumo que estamos en un contexto donde sí que es conveniente usar Sprints.  

En Scrum el concepto de Sprint es protagonista, aunque si no usáramos Sprints todavía tendríamos de Scrum otras prácticas ágiles que son muy interesantes, tales como: equipo auto-gestionado, equipo crosss-functional, los roles de Scrum, etc. Aunque básicamente un Sprint es una iteración, en Scrum establecen las siguientes características específicas:
  • Debe dar como resultado un incremento potencialmente entregable del producto.
  • No debería durar más de 4 semanas.
  • Debería comenzar apenas se termine el Sprint anterior.
  • Contiene ítems cuya suma de esfuerzo estimado debe ser coherente con la Capacidad del equipo. 
Estas características son sencillas y sensatas, pero al usar Sprints en un contexto específico suelen aparecer dudas, algunas de las cuales comento a continuación:

Contenido de los Sprints
  • A priori, se esperaría que al usar Sprints los ítems que se van a implementar en un Sprint estén predeterminados, ya que asumimos que el contexto de un Sprint es el de trabajo planificable (se conoce anticipadamente qué se hará en el Sprint). Además, durante el Sprint no debería haber demasiada presión por añadir ítems adicionales, considerando que su duración es de unas pocas semanas. El cliente puede que no vería resuelto su nuevo ítem al finalizar el Sprint actual, pero si dicho ítem tiene suficiente prioridad podrá incluirse en el siguiente Sprint. Sin embargo, si hay cierta urgencia se podría añadir el nuevo ítem al Sprint quitando otro equivalente en esfuerzo y que aún no haya sido implementado. 
  • Por otra parte, los Sprints pueden ser útiles en contextos NO planificables, es decir, donde no se conoce con exactitud qué trabajo se realizará en las próximas semanas. En estos casos el Sprint permite agrupar ítems de trabajo, aunque el contenido no será definitivo hasta que no se dé por terminado el Sprint. Por ejemplo, en un contexto de mantenimiento de un producto, al comenzar un Sprint se podría en extremo iniciarlo vacío, y en la medida que se van terminando ítems se van incluyendo (ya terminados) en el Sprint. Luego, en algún momento se decide cerrar el Sprint con el contenido de ítems terminados en ese instante. Otro escenario posible sería incluir en el Sprint un conjunto de ítems candidatos y que luego, cuando se considere conveniente, se terminaría el Sprint solo con los ítems terminados, y el resto de ítems se devolverían al Backlog para competir con otros ítems candidatos para el siguiente Sprint.
Regularidad de los Sprints
  • Tener Sprints de la misma duración genera una sana rutina de trabajo para el equipo. Esto además facilita el cálculo de la Capacidad del equipo, es decir, facilita el conocer cuántos Puntos u Horas Ideales (o cualquier otra unidad de medida que se utilice) podría abordar con éxito el equipo en un Sprint. 
  • Por otra parte, si durante el Sprint se detecta que no será posible terminar todos los ítems podría optarse por alargar el Sprint. Si esto se hace de forma habitual puede llevar a una relajación o falta de compromiso del equipo. Suele ser más recomendable terminar el Sprint en la fecha prevista y tomar oportunamente las acciones necesarias respecto a decidir qué ítems no se llegarán a terminar, o incluso para aquellos ítems ya comenzados crear un nuevo ítem que incluya el trabajo no realizado permitiendo así terminar el ítem original solo con la parte del trabajo ya hecha.
  • Hay situaciones en las cuales la demanda de trabajo no es previsible y fluctúa de forma importante. Por ejemplo, en un contexto de mantenimiento podemos pasar por períodos de mucho trabajo (después de una entrega de una versión con cambios importantes), y otros en los cuales hay poca demanda. En esta situación aún podría ser útil usar Sprints como agrupador, pero en este caso los Sprints podrían no ser ni continuos ni de la misma duración.
  • En cuanto al tamaño de los Sprints, ¿cuál es el tamaño aconsejable (considerando que no deben ser de más de 4 semanas)?. Mientras menos duración tengan los Sprints más frecuentemente podremos evaluar la buena marcha del trabajo. Sin embargo, el arranque y cierre de cada Sprint conlleva un esfuerzo (costes de transacción), y debe evaluarse hasta qué punto compensa realizarlo tan frecuentemente. Me refiero a actividades tales como las reuniones de planificación y de revisión del Sprint, el posible despliegue de la versión, pruebas (y especialmente pruebas de regresión), formación de usuarios, actualización de manuales, etc. Para un contexto nuevo de trabajo (nuevo en cuanto a los miembros del equipo, la tecnología utilizada, el dominio de aplicación, etc.) mi recomendación es comenzar con Sprints más bien pequeños, de 1 a 2 semanas, con el propósito de que el equipo aprenda y se adapte rápidamente. Luego, en un régimen de trabajo más estable recomendaría pasar a Sprints de 3 semanas. No me gustan los Sprint de 4 semanas y menos cuando se corresponden con meses de calendario pues prefiero que exista mayor atención (o inquietud) respecto a qué semana se termina un Sprint :-). 
Preparación de los ítems de cada Sprint
  • Para poder tener cierta garantía de cumplir con la implementación de los ítems incluidos en el Sprint debería existir coherencia entre la Capacidad del equipo y el esfuerzo requerido. Pero para hacer estimaciones de dicho esfuerzo con cierta precisión es necesario definir qué involucra cada ítem, es decir, saber cuáles son los requisitos asociados al ítem. Cada ítem necesita una "preparación", es decir, tareas relacionadas con la definición, especificación, validación, diseño y estimación (entre otras). Así pues, cada ítem del Sprint debería estar preparado antes de comenzar el Sprint. De esta forma, durante el periodo del Sprint el trabajo consistiría básicamente en implementar y probar cada ítem. La preparación de ítems de un próximo Sprint se debería hacer en paralelo a la implementación del Sprint actual. Particularmente, podría dejarse dicha preparación hacia el final del Sprint actual, cuando se va extinguiemdo el trabajo del Sprint actual y los miembros del equipo que vayan quedando sin trabajo en el Sprint actual puedan dedicarse a la preparación de ítems del Sprint siguiente. El caso extremo sería esperar a realizar toda la preparación en la Reunión de Planificación del Sprint, para la cual Scrum propone una duración de 8 horas (para un Sprint de 4 semanas). La razón de dichas 8 horas es precisamente porque se asume que los ítems que se incluirán en el Sprint podrían aún no estar preparados.
  • Si hay ítems incluidos en el Sprint y que no están preparados al comenzar el Sprint puede deberse a que simplemente no alcanzaron a ser preparados, y se tendrán que ir preparando durante el Sprint con el ruido que esto conlleve en la marcha del Sprint. También esa situación podría corresponder a una decisión estratégica para abordar un ítem de cierta complejidad, entremezclando su preparación e implementación, llevando al extremo el desarrollo incremental de dicho ítem. Obviamente, cuando no todos los ítems del Sprint están preparados y estimados hay más incertidumbre respecto a si se terminarán todos los ítems en la fecha de fin del Sprint.
Número de Sprints abiertos simultáneamente
  • En ediciones anteriores de la Guía de Scrum (scrumguide.org) se hablaba de la Release Planning Meeting, la cual consistía en establecer previamente cuáles serían los Sprints que conformarían una Release (Entrega). Por ejemplo, si teníamos una Release comprometida en 6 meses, podríamos planificar el contenido de 8 Sprints de 3 semanas cada uno hasta conseguir dicha Release. Sin embargo, muchas veces la dinámica del contexto de trabajo usualmente tira por tierra cualquier intento de planificación detallada a mediano o largo plazo. Por esto es más eficaz trabajar con un Backlog bien gestionado y ordenado, y luego a partir de él ir estableciendo solo el Sprint siguiente. Sin embargo, en la medida que se va extinguiendo el trabajo del Sprint actual podría abrirse ya el nuevo Sprint, aunque no necesariamente para comenzar a implementar sus ítems, sino solo como contenedor de los ítems candidatos que se están preparando para ese próximo Sprint. 
  • Otra situación en la cual puede ser útil tener varios Sprints abiertos, e incluso implementándose en paralelo, es cuando tenemos equipos diferentes trabajando sobre el mismo producto. Podría tratarse que equipos trabajando en diferentes áreas o subsistemas, equipos trabajando en mantenimiento o en desarrollo, etc. En esas situaciones puede que además sea conveniente que cada línea de trabajo tenga su propio Backlog y planificación de Sprints (aunque se trate del mismo producto). Indudablemente en estos casos se requiere una buena coordinación del entre los equipos involucrados.
Como hemos visto, el término Sprint da para mucho más de lo que plantea Scrum. En las implantaciones del enfoque ágil en las cuales he participado me ha resultado útil referirme a "Sprints" (a secas) cuando hablo de Sprints tal como los plantea Scrum, y usar el término "Sprints Flexibles" cuando hablo de Sprints que tienen alguna consideración especial de entre las comentadas antes. Los Sprints Flexibles son un aspecto clave para conseguir una conveniente adaptación de un proceso iterativo e incremental al contexto de trabajo de un equipo. No es necesario renunciar al uso de Sprints cuando no es posible aplicarlos tal como los plantea Scrum. Eso sí, un Sprint no es tal si no da como resultado un incremento del producto o si dura demasiado (orientativamente, más de cuatro semanas), estos dos aspecto son esenciales. Por otra parte, cuando existe una demanda constante de trabajo sobre un producto no hay excusas para no mantener una sana regularidad de duración (la misma duración) y continuidad (uno tras otro) de los Sprints.

Finalmente, y muy importante que cualquier decisión asociada a los Sprints (y otros aspectos de organización del trabajo) debe tomarse considerando las características de cada línea de trabajo, pues puede haber diferencias significativas entre una y otra. Aplicar de forma uniforme una decisión siempre es lo más sencillo, pero suele ser muy ineficaz cuando hay diferencias importantes entre las líneas de trabajo. Cuando digo "línea de trabajo" me refiero al desarrollo, mantenimiento o soporte, de un producto o de un servicio. No es lo mismo un contexto de desarrollo planificado respecto de uno de mantenimiento continuo, o de uno de soporte (donde no podemos prever el trabajo que llegará en las próximas semanas), incluso tratándose del mismo producto o servicio sus líneas de trabajo en general requieren un tratamiento particular. Lectura recomendada: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.



Patricio Letelier

www.tuneupprocess.com 







jueves, 25 de mayo de 2017

"Flecos" de implementación y gestión ágil de proyectos

Para implantar métodos que resulten eficaces hay que entender la naturaleza de la construcción de software. Teóricamente, desde el punto de vista técnico, si disponemos de cierto tiempo podremos preparar (definir, diseñar y estimar) adecuadamente el trabajo que se va a implementar (programar y probar), de tal forma que una vez hecha dicha implementación ésta sea totalmente satisfactoria, que no se requiera trabajar más en ella. Sin embargo, por una parte, la certeza en cuanto a corrección y completitud de dicha preparación no suele ser muy alta, y por otra, cuando el cliente ya puede interactuar con algo tangible suele desear mejoras :-). Esto hace que desde unos requisitos ya implementados aparezcan "Flecos"; mejoras (o incluso fallos) que corresponden a una continuación del trabajo iniciado por un ítem (Historia de Usuario) que ya dábamos por terminado. Aunque los flecos incomoden, es más importante saber gestionarlos que conseguir que no aparezcan (objetivo difícil de conseguir en desarrollo de software). Además, una estrategia puramente ágil, centrada en el desarrollo incremental, promueve los flecos y su gestión. Esta inconveniencia se amortiza con creces en comparación con una estrategia tradicional. Solo desde el punto de vista de la especificación ya estamos evitando el "Análisis-Parálisis", un problema mucho más grave (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).

Para gestionar dichos flecos una opción sería continuar (o reabrir) el mismo ítem original para extenderlo con los flecos que se van detectando. Esta alternativa no es recomendable porque no permite fácilmente distinguir entre lo ya realizado y lo pendiente (asociado a los flecos). Además, psicológicamente no es bueno que se trabaje en algo de forma muy prolongada sin terminarlo (o reabriéndolo una y otra vez). Así pues, recomiendo que los flecos siempre se representen con nuevos ítems dando por terminado el ítem original o los flecos ya abordados. Además, si los flecos están representados como ítems por separado pueden competir individualmente por prioridad con otros ítems, es decir, los flecos puede que ya no sean prioritarios cuando los contrastamos con todo el trabajo pendiente. Así pues, los flecos deberían tener una trazabilidad del tipo "es continuación de" o similar con respecto al ítem original.

Esta naturaleza imperfecta pone en jaque a una mentalidad tradicional para construir software, en la cual, un ítem se prepara y se implementa con la idea de ser terminado al primer intento, sin flecos :-). Si desde una perspectiva ágil además añadimos mucha interacción con el cliente, entregas frecuentes, reuniones de revisión, desarrollo incremental, etc., se desata tempranamente la identificación de flecos, especialmente cuando se trata de requisitos implementados y ya entregados, y más aún si esos requisitos tienen cierto éxito entre los usuarios (por ser muy apreciados y/o porque se utilizan con mucha frecuencia).

En la siguiente figura se ilustra cómo en un proceso iterativo e incremental el trabajo se va preparando e implementando incrementalmente. Obviamente en un desarrollo de un nuevo producto hay un breve período inicial de establecimiento del Backlog con la identificación de ítems y la preparación de los que se implementarán en el primer Sprint. A partir de allí la preparación se repite para cada siguiente Sprint, pero a partir del término del primer Sprint ya podríamos estar detectando flecos. Estos flecos aparecerán como ítems en el Backlog y según su prioridad se irán incorporando en los siguientes Sprints como ítems de mejora o de corrección de fallo. Así pues, la implementación de nuevos requisitos no se concentra toda en una fase inicial, ni tampoco la implementación de los flecos tiene que ser relegada a una fase más hacia el final.



Un enfoque ágil promueve la aparición temprana de flecos y su gestión como nuevos ítems que deben ser priorizados. Esto que parecería algo negativo (y lo es en un sentido tradicional) pues representa cambios no previstos, pero resulta ser una gran ventaja ya que los flecos se detectan y gestionan tempranamente.

Cuando afirmamos que con un enfoque ágil se gestionan mejor los cambios, en gran medida nos referimos a dicha identificación y gestión de los flecos de implementación (lectura recomendada: ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?). Obviamente los flecos y cambios en general nos incomodan, pero esto hay que valorarlo con una visión global del proyecto, ya que su detección y gestión tardía probablemente comprometería el éxito del proyecto. Más aún, el hecho que los flecos compitan con otros ítems pendientes ofrece la oportunidad para que el cliente discrimine entre lo esencial y lo prescindible de cada uno de los requisitos. El cliente podría ir interactuando con versiones parciales/incompletas pero tangibles (implementadas) del requisito, hasta el punto que considere que se ha alcanzado "un MVP" del requisito, lo cual dejaría espacio para la implementación de otros requisitos que de otra forma se habrían descartado por falta de capacidad o tiempo para implementarlos.

Asumir que existirán cambios y gestionarlos conlleva prestar atención continuamente al alcance del proyecto  (lectura recomendada: Gestión del Alcance en un Proyecto Ágil ) y correspondientemente negociar con el cliente. Una medida preventiva para abordar un margen de cambios imprevistos es considerar un Buffer de Capacidad para proyectos ágiles.



Patricio Letelier

domingo, 21 de mayo de 2017

Una estrategia MVP para abordar Épicas

Una Épica es un ítem "grande" (y/o complejo) que supone un importante esfuerzo para terminarlo. Pero ¿de qué  tamaño de esfuerzo estamos hablando? y ¿por qué tenemos que prestar atención especial a las Épicas?. En cuanto a tamaño me refiero a un ítem que, una vez definido y estimado, en su ejecución (básicamente su implementación y pruebas) se necesitaría más de una semana de trabajo. Uso este tamaño orientativo para una Épica porque un período de una semana, desde que se encarga la ejecución de un ítem al equipo hasta cuando lo termina, es un período "saludable", así no se arrastra trabajo sin terminar de una semana a otra. Además, si trabajamos con Sprints de 2 o tres semanas de duración es razonable que un ítem no cope gran parte de dicha duración, dejando espacio para otros ítems y haciendo más visible el progreso del trabajo medido en ítems terminados.

Las Épicas son más usuales cuando se comienza a construir un producto o cuando se hace una extensión importante de un producto existente. Esto es así porque con los nuevos requisitos tenemos una tendencia natural a ser ambiciosos en cuanto a funcionalidad, y más aún, para conseguirla toda a la vez :-). Las mejoras (de requisitos ya implementados) y correcciones de fallos no suelen caer en categoría de Épicas.

En la siguiente figura se presentan 4 alternativas para enfrentar Épicas, haciendo analogía (un poco forzada) con lo que sería enfrentarnos zanparnos mucha comida.


En la imagen superior izquierda se ilustra la opción por defecto, no hacer nada en especial para abordar una Épica, asumiendo que se tardará un tiempo importante en terminarla y que esto puede conllevar inconvenientes. En la imagen superior derecha, aunque se mantiene la Épica como un solo ítem, éste se aborda colaborativamente, por ejemplo, dos o más desarrolladores trabajando a la vez en en la Épica. Esto haría posible terminar la Épica en un tiempo más corto y evita complicaciones que pueden surgir por dividir la Épica en ítems más pequeños. Esta opción es aconsejable cuando la Épica no es muy grande, es decir, cuando abordada colaborativamente sí que es posible terminarla dentro de una semana de trabajo.

La imagen de abajo a la izquierda ilustra dicha división de la Épica en ítems más pequeños. La división de una Épica en varios ítems es atractiva cuando se pueden abordar en paralelo varios de esos ítems. Pero el hacer trabajo en paralelo se ve obstaculizado cuando los ítems no son bastante independiente debido a las dificultades de coordinación e integración que puede conllevar la terminación dichos ítems.  Otro importante inconvenientes es que al dividir la Épica podemos estar perdiendo la oportunidad de identificar lo esencial respecto de lo secundario, es decir, no cuestionar si es imprescindible implementar toda la Épica.

La opción de abajo a la derecha, intenta ilustrar que en lugar de zamparnos gran cantidad de comida a la vez, que lo mejor es hacerlo de forma progresiva y estratégicamente organizado para una dieta equilibrada. Esta es la opción más alineada con un enfoque ágil auténtico, pero siempre que se lleve a cabo con una orientación de MVP (Minimun Viable Product). Desarrollar una Épica con orientación MVP significa desarrollarla incrementalmente, paso a paso, poniendo el primer objetivo en una implementación mínima pero satisfactoria para una determinada versión del producto. Es decir, tal como se aplica MVP a nivel de producto como un todo, aplicarlo a nivel de una Épica. En la práctica esto conlleva discriminar entre lo esencial y lo secundario de la Épica. En términos de división de la Épica, solo necesitamos establecer dos ítems; uno como primera versión de la Épica y otro representando el "resto" de la Épica. Si trabajamos con Sprints el ítem primera versión se incluye en el Sprint y el "resto" se mantiene en el Backlog. Una vez terminado el ítem correspondiente a la primera versión MVP de la Épica el proceso puede repetirse con el ítem "resto" de la Épica. Esto continuaría hasta que se consuma y termine todo el trabajo restante de la Épica o hasta que el "resto" ya no sea tan prioritario en comparación con otros ítems pendientes. Es precisamente esta última situación la gran diferencia respecto de una división temprana del una Épica en varios ítems. Cuando se desarrolla incrementalmente una Épica, todo su desarrollo puede ser incremental, es decir, no es necesario definir en detalle toda la Épica, sino solo el MVP que se va a implementar inmediatamente (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).  


Patricio Letelier



lunes, 24 de abril de 2017

Buffer de Capacidad para proyectos ágiles

En un contexto de proyecto con rigidez en los tres elementos del triángulo de hierro: alcance, plazo y costo, surge la necesidad de una planificación y seguimiento (más) cuantitativo. El enfoque ágil muchas veces es descartado en estos contextos por la creencia errónea que la planificación y el seguimiento ágil no generarán dicha información cuantitativa. Un enfoque ágil, impregnado de la filosofía Lean, evitará todos los elementos prescindibles en el proceso, con lo cual podría prescindirse de la recolección y el procesamiento de información cuantitativa, pero solo cuando ésta no se aproveche adecuadamente. Muchas veces se somete a los equipos a un registro y reporte de datos que no es rentabilizado ni por el equipo ni por los niveles de supervisión.

¿De qué información cuantitativa estamos hablando?. Esencialmente necesitamos tres elementos: la Estimación del Esfuerzo del trabajo, el Esfuerzo ya Invertido y la Capacidad del equipo que ejecuta el trabajo. Un cuarto elemento derivado de lo anterior es el Esfuerzo Restante = Estimación de Esfuerzo - Esfuerzo ya Invertido.

Dependiendo de las necesidades de gestión de una determinada línea de trabajo, desde una perspectiva ágil podría ser válido y eficaz cualquiera de los siguientes niveles de gestión (desde el más simple al más exigente):
  1. Centrarse solo en la generación de un buen flujo de trabajo terminado, SIN usar Estimación NI Capacidad. En esta opción probablemente no se utilizarían Sprints pues su uso conlleva de forma natural alguna de las otras opciones que se plantean a continuación.
  2. Usar el Esfuerzo Restante establecido directamente (NO como la diferencia entre Estimación y Esfuerzo Invertido) y Capacidad. 
  3. Usar Estimación y Capacidad del equipo usando como unidad Puntos (u otra medida similar que represente el tamaño de las unidades de trabajo de forma global).
  4. Usar Estimación, Esfuerzo Invertido y Capacidad del equipo usando Horas Ideales (horas de trabajo ininterrumpido, NO horas de contrato).
Excepto en la opción 1, en las otras tres sería posible responder cuantitativamente la pregunta ¿llegaremos a cumplir el compromiso de alcance-tiempo-costo? En 2, 3 y 4 el equipo conoce su Capacidad y puede con ello calcular a partir de cualquier día del proyecto cuánto trabajo puede abordar desde ese momento hasta el final del proyecto. Además, el equipo puede también conocer en cualquier día del proyecto cuánto es el esfuerzo necesario para abordar el trabajo restante. Por ejemplo, supongamos un equipo tiene una Capacidad mensual de 200 horas ideales de programación y va a abordar un proyecto cuyo esfuerzo total está estimado en 800 horas ideales de programación. Podríamos afirmar que a día de hoy (y respecto de las horas de programación) parece factible realizar dicho proyecto en 4 meses (4 * 200 = 800). Supongamos que más adelante, finalizando el segundo mes del proyecto comprobamos que el trabajo restante es de 500 horas ideales de programación. Si la Capacidad del equipo sigue siendo 200 horas ideales de programación por mes, concluiríamos que en ese momento que con esa Capacidad no podríamos terminar el proyecto en dos meses.

Haríamos un razonamiento similar al usar Puntos en lugar de Horas Ideales, es decir, comparando el Esfuerzo Restante respecto de Capacidad disponible, pero en este caso ambos datos medidos en Puntos (es una medida del tamaño de las unidades de trabajo, medida relativa a una unidad de trabajo usada como referencia).

Hasta aquí todo claro y de muy sencillo cálculo. Pero ¿qué pasa con los cambios que se presenten durante el proyecto y que conlleven un aumento del esfuerzo total asociado al proyecto?. La primera solución sería negociar oportunamente con el cliente una reducción de alcance del proyecto para conseguir una reducción de esfuerzo equivalente a los cambios que han surgido. Como no todos los requisitos son igual de importantes o esenciales, el cliente podría postergar aquellos requisitos relativamente prescindibles (dejándolos fuera del alcance del proyecto). Otra posible opción que puede estudiarse junto con la anterior es que en los requisitos más "grandes" se pueda hacer una reducción estableciendo una parte como primera versión (y dentro del alcance del proyecto) y el resto como un trabajo postergado fuera del proyecto. Sin embargo, puede que el cliente llegue a un punto en el cual ya no está dispuesto a reducir más el alcance del proyecto, y que tampoco sea factible aumentar los plazos/costos del proyecto. Para evitar esta situación límite sabemos que en proyectos en los cuales se presentarán cambios es conveniente tener una determinada holgura. A continuación veremos una forma ágil de establecer y gestionar dicha holgura.

En un proyecto gestionado de forma ágil deberían descubrirse tempranamente los cambios especialmente los de gran impacto pues en los primeros Sprints nos preocuparemos de abordar el trabajo más importante y valioso para el cliente, así como aquello que pueda conllevar mayor riesgo. Además, se asume que al revisar cada versión resultante de un Sprint se detectarán cambios, asociados a fallos o mejoras que probablemente deban ser condsiderados dentro del alcance del proyecto. Así pues, con las reuniones de revisión al final de cada Sprint y con las entregas frecuentes se fuerza desde el comienzo del proyecto la aparición de esos posibles cambios. Pero la solución (fácil) no siempre podrá ser quitar o reducir el alcance del proyecto.

Un buffer nos permitirá abordar los cambios sin que ello suponga reducir el alcance de un proyecto durante su ejecución (y manteniendo su costo y plazo). La idea es sencilla, al planificar el proyecto reservar un porcentaje de la Capacidad del equipo para los eventuales cambios. Por ejemplo, si reservamos un 20% de Capacidad para dicho proyecto de 4 meses lo abordaríamos como si se tratase de un proyecto de 1000 horas ideales de programación, con lo cual tendríamos un margen de 200 horas ideales de programación. Es decir, un proyecto que teóricamente podríamos terminar en 4 menos lo hemos planificado para 5 meses.

La siguiente figura ilustra la reducción ideal del esfuerzo restante durante un proyecto, la cual convergería a 0 al obtener la versión resultante del quinto Sprint. Como se observa en la figura más abajo (en la línea amarilla) si abordamos un alcance de proyecto equivalente a 800 horas ideales de programación con nuestra de 200 horas ideales de programación deberíamos terminar al final del cuarto Sprint.


Sin embargo, lo normal es que después de cada Sprint los cambios que surjan provocarán un repunte del esfuerzo restante. Si disponemos de un buffer de un tamaño adecuado podríamos asumir dichos cambios sin tener que cambiar los plazos ni renunciar a requisitos o cambios imprescindibles. La siguiente figura ilustra cómo con el buffer, y abordando los cambios que se detectan al final de cada Sprint, aun el proyecto llegaría a completarse en el tiempo previsto.

El buffer es del proyecto como un todo, no se debería establecer un buffer para cada unidad de trabajo ya que lo usual es que las diferencias entre los esfuerzos reales invertidos y los estimados de unas y otras unidades de trabajo se anulen entre sí en cierta medida. Es decir, finalmente en algunas unidades de trabajo se requiere más esfuerzo del estimado inicialmente y en otra menos. El buffer global debería cubrir la desviación de forma más eficiente que si cada unidad de trabajo tuviese su propio buffer.

Finalmente, podría pensarse que actuando de esta forma no habría mucha diferencia con respecto a un proyecto gestionado de forma tradicional en el cual también se establezca un buffer. Pero la diferencia existe, en un proyecto tradicional se tienen muy pocas o ninguna evidencia del consumo del buffer hasta que el proyecto está muy avanzado pues precisamente los cambios tienden a detectarse al final del proyecto, donde se concentran las actividades de pruebas.

Otras lecturas relacionadas:




Patricio Letelier

viernes, 21 de abril de 2017

Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega

Un tema escasamente tratado en la literatura ágil es cómo abordar adecuadamente la gestión del trabajo de un equipo en contextos "multi-proyecto". Desde el punto de vista ágil, no es una situación ideal pues implica distribuir la capacidad del equipo y asumir una degradación del desempeño por los posibles cambios de contexto que deberá hacer el equipo para enfrentar varias líneas de trabajo simultáneamente. Desgraciadamente en muchas empresas esta situación existe y es difícil de cambiar, no todas las empresas pueden permitirse tener equipos exclusivamente dedicados a una línea de trabajo.

En un par de posts anteriores comenté respecto del "Agilismo en un contexto multi-proyecto" (Parte I y Parte II). En este post veremos otra forma de "multi-proyecto" que ocurre cuando en el marco de un mismo producto se presentan varias líneas de trabajo con diferentes necesidades de gestión. El reconocimiento y gestión diferenciada de estas líneas de trabajo es clave para el buen funcionamiento de los equipos encargados. En el post "Gestión ágil de productos que tienen varias líneas de trabajo" ya comenté unos aspectos generales respecto de tener varias líneas de trabajo sobre un mismo producto. Ahora veremos una cuestión específica y natural que lleva a una línea de trabajo de desarrollo a transformarse en tres líneas de trabajo sobre el mismo producto.

Mientras un producto/servicio se está desarrollando tiene una una sola línea de trabajo, la línea de Desarrollo, pero a partir de la primera entrega (paso a producción) tendremos que tomar decisiones respecto de cómo abordar las tres líneas de trabajo que existirán a partir de ese momento: Desarrollo, Mantenimiento y Soporte, tal como se ilustra en la siguiente figura.


La situación planteada conlleva tomar decisiones en dos aspectos: qué equipo(s) se encargará(n) de cada línea de trabajo a partir de la primera entrega y qué configuración de gestión se utilizará en cada una de las líneas de trabajo. Comentemos primero respecto de la configuración de gestión.

La línea de trabajo de Desarrollo normalmente es "planificable", es decir, puede definirse a priori lo que se va a desarrollar y acordar con el cliente el alcance, plazos y costo (es decir, estamos en un escenario de proyecto), y opcionalmente (pero deseable) el trabajo se puede organizar en Sprints que agrupan los cambios para producir versiones con una regularidad de un cierto número de semanas (Sprints de no más de 4 semanas). Aún siendo planificable otra opción sería trabajar sin el marco de proyecto, solo definiendo Sprints mientras el cliente estime conveniente que vale la pena continuar. Incluso podría trabajarse sin Sprints ni proyecto, simplemente estableciendo priorización del trabajo, abordándolo según dicha priorización y consiguiendo nuevas versiones al implementar cada nueva característica. Por otra parte, la línea de trabajo de Desarrollo, a partir de la primera entrega tiene una exigencia mayor respecto de pruebas de regresión y no interferencia con el uso que ya están haciendo del producto los usuarios. Además, si ya se tiene una versión en producción las siguientes versiones son en mayor medida potenciales entregas.

Por otra parte, la línea de trabajo de Soporte es claramente "no planificable", no podemos saber qué dudas, mejoras, o fallos nos reportarán los usuarios (llamémoslos tickets). Aunque puede que tengamos alguna acumulación de tickets pasados pendientes de resolver, los cuales podrían en alguna medida planificarse, el Soporte es un servicio, y como tal es muy importante la velocidad de respuesta, con lo cual la idea es priorizar, ejecutar y resolver lo más rápido posible los tickets. Además, las acumulaciones de tickets no resueltos se producirán probablemente por escalamiento a otro nivel de servicio, en particular las mejoras y fallos se suelen derivar a la línea de trabajo de Mantenimiento o de Desarrollo. Cuando dichas mejoras o fallos se implementan en una nueva entrega del producto los correspondientes tickets puedes darse por cerrados.

Finalmente, la línea de trabajo Mantenimiento podría no reconocerse como línea independiente y considerarse incluida en la línea de Desarrollo ya que en ambos casos se trata de cambios de producto y el equipo realiza básicamente el mismo trabajo técnico. Sin embargo, conviene que el Mantenimiento esté diferenciado, especialmente si tenemos una demanda importante de trabajo urgente/pequeño que debe/puede hacerse de inmediato para ofrecer respuesta rápida. El Mantenimiento está a medio camino entre trabajo planificable y no planificable, ya que no todos los cambios son urgentes o pequeños. Todo lo no urgente o de mayor envergadura podría planificarse en Mantenimiento, o incluso pasarse para ser abordado por la línea de trabajo de Desarrollo. Para una línea de Mantenimiento es usualmente recomendable trabajar con Sprints flexibles en cuanto a contenido y duración, es decir, los Sprints podrían contener desde solo un cambio, implementado y entregado inmediatamente, hasta acumular varios cambios que se implementan en unos pocos días y luego se entregan. Esta flexibilidad también podría darse respecto a no llegar a terminar todo lo que se pretendía, porque podrían incorporarse otros ítems durante el Sprint.

El flujo de trabajo de una línea de Soporte (en la cual se gestionan tickets) difiere significativamente del flujo de trabajo de las líneas de trabajo de Desarrollo y de Mantenimiento (en las cuales se gestionan cambios en el producto). De todas formas, en cada línea debería poder visualizarse el estado del trabajo no terminado asociado a la línea (lectura recomendada: Multi-kanban, un tablero kanban para contextos multi-proyecto).

Respecto al equipo encargado de las líneas de trabajo, si es el mismo equipo el que va asumir todo el trabajo habrá que establecer ciertas directrices para la distribución de su capacidad en cada línea de trabajo, asignando cierta capacidad a la línea de Desarrollo y reservando un porcentaje de capacidad para abordar las otras dos líneas. La línea de Soporte es buena candidata para ser encargada a un equipo independiente, que incluso pueda encargarse del servicio de Soporte para varios productos ofrecidos por la empresa. Sin embargo, como comenté antes, los tickets que requieran cambios en producto deben sincronizarse con ítems en líneas de trabajo de Mantenimiento o Desarrollo. Las líneas de Mantenimiento y Desarrollo podrían encargarse a un mismo equipo pero aún así conviene gestionarlas como dos líneas en las cuales el equipo debe distribuir su capacidad. Si el Desarrollo y el Mantenimiento están encargados a equipos diferentes es muy importante su coordinación pues ambos equipos estarán generando versiones del mismo producto, es decir, cada uno tendrá su ritmo de generación de versiones y pueden coincidir en las partes del producto sobre las cuales están trabajando o que los cambios que realiza un equipo tengan impacto en el trabajo del otro equipo.

En un enfoque tradicional puede que esta situación se postergue hasta el final del proyecto de desarrollo, es decir, que se haga una sola entrega al final. Pero si seguimos un enfoque ágil se intentará realizar entregas frecuentes durante el desarrollo (aunque acotadas en cierta medida). Las entregas frecuentes permiten hacer una validación más certera para confirmar que el desarrollo está bien encaminado, pero además, contribuyen a no acumular "tensión" respecto a aspectos que suelen provocar retrasos y problemas cuando se dejan todos para ser resueltos al momento de la entrega final, tales como: formación de usuarios, integración con otros sistemas, migraciones de datos, infraestructuras necesarias para que opere el sistema, etc. Así, todos estos aspectos se van abordando incrementalmente según lo requieran las entregas parciales.  

En cualquier caso siempre llegará el momento en que una línea "pura" de Desarrollo genere las tres líneas que hemos indicado y con ello nos enfrentemos a las cuestiones antes comentadas.


Patricio Letelier


miércoles, 19 de abril de 2017

Design Thinking, Lean Startup y Métodos Ágiles

Design Thinking es un proceso para la generación de ideas innovadoras de productos/servicios, se basa en la comprensión de necesidades de los usuarios potenciales y en una estrecha validación con ellos. El proceso consta de 5 actividades: Empatizar (ponerse en la piel del usuario y comprender sus necesidades), Definir (establecer el problema que se quiere resolver), Idear (determinar posibles soluciones), Prototipar (construir un prototipo, una solución tangible) y Probar (validar el prototipo con el usuario). Estas actividades se realizan una tras de otra pero volviendo a cualquiera de las actividades previas cuantas veces sea necesario. El proceso de Design Thinking se potencia con la participación de equipos multidisciplinares.

Lean Startup es un proceso iterativo para desarrollar una idea de negocio hasta convertirla en un producto con garantías de éxito. El método asume un contexto de emprendimiento caracterizado por una alta incertidumbre y limitaciones de recursos y/o tiempo para validar dicha idea de negocio (contexto natural de una empresa Startup). La validación se basa en la experimentación con versiones preliminares del producto con early adopters (clientes dispuestos a usar el producto aunque no está del todo terminado, y antes de un lanzamiento masivo).  Lean Startup se basa en un ciclo Built-Measure-Learn que se repite en cada iteración. Con "Built" se obtiene un MVP (Minimun Viable Product), con "Measure" se realizan experimentos con early adopters para recolectar datos y con "Learn" se aprende de dichos datos para reforzar la idea original o para pivotar sobre ella re-definiéndola para que ofrezca mejores expectativas de éxito. El MVP es una versión del producto que nos permite llevar a cabo dichos experimentos de validación con early adopters.

Los Métodos Ágiles, representados por Scrum, Kanban, Lean Development y Extreme Programming entre otros, ofrecen un conjunto de prácticas que ayudan a la gestión de proyectos y equipos de trabajo, favoreciendo la satisfacción del cliente, la productividad, la calidad, y la motivación y compromiso del equipo de trabajo. Los Métodos Ágiles promueven un proceso incremental e iterativo (esto último solo en el caso de Scrum y Extreme Programming). Los Métodos Ágiles han demostrado ser especialmente más eficaces (que los Métodos Tradicionales) en contextos donde se esperan cambios durante el desarrollo del producto/servicio.

Una razonable integración de estos tres enfoques sería aplicarlos de forma secuencial de acuerdo con la fase en la cual se encuentra el producto/servicio. Es decir, usar Design Thinking durante la generación de la idea de producto/servicio, usar Lean Startup para validar el producto/servicio construyendo un MVP, y usar Métodos Ágiles para desarrollar el producto/servicio en su versión comercial. Esto se ilustra en la siguiente figura.
Lean Product Management for Enterprises The Art of Known Unknowns, Natalie Hollier


Puede que en productos manufacturados o servicios donde el software no sea protagonista tenga sentido una marcada diferenciación entre la generación de la idea, validación con MVPs y su desarrollo ágil. Pero esta integración no es la más adecuada cuando el software es lo principal del producto/servicio.

En un ámbito de producto software los tres enfoques: Design Thinking, Lean Development y Métodos Ágiles podrían aplicarse de forma conjunta y solapados. Si bien Design Thinking podría ser aplicado de forma más anticipada que los otros dos, incluso podría ser prescindible en caso que la idea de producto esté clara, pues el principal aporte de Design Thinking está en el descubrimiento de ideas.

Design Thinking y Lean Startup coinciden en la construcción de un producto tangible (prototipo en Design Thinking y MVP en Lean Startup) para poder hacer experimentos de validación con early adopters, sin embargo, Lean Startup conlleva ya un camino hacia la construcción del producto comercial, es decir, no se trata de prototipo no operacional o con la intención que sea desechable.

Los Métodos Ágiles no incluyen prácticas asociadas al descubrimiento de ideas de producto, con lo cual Design Thinking puede ofrecer este complemento. Lean Startup y los Métodos Ágiles (particularmente Scrum y Extreme Programming) coinciden en usar un proceso iterativo e incremental. En el caso de Lean Startup el concepto de incremento es el MVP y en los Métodos Ágiles este concepto puede corresponder con la versión resultante de un Sprint, o la versión que se pasa a producción (Entrega o Release). En cualquier caso se trata de una versión del producto, pero una diferencia importante es que el MVP no responde a la regularidad de un Sprint. Los Sprint tienen una duración no mayor de un mes y conllevan una periodicidad, los MVPs no tiene esa regularidad. Con lo cual un MVP se acerca más a lo que representa una primera Entrega (conseguida después de un cierto número de Sprints), lo cual marca un hito en cuanto a incrementos del producto. Sin embargo, el MVP tiene una orientación más experimental y su validación podría dar un giro al posterior desarrollo del producto, pivotando el producto hacia otra dirección. Si bien los Métodos Ágiles asumen esa posibilidad de cambios, Lean Startup va más allá considerando que que los cambios podrían ser más radicales. El aprendizaje ("Learn") de MVP en un ciclo Lean Startup puede producir un pivote radical de la idea de producto/servicio. Por otro lado, los Métodos Ágiles hacen énfasis en la arquitectura y pruebas del producto desde el inicio del desarrollo, en Lean Startup mientras estemos validando con early adopters el foco está en la validación del producto, sin prestar especial atención a la arquitectura y pruebas del producto.

En mi opinión, lo fundamental que hay que tener presente al mezclar Lean Startup y Métodos Ágiles es el contexto de negocio, es decir si se trata de un producto que tiene asegurado su mercado o si se trata de un producto innovador que deberá crearse/ganarse su mercado. Ese último caso se presenta claramente en un marco de emprendimiento (por ejemplo en una empresa Startup). En esta situación pueden aplicarse casi todas las prácticas ágiles, tales como: desarrollo incremental (el MVP ya lo conlleva), priorización del trabajo, tener un tablero kanban para visualizar el trabajo pendiente, todas las asociadas a dinámica de equipo (auto-organización, equipo cross-functional, reuniones y roles de Scrum), minimalismo en la especificación, etc. Probablemente unas pocas prácticas no serían tan recomendables, tales como: desarrollo iterativo, planificación mediante estimación del esfuerzo y contrastada con la capacidad del equipo, refactoring, pruebas automatizadas o uso de estándares. En el otro caso, cuando el producto tiene en cierto grado asegurado su mercado (puede ser un producto interno para una empresa o encargado a medida por una empresa cliente), podríamos pensar que bastaría con aplicar solo Métodos Ágiles pues nos facilitan la gestión de los posibles cambios, siendo estos no tan radicales como se esperaría en un marco de emprendimiento. Sin embargo, pienso que la estratégica del concepto de MVP debería siempre estar presente y alineado con los hitos que representan las Entregas. Es decir, el MVP ayuda a exigirnos una estrategia que busque siempre acotar el alcance de las entregas del producto para así poder en relativamente poco tiempo validar con la parte cliente, poniendo en producción (o pre-producción) una versión parcial del producto. Así pues, el concepto de MVP debe estar asimilado por el Product Owner como mecanismo para reducir la ambición de las entregas del producto/servicio, en favor de hacer evaluaciones tempranas de lo más esencial del producto/servicio, aunque esto postergue la incorporación de otras características menos esenciales.      


Patricio Letelier


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