Mostrando entradas con la etiqueta agile. Mostrar todas las entradas
Mostrando entradas con la etiqueta agile. Mostrar todas las entradas

martes, 21 de marzo de 2023

Habilidades de Scrum Master: Facilitación

Una de las habilidades principales a desarrollar como Scrum Masters es la de Facilitación.

La Facilitación como disciplina es independiente de la agilidad, y se origina alrededor de 1980 como una manera de resolver patrones tóxicos en reuniones de grupos en todo tipo de organizaciones. 


Algunos de estos anti-patrones incluyen:

  • Asumir que se llegó a acuerdos porque nadie se opuso a una decisión (aunque la mayoría de las personas participantes no hayan tenido la posibilidad de hacerlo)
  • Presencia en la reunión sin posibilidad de participación activa, e incluso sin comprender el propósito de la reunión
  • La pérdida de foco en el objetivo de la reunión, yéndose del tema, incluso dejando fuera de tema a una parte importante de las personas participantes
Como una manera de cambiar esta dinámica, surgió el rol de Facilitadora ó Facilitador.

Al asumir ese rol, nuestras responsabilidades pasan a ser:
  • Previamente a la reunión

    • comprender el objetivo final
    • acordar con la o las personas que convocan que realmente quieren generar participación grupal y aceptar opiniones del resto del grupo
    • diseñar las actividades y tiempos aproximados para lograr el objetivo
    • colaborar en la convocatoria, incluyendo (si es necesario) la explicación de la dinámica de la reunión
    • (mi sugerencia) asegurar que las personas invitadas sientan que pueden NO participar. Esto muchas veces implica un énfasis en que la no-participación es positiva si la persona invitada no siente conexión real con el tema.

  • Durante la reunión

    • Asegurar acuerdos mínimos de trabajo (respeto por todas las ideas, confianza en la inteligencia colectiva, apertura a escuchar posiciones contrarias)
    • Explicar la dinámica y tiempos generales
    • Guiar a través de cada una de las actividades, manteniendo los tiempos previstos
    • Asegurar la participación de todas las personas (para esto se suele trabajar en grupos pequeños y luego hacer puesta en común; canalizar ideas por escrito o diagramas, además de hablando; variar tipos de actividad para mantener el interés, etc)
    • Mantenerse tan neutral como sea posible (porque somos humanos, finalmente) sobre el tema en discusión. Cuando facilitamos, no participamos ni opinamos sobre el tema, y en cambio mantenemos el foco sobre la dinámica del grupo.
    • Inspeccionar la interacción de las personas y adaptar el plan (que no debe ser demasiado estricto) para asegurar el mejor resultado posible.
    • Asegurar la captura de elementos importantes del proceso y de las decisiones finales. Puede ser en formato de fotos, videos, audio, documentos, diagramas, etc.
    • Lograr un cierre ordenado de la reunión, con una instancia mínima de reflexión sobre el funcionamiento general, oportunidades de mejora para próximas reuniones, posibles consecuencias o necesidades posteriores, etc.

  • Después de la reunión

    • Realizar una retrospectiva de la reunión con las personas que la convocaron, más allá del feedback del resto de las participantes.
    • Compilar y preparar los contenidos generados durante la reunión para compartirlo con las personas participantes y otras que necesiten tener información del tema.
    • Evaluar la necesidad de próximos pasos

En el contexto de Scrum, estas mismas responsabilidades se aplican a los eventos dentro del Sprint: Planning, Review y Retrospective.

¿Y la Daily Scrum? Como Scrum Master no es nuestra responsabilidad "facilitar" la Daily. Este evento es de y para Developers. Por supuesto, podemos colaborar en el inicio para que estas personas encuentren su propio formato y estilo hasta que les resulte útil. Más allá de eso, no deberíamos influir en el tema, más allá de evaluar con ellas si están teniendo o no problemas de coordinación, manteniendo el foco en el objetivo del Sprint y encontrando oportunidades de colaboración real. Si alguna de estas cosas no sucede, puede que la Daily no esté funcionando por completo, pero siempre será mejor buscar motivos sistémicos menos evidentes que tratar de ajustar una pieza mecánica, como el formato de la Daily.

Para profundizar más en el tipo de actividades que podemos utilizar en la Facilitación, veremos un modelo y algunos ejemplos en el siguiente artículo: el Diamante de Toma de Decisiones Participativa de Sam Kaner.





miércoles, 15 de julio de 2020

Eventos de Scrum: el Sprint

El Sprint es el ciclo principal de Scrum. Es la misma idea que en otros marcos es llamada Iteración, y en el caso de Scrum, su mayor importancia es que todo lo que Scrum describe está contenido dentro del Sprint.

También es el "timebox" principal que regula todos los demás.

La idea de TimeBox se utiliza en Scrum para el Sprint y todos sus eventos internos, y es lo que me gusta llamar una "restricción creativa". A primera vista parece una limitación, pero nos ayuda a mantener uno de los valores, que es el FOCO. Una vez que decidimos cuánto va a durar el Sprint de nuestro equipo, no podemos cambiarlo, y eso nos obliga a tener que aprender a entregar y organizarnos dentro de ese límite.

