El desarrollo de software son conversaciones (V)
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,…
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,…
En los artículos anteriores de esta serie me he centrado en esa parte del proceso en la que fundamentalmente hablamos sobre el qué y no tanto sobre el cómo. Si haces Scrum, me refiero a todo lo que haces antes de la reunión de planificación del sprint. Si haces Kanban, seguramente llamarás “upstream” a toda esa parte del proceso de desarrollo. Esa misma metáfora nos lleva a hablar de “downstream” (ya trabajes por lotes o no) como a la parte del proceso que se dedica al trabajo que ya nos hemos comprometido a construir y desplegar. En este artículo empezaré a hablar de las conversaciones que tenemos en el downstream.
En este tercer capítulo de la serie me concentraré en el proceso de refinamiento, es decir, en pasar de una idea aún demasiado ambigua hasta una especificación suficientemente detallada como para comenzar la traducción de la misma a un lenguaje formal y ejecutable.
En el primer artículo de esta serie me centré en las primeras conversaciones que tiene el equipo respecto de una idea, con el objetivo de descartarla o no. En este artículo voy a explicar qué tipo de conversaciones se tienen para decidir cuál elegir de entre todas las opciones disponibles y qué técnicas podemos emplear para facilitar esas conversaciones.
El proceso que nos lleva desde una idea más o menos ambigua hasta el desarrollo y despliegue de una nueva funcionalidad en un producto de software está guiado por conversaciones que suceden entre personas. En esta primera parte del artículo justificaré esta afirmación y explicaré cómo podemos usar técnicas concretas para facilitar estas conversaciones.
Mi compañero @AgileGibbo, inglés, me alertó de que podría estar hiriendo la sensibilidad de muchos compatriotas al usar la imagen que ilustra mi anterior artículo “El jefe de proyecto ha muerto”. Esta conversación, sin embargo, me inspiró una reflexión sobre las diferencias en entornos multiculturales y en especial sobre las diferencias culturales que se dan durante la introducción de Agile en una organización.
Hace años que uso esta frase para comenzar mi explicación sobre el cambio social que representa la introducción del agilismo en una organización. Lógicamente se trata de una metáfora porque, cuando adoptamos métodos ágiles, nadie mata a nadie (al menos no literalmente). Hablar sobre “la muerte del jefe de proyecto” me permite introducir conversaciones sobre roles, responsabilidades y, sobre todo, acerca de cómo adaptarse al cambio de paradigma respecto de cómo ejercemos el poder en una organización.
La Comunidad es un concepto un tanto subjetivo. Me gustaría que me ayudaras a entenderla mejor participando en un debate.