¿Por qué Scrum?

Desde que estoy inmerso en el mundo Agile, en especial en Scrum, siempre he escuchado frases del tipo “Esos post-it son una chorrada”, “tanta reunión es una perdedera de tiempo”, “¿Eso sirve para algo?”, “Yo hago mi trabajo y listo”.

Haciendo un poquito de historia…

Cuando estaba con  el proyecto de grado de fin de carrera, era necesario entregar un amplio documento técnico hecho al detalle, con infinidad de diagramas UML, dichos diagramas se hacían antes de poner la primera línea de código, como era lógico pregunte a mi profesor de la  U ¿Qué pasa si el código no es como se muestra en el diseño? Su respuesta fue –Cambias el diseño.

Con la poca experiencia que tenía en ese momento, pensé que eso de cambiar el diseño seria el pan de cada día en el desarrollo de software.

Con el tiempo he comprobado que no estaba equivocado, en el software es muy complicado conocer al 100% lo que se quiere como para crear un diseño perfecto.

He visto quejarse al usuario al momento de la entrega de un producto, porque resulta, que eso que le entregaron y por lo cual pagó, no funciona como él suponía que lo haría.

Much@s dirán, pero es que eso es una mala planificación, un mal análisis, una mala toma de requerimientos, etc. Bueno,  seguramente si tengan razón,  pero resulta que el software no es una ciencia exacta (también me lo discutirán).

Creo que el error en el desarrollo de software, es que siempre se ha pretendido predecir con dotes de mago, todo el trabajo que se tiene que hacer para entregar un producto software (sobre todo en lugares malos de la matriz de Stacey).

Pretendemos que construir software es como construir una casa, que se ciñe a unos planos cerrados que describen lo que se tiene que construir.  Pues el software no son ladrillos con cemento, son líneas de código y PERSONAS.

¿Qué tiene Agile, funciona Scrum?

Son varios los puntos que hacen que Agile y en especial Scrum sea un marco óptimo de trabajo para el desarrollo de software. Los puntos más importantes basados en mi experiencia son:

Al tener entregas (demos, preview, etc.) frecuentes de software, tenemos un feedback del cliente, que hace que el cliente defina mejor lo que desea y el equipo hacer lo que en realidad necesita y quiere el cliente. El trabajo que no produce valor real es absurdo.

El producto no es posible si todo el equipo no trabaja en ese sentido, cada persona en el equipo es importante.

Todo el mundo lo sabe todo.

En Scrum existen reuniones como el sprint planning, daily meeting, retrospective, etc. Que tienen dos objetivos principales; crear un ambiente de transparencia, que hace que el conocimiento fluya en el equipo y no se de el caso “…..es que eso sólo lo sabe XXX…” debido a la comunicación que existe. Además, tener un plan realista que se ajusta a los cambios y necesidades reales del cliente, del equipo o el entorno.

No adivine. Planifique, haga, compruebe, actúe. Jeff Sutherland

Uno de los mitos de Scrum, es que no se documenta, lo cual es falso. Sí se documenta, pero se documenta con valor, es decir, no se tienen cientos de folios que no dicen nada. Se considera prioritario el software que funcione.

Debido a la sinergia del equipo, no es posible tener el equipo alguien que no se implique en el trabajo, no aportaría valor por cual sería fácil de identificar.

Las personas son el mayor valor a la hora de desarrollar software, y para eso es fundamental la felicidad, cuando se es feliz se trabaja mejor, se toman mejores decisiones y se rinde más.

En Scrum, la felicidad se mide con el fin de tomar medidas que permitan mantener índice de felicidad alto.

Scrum no es perfecto, pero cuando falla, falla antes, lo cual permite enderezar el camino o desistir.