Forem: Gero DP

A Step-by-Step Guide to Effective Code Reviews

Gero DP — Wed, 22 Nov 2023 07:25:11 +0000

Code reviews are a practice that has become widespread in recent years, where one or more developers review the new code implemented by another colleague, with the aim of detecting code quality issues, bugs, vulnerabilities, bad practices, etc… . This allows feedback loops to be shortened, which we know is very beneficial because the later a problem is discovered, the higher the cost of fixing it and the greater the potential business impact.

As code is the essential material from which software is built, and is created and maintained on a daily basis by different developers and teams, it is vital to have mechanisms in place to ensure its quality. Conducting good code reviews, consciously and according to best practices, can make the difference between the success or failure of an application and, ultimately, a business. Therefore, one of the first recommended steps in adopting code reviews is to have a how-to guide to provide guidance and direction to the whole team. This article is intended to serve as an initial guide that teams can use and adapt to their context.

Fundamentals of good code

Before going into details, I find it interesting to share this document, that although it is called Zen of Python, it is a good guide for any language.

The beautiful is better than the ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability is important.
Special cases are not so special as to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, reject the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than ever.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Source

Objectives of Code Reviews

(Style) Detect divergences from the style defined in the style guides (it is advisable to define style guides for the code of our company) and in the code of the project.
(Architecture) Check if the implementation follows the architecture of the code.
(Modularity) Check if the new code is too tightly coupled. Check that the components have cohesion, have a single purpose.
(Composition and inheritance) Review whether inheritance and composition are used correctly. And priority is given to composition over inheritance.
(APIs) If APIs are created or extended, check that they are consistent and clean.
(Readability) Check that the code is easy to understand, follow and maintain.
(Testability) Check that the code has unit tests and automatic tests that test the new functionality.
(Preventing bugs) Detect possible bugs and/or cases not covered by the code.
(Knowledge sharing) Familiarize the rest of the developers about the changes that are being made in the code. It allows the knowledge to be more distributed in the team.
(Training) Transfer knowledge from senior programmers to newcomers and juniors.
(Security) Check that the code does not expose credentials of any kind, and has no obvious security flaws.

Setting the ground

The objective of the review is not to criticize the work of colleagues, but to review it in order to improve it together, to detect possible lapses or bugs, and to learn through feedback. Comments should always be respectful and should be received in an open manner, thanking our colleague for the time he/she has spent reviewing our code. The review should never be approached as a competition between adversaries, but as a team work.

No matter what seniority we have as developers, we are all human and we all make mistakes. A good developer, no matter how senior, is always open to feedback even if it comes from a more junior developer.

Steps to follow

Pre-review

Open the Pull Request/Merge Request (or PR / MR) and read the description. If you still lack context for the change, open the ticket in your project management software and read it. It is important to read the acceptance criteria, to try to detect if the code can meet all of them or not (of course, the purpose of code review is not to test it, but in many occasions you can detect uncovered acceptance criteria simply by looking at the code).
Verify that the base branch is the correct one. Sometimes by mistake, you can create a PR against main, when you wanted to integrate it in another branch. In case it is not, notify it and stop the revision. Because if the base branch is not the correct one, we may be revising changes already revised.

Review

Start by reviewing the list of changed/created/deleted files. Check that the file and module architecture is consistent with existing and best practice guidelines (if any). Check that the names follow the naming convention.
If the code has unit tests (recommended), starting with the unit tests can be a good way to understand if all the acceptance criteria are covered or not. It is also a good way to understand the code from the outside. Unit tests should cover not only the happy path, but also corner cases and error cases.
Check that the style of the code follows the style guide (if any), if not, check that it is uniform with the existing code. Check the names of variables, classes, methods, etc…
Check that the architecture of the new code respects the existing architecture. For example: new classes are consistent with existing classes. The way the code is organized in files follows the existing patterns.
Check that the code is loosely coupled and has cohesion. Classes and methods should have a single purpose. A common example of high coupling is where access to the database engine for queries is spread throughout the code. This leads to high coupling to the specific database engine, making it difficult to replace in the future, for example.
Check that no code has been duplicated. DRY (Don’t Repeat Yourself)
Revisar que el código es sencillo de entender. Si vemos código complicado, deberíamos añadir un comentario a la PR, para que el desarrollador intenté hacerlo más sencillo y/o añadir comentarios para que se pueda entender.
Check that magic numbers or literals are not used, which makes the code less understandable and less maintainable. Suggest the use of constants with a self-explanatory name.
If an API has been modified, check that the changes are consistent with the rest of the API, and check that the documentation has been updated.
The idea is to review the new code, but sometimes to understand it well we will need to read a little bit the context, the already existing code. Sometimes we can see that the change is incomplete or not correct by looking at the context.
Check that the code does not include passwords, credentials or sensitive information of any kind. If so, this information is already in the repository and could be compromised, consider changing the credentials.
Be on the lookout for any security issues that are obvious to the naked eye. For example, sql injections (using a user input directly in a sql query).
Review whether the changes should reflect changes in the repository documentation (e.g., in the README), and see if it has been updated and is correctly understood. For example, if the way to launch the project locally has been changed, it should be clearly updated in the README.