Según la Guía de Scrum, el Sprint puede durar un máximo de un mes, aunque en la práctica ya son muy pocos los equipos que mantienen Sprint de un mes, que suena a una eternidad. La duración más popular es la de dos semanas, pero es usual que los equipo más maduros prefieran el Sprint semanal.

Diagrama de un Sprint

La condición inicial para poder iniciar un Sprint es tener el Product Backlog listo para planificar el trabajo de todo el Sprint. Esto implica que al menos los Items del Product Backlog (o PBIs) más prioritarios estén lo suficientemente refinados.

La duración del Sprint es la que afecta a la vez el timebox máximo de cada uno de sus eventos interiores. Pero lo más importante es recordar siempre que todo sucede dentro del Sprint. Desde el punto de vista de Scrum, nada sucede fuera del Sprint.


Preguntas frecuentes acerca de los Sprints

¿Nunca se puede cambiar la duración del Sprint?

Sí, es posible hacerlo, pero con mucho cuidado. 

El motivo no debería ser circunstancial. Lo que no vale es cambiar arbitrariamente, agregando o quitando días por cualquier circunstancia, ni decidiendo en cada Sprint cuánto va a durar.

Personalmente encuentro solamente dos motivos para cambiar (en algún momento de la vida de un producto):
  • Que el equipo intentó con una duración muy corta y no le resulta sostenible. Por ejemplo, intentaron Sprints de una semana y descubrieron que algunos temas técnicos o internos hacen que les resulte demasiado difícil entregar un producto funcionando al final de cada semana. En ese caso, luego de analizarlo en una Retrospectiva, podrían decidir decidir cambiar a Sprints de dos semanas (de ahí en adelante, sin seguir variando todo el tiempo).

  • De forma similar, si el equipo comenzó con Sprints de dos o tres semanas y durante una Retrospectiva deciden que ya están lo suficientemente maduros como para hacer Sprints más cortos y así aumentar la frecuencia del feedback, podrían reducirlo (nuevamente, es importante que estén seguros de que será sostenible, para no tener que volver atrás).
En cualquiera de los dos casos, es importante que antes de cambiar la duración, tanto el motivo como la decisión sea comunicada a los stakeholders principales, más allá del Equipo Scrum, porque para quienes asistan a la mayoría de las Sprint Review, ese cambio de frecuencia es importante.

¿Se puede cancelar un Sprint antes de que termine?

Sí, es posible hacerlo, pero con mucho cuidado.
(No, no es déjà vu, la respuesta es la misma que la anterior. 😄)

Después de más de 10 años trabajando con Scrum, recuerdo presenciar un solo caso de cancelación, y era porque la compañía acababa de ser adquirida por otra, y no se sabía si el producto continuaría existiendo.

Los únicos motivos para cancelar un Sprint es que su Objetivo se vuelva totalmente obsoleto, por un cambio de negocio, mercado o tecnología tan enorme que cambia todo el contexto. Esto sucede muy raramente. Aunque la idea puede venir de cualquiera, la responsabilidad de cancelarlo (comunicándolo a todos los demás) es únicamente del Product Owner.

viernes, 6 de marzo de 2020

Scrum: Incremento de Producto



En el Manifiesto por el Desarrollo Ágil de Software, hoy más conocido como el Manifiesto Ágil, hay 4 valores y 12 principios, uno de los cuales dice:
El software funcionando es la medida principal de progreso.
En Scrum, ese principio está representado por el Product Increment. Es importante notar que Scrum ya no habla de software, pero la definición del incremento en la Scrum Guide dice (mi traducción):
El incremento es la suma de todos los ítems del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los previos. Al final del Sprint, el nuevo incremento debe estar "Terminado", lo que significa que debe estar en condición de ser utilizado y cumplir con la definición de "Terminado" del Equipo Scrum.
Podríamos decir que en Scrum, la principal medida de progreso es el Incremento de Producto funcionando.
Este incremento es entonces, una versión actualizada y funcionando del producto que se entrega al final del Sprint (agregando valor sobre los incrementos previos).

El Product Owner es quien tiene la responsabilidad de decidir si ese incremento se libera al mercado (se pasa a producción, se pone en marcha o su equivalente de acuerdo al tipo de producto), más allá de que sea usable.

Que el Incremento deba estar "terminado" significa que debe poder ser liberado sin trabajo adicional del Scrum Team.

Atención 
La Guía Scrum no especifica qué sucede con esfuerzo adicional fuera del equipo para entregar el producto a su público objetivo. Por ejemplo, en muchas organizaciones el equipo entrega un producto de software terminado, pero para pasarlo a producción el esfuerzo de otras áreas puede ser enorme. La comunidad ágil alienta a trabajar en reducir esa brecha, por ejemplo, a través de prácticas de DevOps (que NO es un rol ni un área, sino un estilo de colaboración entre desarrollo y operaciones).

La Definición de Terminado

