Agilismo y Scrum – Cambio de Paradigma

Cambio de Paradigma

“Cuando un paradigma ha sido establecido por el colectivo de científicos al que sirve, los fundamentos del mismo nunca son puestos en duda” Thomas Kuhn

• Paradigma establecido: control definido de procesos
• Problemas y anomalías: proyectos, programas y planes retrasados, sobrepresupestados y los equipos de trabajo desmotivados.
• Nuevo paradigma: control empírico de procesos ágil, Scrum

¿Qué es el Agilismo?

El agilismo es una filosofía de desarrollo de productos que utiliza modelos organizacionales centrados en la gente, en la colaboración y que acepta el cambio como una realidad, por lo que hay que tratarlo con un enfoque práctico.

Procesos definidos, anomalías, problemas…. mentiras

• Podemos revisar el progreso con el “porcentaje de progreso completado”
  • No, las metas no cumplidas tienen un alto grado de incertidumbre. Los porcentajes son muy subjetivos y no indican el avance real del proyecto. Se llega al 90% de avance en el 20% del tiempo, y luego el 10% restante se lleva el 80% del tiempo
• El cliente sabe qué quiere y puede definirlo de manera precisa.
  • No, el cliente no sabe lo que quiere o cómo lo quiere hasta que lo ve, hasta ese momento, lo que quiere va evolucionando. Según va viendo el avance del proyecto, por un lado puede ver desviaciones sobre su necesidad, o por otro lado se le pueden ocurrir nuevas ideas.
• Los planes a largo plazo son exactos
  • No, el futuro es menos previsible cuanto más lejos nos vamos, hay que replanificar continuamente a medida que se va avanzando en el proyecto, lo que implica retrasos continuos en la planificación del desarrollo.
• El equipo SIEMPRE puede completar su trabajo a través de un proceso definido
  • No, para que los desarrollos se realicen, los componentes del equipo deben trabajar de manera oportunista en un entorno auto-organizado.
• Las evaluaciones individuales son una medida real de la efectividad de los miembro del equipo.
  • No, el éxito o el fracaso son en conjunto, las evaluaciones individuales son inútiles, si 3 componentes del equipo terminan en plazo, pero el resto no, el proyecto no se ha entregado en plazo aunque 3 componentes hayan logrado sus objetivos.
• La rastreabilidad se logra mediante la documentación concurrente.
  • La rastreabilidad mediante documentación aún con equipos pequeños no se logra. La documentación se queda rápidamente desactualizada, los componentes del equipo están más preocupados de llegar a sus objetivos que de completar la documentación. Al final se termina el desarrollo, la documentación no se ha actualizado, las peticiones de cambio llegan de las formas más variopintas, desde emails hasta “aprovechando que te veo aquí en el baño, hay que cambiar…”
• Las partes del sistema pueden desarrollarse de manera independiente y más tarde ser integradas y probadas.
  • La integración y las pruebas son complejas y según el sistema va creciendo, se hacen más y más complicadas, lo que hace que al final se pueda pasar más tiempo en la integración y las pruebas en sistemas grandes que casi en el mismo desarrollo. Es más conveniente que se vayan realizando de forma continua en el día a día.
• El equipo y el cliente pueden comunicarse por medio de documentos
  • Eso no funciona, ya que los documentos tienen que ser interpretados, cuanto más grande sea la documentación, surgen más dudas y preguntas, y la trazabilidad se hace más difícil. Aparte el cliente suele “estar ocupado y no tiene tiempo” para poder leer la documentación, lo que hace que la apruebe sin leerla ni entenderla.
• El Project Manager puede estimar el trabajo y asignarlo a otras personas, y predecir de manera acertada el final del proyecto.
  • No, sólo los programadores que están trabajando en el desarollo están al pendiente de las nuevas tareas y/o nuevas estimaciones. Ellos son los que saben mejor que nadie el trabajo que se está realizando y el que queda pendiente, y sólo mediante la medición de su velocidad colectiva pueden saber qué tanto pueden hacer.
• Las personas que trabajan en equipos grandes son igualmente productivas.
  • Esto no es así, los equipos pequeños son mucho más productivos. Por un lado los equipos grandes pierden más tiempo en la comunicación entre los componentes del equipo, por otro lado es más complicado hacer seguimiento del avance y el reparto de las tareas.
• Las personas no procastinan
  • Las personas procastinan continuamente, leen el correo, redes sociales, revisan el partido del día anterior, cafés largos, reuniones interminables sin ajustarse al tema. Eso hace que todo el esfuerzo termine produciéndose alrededor de los “deadlines” o entregas.
• La capacidad del equipo es igual a la suma de las habilidades individuales.
  • Esto o es así, la cooperación y la compartición del conocimiento hacen que la productividad del equipo no sea lineal. El grupo es más inteligente que cualquiera de forma individual.