Post review

In the event that we have made comments, be attentive to the possible response and changes in the PR, to review again.
If we have not made comments and we see it well. Indicate it in the PR and accept it. Here, depending on the rules that we have defined in our team, it may be necessary that other people review it and follow a specific process to merge the PR.

Final notes

This guide serves as a generic reference for making code reviews in a uniform way across a team/organization. The idea is that each team/organization can customize and extend it to their particular case, and work continuously to improve and adapt it to their circumstances.

In addition to all these manual checks, it is highly recommended to incorporate static code analysis tools, linters, and formatting rules in the IDE, among others, into the process. These will allow us to detect problems, quickly and cheaply, even before creating the PR to request the code review.

And of course, your comments are always welcome.

7 Thoughts on using ChatGPT and Github Copilot for coding

Gero DP — Fri, 17 Nov 2023 12:53:23 +0000

This year I've started using ChatGPT and Github Copilot to code some projects. So far the experience has been very positive, so I wanted to share some of my thoughts on these technologies (from now on I'll refer them as copilots):

In my experience, ChatGPT4 is much more powerful for generating code than Github Copilot. The problem is that using ChatGPT Plus doesn't protect your sensitive information (unless you go for Enterprise). So it won't be an option for many companies. However, if you're working on open source or small projects, it's definitely worth considering.
Copilots can significantly increase the duplication of code, with all its implications. Imagine if copilot suggested a snippet of code instead of suggesting the use of a library. If the library has a bug and it's fixed sooner or later, you'll benefit by upgrading to a new version. You can even be notified when a new version is available. But you lose this if the code is generated by copilot and doesn't include the use of third-party libraries.
Developers risk getting lazy. This happens to me sometimes. I'd say that for senior developers this might be less important, but for junior developers it can become a disadvantage. At least for the time being, copilots are not yet a replacement for programmers, and good programming skills are needed to check copilot output. In my opinion, companies should carefully analyse these implications before offering Co-Pilot to every developer on their staff. And developers should be aware of the impact of using copilot on their skills.
ChatGPT is great for understanding code. For some programmers working in mature systems, and especially for newcomers, it can be a great help. For example, you can use it to understand open source code. If you want to use it in your company, it's wiser to use ChatGPT Enterprise, which protects company data.
OpenAI doesn't want you to use ChatGPT to build AI models that compete with GPT. They have this clause in their terms and conditions. Does this mean that they think you can build serious competitors to GPT models using ChatGPT? Interesting…
In my opinion, the productivity gains from using co-pilots should be used to spend more time on best practices such as automated testing, code reviews, increased security, CI/CD pipeline automation and technical debt management, before considering reducing the number of programmers or increasing the scope expected of programmers. This is particularly important for small and medium sized enterprises, which typically make multiple trade-offs in these areas.
OpenAI's new GPT creation functionality allows you to create applications using natural language. This can replace programmers for certain use cases. However, even when building GPTs, programming skills will generate better prompts and therefore produce better applications.

Overall, my experience has been pretty good and I think we have only just begun to see some of the full potential of these technologies. I'm looking forward to revisiting these thoughts in a year's time and seeing how things have developed.

Revisitando las metodologías ágiles: XP, Scrum, Kanban y Scrumban

Gero DP — Thu, 16 Mar 2023 18:07:30 +0000

Llevo casi 10 años desde que empecé a trabajar en agile, recuerdo que mi primera experiencia fue cuando estaba trabajando en el sur de Francia para la empresa Amadeus. Por aquel entonces la dirección de la compañía planteó cambiar y actualizar la forma en la que los equipos de desarrollo trabajábamos, y llevar a cabo una adopción de metodologías ágiles, principalmente utilizando el framework de Scrum. En mi equipo me ofrecieron hacer la formación de Scrum Master, que duraba 3 días, después de los cuales había que hacer un examen para certificarse. Y así fue como me convertí en Scrum Master certificado..