La DoD (del original en inglés, Definition of Done) es creada por el Scrum Team com una manera de evaluar si su trabajo en un ítem del Product Backlog ó en el Incremento está completo.
Definición de Terminado
El objetivo de esta definición es brindar transparencia sobre el nivel de calidad que se considera suficiente para entregar el Incremento de Producto.

La definición es dinámica, y a través de los Sprints será inspeccionada y adaptada, en colaboración entre el Scrum Team y los Stakeholders.

Es importante que el Development Team tenga esta definición en cuenta a la hora de determinar cuánto comprometer durante la Sprint Planning. Una buena Definición de Terminado balancea el nivel de calidad esperado con el esfuerzo requerido.

Es común que la definición varíe mucho entre diferentes equipos, ya que depende mucho del tipo de producto, el contexto y la madurez en diferentes aspectos.

Cuando múltiples equipos trabajan sobre el mismo producto, usualmente colaboran para tener una Definición de Terminado mínima, compartida por todos, sobre la que cada equipo puede agregar sus propias condiciones.

Tips

En mi experiencia, es preferible comenzar con una definición humilde pero alcanzable, y trabajar con el Scrum Team en seleccionar qué prácticas pueden elevar el nivel de calidad del producto, priorizándolas. Es usual que esas prácticas tengan una curva de aprendizaje, que hace que el equipo deba inicialmente invertir más esfuerzo en cada ítem.

La buena noticia es que las prácticas de calidad, una vez que tienen impacto, ahorran esfuerzo en la medida en que el producto se vuelve más estable y el equipo las incorpora como propias. En el momento en que el equipo ya está acostumbrado a esa nueva práctica, puede agregar la condición correspondiente como parte de la Definición de Terminado, y comenzar con la adopción de la próxima práctica de calidad que sea más prioritaria.

Para ayudar a pensar en posibles ítems de la Definición de Terminado de un equipo, en Kleer creamos una guía ágil y las DoD Cards,  con ejemplos y sugerencias.

DoD Cards

jueves, 5 de marzo de 2020

Scrum: Sprint Backlog

El Sprint Backlog es el subconjunto de ítems que un equipo "toma" del Product Backlog como compromiso de trabajo para un Sprint, con algunos agregados.
Sprint Backlog
Esta selección de ítems se realiza durante la Sprint Planning, y los agregados que el equipo hace representan la estrategia para cumplir con esos ítems y alcanzar el Objetivo del Sprint y entregar el Incremento de Producto.

La Guía de Scrum no entra en detalle específico de esa estrategia, pero en muchos casos se trata de una desagregación de tareas para cada ítem, de acuerdo a diversas perspectivas como componentes, especialidades, áreas de trabajo, u otras que el equipo determine.

Es recomendable tener en cuenta que aunque cada ítem se descomponga en tareas, el equipo tiene como objetivo principal lograr ítems completos, que ayuden a alcanzar el objetivo, y tiene que evitar caer en la trampa de dedicarse a completar tareas en cualquier orden, según la especialidad de cada uno, sino en colaborar activamente para terminar ítems, respetando el orden de prioridad original.

El Sprint Backlog usualmente se hace visible a través del uso de un tablero, físico o electrónico, y es importante que esté disponible para todos los interesados y permita ver claramente el estado de cada ítem, de manera transparente.

También es recomendable que junto a los ítems del Sprint Backlog, el tablero mantenga altamente visible al menos un elemento de mejora decidido en la última retrospectiva.

Es común que el equipo modifique y complete detalles del Sprint Backlog a medida que avanza en el Sprint, posiblemente como resultado de la Daily Scrum. Todo ajuste tiene por objetivo mejorar las posibilidades de alcanzar el Objetivo del Sprint.


El Development Team es el único que puede alterar el Sprint Backlog, agregando, actualizando o removiendo detalles. El resto del Scrum Team y los Stakeholders sólo tienen acceso a éste para ver el estado de avance, sobre el que pueden pedir más detalles al equipo. En mi opinión no es bueno tomar el estado de actualización del Sprint Backlog como única fuente de información, sobre todo en caso de notar algo fuera de ciertas expectativas. En un ambiente colaborativo como el de Scrum, la comunicación cara a cara siempre brinda detalles que nos dan una visión más clara de las cosas.

miércoles, 4 de marzo de 2020

Scrum: Product Backlog

Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.
Product Backlog
Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.

Esa evolución se da a través de los Sprints, a medida que:
  • Se pasan ítems al Sprint Backlog, durante la Planning.
  • Se agregan nuevos ítems que sean valiosos para el producto
  • Se eliminen ítems cuyo valor ya no es relevante
  • Se descompongan ítems grandes en otros más pequeños
  • Se cambian las prioridades de los ítems, al reconsiderar su valor actual
Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.

Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.

El Product Owner es el responsable por su contenido, visibilidad y priorización.

El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.

Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.

Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:
  • Con su valor establecido (y ordenados en consecuencia)
  • Divididos en los ítems más pequeño posibles
  • Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
  • Detallados (suficiente como para que nada se bloquee en la Planning)
Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:
  • Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
  • Evitar analizar ítems que pueden variar (o desaparecer)
La actividad de agregar estos detalles al Product Backlog  no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.

Product Backlog Refinement

La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.

Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.

Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).

