El desarrollo de software son conversaciones (V)

Tiempo aproximado: 8 min.

Retomando la serie “El desarrollo de software son conversaciones“, en esta entrada voy a centrarme en las conversaciones que tienen lugar en lo que llamamos construcción, es decir, cuando ya tenemos claro qué hay que hacer y nos ponemos a ello.

Construcción

En general estoy bastante en contra de las metáforas que equiparan el proceso de desarrollo de software con la construcción de objetos físicos (ya sean edificios, puentes, coches, etc), especialmente desde que vi esta presentación. (Si tienes prisa puedes saltar hasta el min 40, pero merece la pena escucharla completa).

Sin embargo, aclarada la analogía, creo que podemos coincidir en que las actividades que hacemos una vez ya hemos escrito una historia de usuario, están orientadas a la construcción de uno o varios artefactos de software que se podrán desplegar para ser ejecutados y aportar a los usuarios el valor prometido en esa historia.

Los detalles

Así pues, de alguna manera, la historia de usuario condensa un compromiso con los usuarios.

Como <usuario>, cuando <esta historia> esté construida y desplegada, seré capaz de obtener <este valor>.

Ésa es la expectativa que hemos creado. En el artículo anterior de esta serie me refería a la Historia de Usuario como a una plantilla (Como <usuario> quiero <funcionalidad> para <beneficio>) más un Criterio de Aceptación. Ambas son imprescindibles para comenzar a trabajar pues acotan el resultado final. Sin ellos es fácil desenfocarse y comenzar a construir algo bien diferente a lo que realmente creemos que necesitan nuestros usuarios.

En cualquier caso, una historia de usuario no es una descripción detallada. Podría serlo. De hecho, es fácil encontrar equipos que reclaman que estén acordados hasta los más mínimos detalles antes de aceptar que se puede comenzar a trabajar en una historia de usuario. En mi experiencia éso es poco práctico y demuestra que el equipo aún no es suficientemente ágil. Y no porque el agilismo consista en no documentar nada, sino porque en realidad sólo debemos documentar aquello que es útil, y documentar algo que es susceptible de cambiar mientras trabajamos en ello es poco útil. También restringe las opciones del equipo a la hora de ofrecer la mejor solución al problema descrito en la historia de usuario.

Recuerda que la historia de usuario se centra en el qué y deja el cómo en manos de quien debe construir el software.

Estas conversaciones que se producen acerca de los detalles de una historia de usuario pueden ser muy enriquecedoras y aportar mucho valor al producto, o también pueden ser una gran fuente de conflictos internos y externos. Pero no caigamos en el pesimismo: discutir sobre los detalles también es enriquecedor, pues nos ayudará a encontrar las mejores soluciones al reto de satisfacer la necesidad del usuario.

Empleemos un momento en analizar por qué algunos equipos suelen pedir los requisitos bien detallados. En mi experiencia, las causas pueden clasificarse en:

  • falta de confianza e incluso penalizaciones (principalmente miedo al “no hiciste lo que te pedí” o al “tardaste más de lo que me prometiste”),
  • problemas de comunicación (especialmente con el dueño de producto o el cliente), que llevan a dejar constancia por escrito de los acuerdos,
  • pasa mucho tiempo desde que hablamos de la historia de usuario hasta que comenzamos a codificar, o las historias son demasiado grandes como para recordar fácilmente todos los detalles, por lo que llegamos a la solución de registrar las conversaciones en un formato que se pueda recuperar más tarde,
  • falta de costumbre en colaboración interdisciplinar o demasiada especialización (yo sólo sé programar o a mí sólo me pagan por programar),
  • alguien está pidiendo una estimación.

Las dos primeras son disfunciones en el equipo, mientras que las otras dos siguientes son más bien defectos en los procesos. La última yo diría que es una combinación de ambos problemas. Todas tienen solución, claro, pero pasan inicialmente por ser capaces de identificarlas.

En el caso de las disfunciones del grupo, es más fácil si eres un agente externo (un Agile coach, por ejemplo), pero no imposible. Te recomiendo la lectura de “Five Dysfunctions of A Team” de Patrick Lencioni y la puesta en práctica de alguno de los ejercicios que propone. Por supuesto, no es una medicina para todo problema interno en un equipo, pero sí creo que es un buen punto de partida.