Desde entonces he tenido la oportunidad de trabajar con Scrum en 3 compañías y 8 equipos diferentes, completando proyectos y desarrollando productos para muy diversos fines. Sin embargo, me he quedado con una sensación agridulce. Por un lado, creo que la idea de Scrum de descomponer el trabajo en pequeñas iteraciones y liberar versiones frecuentemente para que los clientes lo prueben y den feedback, nos ha aportado mucho. Pero por otro lado, en bastantes ocasiones he visto como la productividad de los equipos se iba degradando, y no he sentido que el framework nos diese las herramientas para encauzar la situación. Es más, muchas veces su naturaleza altamente prescriptiva se me hacía algo rígida para resolver nuestros problemas.

En estos últimos años también he trabajado con equipos que usaban Kanban para las operaciones y Scrumban para el desarrollo, pero al igual que con Scrum, no he tenido la sensación de que nos estuviesen aportando todo el valor que esperábamos.

Es por estos motivos por los que me he planteado revisitar los frameworks y metodologías ágiles más comunes para tratar de entender 1) cuál es la filosofía e ideas claves detrás de cada uno de ellos y 2) cuales han sido las posibles deficiencias o fallos cometidos al implementarlos en nuestros equipos. Pero quiero anticipar que este post no pretende ser completo en la descripción de las diferentes metodologías y sus problemas, sino más bien un compendio de ideas y experiencias que sirva como punto de partida para explorar más en detalle la metodología que nos interese. Para lo cual las referencias al final del post son muy recomendables.

Me he centrado en 4 herramientas, metodologías o frameworks ágiles: Extreme Programming, Scrum, Kanban y Scrumban, por ser los más conocidos en la industria del software. Pero antes de nada me gustaría empezar por el principio: el agile manifesto.

Agile Manifesto

Surge el fin de semana del 11 al 13 de Febrero de 2001, en el que un grupo de ingenieros de Software entre los que estaban Martin Fowler, Robert C. Martin, Kent Beck o Jeff Sutherland, entre otros, se juntan en un resort de Ski en las montañas de Utah para hablar e intentar alcanzar un marco común que expresase como veían el desarrollo de software. Surge como respuesta contra el modelo imperante hasta la fecha, que apostaba por procesos largos y dirigidos por extensa documentación. Su objetivo principal era devolver el protagonismo a las personas, que habían sido relegadas a un segundo plano en las grandes organizaciones burocratizadas de la época. Los allí reunidos querían definir los valores y principios de un nuevo movimiento “cultural” que sirviese para crear comunidades y organizaciones donde sintieran que querían trabajar.

agilemanifesto.org

Al volver a releer el manifiesto, me vienen a la cabeza situaciones en las que aún trabajando con frameworks ágiles, no hemos sido fieles al manifiesto. Recuerdo un caso, que representa bien el valor de priorizar: “Colaboración con el cliente sobre negociación contractual”. Hace algunos años, en un proyecto que estábamos ejecutando con un equipo en Scrum, tuvimos que desarrollar una funcionalidad que había sido comprometida por contrato, aunque el cliente nos había comentado a posteriori (durante una de la reuniones semanales) que no la iba a utilizar. Aún así el equipo comercial nos pidió implementarla para no incumplir el contrato. Analizado en retrospectiva y con el manifesto delante, creo que la forma adecuada de proceder hubiera sido aplicar los principios ágiles también durante la redacción del contrato. Se podrían seguir incluyendo las funcionalidades en el contrato, pero añadiendo una cláusula donde se pudiesen cambiar esas funcionalidades por otras (de coste similar) previo acuerdo de ambas partes.

Este es solo un ejemplo de cómo la filosofía ágil va mucho más allá de la organización del trabajo en equipo y supone un cambio de mentalidad y forma de trabajo para toda la organización. Por eso cuando una empresa quiere llevar a cabo una transformación agile tiene que entender que supondrá un cambio de cultura y de trabajar en muchos de sus departamentos, no solo en los equipos de desarrollo. Desde este enfoque es fácil ver que pagar un curso de Scrum Master a los desarrolladores difícilmente sea suficiente para llevar a cabo esta transformación agile en toda la empresa.

