Agile

Imagen de http://www.harringtonstarr.com/agile-methodology-best-option-software-delivery/

Todo el mundo habla de Agile, scrum, Kanban, XP o de ser más agile. Pero, ¿qué es agile?

Agile comenzó cuando 17 personas se juntaron en Utah en el 2001 y crearon el manifiesto agile.

Personalmente, agile es una filosofía y una forma de ver las cosas. Solo hay que comprobar que el manifiesto contiene también 12 principios. Esos principios me gustan más que el manifiesto.
Por ejemplo, el primer principio que es muy bueno y dice: “nuestra prioridad número uno es satisfacer al cliente con frecuentes entregas de software que aporta valor”.

Además agile es una forma de solucionar varios problemas que tenemos en el desarrollo de software. Los principales problemas que intenta solucionar son los siguientes:

Los requisitos cambian

Porque el cliente no tiene claro lo que quiere, porque no hemos entendido lo que quiere, porque ha surgido una nueva funcionalidad que puede ayudar al cliente más que los requisitos actuales, porque ha surgido una nueva funcionalidad que es necesarias para poder dar valor a las demás. Seguramente que puedas sacar más porqués por tu cuenta, pero lo que está claro es que cambian.

El coste se va de las manos

Y el coste se va porque no somos buenos estimando proyectos, porque nos confundimos en el desarrollo, diseño o toma de requisitos, porque añadimos mayor complejidad a nuestros diseños o código lo que hace que vayamos avanzando más lentamente, porque nos encontramos problemas que no conocíamos o que conocíamos pero que no hicimos nada al espectro o que aún conociéndolos y haciendo algo al respecto nos hizo perder mucho más tiempo de lo esperado, porque dejo la empresa gente que trabajaba en el proyecto, porque gente del proyecto es movida a otro proyecto con mayor importancia para la empresa.

El valor obtenido es muy pequeño

Este problema es una combinación de otros problemas. Como por ejemplo, de los dos primeros ya que si los requisitos cambian pero no hacemos nada al respecto el cliente obtendrá menos valor y además si el coste aumenta mucho quizás el valor que le hemos dado no compense.

En resumen, agile es una filosofía que ayuda a resolver los principales problemas que tenemos en el desarrollo de software.

Método iterativo e incremental

Imagen de Henrik Kniberg

Tu empresa ha externalizado la creación de una aplicación a una empresa en India y a los cuatro meses de la fecha límite entregan una primera versión.
En esa primera versión te das cuenta que tiene bastantes problemas. Como por ejemplo:

  • Los requisitos mínimos no han sido cumplidos.
  • La interfaz de usuario tenía que ser igual a otra aplicación, ya que los usuarios están acostumbrados a esta primera, y no se parece nada.
  • La aplicación no funciona con el número mínimo de usuarios concurrentes que va a tener.
  • Las funcionalidades desarrolladas hacen lo que tiene que hacer, a veces.
  • El código no tiene un mínimo de calidad

Como puedes imaginar, no vas a poder arreglar todos los problemas en solo cuatro meses y los costes en cuanto a tiempo y dinero aumentan con cada mes que no ha entregado el producto, y serán muchos meses.
Además, la gente de negocio tiene que hablar con los clientes sobre estos cambios, ya que no van a estar terminados en la fecha prometida. Lo que bajará la confianza de los clientes en la empresa.
Lo mismo pasa con la gente de marketing y la campaña que tenían pensada hacer para captar nuevos clientes, que tendrán que ser pospuestas. Con el coste adicional que supondrá este cambio.

La forma de desarrollar este producto es en cascada (waterfall) ya que todos los requisitos han sido dados al principios del desarrollo y el producto se entrega cerca de la fecha de entrega.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles

La forma de desarrollar un producto en cascada es la más eficiente porque si los requisitos han quedado claros y no hay problemas durante el desarrollo del producto se han gastado cada céntimo en las cosas necesarias para obtener el producto.
El problema es que en los 10 años que llevo desarrollando software siempre hay “problemas”. Puede ser que sea casualidad o que los problemas no son tal, si no un es algo habitual en el desarrollo de software. Personalmente me decanto por el segundo motivo.

Hay varias alternativas a este tipo de desarrollos en cascada pero voy a hablar del que conozco. Del desarrollo iterativo e incremental.

El desarrollo iterativo e incremental consiste en ir entregando versiones de tu producto que vayan entregando cada vez más valor con cada versión del producto.

Imagen de https://www.adictosaltrabajo.com/tutoriales/metodos-agiles

La ventaja de esta forma de desarrollar un producto es que si hay algo mal, como la lista que he comentado al principio, tenemos tiempo suficiente para poder solucionarlo. O lo que es lo mismo, estamos reduciendo el riesgo que es el entregar un producto al final del desarrollo sin saber si está bien.

