En todos los trabajos en los que he estado, desde que las metodologías ágiles – agile en inglés. No me gusta cómo han traducido el término pero es lo que hay – y más concretamente SCRUM, llegaron a España, ha habido algún iluminado que ha afirmado categóricamente que no sirven para nada, y que de hecho ralentizan los proyectos.
Y la cosa es que, si no conoces nada de SCRUM, y viendo cómo se ejecuta en la mayoría de los sitios en los que tienen la desfachatez de presumir de que lo usan, es hasta normal que pienses que no sirve para nada.
El principal problema con estas metodologías para proyectos software en España es que se parte del “todo mal”: toda la planificación y trato con el cliente está en manos de un jefe de proyecto o un comercial, y el equipo de programadoras se limita a seguir órdenes y picar el código que les dicen que tiene que estar para tal fecha. Nada de lo que diga el programador se tiene en cuenta porque las estimaciones se han hecho incluso antes de poder dimensionar el proyecto, cuando se ha pactado lo que quiera que se haya pactado con el cliente. Un cliente que es un ente abstracto que no tiene ni idea de lo que quiere pero sabe que lo quiere ya, y que lo quiere lo más barato posible. Como normalmente los proyectos se dimensionan mal, no se documentan “porque es una pérdida de tiempo”. Los funcionales y cualquier otra documentación, cuando la hay, se hace después de terminar el código y las pruebas, y no antes.
Con esta organización, no es que aplicar SCRUM no funcione, es que es milagroso que se llegue a entregar algo que satisfaga al cliente.
SCRUM no es abrir un proyecto en redmine, hacer veinte etiquetas para “tareas” y aumentar el número de reuniones a un nivel que hace imposible trabajar. Las metodologías ágiles requieren un cambio organizativo profundo que casi ninguna empresa – sobre todo consultoras – está en situación de – o quiere – llevar a cabo, y por eso en la mayoría de los casos SCRUM no sirve para nada: porque no se puede implantar.
El problema de raíz que veo yo es que cualquier metodología agile parte de la base de que se tienen todos los recursos necesarios para realizar una tarea, y lo que hay que hacer es gestionar el proceso de realización. Esto empieza no siendo cierto en un proyecto cerrado de software típico, en gran medida por lo que he comentado antes de que las estimaciones se hacen mucho antes de estar en situación de poder estimar nada, porque lo que prima es vender, no hacer algo bien hecho.
Otra gran ruptura con un proyecto de software tradicional es que no hay una fecha de entrega: se planifican las tareas que se van a realizar en cada iteración, y al final de cada una se entrega y se planifica para la siguiente. Como toda persona que haya programado sabe, estimar el 100% de un proyecto incluso antes de ponerse a analizar lo que hay que hacer es una estupidez, entra dentro del terreno de la adivinación, y en cualquier caso los plazos estimados de esa manera nunca se cumplen… o lo hacen a costa de que las programadoras echen más horas que un reloj y pongan en peligro su salud física y mental.
Ese cambio tampoco gusta a los clientes en general: “el cliente” no quiere una funcionalidad nueva cada dos o tres semanas sin saber cuándo estará el producto completo; quiere una garantía de que todo va a estar perfecto para tal fecha, y por la menor cantidad de dinero posible. Pero ni sabe ni le interesa saber lo que es ese “todo” que quiere.
Ese desconocimiento del producto que se está pidiendo, que es algo muy común en el desarrollo del software – ese “tú ve haciendo algo y yo ya cuando lo vea te digo si es o no es lo que quiero” de moda – es otro problema, y muy grave, a la hora de intentar implantar SCRUM. Esta metodología – no sé si todas, pero esta sé que sí – implica que el cliente sepa lo que está pidiendo, y se implique en el proceso de desarrollo. No tiene que saber programar, pero es necesario que tenga un conocimiento total de las funcionalidades que hay que implementar, y sepa trasladarlo al equipo de desarrollo. Nada se empezará a programar hasta que no esté completamente definido, y por lo tanto se haya podido estimar el tiempo que va a llevar de una forma realista.
Lo que lleva al cuarto gran problema para implantar SCRUM: ese “funcionalidades completamente definidas”. La documentación precede a la implementación. El trabajo de definir y generar tareas como “funcionalidades completas” del producto final, que puedan realizarse y entregarse por iteraciones, tiene que ser previo a ponerse a programar.
Este definir y estimar es realizado por todo el equipo de desarrollo, ya que la organización no es jerárquica sino horizontal, y la famosa figura de Scrum Master no es un jefe de proyecto sino el encargado de que los programadores puedan trabajar sin bloqueos. El cliente y el equipo se reúnen con frecuencia para definir y estimar las tareas, tener en cuenta posibles cambios en las prioridades, y en general estar todos al tanto de lo que está sucediendo. Los programadores no solo son programadores, son también gestores, y todos deben de tener el mismo nivel de conocimiento, sin especialistas en una cosa u otra. El cliente no es solo quien pide y paga, se le pide que sepa qué está pidiendo.
Todas estas cosas que SCRUM requiere hacen que el proceso de desarrollo de un proyecto software esté mejor documentado, haya trazabilidad de cada línea de código a la tarea que la generó, se pueda “reaccionar” de forma rápida a posibles cambios en la definición del producto, y se cumplan los plazos… porque los plazos se estiman a dos o tres semanas vista. También hace que el producto terminado tenga bastante mejor calidad que si se hubiera asumido su ejecución a lo bestia como un proyecto cerrado, y seguramente lleve menos tiempo.
Pero la sensación que da es de “pérdida de tiempo” porque exige cambios a la hora de abordar un proyecto que, sobre todo a los de arriba y al cliente, no les apetece realizar.
Que para poder hacer las cosas bien no vale con parchear lo que se hace mal y cambiarle el nombre, vaya. Para poder hacer las cosas bien, hay que hacerlas bien.
************************************************************
Espero que esta entrada pueda ser de utilidad, y si no, como siempre, aquí tenéis un gato para compensar.