Otro punto que parece interesante mencionar es el que dice “(valoramos) Individuos e interacciones sobre procesos y herramientas”. Pues tengo la sensación que muchas veces se siguen los frameworks y metodologías ágiles de una forma mecánica, marcando casillas en un checklist, ignorando que deben ser herramientas al servicio de las personas y no al revés.

No quiero extenderme mucho más en este punto, pero os recomiendo que visitéis la página del manifiesto y lo leais con atención. Estoy seguro que os servirá de espejo para ver cómo estáis trabajando con agile y ver si hay cosas en vuestra forma de trabajar actual que podéis repensar de acuerdo a los principios ágiles.

Extreme Programming

Es una filosofía de desarrollo de software desarrollada por Kent Beck a finales de los 90, y que se hace pública en 1999 con su libro Extreme Programming Explained. Podríamos decir que sirve para inspirar (junto a otras metodologías existentes) el agile manifesto que desencadena el movimiento agile. El autor dice que elige el adjetivo extreme porque piensa que para desarrollar software de calidad hay que llevar las prácticas de programación al extremo o a su expresión más pura. Una de estas prácticas que prescribe es la de pair programming que según él se debería utilizar para programar todo el código de producción (lo cual a mi personalmente me parece bastante extremo).

Beck dice que XP es un intento de reconciliar la humanidad y la productividad en la práctica del desarrollo de software. Y expresa que ha comprobado que cuanto más humanamente se trata a sí mismo y a los demás, más productivos se vuelven. Aboga por aceptar que los programadores somos personas en un negocio entre personas. Huyendo de las ideas imperantes en las organizaciones, que trataban a los desarrolladores como piezas de un complejo engranaje desprovistas de humanidad.

La filosofía XP introduce una serie de valores, principios y prácticas recomendadas para el desarrollo de software. Y muchas ideas nuevas y contrapuestas a los procesos reinantes en aquella época, principalmente Waterfall, entre algunas de las más importantes están trabajar en pequeñas iteraciones o escuchar feedback del cliente frecuentemente durante el desarrollo. También recomienda que los desarrolladores programen la mayor parte del tiempo en parejas (pair programming) o comenzar el desarrollo por los tests (tests first). Además introduce conceptos como la integración continúa o los builds de 10 minutos (estamos hablando de 1999), que se han adoptado como estándares en la industria.

Ron Jeffries — The Circle of Life: XP Practices

Estas prácticas y principios, se fundamentan sobre los valores de comunicación, feedback, simplicidad, valentía (courage es la palabra en inglés) y respeto. Los dos últimos valores se centran en el individuo, por un lado se comenta que hay que tener la valentía (courage) de hacer un buen trabajo, buscar el éxito y lidiar con las consecuencias (es lo que Beck también describe como extremo o extreme). Y por otro lado los individuos de un equipo tienen que tener suficiente respeto mútuo con todos los stakeholders, y la apertura para probar nuevas formas de trabajar si es la voluntad del equipo.

Una idea importante es que las prácticas tienen que estar fundamentadas en los principios y los valores. Hay que entender el porqué seguimos una práctica, si el motivo es porque nos viene impuesto por los managers entonces se vuelven tediosas y propensas a no realizarse correctamente o evitarse. Personalmente creo que la persona que introduce las prácticas debe explicar la motivación de usar esa práctica a los nuevos integrantes del equipo, para luego hacer seguimiento de la adopción de las prácticas y poner énfasis en el valor obtenido cuando los nuevos integrantes comienzan a usarla. Es cuando usamos y vemos de primera mano el valor que nos da una práctica cuando tenemos la información necesaria para aceptarla e integrarla en nuestra forma de trabajar.

Otro punto importante, es entender realmente las prácticas y lo que nos aportan. De este modo evitamos implementar la práctica de forma incompleta o sustituirla por una que parece similar pero no lo es. Esto pasa, por ejemplo, cuando sustituimos Test Driven Development (TDD) por Unit Testing. En Test Driven Development se prescribe comenzar a escribir los tests, ejecutarlos para ver cómo fallan y luego ir escribiendo el código de la aplicación hasta que todos los tests pasen con éxito, y en ese momento detenernos (TDD prescribe que sólo deberíamos escribir el código necesario para pasar todos los tests). De este modo los tests se convierten en el mecanismo para detectar cuándo hemos completado la funcionalidad y podemos dejar de codificar, además de que nos obliga a diseñar la arquitectura del código para que sea testeable. Sin embargo, si solo escribimos Unit Tests al terminar de codificar la funcionalidad, el test ya no sirve para guiar la codificación de la funcionalidad, sino que su valor queda reducido a probar la funcionalidad. Además de que al hacerlo así, la funcionalidad ya está codificada, por lo que en nuestra cabeza hay una sensación de haber terminado aunque nos queda cumplir con el tedioso trámite de los unit tests.