También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.

miércoles, 26 de febrero de 2020

La estructura de Scrum

Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. 😁

Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.

La estructura de Scrum


AVISO
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.


 Artefactos -> Transparencia


Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.


Product Backlog


El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.

El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.

Product Backlog

Sprint Backlog


El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.

El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.
Sprint Backlog

Product Increment


El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.

Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.

Para  asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.

Product Increment


Eventos -> Inspección y Adaptación

Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.

Sprint

El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.

Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.

Eventos de Scrum

Sprint Planning

Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información  adicional de cómo desarrollarlos, se convierten en el Product Backlog.

En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.

Daily Scrum

Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para inspeccionar cómo avanza hacia el objetivo del Sprint y adaptar sus planes para alcanzarlo.

El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.

Sprint Review

Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para inspeccionar el Product Increment, de manera de poder adaptar, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.

Sprint Retrospective

La "Retro" es una oportunidad para que el equipo se auto-inspeccione, y adapte su manera de trabajar, mejorando de manera continua.

Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.



Roles


Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.

La suma de las personas cubriendo estos tres roles en un equipo es lo que se llama Scrum Team (o equipo Scrum).

Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados Stakeholders, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.

Development Team

Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.

Product Owner

Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.

Scrum Master

Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.


martes, 25 de febrero de 2020

Pilares y Valores de Scrum

Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"

La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.

Procesos de Control Empírico


Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.

No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:

  • Volatilidad
  • Incertidumbre
  • Complejidad
  • Ambigüedad

De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.

Pilares de Scrum

 Transparencia, Inspección y Adaptación
Transparencia, Inspección y Adaptación
Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?

La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.

En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:
  • Decisiones acertadas o no
  • Hipótesis de negocio comprobadas o no
  • Calidad del producto
  • Estado actual frente a un contexto volátil
  • Comprensión correcta entre todos, en un entorno ambiguo
Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.

Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.

Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.

Valores de Scrum

Compromiso, Coraje, Foco, Apertura, Respeto
Compromiso, Coraje, Foco, Apertura, Respeto

Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.

Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:

Compromiso (commitment)

Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.

En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.

La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.

Coraje (courage)

Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.

En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.

Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.

Foco (focus)

Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".

Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.

Apertura (openess)

Algo abierto es algo expuesto y evidente.

En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).

La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.

Respecto (respect)

Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.

En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.

Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.


¿Y cuál es la respuesta?

Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.

Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.

Scrum no es un modelo predictivo, es un modelo adaptativo.

Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:
  • ¿El producto agrega valor?
  • ¿Estamos más cerca de resolver el problema?
  • ¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?
Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.

lunes, 24 de febrero de 2020

¿Qué es Scrum y para qué se usa?

Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.

Scrum Guides (portada)
Sitio de la Guía de Scrum

¿Qué es Scrum?


Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):
Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.
Me gusta esa  definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.

Un marco de trabajo...


Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.

Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.

Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.

...en el que las personas...


Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.

...abordan problemas adaptativos complejos, mientras entregan productos...


Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.

Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.

Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.

...del mayor valor posible de manera productiva y creativa


El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.

La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.

Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.


Otras características

Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".

Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.

Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.

Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.


Hacia adelante

Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:

(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)



viernes, 14 de septiembre de 2018

3 elementos para una Arquitectura más Ágil

Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.

Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:

Arquitectura incremental

Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.

IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.

Arquitectura Incremental en Scrum

Validación continua

Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.

Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.

Validación Continua

Demasiado importante para dejárselo a los Arquitectos

Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.

Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.

Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.

Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.

Arquitectura Colaborativa

 

Continuando la discusión

Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:

 

viernes, 6 de julio de 2018

Colaboración real: lo que más cuesta lograr en los equipos

Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:

  • Trabajan en iteraciones (o sprints)
  • Planifican al inicio
  • Revisan al final
  • Hacen retrospectivas (a veces) y tratan de mejorar

En muchos casos también tienen su reunión diaria (la daily standup o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.

Antipatrón 1: cascada iterativa

Cascada Iterativa

Se nota al sincronizar que los miembros del equipo tienden a esperarse entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...

Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.

Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.

Antipatrón 2: sobre-especialización

Especialización

También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.

En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.

La magia de trabajar de a pares

Pares

Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.

Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:

  • Tratar de terminar cuanto antes lo que tiene más valor
  • Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos
  • Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.
  • Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.

¿Todo hay que hacerlo de a dos?

Solos o de a pares

No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.

Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.

Colaboración real en equipos

Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.

Lo que busca un equipo ágil es aplicar el principio de Pareto a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.

En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".

Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.

jueves, 29 de junio de 2017

Katas de Arquitectura

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):


¡Hola, Rox! 

Tarot de Arquitectura

Te paso el material:

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.

martes, 31 de mayo de 2016

3 dudas sobre Extreme Programming

Esta semana una asistente a uno de mis talleres de Desarrollo Ágil de Software me envío estas consultas, que como acordamos, intento contestar aquí de manera abierta, para ella y para otros que puedan tener esas dudas.

Hola Martín!

Saludos desde Lima.

Disfruté mucho el taller de Desarrollo de software ágil, ya lo estoy recomendando.... al pasar los días me surgieron unas preguntas que cuando tengas oportunidad por fa me escribes...

Vale la pena aclarar que yo voy a dar mi opinión personal. Yo empecé a utilizar ideas de Extreme Programming (XP) a fines de los '90 y a principios de los 2000 me convertí (se ve que no había mucho más para elegir) en XP Coach de varios equipos. En todo ese tiempo he juntado muchas ideas y dudas nuevas, pero trataré de aportar alternativas y vías de exploración, ya que no creo en que haya UNA respuesta para estos temas.

 

1- Una vez que se decide adoptar XP. El pair programming se aplica todo el tiempo? O se da cabida a espacios para programar individualmente y mob programming?  

Aunque en los orígenes de XP esa era la idea, en la práctica y a medida que ha pasado el tiempo la práctica se ha vuelto más pragmática. Recordemos siempre que a pesar del nombre, XP está basado en principios y valores que son los que buscamos, y las prácticas son solo un reflejo adaptable de ellos.

Cuando la solución más sencilla (recordemos que la Simplicidad es primordial en XP) es escribir el código de a uno, no vale la pena buscar un par. Los casos típicos son los que son triviales: construir otra pantalla, adaptador o función que es una variante particular de otras que ya están hechas.

Cuando el desafío es bajo y las tareas son de muy bajo riesgo, podemos obviar el par. Ahora, cuando nos encontramos realizando tareas repetitivas pero que pueden ser críticas, podemos al menos mantener un criterio de revisión de a pares. Lejos de la programación, en Kleer siempre hacemos revisión de a pares para propuestas o presupuestos.

Mob Programming es todavía una técnica relativamente experimental como práctica continua, pero en varias oportunidades en distintos equipos en los que trabajé pasamos de programar de a pares a tríos o cuartetos. Cuando uno pasa ese límite es difícil trabajar con un monitor usual y el salto a un proyector o una pantalla grande  implica un reacomodamiento mayor. Un paso intermedio usual es realizar workshops de diseño en conjunto para definir componentes de arquitectura, refactorizaciones importantes a nivel de framework o para ensayar alternativas de diseño con todo el equipo.

En todos los casos lo que funciona es probar y aprender. Una de las premisas es que si no experimentamos en la búsqueda de mejores maneras de trabajar como equipo, siempre estaremos ocupados pero probablemente desperdiciando esfuerzo.

 

Working Effectively with LEgacy Code

2- Se puede aplicar TDD o BDD a proyectos que ya han empezado de la manera tradicional (sin metodologia de desarrollo agil o casos de prueba?) o tiene que ser proyectos que aún no hayan arrancado?  

Claro que si. Lo más sencillo es usar TDD para código nuevo aunque la solución sea vieja. Un poco más complejo es construir la infraestructura de pruebas en el código antiguo. Para eso utilizamos una serie de técnicas especiales para romper dependencias fuertes en el código. La referencia canónica para esto es el excelente libro de Michael Feathers, Working Effectively with Legacy Code.

Básicamente, mientras haces TDD para el código nuevo, vas necesitando desacoplar la parte del código viejo con el que hay que interactuar, y para eso hay que ir logrando desarmarlo e ir dejando algunas pruebas que nos ayuden en esa tarea.

Algo que si desaconsejo es generar proyectos de "refactorización pura". Cuando nos ponemos exquisitos en cuanto a la calidad del código sin tener en cuenta las necesidades reales de la organización o sus clientes, nos arriesgamos a entrar en un proyecto con objetivos poco claros. Mejor que eso es comprometernos a usar estas técnicas para mejorar el código relacionado con la funcionalidad que necesitamos modificar, y esa manera, con el pasar del tiempo, las partes del código que requieren más cambios (lo que de alguna manera demuestra que son más valiosas) irán mejorando y serán más fáciles de entender, probar y extender.

 

3- Algunas empresas no les agrada mucho el aplicar Pair Programming porque tienen la idea que es menos productivo y que así los programadores charlarán entre ellos y no programaron. ¿ Qué argumentos se pueden utilizar para cambiar esas ideas? Y Cómo hacer para que los programadores efectivamente no se pongan en ese plan (pudiera pasar)  

Lamentablemente todavía hay organizaciones que dejan pasar las oportunidades de mejorar porque se enfocan en que la gente (a a que suelen llamar recursos) cumple un horario haciendo lo que suponen que es su tarea.

Si pensamos que la tarea de un desarrollador de software es programar, y no hablar, casi seguro obtendremos como resultado código que hace lo que el programador interpreta de un documento, sin entender lo que hace, y sin preocuparse por que lo que hace agregue valor. Para un desarrollador en esas situaciones siempre recomiendo tratar de generar evidencias de que hay maneras mejores de trabajar, y en último lugar recuerdo siempre el dicho "si no puedes cambiar tu trabajo, cambia tu trabajo". No me parece bien tomarse livianamente la ida de que la organización "es así", porque en muchos casos vi gente desde las posiciones más humildes e inesperadas generar una ola de cambio. 