• Las personas leen la documentación técnica
  • La mayoría de las personas prefieren las conversaciones a leer la documentación, más si además la documentación es extensa.
• El progreso de los equipos puede ser medido por medio de reportes de actividades semanales
  • Es preferible que el estatus del equipo se haga de forma diaria, de tal forma que los miembros del equipo se puedan apoyar unos a otros y comunicarse los cambios lo más pronto posible.
• El flujo es independiente de la calidad
  • No, la calidad dirige el flujo, el flujo es proporcional a la calidad.
• Todo el trabajo  es igualmente importante, “valor ganado”
  • No es así, hay trabajo con mayor valor de negocio que otro, por lo que es importante conocer el valor de negocio de cada funcionalidad para poder priorizarla.
• Los planes más detallados, donde se invierte más planificación son mejores
  • Por mucho que se planifique, nunca se puede predecir el futuro. Las personas se enferman, pueden bajar o aumentar su rendimiento dependiendo de su estado de ánimo, con lo que por mucho que se intente planificar, es complicado que se cumpla al pie de la letra el proyecto.

Modelo operativo

El modelo operativo está transicionando de un modelo tradicional jerárquico donde las órdenes e instrucciones van pasando de un nivel a otro, lo que conlleva pérdidas de tiempo tanto en la transferencia de información, como en la toma de decisiones, a un modelo de red de liderazgo descentralizado, donde todos los miembros del equipo son importantes, la toma de decisiones y la transferencia de información es mucho más rápida.

¿Qué no es ágil?

Ágil NO ES una excusa para dejar de producir documentación, es cuestionar lo que no tiene valor. Hay que seguir produciendo documentación, pero únicamente la necesaria, no producir documentación que no sirve para nada, sólo porque la metodología lo exige.

Ágil NO ES una oportunidad para eliminar la planificación, es un método para establecer una planificación gradual con el adecuado nivel de detalle, según se vaya avanzando en el desarrollo.

Ágil NO ES una puerta abierta para modificar el alcance, es una apertura para que el cliente tenga una manera de cambiar sin dolor sus requisitos y para que el equipo reaccione adecuadamente.

Ágil no es seguir ciegamente “mejores prácticas“, es hacer lo que haga sentido basado en la filosofía ágil y la situación.

¿Qué es Scrum?

Scrum es un marco de referencia basado en el control empírico para entregar resultados con el más alto valor de negocio, en la menor cantidad posible de tiempo, a través de equipos auto organizados.

Scrum es una manera de implementar la filosofía ágil.

Scrum se basa en la teoría de control de procesos empírica o empirismo, emplea un enfoque iterativo e incremental para optimizar la predictividad y el control del riesgo.

Scrum es un modelo de desarrollo ágil caracterizado por:

• Adoptar una estrategia de desarrollo incremental, en lugar de planificación y ejecución completa del producto
• Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados
• Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada

Scrum es ligero, adaptativo, fácil de entender y extremadamente difícil de llegar a dominar

¿De dónde viene Scrum?

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986)

Jim Coplien, Organization Patterns, 1992. Bell Labs

Jeff Sutherland, 1993, en EASEL tratando de replicar el éxito del equipo Quatro Pro en el uso de los conceptos “The New Product Development Game”

Schwaber, 1995, “Scrum Development Process” en OOPSLA 95 (Object-Oriented Programming Systems & Applications
conference)

Schwaber y Beedle, 2001, Primer libro de Scrum.

Teoría de control de procesos

Es típico adoptar el enfoque de modelado definido (teóricamente) cuando los mecanismos subyacentes por los cuales un proceso funciona están razonablemente bien entendidos. Cuando el proceso es demasiado complicado para definir un método, el método empírico es el más apropiado”.

Process Dynamics, Modeling, and Control. Ogunnaike and Ray, Oxford University Press, 1992

Proceso adaptativo/empírico

La pregunta es, ¿cuándo debo usar procesos adaptativos/empíricos?

Cuando las cosas no se pueden definir lo suficiente para que se ejecuten de forma desatendida y produzcan un resultado repetible, de una calidad aceptable.

Los modos empíricos se utilizan cuando las actividades son impredecible, no lineales, y son demasiado complejas de definir en detalle repetible. El control es a través de la inspección y adaptación.

Diagrama de complejidad de Stacey

Este diagrama nos muestra cuál es la metodología a utilizar dependiendo de la complejidad tecnológica y de requisitos.

Cambio de paradigma en los procesos de negocio

Procesos predecibles y controlados – Producción

• Manufactura
• Contabilidad
• Nómina
• Facturación

Procesos adaptables/empírcos

• Márketing
• Estrategia
• Investigación básica
• Desarrollo de Software
• Desarrollo de Productos
• Rediseño de procesos

Puedes ver más información en este libro:

Fundamentos de los Requisitos de Software

Trabaja con nosotros

Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.