Personalmente no he conocido a nadie que trabaje con Extreme Programming en su expresión más extensa, y tampoco tengo la impresión que hoy en día muchas empresas lo hagan (he realizado una búsqueda rápida en LinkedIn y solo aparecen 30 ofertas de trabajo en España que contienen la palabra Extreme Programming contra más de 6000 que contienen la palabra Scrum). Aún así creo que Extreme Programming es una fuente muy interesante de prácticas y principios que se pueden aplicar en cualquiera de las otras metodologías ágiles, de hecho muchas ya se utilizan cuando trabajamos en Scrum, por ejemplo. Además a diferencia de otras herramientas que funcionan más como recetas que hay que seguir, en el caso de XP se ahonda en los motivos y los porqués, lo cual nos dota de más recursos para tomar decisiones robustas que afecten a la forma en que trabajamos.

Scrum

Es uno de los framework ágiles más populares en la industria del desarrollo de software, aunque ya no es específico para software sino que se usa en diferentes industrias. Aparece en 1995 y se define como una forma de realizar trabajo en equipo, más concretamente en equipos pequeños multidisciplinares y autogestionados (self-managed), donde se trabaja en pequeñas tareas con ciclos de desarrollo cortos (llamados Sprints), al final de los cuales se obtiene un incremento de funcionalidad potencialmente entregable.

Es un proceso empírico que se fundamenta en 3 pilares: la transparencia, la inspección y la adaptación que se manifiestan de la siguiente forma: el proceso y el estado del trabajo en curso es visible para el equipo y el resto de stakeholders (principio de transparencia), esto permite inspeccionar el progreso con respecto a los objetivos marcados (principio de inspección) y adaptar/ajustar el rumbo en el caso de que se produzcan desviaciones (principio de adaptación). Esta adaptación es un resultado de la mejora contínua que deben llevar a cabo los equipos.

Scrum.org: Valores Scrum

Aunque comparte muchas de las prácticas de gestión de proyecto con XP, no prescribe ninguna práctica ni principio técnico, y por supuesto no presenta una filosofía específica de cómo ser desarrollador. Esta falta de prescripción de principios y prácticas técnicas es lo que ha causado y sigue causando muchas de las implementaciones defectuosas, en las que la deuda técnica del proyecto va creciendo y causando la merma de la productividad del equipo, como ya comentaba Martin Fowler allá por 2009, en su artículo Flaccid Agile.

El framework prescribe una serie de roles: Scrum Master, Product Owner y Developers. El Product Owner es el responsable de la visión y objetivo del producto. Además es quien define las historias de usuario y las prioriza en el backlog. El Scrum Master es el garante del proceso, el que entrena al equipo, elimina impedimentos y el que facilita, entre otras cosas. Y luego los Developers son los que planifican y ejecutan el trabajo garantizando su calidad y conformidad a los objetivos del Sprint. Uno de los problemas que me he encontrado habitualmente es que las personas que cubren los roles de Product Owner y Scrum Master tienen otras responsabilidades ajenas al Scrum, lo cual provoca que muchas veces se conviertan en cuellos de botella que impactan la productividad del equipo. Un caso típico es un Product Owner que por falta de tiempo no define los criterios de aceptación en las historias de usuario, causando que los desarrolladores tenga que revisitar historias de usuario ya cerradas para completarlas, con la consecuente frustración de los clientes y los propios desarrolladores.

Otro problema habitual es la falta de un definition of done o su no cumplimiento. El definition of done son unos criterios generales que tiene que cumplir una tarea para poder cerrarse. Por ejemplo: tener hecha una code review por 2 personas, haber añadido/modificado nuevos unit tests y haber mergeado las ramas de código en la rama de integración. Por mi experiencia personal, el definition of done es algo que tiene que venir de los desarrolladores. Es importante que al menos un desarrollador en el equipo (idealmente más) entienda la necesidad y el valor que aporta. Si el definition of done viene definido por el manager, pero dentro del equipo no hay convencimiento de su valor, lo más probable es que a la primera de cambio se ignore y caiga en desuso.