Para el caso de defectos en los procesos, tenemos las retrospectivas o demás técnicas de mejora continua (como A3 Thinking o @Germanicus1/the-toyota-improvement-kata-from-the-trenches-b64744a43898">Toyota Kata). No voy a abundar aquí en ellas porque no es el objetivo de esta serie, pero no puedo evitar hacer hincapié en que la mejora continua es el principio clave del agilismo.

Para el caso de “¿Cuánto tardaréis en hacer esto?”, ya escribí no hace mucho sobre ello en la entrada “Estimaciones, adivinaciones, predicciones y pronósticos“. En ese artículo doy varias pistas sobre cómo abordar esta conversación. Que se de en una fase tan avanzada del proceso de desarrollo, cuando igual ya hemos empezado a programar, indica que nuestro proceso no está manejando bien las expectativas de los stakeholders y que debemos mejorar, seguramente con más transparencia y probablemente incorporándolos más activamente en las conversaciones que tienen lugar al principio de nuestro proceso.

En cualquier caso, si te fijas, tanto las soluciones fáciles de tener esas conversaciones no tenidas hasta este momento, como las más difíciles de abordar disfunciones en el equipo o defectos en los procesos, todas se basan en conversaciones.

UX y UI

Durante el refinamiento es fácil haber debatido sobre la UX (eXperiencia del Usuario) y cómo éste interaccionará mejor con nuestro sistema. A mí me gusta mucho el enfoque Lean UX, según el cuál nos enfocamos menos en los entregables que la UX más tradicional y se potencia la colaboración más estrecha entre diseñadores y desarrolladores. Así, cuando la conversación acerca de cómo debe ser la experiencia de usuario se realiza entre ambos perfiles, con una pizarra o incluso una servilleta, se encuentran soluciones muchísimo más ricas que cuando se trabaja por separado, además de ser mucho más rápido.

Algo parecido pasa cuando hablamos de la UI. ¿Quién no ha oido a un diseñador decir que en esa maquetación no hemos usado el color correcto o que hay una caja que está desajustada dos pixeles a la derecha? Bien, esto pasa porque no trabajamos lo suficientemente juntos. No siempre es posible, a veces el diseñador es compartido por cinco equipos más o vive en otro huso horario. Sin embargo, nuestros procesos deberían tener en cuenta que, si queremos que se produzcan las conversaciones adecuadas que llevarán al equipo a construir la mejor solución para nuestros usuarios, debemos favorecer que éstas sucedan.

Dedicaré un futuro artículo a “La relación entre UX y el resto del proceso de desarrollo” pues hay muchos puntos de vista y diferentes experiencias que compartir sobre este tema.

Silos de comunicación

Yo soy de una generación en la que he trabajado en cubículos bastante parecidos a los de la foto que ilustran este artículo. Personalmente estoy bastante alineado con esto que escribía Enrique Dans hace un par de años, excepto por lo del papel, principalmente porque soy un firme defensor de la comunicación visual. Los tableros físicos, posters con acuerdos de trabajo, pizarras para pensar solo o en grupo, pantallazos impresos y pegados en las paredes, etc. Todo lo que ayude a tener conversaciones más ricas y que cueste poco de mantener. Ojo, eso no quiere decir que esté en contra de herramientas digitales para colaborar. Por ejemplo, aquí tienes mi comparativa entre usar tableros físicos y tableros virtuales.

Por ejemplo, cuando empezamos a usar Kanban es bastante frecuente que los tableros muestren un mini-waterfall: análisis funcional, diseño UX, análisis técnico, diseño UI, programación y pruebas. O algo parecido. El tablero es un radiador de información que nos indica que nuestro proceso está dividido en actividades excluyentes, que no fomentan la colaboración entre los diferentes roles. Lo peor es que desincentiva la propiedad colectiva de las tareas y, por tanto, favorece una cierta falta de atención a los resultados (que es justamente la disfunción que Lencioni coloca en la cúspide de su pirámide). Los tableros son una manera de romper el silo de comunicación entre las diferentes disciplinas o roles de un equipo multidisciplinar.

Sin embargo, la sociedad del siglo XX fue buscando la especialización de los trabajadores, lo cuál nos llevó también a la especialización en las relaciones. Desde mi posición como Agile coach en transformaciones de grandes empresas puedo ver que diferentes roles usan diferentes herramientas para comunicarse. Es fácil ver a los programadores que chatean por Slack y comparten enlaces a Bitbucket o Github, mientras que los Product Owners hablan por teléfono o comparten powerpoints por correo electrónico, o que los diseñadores se aislan para dibujar sus mockups con Photoshop o InVision. Todos son ejemplos, una generalización basada en estereotipos, pero el hecho es que muchos tendemos a trabajar en nuestro silo. Nos hemos acostumbrado a hablar con los demás usando nuestras propias herramientas. Y esto crea un silo de comunicación incompatible con la idea de equipo multidisciplinar.

Entre desarrolladores también se habla

Vuelvo a la visión del cubículo. El efecto del espacio de trabajo sobre nuestras conversaciones es brutal. Un espacio de trabajo ruidoso hace que busquemos aislarnos (independientemente de nuestro rol). En el caso de los programadores esto tiene un impacto muy serio sobre el trabajo. Un buen trabajo de programación no son unas lineas de código tan limpias que ni el mismísimo UncleBob podría mejorarlas, sino una solución a una necesidad de un usuario que hemos puesto en producción teniendo en cuenta las restricciones y necesidades de la empresa para la que trabajamos. Por éso tenemos tantas conversaciones, porque necesitamos entender todas las necesidades implicadas. Pero una vez que nos sentamos a programar nos surgen dudas. Algunas son meramente técnicas y es fácil que la respuesta esté en StackOverflow o en la documentación de la API de turno. Otras también son técnicas, pero tienen que ver con “cómo trabajamos aquí”, con “cómo hemos resuelto esto antes”, etc. Y aquí nos encontramos con varios tipos de soluciones a este problema de las dudas técnicas:

  • Interrumpo a algún compañero para resolver mi duda. Es una ineficiencia en el proceso. Por un lado provocamos una interrupción sin la garantía de a quién interrumpimos nos vaya a resolver la duda. Algunos, conscientes de ello, sueltan la duda en un canal asíncrono (email, chat, etc), incurriendo en otro desperdicio: la espera por la respuesta.
  • Otra manera es tomar una decisión. La que sea. Con nuestro mejor criterio. Y confiar que un proceso de revisión, ya sea la “revisión de código” (code review) o el “control de calidad” (QA), encontrará el defecto, si lo hubiere. “Que no creo, porque soy un gran programador”, es lo que hemos pensado todos alguna vez. Yo al menos.
  • Mi preferida, sin embargo, es la prevención mediante la programación por parejas (“pair programming”). No voy a glosar las ventajas de la misma, pero sí a hacer hincapié en que está basada en conversaciones entre programadores, y a veces con otros roles.

Las dos primeras son soluciones que no salen del paradigma del cubículo. Pretendemos que trabajamos en oficinas con espacios abiertos, pero luego nos comunicamos con nuestros compañeros como si estuvieramos encerrados en un cubículo. La programación por parejas nos obliga a rediseñar el espacio de trabajo para que se puedan tener conversaciones mientras se trabaja sino para que éstas tengan lugar cara a cara. Ojo, cuando digo cara a cara, también puede ser a través de Hangout, Skype, o similar, pero siempre respetando este principio Ágil.

“El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.”

Las herramientas también nos hablan

Y finalmente, no quería olvidarme de unos compañeros muy importantes durante esta fase del desarrollo de software: todas las herramientas que usamos. Desde el editor (con su comprobación de sintaxis, por ejemplo) hasta el sistema de integración continua, todas las herramientas que hemos ido incorporando a nuestro proceso de desarrollo para encargarse de todas esas tareas exhaustivas y repetitivas en las que las máquinas son mejores que los humanos. Sin embargo, no debemos olvidar que ahí también hay una conversación y que requieren tanta atención como las que tenemos entre humanos.


En el siguiente articulo escribiré sobre las pruebas. Espero no tardar tanto como con éste. Compártelo si te ha gustado y ayúdame con tus comentarios ahí abajo.