Introducción

Para comenzar, vamos a dar una pequeña introducción a la organización del trabajo y a las metodologías ágiles ampliamente utilizadas hoy en día en el desarrollo de software. En las siguientes lecciones, iremos desgranando GitHub Projects y GitHub Issues para facilitar esta organización del trabajo.

Al finalizar, sabrá:

Qué es la organización del trabajo.
Por qué realizar esta organización.
Qué es el ciclo PDCA.
Qué es la mejora continua, por qué es importante y cuándo se puede aplicar en el desarrollo de software.
Qué es el desarrollo ágil y algunos conceptos importantes a conocer.

Introducción

La organización del trabajo (work organization) tiene como objeto registrar, planificar y gestionar el trabajo a realizar para lograr nuestro objetivo, en nuestro caso, el desarrollo de un producto de software. Todo ello de la manera más óptima, eficiente y efectiva posible.

El ciclo PDCA (PDCA cycle) es un método iterativo para la gestión, muy utilizado hoy en día en el mundo de los negocios porque ayuda a la mejora continua. Esta mejora continua (continuous improvement) es una manera de trabajo que permite analizar el proceso de desarrollo periódicamente con el objeto de mejorarlo continuamente y, así, ser más eficientes y productivos. Hay que ser realistas, un proceso no es infalible y lo que funciona en una organización no tiene que funcionar en otra y lo que funciona en un proyecto tampoco debe hacerlo en otro de la misma organización. Teniendo en cuenta esto, es recomendable sentarnos a analizar y evaluar nuestro enfoque de trabajo, detectar aquellas cosas que no están funcionando, proponer una mejora y entonces aplicarla. Así, continuamente.

El ciclo PDCA debe su nombre al acrónimo inglés de las cuatro fases que lo componen:

Planificación (plan). En esta primera fase, lo que se hace es analizar las actividades que hay que realizar y planificar aquellas que entrarán a formar parte de la siguiente iteración de desarrollo.
Hacimiento (do). Aquí, se realizan los cambios planificados para incrementar el valor del producto.
Comprobación (check). Se realiza un análisis de las métricas recopiladas para evaluar cómo ha ido todo y si podemos hacer cambios que mejoren nuestro proceso.
Actuación (act) En esta última fase, tras los datos recopilados y analizados en la anterior, decidimos qué cambios debemos hacer para la siguiente iteración.

Por ejemplo, en el momento de escribir estas líneas, en el proyecto Akromio, https://akromio.com, las iteraciones son bimestrales, aunque anteriormente eran trimestrales, pero se observó que eran periodos demasiado largos y sólo había cuatro momentos al año para aplicar la mejora continua. Al hacerlo bimestral, hay seis puntos de control al año, aunque no se ha descartado reducirlo a un mes. Cada dos meses, hay una análisis y evaluación de cómo ha ido el último bimestre y se toman las medidas correspondientes para mejorar en el siguiente. Se intenta que cada dos meses se realicen cambios que mejoren el proyecto y, así, la productividad. Es posible que en la fase de comprobación se detecten varios cambios, pero no todos ellos se pueden aplicar de inmediato a la siguiente iteración. Se seleccionan los que son más importantes y factibles de llevar a cabo, se consideran como objetos de mejora para el siguiente bimestre y se aplican durante la siguiente iteración. Tenga en cuenta que no hay nadie en el mundo que sea perfecto y como los desarrolladores somos personas, entonces no somos perfectos y cometeremos errores y, a veces, tomaremos decisiones equivocadas. La idea del ciclo PDCA es comprobar que el proceso está funcionando bien y, en caso de no ser así, mejorarlo para incrementar la productividad y la eficiencia.

La mejora continua (continuous improvement) tiene varios objetivos en mente:

Minimización de los desperdicios. Un desperdicio (muda) no es más que algo que no aporta valor, que genera un derroche de alguna otra cosa o un residuo que no se puede utilizar. En el desarrollo de software, hace referencia a cualquier actividad que consume recursos y que no añade valor al producto de cara a sus usuarios. Entre otros ejemplos, encontramos: las esperas, es decir, el tiempo que estamos parados sin hacer nada debido a que estamos esperando a que algo de lo que somos dependientes termine para, así, poder continuar, por ejemplo, una tarea que está realizando otra persona del equipo; los defectos añadidos, por ejemplo, debido a la definición o concepción incorrecta de un requisito; etc.
Mejora de la productividad. Si conseguimos reducir o incluso suprimir los desperdicios, estaremos utilizando mejor los recursos y seremos más productivos.
Mejora del diseño del producto. Como periódicamente nos paramos a pensar y analizar la situación, entre otras cosas, podemos evaluar el feedback de los usuarios y, así, analizar si les estamos entregando lo que quieren y, por otra parte, detectar si deberíamos hacer otras cosas que les proporcionan más valor que las que inicialmente pensábamos se lo daría.
Mejora del proceso de desarrollo. Como en cada iteración vamos afinando el proceso, estamos aprendiendo continuamente y, a corto, medio y largo plazo, nos enriquece como organización de desarrollo.

Desarrollo ágil

La agilidad (agility) es la capacidad de ser ágil, en nuestro caso, viene a reflejar nuestra facultad y aptitud para adaptarnos a los cambios con soltura y rapidez. El desarrollo ágil (agile development) consiste en un enfoque iterativo e incremental para el desarrollo de software que permita la mejora continua. Con iterativo (iterative), hacemos referencia a la repetición, o sea, que se repite una y otra vez el proceso de desarrollo, permitiendo así que tras cada repetición haya un momento de análisis de situación que permite la mejora continua de cara a la siguiente repetición. Cada una de estas repeticiones se conoce formalmente como iteración (iteration). En cambio, con incremental hacemos hincapié en que el producto se va construyendo poco a poco con pequeñas añadiduras de valor. Cada uno de estos añadidos se conoce formalmente como incremento (increment) porque añade nuevo valor al producto.

En resumen, el desarrollo ágil consiste en ir generando el producto de software mediante iteraciones, bloques de tiempo en cada uno de los cuales se desarrolla un incremento que proporciona valor al producto final. Según la metodología, la duración puede ser distinta, de una semana a dos meses es lo más común, pero no es extraño que sea mayor si el proyecto así lo requiere. Tras la iteración, tendremos una nueva versión del producto que satisfaga ciertas necesidades de los usuarios y que les proporcione valor. La clave aquí es el concepto de valor. El valor (value) no es más que cualquier cosa que proporciona utilidad a los usuarios. Si implementamos algo que no usarán o que no les proporciona utilidad, hemos desperdiciado recursos. El final de cada iteración, a su vez, se convierte en un punto de control en el que podemos analizar cómo ha ido y adaptarnos a los cambios, ya sean del proceso de desarrollo o de requisitos.

Hoy en día, existen muchas metodologías de desarrollo ágil como, por ejemplo, Lean o Scrum, diferentes formas de ver el desarrollo, pero todas ellas con el objeto de mejorarlo, permitiendo la mejora continua. Sin particularizar mucho en ninguna metodología ágil, groso modo, tenemos que cada iteración consiste en:

Planificación y refinamiento de la iteración.
Desarrollo de la iteración con reuniones periódicas por parte del equipo de desarrollo y el propietario del producto para mantenerse informados de lo que están haciendo los demás y de cómo va el proyecto. Cada día se suele llevar a cabo lo que se conoce como reunión diaria (daily meeting) en la que el equipo se reúne, con una duración de no más de quince minutos, para explicar lo que cada uno hizo el día anterior, qué problemas encontró, escuchar lo que otros están haciendo y proporcionar ayuda si alguna otra persona del equipo está teniendo problemas, compañerismo. Toda reunión tiene un moderador que garantiza que la reunión no dure más de esos quince minutos, que no se desmadre y que se usan buenas formas para comunicarse los unos con los otros.
Revisión del incremento.
Retrospectiva de la iteración.