Entre las ceremonias que prescribe el framework una de las más largas es el Sprint Planning que tiene como objetivo que el equipo revise las historias de usuario priorizadas por el product owner, las estime y las asigne hasta completar su capacidad para ese Sprint. Sin duda la tarea más larga es la estimación de las historias de usuario, en las que todo el equipo habla acerca de cómo descomponer la historia en subtareas y se discuten aspectos técnicos y de implementación para luego estimar en story points. En ocasiones he visto como una sola historia de usuario ha tardado una hora en estimarse. En un equipo de 8 personas, esto son 8 horas solo para estimar una historia. Es cierto que el ejercicio de estimar minuciosamente en equipo, permite comenzar a diseñar cómo se va a implementar la historia y tener el input de varias personas lo cual proporciona nuevos puntos de vista y permite anticipar cuestiones y potenciales problemas, pero desde mi punto de vista sale demasiado caro. Por no hablar de que muchas veces,solo intervienen 2 o 3 personas, mientras que el resto permanecen callados y muchas veces se desconectan, lo cual suele desmotivar.

En mi opinión, Scrum puede ser un framework interesante a considerar en equipos que comienzan a desarrollar un nuevo proyecto/producto, y que no tienen ya una forma eficiente de trabajar. Pero desde el principio hay que definir unas prácticas técnicas que todo el equipo entienda y siga, siendo muy conscientes de que la deuda técnica estará siempre al acecho. También pondría especial énfasis en visualizar el flujo de trabajo, utilizando un tablero Kanban (si puede ser físico mejor y sino Jira ya incorpora un tablero en los proyectos de Scrum también), para saber minuto a minuto cómo va el trabajo y detectar los bloqueos tan pronto se produzcan. Y si la productividad no es la esperada o merma con el tiempo, consideraría introducir más elementos de Kanban y Scrumban.

Kanban

Es un método lean para la mejora del proceso de trabajo que está basado en el Toyota Production System. Muchas veces es malinterpretado y es entendido como un método para la organización del trabajo dejando fuera justamente su esencia, que es la parte de mejora de procesos.

Se basa en las ideas de Lean Manufacturing que abogan por producir just-in-time y reducir el waste (desperdicio). Se considera desperdicio la sobreproducción y los defectos. Para evitar la sobreproducción se limita el work-in-progress en las diferentes etapas del proceso ajustándose estos para asegurar que la etapa más costosa está siempre funcionando al máximo de su capacidad, de este modo se consigue la máxima productividad (está basado en la Teoría de las restricciones). Para asegurar la calidad, se incluyen procesos de validación y control de calidad en el propio proceso productivo. En el caso de Toyota se permitió que cualquier operario en la cadena de producción pudiese detener la producción si detectaba algún problema, lo cual supuso un cambio radical en cómo venían operándose las fábricas y un empoderamiento de los trabajadores.

A diferencia de Scrum, que es altamente prescriptivo, Kanban es bastante minimalista y sólo prescribe unas pocas prácticas, dejando flexibilidad para que cada equipo encuentre su forma óptima de trabajar en su contexto. Entre sus prácticas principales están: la utilización de un tablero para visualizar el trabajo, con columnas para representar las etapas por los que pasa una tarea y con límites explícitos de work-in-progress (WIP) para cada paso. Se recomienda que el muro sea físico, hoy en día esto es difícil.. pero si el equipo está físicamente en el mismo espacio, creo que es interesante porque se crea un espacio de reunión y socialización, donde ver el flujo de trabajo y hablar sobre él, lo cual con un muro virtual no es igual. Aunque si no hay más remedio, se puede hacer así también.

Son comunes implementaciones incompletas de Kanban, como por ejemplo utilizar un tablero para organizar el trabajo, pero sin definir límites de WIP o no definir explícitamente las políticas de validación para las diferentes etapas. Algunas de las herramientas disponibles en el mercado, como Jira, no ayudan, puesto que por defecto no se establecen límites de WIP al crear un nuevo proyecto Kanban (hay que hacerlo por configuración). Esto impide obtener el verdadero valor de la herramienta para detectar los cuellos de botella y mejorar el proceso.

A continuación os comparto un ejemplo de tablero para una empresa de fotografía a la que he ayudado a implementar Kanban. Las tarjetas superiores son las políticas de proceso, que son explícitas, lo cual permite que todo el equipo siga el proceso sin tener que tirar de memoria. Además permite que los nuevos sepan cómo es proceso y todo esté en el muro.

