vendidoLos "CMMI's" cada vez se llevan menos. Tras 20 años de ayudar a las empresas de programación, no se sabe si a mejorar el software, o a licitar con ventaja en los concursos públicos, han perdido fuelle y terreno frente a la agilidad.

Así que ahora le toca al negocio de la consultoría renovarse, porque el asesorar con "CMMI's" se vende cada vez peor, y la agilidad es sin duda la nueva tendencia. Lo malo es que algunos, o bien no entienden lo que venden, o sólo les preocupa hacer el dibujo de un marco lo suficientemente creíble para engatusar a los clientes que se conforman con aparentar e ir a la moda.

 

agile for phbs

 

Así que van a convertir a la agilidad en otro modelo de procesos, porque gracias a su capacidad de marketing, van a ser muchas las empresas a las que les van a enseñar cómo deben organizar a los equipos autoorganizados, o a las que convencerán de que Scrum tan sólo es un ciclo iterativo que pueden implementar sin dejar de "embau-contratar" con clientes y administraciones como hasta ahora, porque su marco ágil funciona sin esa bobada de la colaboración estrecha entre cliente y desarrolladores, que sólo serviría para destapar información inconveniente, como que le están facturando 7 "recursos senior" y en su proyecto sólo hay dos becarios desmotivados.

Y de cosas como la autonomía y "empowerment" de los equipos, cultura ágil de la organización... mejor ni hablar.

 

coste laboralEl coste laboral está en relación directa con el salario: coste = salario, pero con un modificador importante: "valor que aporta la persona".

coste = salario / valor.

En la manufactura industrial, y demás trabajos que aplican ingeniería de procesos para garantizar la calidad del resultado,  y que la diferencia entre las personas no resulte significativa, al factor "valor" se le puede considerar una constante.
Además la ingeniería de procesos minimiza la pérdida de know how en la rotación de personal, así que si no escasean los "operarios" en el mercado laboral, se puede simplificar la fórmula y dejarla en "coste = salario", considerando más barato al que menos cobra.

Sin embargo, en la construcción de software, la diferencia de valor aportado entre los buenos y los mejores es enorme. Tan grande que resulta miope mirar al factor "salario" para reducir el coste.
Y por supuesto a los malos y mediocres, ni los considere. A ningún precio; porque disparan el coste al no aportar valor, o aportarlo negativo, porque degradan y complican el código tocan.

 

triadaEs posible que en determinados trabajos se necesiten personas con una de estas fortalezas:

Su capacidad de trabajo:
"Dame gente trabajadora, dispuesta a echar horas o fines de semana".

Su talento:
"No necesito gente para calentar la silla; quiero brain time, no body time".

O su nivel de compromiso:
"Quiero gente que sienta los colores, que se sienta empresa".

Sin embargo un equipo Scrum no funciona por su dedicación, talento o compromiso, sino por la combinación equilibrada de los tres. De hecho no es otro el motor de Scrum: gente capaz, comprometida y laboriosa, trabajando en equipo.

 

perfil equipo scrum

 

 

excipientes

Excipientes de Scrum

Gráficos burndown, estimación de póquer, product backlog, sprint backlog, formatos de historias de usuario, reuniones de pie, tableros visuales kanban etc.

Principios activos de Scrum:

  • Visión: El proyecto tiene un objetivo definido, conocido y asumido por todos los miembros.
  • Priorización: El criterio de prioridad del cliente define en cada momento las tareas inmediatas para avanzar hacia el objetivo.
  • Visibilidad: No hay información oculta y en las decisiones se tienen en cuenta las consideraciones y aportaciones del todo el equipo.
  • Competencia: Todos los miembros tienen la competencia profesional necesaria para aportar un trabajo valioso.
  • Respeto: Todos los miembros dan y reciben respeto y valoración.
  • Compromiso: Las personas no anteponen sus intereses propios a los del equipo.
  • Confianza: Todo el equipo tiene confianza real en el desempeño, valor y compromiso de los demás.
  • Coraje: Todos los miembros y el equipo en su conjunto hace frente con decisión y solvencia a las situaciones adversas.
  • Responsabilidad: Cada persona tiene el margen de acutación y decisión necesario para su aportación al proyecto y es responsable de sus decisiones, acciones y omisiones.
  • Ritmo: El desarrollo se realiza con una cadencia de avance objetivo continuo y sostenible.
  • Retroalimentación: De forma periódica el equipo analiza su forma de trabajo y toma decisiones de mejora.