Un buen desarrollador tiene que charlar con el resto del equipo y buscar soluciones apropiadas a las necesidades planteadas, y debe lograr entender el contexto de negocio y aportar su visión. Si limitamos a los desarrolladores a programar lo que otros le indican sin nada más, llegaremos siempre a soluciones mediocres o pobres. De la misma manera, si el equipo no entiende y no está conectado con los problemas que tiene que resolver, su motivación será obviamente más baja, y eso no lo compensa trabajar de a pares o no. 

Al revés, si el equipo está conectado con el negocio, al trabajar de a pares encontrarán mejores soluciones que trabajando solos. El principal problema de trabajar solo para un desarrollador es la facilidad para perder el foco o bloquearse en detalles menores, cosas que casi no suceden al trabajar de a pares.

En resumen, para mi un argumento fundamental es si queremos "cantidad de código" o "buenas soluciones".

lunes, 16 de mayo de 2016

El Kyū-Dan de la Integración Continua

Cinturones de Judo

En algún momento del 2014, tuve una consulta de mi amigo Sebis Henzenn, que generó (estaba lejos y tenía un rato)  un mail con una explicación bastante larga de lo que se me ocurrió en ese momento como una metáfora aproximada de los pasos de aprendizaje respecto a prácticas relacionadas con Integración Continua y sus derivaciones.

El mensaje quedó guardado unos años, pero lo recordé recién hablando con otro amigo, Edson Chávez, de Kleer Perú, donde estoy en este momento.

Así que aquí va mi elucubración de esa vez, que no sufrió mucho cambios en el ínterin. Sólo aclararía que no es una categorización exhaustiva, sino un recorrido posible, que espero que le sirva a alguien para formular sus planes al respecto.

Aquí el texto original:

Mi recomendación es empezar por el build server, e ir evolucionando. Por ejemplo:

Cinturón blanco:
- instalás Team City (o Jenkins, o el que te guste -salvo TFS que yo no recomendaría).
- empezás haciendo que cada equipo aprenda a configurar su proyecto (es importante que sepan hacerlo ellos)
- lo básico es que en cada commit el proyecto compile, por lo menos
- que se acostumbren a no tener el proyecto en rojo NUNCA. Si queda en rojo, arreglarlo antes de seguir con nada.

Cinturón amarillo:
- pueden empezar a hacer tests (si no los hacen) y correrlos en el build en cada commit.
- de nuevo: nunca dejarlo en rojo, y aprovechar los arreglos para entender más lo que los demás están haciendo y nivelar la calidad de las pruebas.

Cinturón naranja:
- empezar a hacer TDD y ATDD, y elevar el número de pruebas
- seleccionar alguna manera de medir code coverage y hacer que el build falle si ni se alcanza el 1% (pruebas mínimas)
- cada tanto medir el coverage promedio de la solución e ir subiendo el límite casi hasta ahí (incrementalmente)
- cada vez que se reporta un incidente o bug (en testing o producción), no puede arreglarse si no se escribe la prueba primero que demuestra el problema, y se da por resuelto una vez que se corrige la aplicación para que pase ese test

Cinturón verde:
- empezar a ejecutar analizadores estáticos, y que el build server muestre el informe.
- concentrarse en los problemas más importantes; cuando ya no existen en la solución, hacer que rompan el build
- seguir con el problema más importante, y así sucesivamente; alcanza con eliminar un tema o dos por sprint

Cinturón azul:
- empezar a versionar junto al código migraciones de bases de datos, configuraciones y scripts de instalación de componentes o librerías
- hacer que si el build server compiló con éxito y ejecutó todas las pruebas y validaciones, genere desde cero un entorno nuevo de testing

Cinturón marrón:
- trabajar en conjunto con el equipo responsable de despliegue para que valide y adopte los scripts y métodos de generación de ambientes
- lograr que el build server genere en cada commit un ambiente de prueba desde cero, y otro incremental
- lograr que si se detecta un problema en el ambiente incremental, se pueda volver a la versión anterior de la aplicación con el script de reversión

Cinturón negro:
- cada vez que un desarrollador hace un commit que pasa todo el pipeline de pruebas y validaciones en csda uno de los ambientes de prueba, potencialmente puede llegar a producción de manera automática, aunque se opte por decidir manualmente el momento de despliegue
- trabajar en el diseño de la solución para que soporte el desplliegue sin interrupciones de servicio (hot deploy)

Cinturón rojo:
- cada vez que un desarrollador hace un commit, llega a producción sin interrupción de servicio

 

Cada uno de esos saltos puede llevar de 1 a 9 meses, dependiendo del equipo, el proyecto, y de dónde arrancar en cada parte, pero creo que te das una idea. :)

martes, 19 de mayo de 2015

Story Mapping en acción

En el artículo anterior hablamos del objetivo general del Story Mapping, cómo realizar la convocatoria y otras características generales. Como prometí, esta vez voy a entrar en mayor detalle en la mecánica de la construcción.

Aviso: después de facilitar muchos talleres con esta actividad uno desarrolla ideas y tácticas propias, así que es importante destacar que voy a describir la manera en que yo veo el Story Mapping, que puede no coincidir con la de otros. La mayor parte está tomada de Jeff Patton, pero hay agregados personales que surgen de mi aprendizaje continuo practicando esto, sobre todo en América Latina, que puede cambiar el contexto cultural.

Cúentame tu vida

El primer paso de esta actividad es charlar sobre el problema que queremos resolver, pidiendo a los involucrados que cuenten la historia detrás. Usualmente dejo que esta parte sea bastante libre, y a medida que ellos cuentan los detalles, voy anotando en papeles algunos detalles como personajes, acciones, lugares, etc.

Voy a dejar para más adelante el tema de personajes y técnicas específicas para usarlos en el contexto del diseño del producto, y por ahora vamos a concentrarnos en la historia de alto nivel. Como ejemplo, vamos a tomar el clásico sistema de ventas, porque creo que es algo bastante común para todos los que desarrollamos software, y aunque puede haber algunas diferencias menores entre países, es un dominio relativamente conocido y sencillo de entender.

Supongamos entonces que de la narración de los involucrados sobre cómo es el proceso, aprendemos que: "hay un cliente que llega y realiza un pedido, para lo que hay que buscar los productos en el depósito y preparar la entrega mientras se le realiza una factura, que debe pagar."

Podemos preguntar algunos detalles más, y finalmente aislamos ciertas actividades principales a partir de esa historia, y algunos detalles para cada una. No voy a entrar mucho en los detalles del ejemplo, que están elegidos para dar una idea del flujo. Podríamos terminar con una serie de actividades de primer orden y un segundo nivel de actividades como el que se ve aquí:

Actividades principales

Algo que tratamos de mantener es que leyendo las notas de más arriba y agregando algunos conectores en el medio, podemos reconstruir la historia original: "llega un pedido, se busca en el inventario, se factura y luego se cobra".

La segunda línea agrega algunos detalles o partes de cada actividad principal. El Pedido, por ejemplo, tiene productos y condiciones, el Inventario requiere chequear si hay suficiente para un pedido, entregarlo, en algún punto requerirá reposición, etc.

El demonio está en los detalles

A partir de este "espinazo", podemos empezar a entrar en los detalles de cada una de esas secciones, hacia abajo, para entender el panorama completo. Eventualmente podemos llegar a algo como:

Detalles de la historia

Como se ve, en un primer nivel tratamos de cubrir todas las características que creemos necesarias, sin importar todavía el orden o valor de cada una.

Entregas y esqueletos caminando

El siguiente paso es -ahora si- comenzar a priorizar. Lo que vamos a tratar de hacer es ver qué es lo imprescindible de cada columna para una primer entrega que sea valiosa, desde el punto de vista de habilitarnos a usar la solución y obtener algún resultado. Es probable que podamos incluso saltear alguna columnas para la primer entrega.

Y como un valor que buscamos siempre con estas técnicas es maximizar el aprendizaje, usualmente buscamos una entrega anterior a la primera "oficial", de carácter interno, que solemos llamar Walking Skeleton (esqueleto caminante), y que debería permitirnos verificar que cumplimos el circuito que queremos recorrer (la solución ya camina) aunque todavía no podríamos exponerlo al público (le falta carne).

Una vez que encontramos ese esqueleto posible, podemos avanzar, agregando lo mínimo indispensable para llegar a la primer entrega que haríamos a nuestro público. Obviamente, esto asume que cuando construyamos realmente el Walking Skeleton lo que aprendamos no nos haga replantear toda la situación. Si es de esperar que comprendamos mejor y tengamos que hacer algunos retoques a nuestro plan.

En la figura se ve un posible Walking Skeleton y una primer entrega (R1 o release 1):

Walking Skeleton y R1

Por supuesto podríamos discutir si en este ejemplo las características elegidas alcanzan o no, pero supongamos que entre todos los involucrados en el ejercicio de Story Mapping (responsables del negocio, roles operativos, gente de tecnología, procesos, etc) nos hemos puesto de acuerdo en que el esqueleto es suficiente para aprender lo que necesitamos y probar el circuito completo, y que agregando lo mínimo podemos tener una primer versión valiosa, que en este caso nos permitirá tomar pedidos para entregar en el momento, facturarlos y cobrar en efectivo y cheque (que por alguna razón es necesario para arrancar).

Como vemos, esta primer entrega es muchísimo más pequeña que lo el alcance total que imaginábamos, pero mediante este ejercicio encontramos qué es lo mínimo que nos permitirá empezar a usar la solución tempranamente, en una fracción de lo que involucraría construir toda la funcionalidad imaginada.

Este es un tema clave en el desarrollo ágil, y como vemos, el Story Map nos permite tener una visión global, para que el foco de corto plazo en el backlog de producto no nos haga perder de vista el objetivo final.

En uno o dos artículos más voy a profundizar en alternativas, el uso del Story Map a lo largo del proyecto y algunos consejos a la hora de facilitar la actividad. Por supuesto, si tienen consultas o comentarios, pueden avisarme a través de Twitter, idealmente con el hashtag #StoryMap. Nos vemos.

martes, 5 de mayo de 2015

Story Mapping: de la Incepción hacia el Backlog de Producto