Ejemplo de Tablero Kanban. Utilizado en empresa de fotografía

La idea principal de Kanban es visualizar el trabajo y limitar el work-in-progress con el objetivo de detectar problemas y bloqueos tan pronto como se produzcan, analizar las causas de raíz y ponerles solución. Y repetir, para mejorar el proceso iterativamente.

A diferencia de Scrum que es un push system donde las tareas se “empujan” en el Sprint Backlog y son asignadas a un miembro del equipo durante el Spring planning, Kanban es un pull system en el que las tareas están en el backlog sin asignarse y el equipo las va cogiendo según tienen capacidad y siempre respetando los límites de WIP. Esto además permite liberar al manager de tener que asignar la tareas a cada persona. En el caso de la empresa de fotografía que comentaba antes, el manager me comentó que ya no tiene que ir puesto por puesto repartiendo tareas, sino que son los miembros del equipo los que van al muro y cogen tareas cuando están disponibles. Es la idea de Kanban: “Gestionar el flujo de trabajo, no a los trabajadores”.

La concepción de que es un método solo para equipos de operaciones y mantenimiento, no se corresponde con la realidad. Por ejemplo en Microsoft tienen múltiples equipos de desarrollo de productos como Xbox y Windows trabajando con Kanban. Muchos de estos equipos hacen la transición desde Scrum porque ven como el exceso de ceremonias del framework les produce una merma de la productividad (como cuenta Eric Brechner en su libro, ver en referencias).

Scrumban

Es el más nuevo de todos y quizás el menos conocido. Es un hibrido entre Scrum y Kanban, que combina el foco en la gestión de proyectos y product delivery de Scrum con el pull system, visualización de flujo de trabajo y mejora de procesos de Kanban.

Las ceremonias y prácticas son principalmente las de Scrum, pero utilizando el tablero de Kanban donde se definen las etapas del flujo de trabajo, los límites de WIP y las políticas para validar y transicionar tareas entre etapas.

Otro de los cambios importantes con respecto a Scrum, es en la forma de hacer los plannings: en Scrum se estiman las historias de usuario individualmente (normalmente en story points), se calcula la capacidad del equipo para el Sprint y se asignan estas a los miembros del equipo hasta completar la capacidad. En Scrumban sin embargo, no es necesario estimar todas las tareas, solo hacer un cálculo aproximado de la media de tamaño de las tareas y usar el número de tareas completadas en los Sprints anteriores para rellenar el backlog. Es una diferencia sustancial ya que la estimación de historias de usuario es una tarea bastante costosa y tediosa en los equipos de Scrum (los que las habéis vivido sabréis de que os estoy hablando). Otra diferencia es que en Scrumban los plannings se hacen bajo demanda cuando se va vaciando el backlog, a diferencia de Scrum en el que estos son fijos en el tiempo, y muchas veces se realizan cuando todavía quedan muchas tareas abiertas del Sprint anterior.

La única experiencia que tengo trabajando con Scrumban fue corta y fue en un equipo que la adoptó para flexibilizar los Sprints, y celebrar las ceremonias de Scrum bajo demanda, con el objetivo de evitar hacer plannings teniendo mucho trabajo en progreso. El problema es que no adoptamos el muro Kanban ni en consecuencia la fijación de los límites de WIP, por lo que no vimos una mejora significativa de la productividad. Esto se debió a que hicimos la transición a Scrumban en un momento que estábamos desbordados de trabajo y queríamos quitar barreras de Scrum, pero nos faltó parar un poco para entender Scrumban e implementarlo correctamente.

Según el introductor de Scrumban (Corey Ladas), este es un framework de transición y que los equipos que lo adopten correctamente verán con el tiempo como muchas de las ideas de Scrum ya no les son útiles y podrán trascender el framework quedándose con el pull system de Kanban.

Personalmente, ahora que entiendo el concepto, y que he visto Kanban funcionando, si tuviera que elegir un framework para un equipo de desarrollo nuevo, que tiene que comenzar un proyecto, probablemente me decantaría por Scrumban, creo que junta lo mejor de los dos mundos: Scrum y Kanban. Además de flexibilizar alguno de los aspectos más tediosos de Scrum como son las estimaciones y los plannings. Y dar libertad al equipo para ir encontrando su propio proceso.

Conclusiones TL;DR