Claro que esta forma de desarrollo tiene sus inconvenientes. El más importante es el tiempo que hay que dedicarle a verificar que vamos por el buen camino. El tiempo que dedicamos a hablar con el cliente o con la gente de negocio para comprobar que lo que estamos desarrollando encaja con lo que tenían pensado.
Otro inconveniente importante es que la forma de desarrollar cambia de forma drástica. En cada nueva versión de nuestro producto tenemos que comprobar que las nuevas funcionalidades funcionan de la forma correcta y que las funcionalidades desarrolladas en las versiones anteriores siguen funcionan. Así, con cada nueva versión que se acerca más al producto tenemos que probar muchas cosas: las funcionalidades nuevas y las antiguas.
Como puedes imaginarte llega un momento que este proceso de comprobar que todo lo desarrollo funciona de forma correcta no se puede realizar de forma manual. De forma manual quiero decir de una persona que compruebe un todo funciona.
Por lo que necesitamos algún tipo de proceso automático que nos permita comprobar que lo que hemos desarrollo funciona. Aquí es donde entra en juego los test unitarios, los test de integración y los test de aceptación.
Los test unitarios y de integración comprueban que la aplicación funciona como debe funcionar y los test de aceptación comprueba que la aplicación funciona como el usuario final quiere.

Los cambios de un proceso en cascada a un proceso iterativo e incremental son grandes. Tanto a nivel de negocio como a nivel de desarrollo. La gente de negocio tiene que ayudar a comprobar que lo que que el usuario quiere es lo que se está desarrollando (test de aceptación) y la gente de desarrollo tiene que crear test de integración y unitarios para comprobar que lo que se está creando funciona de forma correcta.
Estos cambios son grandes pero van a permitir a vuestra empresa a reducir los riesgos. Lo que va a permitir a vuestra empresa crecer reduciendo los riesgos en este crecimiento.

Personalmente las ventajas ganan a los inconvenientes en un proceso iterativo e incremental. ¿Tú qué opinas?

My first project with Scrum

Image from http://www.3news.co.nz
Image from http://www.3news.co.nz

Introduction

I’ve been working on a new project for the last few months. I worked with two external developers on this project. One of them has experience as Scrum master so the team decided to use Scrum as the methodology in the project.
I’d read a lot about Scrum and I’d applied some practices in the past but I’d never used Scrum by the book.

In this blog I’ve written a summary about my experience using Scrum in a project that was built from scratch.

I’m not going to talk about the practices of Scrum, so if you want to know more, a good place is:

http://www.scrumguides.org/

you can find there the official guide of Scrum in many languages.

Pros

  • Retrospectives really work. Every retro helped us to discover the problems in the sprint and to solve them. For example, part of the team didn’t work at the office and that caused communication problems. The communication improved thanks to the retros and the actions that we took in each one.
  • Team building. We spoke a lot, and because of all the meetings we knew each other and came together as a team. I was new in the company and I didn’t know my colleagues nor the external developers. I believe we made a good team in few months due to the scrum practices.
  • The product’s design is understood for each member of the team. In this case, sprint meetings allowed us to understand the whole design of the application. That could also improved the design because many decisions were taken together.

 

Cons

  • Scrum can be used as a tool for micromanaging the team. That could happen when dailies and retros are done in the wrong way. Dailies would just be about the status of each story and retros would just be about checking estimations in detail. It didn’t happen but I realized how a person could transform scrum into something ineffective.
  • Feedback in the last part of the project. We did an acceptance test after the development had finished where most of the company participated and we received a lot of feedback. I see this like a negative thing because we couldn’t transform the feedback into new features. Our sprints were two weeks long and the last day of each sprint we did a demo where all the people involved in the product attended, including the people who gave us feedback in the acceptance test.

I’d like to add that we could apply the use of Scrum better because, for example, we had to write documents and other tasks after the development had finished and they should have been included in the project.
Furthermore, our main problem was that we didn’t have a product owner and a colleague had to play that role. I believe the highest benefit of Scrum and other Agile methodologies is that the value is maximize and due to the fact that we didn’t have a proper product owner that benefits were decreased.

The next blog explains the meaning of value very well:

http://ronjeffries.com/xprog/articles/value-is-what-you-like/

The same writer has just released a book with the title “the nature of software development” and is amazing. It has a little more than 100 pages that explains in the most clear way possible what software development is about. I’ve read it recently and it´s a really nice book.

Recap

I’m happy with the end result of the project although we could do it better . I love how Scrum practices allow us to improve the team performance and the development process.

Scrum doesn’t have development practices and I miss them because developing an incremental and iterative product without them is very hard. For example, TDD and continuous integration.
So, in regards to development practices XP is better than Scrum because it includes many practices for us, programmers.

* 22-06-2015 Solved grammar error