Es posible que la metodología particular usada por su organización incluya otras fases o no incluya todas las aquí indicadas. Este libro no tiene como objeto explicar una metodología en concreto, sino explicar cómo desarrollar software y cómo administrar y organizar el trabajo con GitHub Projects y GitHub Issues. Aplicaremos distintos términos a lo largo del libro, cuando sea necesario, por si ya es conocedor de alguna metodología.

Planificación y refinamiento de la iteración

Para comenzar, hay una planificación de lo que se debe desarrollar en la iteración que va a comenzar, o sea, su alcance. Lo determina el propietario del producto tras analizar las necesidades del cliente y los usuarios. A los clientes y usuarios se les conoce formalmente como interesados (stakeholders). El propietario del producto (product owner) es la persona responsable de mantener la visión global del producto a desarrollar. Entre sus principales funciones, encontramos:

Interactuar con los usuarios y clientes para conocer sus necesidades y lo que hay que desarrollar.
Priorizar lo que hay que desarrollar teniendo en cuenta las preferencias del cliente y los usuarios.
Analizar las necesidades y describirlas detenidamente para que el equipo de desarrollo pueda entenderlas sin malas interpretaciones.

Es importante tener claro que este rol no es específico ni de Scrum ni de las metodologías ágiles.

El refinamiento de cada cosa corre a cargo de todos. Por un lado, el propietario de producto debe refinar lo que debe hacerse en cada ítem. Por otra parte, el equipo de desarrollo lo refina determinando exactamente que habrá que hacer en el software. A esta reunión de perfeccionamiento de los ítems por parte del equipo de desarrollo se le conoce como refinamiento (refinement meeting).

Básicamente, todo consiste en determinar qué ítems del registro del producto (product backlog) se llevarán al registro de la iteración (iteration backlog). Por otra parte, del registro de la iteración deberán refinarse para que sea fácil moverlas al estatus Todo por parte del equipo a lo largo de la iteración.

Revisión del incremento

La revisión (review) es una reunión, al final de la iteración, a la que acude el cliente, algunos usuarios, el propietario del producto y, recomendable, el equipo de desarrollo para validar que lo presentado en el nuevo incremento generado es lo que se necesitaba. En otras palabras, que se entendieron bien los requisitos y se implementaron correctamente. Como el mundo no es perfecto, no siempre será un camino de vino y rosas. Pero nos ayudará a seguir por el buen camino y no desviarnos mucho de él. Es otro evento en el que obtenemos feedback con el que mejorar.

Retrospectiva de la iteración

La retrospectiva (retrospective) es una reunión, definida por la metodología Scrum, en la que se busca hacer un análisis o balance de cómo ha ido el último sprint o iteración. La idea es que las personas participantes expongan lo que consideran ha ido bien y lo que ha ido mal. Si sabemos qué ha ido mal, podemos buscar soluciones al problema y, entonces, aplicar mejora continua en la siguiente iteración. Lean dice que periódicamente hay que pararse, hacer un análisis de situación y ver si se puede mejorar algo. La idea de esta reunión es esa, buscar lo que está yendo mal y, así, mejorar; y, por otra parte, no tocar lo que está yendo bien para no empeorar.

En Scrum, acuden el equipo de desarrollo, el propietario de producto (product owner) y el scrum master.

En los proyectos individuales también se puede aplicar la retrospectiva al finalizar la iteración. Nos sentamos con nosotros mismos, analizamos cómo ha ido todo y vemos qué debemos o podemos mejorar. Es un momento de autocrítica, es muy poco probable que todo haya ido sobre ruedas y no podamos mejorar nada. Así, tenemos unos objetivos de mejora a aplicar en la siguiente iteración y vamos mejorando continuamente.

Si encuentra varios puntos de mejora, elija dos de ellos para la siguiente iteración. Algo que sea posible de llevar a cabo y con lo que mejorar. No se venga arriba e intente cambiarlo todo. Estos puntos de mejora elegidos se conocen como objetivos de mejora (improvement goals) en la siguiente iteración. Que al finalizarla, veremos si los hemos alcanzado y si las medidas tomadas para la mejora han tenido sentido.