En este post he tratado de hacer un repaso de algunas de las ideas del movimiento agile y de sus manifestaciones en framework y metodologías. Por supuesto que no cubre todas las ideas ni conceptos, pero he intentado que pueda servir como punto de partida para revisitar las herramientas disponibles con el fin de analizar y refinar cómo las utilizamos en las empresas y equipos que trabajamos.

Estos son algunos de los puntos que considero más importantes:

Adoptar una metodología ágil requiere no solo un cambio de hábitos, sino también un cambio de cultura y de mentalidad a nivel de equipo pero también a nivel de organización. Releer los principios del agile manifesto siempre puede ser un buen punto de partida.
Es muy común encontrar implementaciones de las metodologías ágiles incompletas que reducen su efectividad, principalmente porque no se conocen completamente, y muchas veces se eliminan o malinterpretan prácticas y principios fundamentales. Cambiar la metodología de trabajo en medio de un proyecto puede ser delicado puesto que todo cambio de proceso grande, requiere de un margen de adaptación y un período de gracia en el que la productividad puede mermar temporalmente. Si lo hacemos en un proceso que ya acumula retrasos es fácil caer en la trampa de implementar solo la parte de la metodología que no impacte a la productividad inmediata.
Las formaciones y certificaciones de herramientas ágiles, pueden ayudar para familiarizarse con los frameworks y metodologías. Pero interiorizar una filosofía de trabajo nueva y cambiar la mentalidad, es un proceso más lento y que requiere de práctica, reflexión y re-estudio.
Extreme Programming va más allá de ser una metodología y se define mejor como una filosofía para programadores, que les guía en cómo ser buenos profesionales, organizarse en equipos sanos y entregar valor al cliente de forma contínua. Aunque parece que no se usa mucho actualmente, sigue siendo una excelente fuente para complementar al resto de frameworks.
Mientras que XP prescribe múltiples prácticas técnicas, Scrum, Kanban y Scrumban no lo hacen. Pero si hay algo clave, independientemente de la herramienta que seleccionemos, es que tenemos que tener bien definidos unos valores, principios y prácticas técnicas porque es la única forma de desarrollar software de calidad.
Kanban no es una forma de organizar el trabajo, es una manera de visualizar y mejorar cómo trabajamos. Lo cual requiere de una evaluación y adaptación continúa de cómo trabajamos. El outcome de Kanban es un proceso de trabajar refinado y adaptado a nuestro equipo.
A veces las herramientas y plataformas disponibles pueden llevarnos a implementaciones erróneas o incompletas. Por ejemplo, en Jira los limites de WIP (work-in-progress) no se fijan durante la creación de un proyecto Kanban, sino que se tienen que fijar a posteriori por configuración. Por ello es importante conocer las metodologías antes de implementarlas.
El muro Kanban es el lugar donde se visualiza el flujo de trabajo y donde los trabajadores van a buscar las tareas. El manager ya no tiene que asignar las tareas el mismo. Se gestiona el flujo de trabajo, no a los trabajadores.
Scrumban une la forma de trabajar en iteraciones que aporta Scrum con la mejora de procesos de Kanban. Y flexibiliza la duración de las iteraciones y la forma de estimar historias de usuario, entre otras cosas. Además de dar más libertad que Scrum para que el equipo vaya definiendo su propia forma de trabajar.

Como nota final decir que las metodologías y herramientas ágiles, como cualquier otra herramienta creada por el hombre, no son perfectas y tienen sus limitaciones que experimentamos cuando las aplicamos en el mundo real. Es en estas situaciones cuando el sentido común y volver a los valores y principios ágiles nos pueden permitir seguir avanzando. Y nunca debemos olvidar que son herramientas que deben estar al servicio de las personas y no al revés. Ya lo decía el agile manifesto, valoramos “Individuos e interacciones sobre procesos y herramientas”.

Referencias

Agile Manifesto

Scrum Guide

Scrum.org

The Essence of Agile Software Development — Martin Fowler Web

Libro Clean Agile — Rob. C. Martin

Libro Extreme Programming Explained. Second Edition — Kent Beck & Cynthia Andres

Artículo Agile Alliance sobre Scrumban — Corey Ladas

Libro Scrumban — Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean) — Corey Ladas

Libro What is Scrumban? — Andrew Stellman

Libro gratuito Kanban and Scrum — Making the most of both — Henrik Kniberg & Mattias Skarin

Libro Agile Project Management with Kanban — Eric Brechner

Video Agile Project Management with Kanban — Eric Brechner at Google