¿ScrumBut se basa en valores y principios?

Cortesía de Pixabay

Con este post quiero poner un poco de humor en el blog :-D

Estamos viviendo unos tiempos interesantes, la Agilidad se expande a todo tipo de disciplinas y emergen Manifiestos Ágiles en algunas de ellas. Ejemplos son el Manifiesto Ágil de Marketing, el Manifiesto Ágil para el Desarrollo de RRHH (recursos humanos), el Manifiesto Ágil para Negocio, el Manifiesto Ágil para Ventas,... y los manifiestos complemento como lo son el Manifesto for Software Craftmanship, el Manifiesto para Gente Ágil, el Testing Manifesto, el Manifiesto de Sistemas Reactivos... y hasta, con mucho sentido de humor y gracias a Kerry Buckley, un Manfiesto Ágil que soporta ScrumBut, ideal para esas empresas que para tomar su camino hacia la Agilidad adaptan Scrum en lugar de adoptarlo.

A continuación la traducción del Manifiesto :-P

Manifiesto para el Desarrollo Ágil de Software a Medias Tintas

Hemos escuchado sobre nuevas formas de desarrollar software pagando consultores y leyendo informes de Gartner. A través de esto nos han dicho que valoremos:

• A los individuos y su interacción, por encima de los procesos y las herramientas
  y teniendo procesos y herramientas obligatorias para controlar cómo interactúan esos individuos (preferimos el término "recursos")

• El software que funciona, por encima de la documentación exhaustiva
  siempre y cuando ese software esté exhaustivamente documentado

• La colaboración con el cliente, por encima de la negociación contractual
  dentro de los límites de los contratos estrictos, y por supuesto sujetos a un riguroso control de cambios

• La respuesta al cambio, por encima del seguimiento de un plan
  siempre que se haya establecido un plan detallado para responder al cambio, y este se sigua de forma precisa

Es decir, aunque los elementos de la izquierda suenan bien en teoría, somos una gran empresa, y no hay forma de que dejemos de lado los elementos de la derecha.

---

Y gracias a Rafael Sabbagh de Knowledge21 reproduzco a continuación:

Los 12 Principios Frágiles (de la Gestión Tradicional de Proyectos)

1. Nuestra mayor prioridad es respetar el plan mediante de la entrega de software, dentro del plazo previsto, con el alcance comprometido.
2. No nos gusta que los requisitos cambien, incluso queremos que los cambios sean evitados o gestionados estrictamente en cualquier etapa del desarrollo. Los procesos tradicionales aprovechan el cambio para poder cobrarle más caro al cliente.
3. Entregar software funcional, entre muchas semanas y muchos meses, con preferencia al periodo de tiempo más largo posible.
4. Los responsables de negocio y los desarrolladores trabajamos separadamente de forma cotidiana durante todo el proyecto y se comunican a través de documentos y especificaciones.
5. Los proyectos se desarrollan en torno a los mejores procesos y herramientas. Hay que dirigir y controlar a los individuos, sin nunca confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es partir de documentos detallados.
7. El porcentaje de tareas cumplidas es la medida principal de progreso.
8. Los procesos tradicionales promueven el desarrollo haciendo lo necesario. Los promotores y los usuarios debemos ser capaces de mantener una presión constante sobre los desarrolladores para acelerar su ritmo de trabajo de forma indefinida y para que entreguen lo prometido.
9. La atención continua al plazo y al presupuesto mejora las posibilidades de que se produzca la entrega, incluso si deben hacerse concesiones en materia de calidad.
10. La complejidad, o el arte de maximizar la cantidad de trabajo realizado, es esencial.
11. Las mejores arquitecturas, requisitos y proyectos son definidos y detallados por gerentes y jefes antes del inicio del trabajo.
12. Al final del proyecto el equipo reflexiona sobre lo que ha ido mal y de quién fue la culpa, y espera poder ajustar y perfeccionar su comportamiento en consecuencia en algún próximo proyecto.