Desarrollo de software. Transparencia y libertad

En un proyecto de desarrollo de software la transparencia es sinónimo de liberación. Es cierto que se siente presión porque los responsables funcionales conocen la realidad del proyecto y no aquella que se le quiera, en un momento dado, vender, pero una vez que se asimila esta forma de trabajar, poder mirar a los ojos a los usuarios y que ellos confíen en tu trabajo crea un clima en el que, si bien no se asegura el éxito, sí que resulta mucho más efectivo.

No es cuestión de metodología, esto no va de eso, es cuestión de una actitud con respecto al proyecto y a los usuarios. Es cierto que ciertos enfoques como el ágil favorecen y a la vez necesitan este tipo de contextos pero en cualquier circunstancia es perfectamente aplicable.

Hacer visible los trabajos, hacer visibles los problemas, reconocer errores, de eso va esto, manteniendo una comunicación fluida con los usuarios y permitiendo que ellos mismos, sin necesidad de tu intervención, puedan obtener parte de esa información cuando ellos quieran. No se trata de microgestión, sino de abrir ventanas y que cuando quieran se asomen, la frecuencia con que lo hagan es cosa suya, si bien, no está de más, si notamos que no lo hacen las veces que debieran, recordarles que tienen esa posibilidad.

Un proyecto requiere la colaboración continua entre equipos y personas, sin confianza todo es más difícil, por lo que es necesario poner todos los medios que sean posibles para crearla y mantenerla (que es lo más complicado), la transparencia es una buena base para ello.

Deja que el responsable funcional o el product owner tenga visibilidad sobre el sprint

Transparencia absoluta y posibilidad de feedback dentro del sprint. Todo eso podemos conseguir si damos visibilidad al responsable funcional sobre el entorno de desarrollo.

Esto se puede hacer en dos niveles y dependerá del momento del proyecto si resulta conveniente hacerlo o no. En cualquier caso que el usuario elija. Un primer nivel es el entorno en el que se ve el día al día del desarrollo, en el que tendremos historias de usuario el sprint resueltas y otras que están en construcción. En un segundo nivel el entorno de integración en el que solo deberíamos tener historias de usuario resueltas.

Sobre esto puede haber opiniones para todos los gustos (y respeto todas), desde los que piensen que es contraproducente dar esta visibilidad, como los que crean que con que tengan acceso al entorno de integración es suficiente.

Solo con la posibilidad de obtener feedback que permita ajustar mejor determinados detalles ya estaría del todo justificado esta decisión. ¿Tiene sus riesgos? Claro que los hay, como puede ser el hecho de que el responsable funcional interfiera demasiado en el sprint, afecte al ritmo del equipo y por tanto al cumplimiento de los objetivos.

Esa interferencia puede ser provocada por su deseo de cambiar una historia de usuario en pleno sprint (una cosa es ajustar detalles y otra darle un enfoque sensiblemente diferente) o por sus nervios si no terminan de ver unos resultados de calidad (muchas veces esto es provocado por trabajar con un entorno inestable, por eso hay quienes defienden que visibilidad sí pero solo al entorno donde se muestren las historias de usuario completadas).

Ante esto, lo mejor es recordar al usuario cuáles son las reglas del juego y hacerlo cuantas veces sea preciso.

Si quiere cambiar una historia de usuario, mejor prepararla bien y que sea en el siguiente sprint, anulando por tanto esa tarea en el actual. Si piensa que no se van a cumplir con los compromisos del sprint se le dan las explicaciones que sean oportunas.

Feedback, cuanto antes mejor pero con intención

El desarrollo de un producto que satisfaga las expectativas del usuario requiere poner en contraste de manera sistemática las distintas versiones que se van obteniendo en cada iteración, pasen o no a producción, con las ideas que tiene el usuario, las cuales evolucionan de la mano del sistema.

