Malas noticias, hacer Scrum no es sinónimo de trabajar sin burocracia….

 

Malas noticias,  hacer Scrum no es sinónimo de trabajar sin burocracia….   Al contrario de lo que se puede pensar cuando se conoce muy poco de Scrum. Scrum es un método de desarrollo de sistemas, que no reduce la carga burocrática del tradicional método de desarrollo en cascada.

En realidad, el Scrum es sólo un método para trabajar las necesidades del Cliente/Usuario de manera tal que su ansiedad disminuya… o en palabras de los Scrum Masters… “Que obtenga los mayores beneficios en el menor tiempo posible”,  sin soslayar los beneficios de poder obtener rápida retro alimentación y con esto encausar de mejor manera el resto del desarrollo.  Pero no por ello, se dejan de levantar requerimientos, ni tampoco tienen porque ser meno detallados. El usuario, de cualquier manera los debe firmar (hacerse responsable de lo que pide); de cualquier manera existe una gestión de backlog que es incluso más extensiva y burocrática que la Gestión de cambios de un proyecto tradicional en cascada.

Escuché a un alto ejecutivo argumentar: “A mí me gusta más ese método de desarrollo ágil, porque cuando usan ese método, puedo pedir lo que quiera, en el momento que quiera y no me van a salir con eso de que “Esta fuera de alcance”  “.

Creo que hay un error en esta concepción,  ya que todo lo que pida el usuario, fuera del tiempo calendarizado para recabar los requerimientos específicos de una  función, estará siempre fuera de alcance, independientemente del método que se emplee de desarrollo. Lo mejor que puede hacerse, es colocar el requerimiento en el siguiente sprint…   Todo lo que se pida costará, nada es gratis, y en la medida que se pida y descubran las cosas de la manera más ordenada posible, en esa medida el producto final gozará de mayor calidad y menor costo.

Es una cuestión de equilibrio entre que tanto permitir un descubrimiento evolutivo y que tanto congelar un requerimiento y una arquitectura para hacerlo más sustentable.  En la medida que se tenga la totalidad del requerimiento  desde el inicio, en esa medida se podrá asegurar una mejor arquitectura resistente al paso del tiempo y de los cambios…  pero al congelar todo el requerimiento en un solo paso (un sprint),  no gozaremos de la retro alimentación práctica del funcionamiento del sistema en la vida real (en producción).

En realidad no hay ningún proyecto que pueda definirse  en un solo paso, pues todo sistema o producto derivado de un proyecto, entrará en una etapa operativa, donde se recibirán cambios, mantenimientos y evolución.  Es decir, tendrá “raleases”.

Pero por otro lado, permitir una libertad total en la toma de requerimientos, es decir, permitir vacilaciones, requerimientos contradictorios, especificaciones insuficientes, puede llevar al producto a una inestabilidad tan seria, que lo vuelva insostenible, in-mantenible y muchas veces inoperable. Algo así como una favela que aunque funciona, su funcionamiento no es sostenible y la calidad de vida ínfima.  No todo tiene que ser un Champs elysee..  El punto es planear y acordar de antemano con el Cliente/usuario cual será la morfología (Favela o Champs elysee, o que tanto de uno y que tanto del otro) del producto deseado considerando su tiempo total de vida; Desde su concepción, incluyendo operación, su retiro y sustitución. Este acuerdo tiene implicaciones de tiempos, costos y entrega de beneficios; es parte del “Business case”.

Hay quienes prefieren un método ágil, como medida para mitigar el riesgo de que se construya algo muy alejado de lo especificado por el usuario, pero esta aproximación es sólo una manera de formalizar un método sucio de trabajo, de prueba y error. No hay cura contra una especificación deficiente, ya sea porque el usuario no ha sabido especificar o el analista.  En otras ocasiones, es el usuario el que no sabe lo que quiere y prefiere no tener que comprometerse con especificaciones de gran alcance y se conforma con ir pidiendo según la necesidad del día a día, es decir, desarrollo a base de bomberazos.. eso definitivamente no es Scrum.

Scrum tiene muchos beneficios,  pero librarse de la burocracia y de enfrentar todos los requerimientos expuesto por PMBOK no es uno de ellos.

De todas maneras se debe hacer una gestión de Tiempos, Costos, Alcance, Recurso, Calidad, Riesgos, Interesados, Comunicaciones y de todas maneras existe una línea base que debe administrarse. En Scrum se llama Backlog y “Árbol de características / funcionalidades”.

Aún no cambio de opinión, para poder hacer Scrum de manera responsable, primero se debe saber hacer proyectos según PMBOK.

Para más información, les recomiendo este excelente artículo de Joy Beatty and Candase Hokanson ->   RequirementsinAgileWhitepaper1

Autor: Humberto Ramos  ( [email protected] )
PMI Capítulo México, Comunicaciones Digitales