La mejora que cabe esperar al emplear prácticas Scrum un equipo sin principios ágiles es la propia de un placebo.

 

Gestión de proyectos predictiva - evolutiva (cascada - agilidad)


A la terceraLas estimaciones de esfuerzo y velocidad no suelen ser fiables en los equipos novatos de scrum hasta el tercer sprint, pero de todas formas la precisión al estimar es la habilidad menos relevante de las analizadas para un equipo ágil.

Son conclusiones del estudio realizado por la Facultad de Informática de la Universidad de Liubliana: A Case Study on Agile Estimating and Planning using Scrum.

Se ha desarrollado en el curso académico 2009-10, y en él han participado 52 alumnos de Ingeniería Informática, formando 13 equipos.

Los 13 han desarrollado el mismo sistema empleando Scrum: una plataforma web de gestión académica: registro de alumnos, exámenes, estadísticas... a partir de una pila de producto inicial de 60 historias de usuario.

Antes de empezar todos recibieron una pequeña formación sobre agilidad y trabajo con scrum, porque el objetivo ha sido simular la implantación de trabajo ágil en una empresa para determinar: la precisión de las estimaciones y qué prácticas de scrum consideraban que habían sido más útiles al terminar el desarrollo.

En cuanto a las estimaciones el resultado ha sido que en el primer sprint son normales las estimaciones muy optimistas, y que no se logre terminar con las tareas previstas (sólo lo logró 1 de los 13 equipos del estudio). La media fue completar sólo el 42% de las tareas. A partir del tercer sprint las estimaciones ya comienzan a ser fiables. En cuanto a la valoración que daban a cada una de las prácticas (de 0 a 5) empleadas para el éxito de una implantación ágil estos son los resultados.

 

Resultados

¿CMMI?CMMI es un modelo para mejorar y evaluar la madurez de las empresas de software y la capacidad de sus procesos. La Administración americana lo puso en marcha (entonces como CMM) en los 80 a través de SEI para tener un medio con el que evaluar la fiabilidad de sus proveedores de software.

En los 90, las críticas hacia los modelos de procesos generaron su antítesis: la agillidad que los consideraba inapropiados, e incluso contraproducentes para el desarrollo de software.

Desde entonces hay dos tendencias estratégicas distintas para lograr la excelencia en proyectos de software: basar la calidad en la capacidad de los procesos, o basarla en el talento de las personas.

a) La calidad de un sistema de software es consecuencia de la calidad de los procesos empleados en su desarrollo. La evaluación de los procesos (CMMI, ISO 15504, Spice...) es la estrategia adecuada para determinar el nivel de calidad que ofrece la empresa.

b) La calidad de un sistema de software depende principalmente del talento de las personas. Contar con los mejores profesionales y un clima de trabajo adecuado es una garantía de éxito más fiable que la capacidad de los procesos de trabajo que tenga institucionalizados la empresa.

Aplicar las dos estrategias simultáneamente: procesos + talento es también una opción pero a menudo más quimérica que realista cuando se trata de sistemas de software innovadores, porque los procesos combinan bien con el trabajo disciplinado, pero no tanto con el talento creativo. De hecho la primera reacción al combinarlos fue el Manifiesto Ágil.

 
cmmi vs agile
 
 
Observando lo ocurrido con el proyecto healtcare.gob y las decisiones de la Casa Blanca en el último año: