Es muy fácil dividir el trabajo en diferentes actividades especializadas y repartirlas entre diferentes personas. Pensamos que definiendo claramente las responsabilidades de cada miembro de un equipo, desarrollaremos software de una manera más eficiente. Sin embargo, este enfoque taylorista no parece compatible con el trabajo del conocimiento, ni siquiera con uno que requiere habilidades y conocimientos tan dispares y tan proclives a la especialización como el desarrollo de software. Por ello se hace cada vez más imprescindible que le demos más importancia a ese «individuos y sus interacciones sobre procesos y herramientas».
Por supuesto, los procesos y las herramientas son importantes. Esenciales, diría yo. Un proceso de desarrollo de software conocido por todos los miembros de la organización que participa de la construcción del mismo permite hacerlo con eficacia (conseguir los objetivos) y eficiencia (mejor uso de los recursos). Sin embargo, cuando hablamos de individuos y sus interacciones parece que estemos hablando apenas de otros procesos más, destinados a cubrir las necesidades de interacción de los miembros de los equipos. Básicamente reuniones. Tratamos de canalizar las comunicaciones, programar las interacciones y darles un propósito para hacerlas más eficaces.
En un entorno muy complicado para tomar decisiones, como puede ser una gran organización, todo esto es necesario. De lo contrario es muy difícil que los individuos lleguen a interaccionar entre sí. Sin embargo, una de las habilidades más importantes y menos cultivadas para desarrollar software es la conversación entre personas. Es por ello que en algunos contextos sea necesario algún tipo de receta para ayudar a estructurar esas conversaciones.
La imagen que ilustra este artículo es la que uso desde hace un tiempo en eDreams ODIGEO para explicar cómo veo el proceso de desarrollo de software. Acompañado a esa imagen va, indefectiblemente, una referencia a que todo lo que hacemos es mantener conversaciones para ir entendiendo cada vez mejor qué es lo que debemos poner en la calle y así satisfacer las necesidades de nuestros usuarios.
Hagamos un repaso por este flujo ideal, y seguramente imperfecto, para entender mejor a qué me refiero.
La primera conversación
El proceso de desarrollo de software comienza con la primera conversación entre dos o más individuos. Seguramente ninguno de ellos formará parte del equipo o equipos que van a participar de la construcción y despliegue de la solución o soluciones que sucederán a esa primera conversación. Así que el primer paso es coleccionar ideas, es decir, elaborar un breve resumen de esa primera conversación.
Un titular que nos permita recordar de qué iba esa conversación es suficiente. No necesitamos todos los detalles porque, entre otras cosas, por muy extensa que nos haya parecido esa primera conversación, no será nada comparado con el tiempo de desarrollo de la misma.
Ojo, porque es fácil caer en la trampa de, todavía en este punto, hacer un documento de especificación de requisitos, tratando de recoger todos los detalles. Alguien incluso, con una mentalidad más Agile, podría decir que sería el momento ideal para comenzar ese documento e ir completandolo a medida que se avanza. Sigamos y veremos por qué creo que no es oportuno.
Dependiendo de cuáles son las competencias del equipo, a veces podemos extender esta «primera conversación» y hacer trabajos de ideación e incluso prototipado. Me gustaría dedicar un futuro artículo sólo a esto, de modo que de momento vamos a simplificar el proceso y vamos a considerar que el equipo no realiza esas actividades. En eDreams ODIGEO, por ejemplo, esto tiene mucho sentido porque en la mayoría de los casos, los equipos cuidan de un trozo del producto. Por tanto, no todos los desarrollos, pero sí la mayoría, son evoluciones del producto que ya está funcionando.
¿Podemos y debemos trabajar en esto?
Volvamos a esa lista de ideas que vamos recogiendo. Esa lista no está priorizada. Bueno, sí, las primeras ideas en llegar serán las primeras en ser tratadas. Aunque hay que reconocer que, de vez en cuando, también se aplica @Unlockd/do-you-prioritize-like-a-hippo-829479735376">HiPPO. En cualquier caso, que esta lista sea corta es beneficioso para todos, ¿verdad?
«¿Podemos trabajar en esto?» es la primera pregunta que se hace el equipo. Como el equipo está haciendo Kanban, si pueden, es decir, si tienen capacidad para trabajar, entonces tirarán de la primera idea de la lista. En la práctica esto puede ir desde días hasta semanas. Depende de muchos factores, pero la visualización y las métricas ayudan a que esta conversación tenga lugar con la cadencia necesaria.
A continuación, el equipo debe responder a la pregunta «¿Debemos trabajar en esto?». No es nada fácil. Probablemente es de las más difíciles a las que se enfrentará durante todo el proceso, pues no siempre tenemos un criterio claro para descartar una idea. Para ayudar a tomar esta decisión, tenemos muchas técnicas a nuestro alcance que nos ayudarán a estructurar las conversaciones para decidir si descartamos la idea o seguimos adelante con ella.
Yo recomiendo, sin ningún orden determinado, las siguientes técnicas:
Impact Mapping
Algunos equipos con los que trabajo están usando Impact Mapping. Les pido que alineen sus objetivos con la misión del equipo y, a partir de ahí, vamos trabajando qué pueden hacer ellos (u otros actores) para conseguir esos objetivos. El resultado es un documento vivo que pueden ir usando para asegurarse de que cada nuevo desarrollo está alineado con su propósito como equipo, que ayuda a conseguir los objetivos que se han marcado, y que además les recuerda cómo medir esa contribución. Si la idea no encaja en el mapa, lo mejor es descartarla… o cambiar el mapa para que el nuevo desarrollo tenga su hueco.
Risk Profile
Se trata de elegir una serie de dimensiones que nos permitan entender mejor el valor que esperamos que aporte la idea una vez desarrollada, así como los riesgos que vemos a primera vista.
Solemos usar un diagrama de radar, pero bien podría ser cualquier otra visualización porque lo realmente relevante de esta técnica es que podemos facilitar las conversaciones para que todos los miembros del equipo conozcan y participen de la decisión de descartar o no esa idea. Es muy fácil hablar sobre si hay una fecha límite o si se trata de una emergencia o un intangible y conocer el Coste de Retraso, aunque sea apenas de una manera cualitativa o aproximada en órdenes de magnitud.
Al hablar sobre esto, de una manera estructurada, todo el equipo podrá participar de la decisión de priorización porque tendrá la información necesaria y, como beneficio añadido, podrán ir consiguiendo una mayor predictibilidad pues estarán clasificando los desarrollos según la naturaleza de los mismos.
También podrán dividir una idea demasiado grande en otras ideas más pequeñas y así reducir, por ejemplo, el Riesgo Técnico. De esta manera, en una etapa muy temprana del desarrollo, se puede planificar un primer prototipo y luego otro desarrollo en el que se incorpore el aprendizaje conseguido.
Agile Inception
Es frecuente ver en el Risk Profile una versión superreducida de una Agile Inception. Sí, uno de los propósitos principales de ambas técnicas es que todos los miembros del equipo estén de acuerdo en qué hay que desarrollar. Sin embargo, la Inception es una reunión mucho más ambiciosa y cara, que normalmente cubre otros aspectos. A veces incluso se mete en terrenos más relacionados con lo que hemos llamado más arriba «la primera conversación».
En la práctica, cuando hacemos un Risk Profile y observamos que la idea es demasiado grande para dejarla pasar a la siguiente etapa del proceso de desarrollo, o cuando no hay consenso sobre la misma, creo que una Agile Inception sería una buena continuación para esa conversación.
User Story Mapping
Sin embargo, a veces la idea está lo suficientemente clara en cuanto a qué se persigue con el desarrollo pero no en cuanto al plan para construirla y desplegarla. En estos casos yo aconsejo usar el User Story Mapping. En el taller para construir el User Story Map se producen muchas conversaciones, todas ellas orientadas a tener un plan de versiones iterativo e incremental.
A veces, cada versión de ese plan será una nueva Idea que deberá ser revisada (para descartarla o no) como cualquier otra. Simplemente estaremos difiriendo en el tiempo esas conversaciones, evitando entrar en detalles en este momento, pudiendo enfocarnos a partir de ahora en la primera de las versiones. ¿Lo ves? Otra técnica más de facilitación de las conversaciones.
Test Card
Recientemente estoy intentando que algunos equipos comiencen a usar las Test Cards. De nuevo, no es más que una plantilla para estructurar una serie de conversaciones. De momento no puedo compartir más experiencia que la de las formaciones internas en las que las he usado. Creo que son muy útiles, sobre todo para que el equipo reflexione y se ponga de acuerdo sobre cuál es la hipótesis detrás del desarrollo que van a comenzar.
Desde luego, habría que completarla con el uso de las Learning Cards. Las volveré a mencionar más adelante, cuando hable de las últimas etapas del proceso de desarrollo.
En la próxima entrega continuaré explicando cómo el resto del proceso también está guiado por conversaciones. Hablaré, especialmente, de historias de usuario y de cómo éstas nos ayudan a guiar las conversaciones del equipo dentro y fuera del mismo. De momento, si quieres que profundize en alguna de las técnicas que he descrito más arriba, usa los comentarios más abajo y prometo escribir pronto sobre ello.