Esto es así porque las ideas no se aclaran hasta que son tangibles, por muy buenas ideas que se tengan y/o muy claro se tenga cuál debería ser el resultado final. En otros contextos como son, por ejemplo, las obras de arte, los mismos artistas que son, además, sus propios usuarios (independientemente de que la creación la adquiera un tercero), necesitan trabajar sobre la solución y en muy contadas ocasiones, todo sale a la primera.

Pensar que la solución no se obtiene a la primera no es una actitud derrotista o una bajada de brazos sino de ver el proyecto desde una perspectiva más realista.

Las ideas son solo hipótesis que cobran forma cuando se materializan en producto. Cuanto más se tarde en corregir las desviaciones entre el producto y las expectativas del usuario más costoso resulta volver a encontrar el camino, por eso el feedback no solo es necesario sino que cuanto antes empiece a aplicarse mejores resultados se obtendrán a la par de un mejor aprovechamiento de los recursos disponibles.

No olvidemos, sin embargo, que se debe desarrollar con intención, el feedback no es un salvoconducto para la programación por permutación o para probar hipótesis que no han sido lo suficientemente reflexionadas. Si se actúa de esa manera se desvirtúan los beneficios del feedback, pasando de un enfoque evolutivo a otro basado en el prueba y error, que no niego que en alguna ocasión para funcionalidades que no se tienen claras pueda ser de utilidad, pero que no debe ser la práctica habitual en un desarrollo de software en el que se trata de adquirir el mayor valor posible con respecto al esfuerzo invertido.

Sincronización de los sprints en proyectos con más de un grupo de trabajo

Teniendo en cuenta que habría que estudiar cuál es la solución más adecuada en cada proyecto, soy de la opinión de que resulta más productivo a la vez de que simplifica la gestión, tener sincronizados los sprints de los diferentes grupos de trabajo que participan en el desarrollo de un producto.

Tal vez una primera cuestión, antes de analizar el tema de la sincronización, podría ser si tiene sentido tener varios equipos o no, la respuesta es que depende del número de personas que participan, de si se pueden independizar los desarrollos de manera que no exista gran acoplamiento en los trabajos, de si se tiene uno o más proveedores, de la localización geográfica…, y por supuesto del proyecto.

Si tenemos varios equipos de trabajo es porque de manera acertada o errónea se ha determinado qué es la mejor opción en estos momentos. Superada esa primera decisión, toca determinar si los equipos entregan a la vez o no.

Podría dar igual si cada equipo va desarrollando partes totalmente independientes del producto, es más, podría resultar hasta más productivo de cara a un cliente (aunque no es más que un efecto óptico) ver cómo de manera continua se están añadiendo nuevas funcionalidades al sistema, en lugar de esperar todo un sprint para ver un nuevo incremento. Sin embargo, resulta complicado encontrarnos con situaciones en la que los desarrollos se encuentren totalmente desacoplados, ya que llegará un momento donde será necesario integrar las piezas del puzzle que unen unos desarrollos con otros y esto sucederá tarde o temprano y más de una vez.

Este tipo de desarrollo es demasiado vertiginoso tanto para los propios gestores técnicos del proyecto que tienen que tratar de sincronizar e integrar trabajos de equipos que trabajan en tiempos distintos, como para los propios usuarios que no terminan de trabajar sobre un producto asentado lo que afecta a la calidad de su feedback, a la par de someterles a una gran presión ya que además de eso, deben seguir colaborando en el refinamiento de la pila de producto, proporcionando toda la información y material necesario para que los equipos de proyecto puedan cumplir con sus compromisos.

Además, resulta más fácil alinear los objetivos de varios equipos, así como fomentar su colaboración, ya que tienen un horizonte común que no es otro que la fecha de finalización del sprint, independientemente de las tareas que tengan que realizar cada uno.

A todo lo anterior hay que sumarle el overhead que supone la gestión de más procesos de pasos a producción, que se multiplicarían con aquellos casos en los que sea necesario realizar subidas fuera de sprint para resolver incidencias críticas.

Desarrollo de software. El daño de los tiempos de espera

En esa situación ideal de tener al personal que trabaja en un proyecto repartido entre varios y poder balancearlos en función de la carga de trabajo existente, los tiempos de espera no presentan mucho problema. Sin embargo, todos sabemos que es muy complicado (que no imposible), llegar a encontrarnos con algo así.

En los ciclo de vida clásicos, tal vez sea más sencillo encontrar ese equilibrio, porque por mucha agenda que haya, todos sabemos lo que suele pasar: El análisis, la construcción o ambos tienden a durar más de lo que se esperaba.

En los enfoques ágiles los tiempos de espera atacan directamente a la línea de flotación del propio planteamiento del proyecto porque rompe el ritmo y afecta al cumplimiento de los compromisos. Por otro lado, sabemos que no es productivo tener a personas compartidas entre proyectos que no tienen nada que ver entre sí y que lo mismo no es tan fácil o rápido recuperarlas cuando el proyecto vuelva a arrancar.

Por otro lado, resulta esencial que al comienzo de una iteración se tenga todo lo necesario para realizarla, soy muy pesado con este tema, porque he vivido en primera persona lo perjudicial que resulta no empezar con todo lo necesario porque resta flexibilidad a la hora de afrontar los trabajos y porque llegado un punto no se podrán cumplir con los compromisos adquiridos y os aseguro que nos lo demandarán y exigirán de igual forma que si hubiéramos recibido todo lo necesario al principio.

Por el bien del proyecto a veces será necesario romper esa regla pero esas excepciones debemos tratar que se conviertan en norma, porque no solo es responsabilidad de los desarrolladores que se cumplan los compromisos.

Objetivo no arrastrar defectos

Sabemos que la mayoría de los defectos, incidencias o malas prácticas de desarrollo tienden a ser más costosos de corregir conforme pasa el tiempo, ya que van quedando, cada vez, más imbricadas dentro del código.

A eso hay que sumarle su impacto sobre la versión del producto que está en producción y sobre la mantenibilidad del sistema.

Por ese motivo, se considera una buena práctica corregir el defecto lo más cerca posible de su origen. Para ello primero hay que detectarlo y después encontrar el momento más adecuado para resolverlo, pero, ¿no es la mejor solución corregirlo cuanto antes?, sí, pero no es tan simple.

Supongamos que hemos detectado un defecto en una de las funcionalidades del sprint, que la misma no resulta crítica para el sistema y que su resolución requeriría de un esfuerzo que comprometería el resto del sprint, ¿se debe corregir ahora o mejor lo dejamos para uno de los próximos sprints?, ¿se incluye la funcionalidad con esa incidencia conocida en la entrega o no se pasa la funcionalidad completa?.

Hay que analizar la situación y solicitar la opinión del responsable funcional, no hay soluciones que valgan para todo. Sí que es cierto que corregir el problema cuanto antes evita que la grieta se ensanche, que estudiar la causa del mismo puede prevenir de otros fallos similares, también es cierto que todas las incidencias no son iguales y no impactan de la misma manera y todos esos factores son necesarios tenerlos en cuenta para seleccionar el momento más apropiado para realizar la corrección.

La economía de la intención

El desarrollo de software debe buscar la satisfacción de las expectativas del cliente. De lo que nos aproximemos a ese hito, será lo cerca o lejos que estaremos del cumplimiento de los objetivos.

Hablo de objetivos relacionados con la calidad del producto. La calidad técnica, es importante, muy importante, pero para el usuario está en un segundo plano, respecto a si el producto hace lo que espera y le permite trabajar de manera productiva.

Por ese motivo se dice que la calidad tiene dos puntos de vista, el del usuario y el del desarrollador. Es cierto que existe esa dualidad pero también que no se debe entender la una sin la otra.

Un producto software siempre es susceptible de ser evolucionado. Habrá un motivo para ello y el resultado debería ser un incremento del valor del mismo siendo proporcional al esfuerzo (coste) invertido para conseguirlo. De aquí surge otro objetivo: conseguir el mayor valor posible invirtiendo el menor esfuerzo posible.

Si conseguimos ganar valor, ahorrando esfuerzos, tendremos la posibilidad de seguir evolucionando el producto para así conseguir generar más valor. Es algo que debemos tener siempre presente, pero que no debe llegar a obsesionarnos porque llegado a un punto puede dar lugar a situaciones en las que se ponga muchos reparos a especular en el desarrollo, algo que a veces es inevitable porque el usuario no siempre tiene claro lo que quiere y necesita ver ejecutada su especificación para valorar si su idea es buena o si por el contrario necesita ajustes.

Tener presente ese rendimiento de la inversión obliga a tener en cuenta la calidad técnica en los desarrollos (y por ahí es donde se puede y se debe trabajar este asunto con el cliente), rematar las tareas, cumplir los compromisos, reducir la tasa de errores y desarrollar con intención.

Con la intención se pretende minimizar el número de iteraciones. Es cierto que intención y especulación son dos términos que no se llevan bien, pero no son incompatibles, de hecho no se utilizaría el término intención si se tuviera la certeza de que todas las decisiones que se toman son correctas. Se trata, por tanto, de trabajar con el usuario, para incrementar la probabilidad de éxito: historias de usuario con prototipado de pantallas tomando como referencia versiones ya liberadas del producto, de las funcionalidades más prioritarias seleccionar aquellas que se tenga más clara su operativa de uso, etc…

Peter Drucker. Lo que no se dice

Me parece muy sabia la siguiente reflexión de Peter Drucker: “El aspecto más importante de la comunicación es escuchar lo que no se dice”. Y no se refiere a lenguaje no verbal, sino a interpretar realmente lo que nos están comentando porque no debemos olvidar que somos personas, estamos llenos de emociones, también de miedos y no siempre trasladamos la realidad de una situación o de un problema a palabras bien porque no queremos, no sabemos o no podemos.

El objetivo de las relaciones entre las personas en un ámbito profesional y colaborativo debe ser la transparencia, pero no deja de ser un fin, no digo una quimera, pero sí algo que es más complicado de lo que parece porque hay que ser muy valiente para no guardarte nada y exponerlo todo. Además de valentía se requiere confiar en la otra parte y la confianza cuesta mucho construirla y consolidarla.

Pero hay que intentarlo. En un contexto como el del desarrollo de software en el que la comunicación y la interacción entre las personas es esencial, es la base para establecer una relación de confianza entre todas las partes, algo que resulta fundamental para que el proyecto se desarrolle sobre un contexto propicia (independientemente de que después las cosas salgan mejor o peor).

Poco a poco, mientras tanto tocará interpretar lo que se dice pero también lo que no.

Desarrollo de software. Entrega rápido… pero bien

Entregar rápido permite que tanto usuarios como desarrolladores aprendan antes, que los problemas salgan a relucir pronto, que el valor del producto se acelere, que la visión del producto cobre forma y que nuestra respuesta al cambio sea adecuada.

Ahora bien, entregar rápido debe modularse a las características del proyecto en el que nos encontremos, del equipo de personas que trabaja en él, la capacidad de trabajo que se puede absorber, su contexto y el estado actual del desarrollo.

Hay proyectos donde se puede considerar entregar rápido definiendo sprints de 2 semanas y otros que pueden ser igual de rápidos con sprints de 6. Depende. Lo mejor es adaptar la solución al proyecto y no el proyecto a la solución.

Entregar rápido funcionalidades incompletas no presenta ventajas. Entregar rápido funcionalidades con errores críticos es incluso peor. Entregar rápido con baja calidad en el código a la larga es devastador. Entregar rápido funcionalidades que aportan poco valor produce poco beneficio a esta estrategia e incluso puede ser perjudicial si tenemos que llevar de lastre funcionalidades no decisivas mientras se desarrollan las que verdaderamente importan.

Una buena práctica o estrategia ejecutada a ciegas probablemente produzca resultandos opuestos a los esperados.

El analista y los proyectos ágiles

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).