Tiempo atrás publiqué una serie de artículos sobre la práctica de Incepción Ágil que tuvieron bastante éxito y generaron varios comentarios y preguntas, entre otras, acerca de otra práctica relacionada, que a veces algunos incluyen como parte de la Incepción: User Story Mapping.

Esta técnica para analizar un proyecto (completo o un sub-proyecto) fue nombrada y documentada originalmente por Jeff Patton, primero en un artículo de su blog, y posteriormente en su libro "User Story Mapping" (pueden ver la tapa a la derecha), ambos inmensamente recomendables.

Conocí los detalles de esta práctica por primera vez alrededor de 2008 o 2009, y comencé a usarla en algunos proyectos míos o de organizaciones a las que estaba ayudando, y después de usarla al menos una docena de veces, comprendí mejor cómo aprovecharla y cómo facilitar su construcción, y se convirtió en una pieza clave para mi en el inicio de proyectos ágiles.

Lo que quiero hacer en este artículo es recorrer qué es un Story Map, cómo se genera, cómo se usa posteriormente y cuáles son sus beneficios. En algunos posteriores entraré en detalle sobre la mecánica de la reunión, las alternativas y conceptos subyacentes.

¿Cómo y cuándo?

Trabajando en conjunto

Como en el caso de la Incepción Ágil, el Story Mapping se realiza al inicio de un proyecto, o una nueva fase, típicamente en formato taller. Algunas veces se realiza como parte final de la Incepción, aunque para mi es bueno entenderlo como momentos diferentes.

La Incepción trata de poner el foco en asegurar que todos los involucrados acuerdan un objetivo común, ciertas características y restricciones del producto, y deciden en conjunto qué van a construir.

Story Mapping es una actividad que nos permite entrar en detalle estratégico sobre cómo construirlo, entender qué es lo fundamental, poner foco en la entrega temprana y entender cómo ir incrementando el valor frecuentemente.

Lo que tienen en común ambas prácticas, que para mi son complementarias, es el tipo de convocatoria: en ambos casos queremos contar durante toda la actividad con gente de negocios a nivel directivo y a nivel operativo, operaciones, procesos, infraestructura, desarrollo, seguridad, etc. Queremos tener representados a la mayor cantidad posible de sectores involucrados en el proyecto del que vamos a hablar, para tener una perspectiva amplia.

También, como en el caso de la Incepción, más allá del entregable (el Story Map) lo más valioso son las conversaciones durante el ejercicio. No deja de sorprenderme al facilitar encuentros de este tipo en diferentes organizaciones (desde micro-emprendimientos hasta corporaciones) cómo surgen discusiones que nunca se habían tocado antes a pesar de estar trabajando en el tema en cuestión durante muchísimo tiempo.

Dependiendo de la complejidad y la importancia del proyecto, la actividad puede durar desde 2 o 3 horas, hasta un día completo. En proyectos críticos he facilitado frecuentemente un día completo de Incepción y otro día completo de Story Mapping.

Entre uno y otro puede pasar un tiempo, porque a veces la Incepción sirve para confirmar qué tipo de proyecto tenemos que realizar (cuanto más temprano la hagamos, mejor, porque tenemos menos cosas decididas de antemano), y podemos tomarnos un tiempo para tener identificado al equipo de trabajo y saber quiénes deberían estar presentes para construir el Story Map.

 

¿Qué queremos lograr?

En los próximos artículos voy a entrar en detalles, pero para cerrar éste, quiero mostrar el resultado final y explicar cuál es la expectativa.

Story Map final

 

La imagen muestra un mapa de un proyecto real. La imagen no tiene nitidez suficiente para leer lo que está escrito en las notas, que es algo específico y particular de este proyecto, pero que no importa para explicar el resultado.

Lo que se ve en la primer fila, en las notas celestes, como cabeceras de cada columna, son las Actividades Principales del proyecto, en el orden en que fluyen en "la historia" contada por los diferentes participantes de la actividad. Hacia abajo de cada Actividad hay Detalles sobre cómo se realiza esa actividad, en muchos casos como alternativas o pasos que pueden ser o no opcionales.

Las líneas azules que cortan transversalmente el mapa (en dos tajadas finas, inicialmente) son las Entregas planificadas, cada una con el mínimo de funcionalidad necesaria para cumplir con el propósito de la solución. Como puede notarse, esas dos primeras entregas son muy pequeñas respecto al total del alcance esperado (el conjunto total de notas debajo de los encabezados celestes). Sin embargo, las dos entregas planificadas concentran el más alto valor de negocio, porque destraban problemas importantes y habilitan nuevas posibilidades. Esto suele suceder en casi todos los proyectos, siguiendo la ley de Pareto: aproximadamente el 20% del alcance da el 80% del valor de negocio de un proyecto.

Utilizando esta práctica, que detallaré más en los próximos artículos, podemos buscar ese mítico 20% y tratar de concentrarnos en tener el más alto valor rápidamente, que además nos permitirá tener un producto real funcionando y poder aprender de la experiencia concreta antes de seguir agregando funcionalidad en abstracto.

Actualización: podés encontrar el siguiente artículo de esta serie aquí.