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:
 

cubo Descargar Descargar el artículo en formato pdf.

Introducción

Es tanta la información de estándares, modelos, marcos y prácticas para desarrollo de software, que apostar por uno u otro puede acabar siendo más una decisión guiada por conformidad con la mayoría, que por conocimiento y  evaluación de las opciones existentes. Para ayudar en esta decisión este artículo dibuja el marco general de los modelos de procesos y prácticas de la industria del software: CMMI, ISO 15504, Scrum, Extreme Programming, DSDM, MSF, RUP, PMI, etc. en una síntesis ejecutiva que muestra los principios de los principales modelos, sus fortalezas y debilidades.

estrellaComo cada proyecto, y cada empresa es diferente, éstos son cinco factores importantes para decidir si abordarlos con principios ágiles, o siguiendo modelos de procesos y planificación:

  • ¿Cuál es el nivel de estabilidad de los requisitos?. ¿Se esperan pocos cambios, o serán la tónica habitual?
  • ¿Cuál es el nivel de criticidad del proyecto? ¿Qué clases de pérdidas pueden producir los errores en su desarrollo: vidas, bienes materiales o funcionalidad para los usuarios? ¿Se trata del sistema de software para regular el núcleo de una central atómica, o para gestionar una agenda infantil?
  • ¿Cuál es el tamaño del equipo de desarrollo: 4 ó 40 personas?
  • ¿Cuál el porcentaje de técnicos competentes y expertos frente al de principiantes y menos duchos?
  • ¿Cuál es la cultura de la organización?. ¿Jerarquizada, de funciones delimitadas y procedimentadas, o por el contrario se trata de una cultura de autonomía, y multifuncionalidad?

estrella b t

Estas son las 5 puntas del gráfico propuesta por: Barry Boehm y Richard Turner. (1)

Si la estrella no te sale muy simétrica, si quizá se trata de desarrollar el sistema de asistencia al pilotaje de un avión, con un equipo de tres programadores junior.... igual estás buscando la cuadratura del círculo,  y ni los modelos ágiles ni los basados en procesos puedan ser de gran ayuda ;-)

(1) Boehm B. & Turner R (2002) Balancing Agility and Discipline (pág. 160) Boston:  Addison-Wesley

 

portadaHe cerrado una nueva revisión de este libro que empezó hace algunos años como recopilación de apuntes y artículos sobre scrum.

A ver si Iteración a iteración vamos a acabar haciendo de esto un libro :-)

A todos los que lo habéis leído, muchas gracias y disculpas por las erratas que me sonrojan al descubrirlas en cada revisión. Así que tirad la  anterior, y cambiadla por esta ;-) Y a los que no lo tuviérais y os pueda interesar, espero que os guste y sobre todo que os resulte útil.

Descargar: Gestión de proyectos Scrum Manager v 2.5

// Actualización Julio 2016 //

 

 

 

no prohibirHas aprendido a avanzar en scrum cuando sabes romper las reglas.

 

NIVELES DE

SCRUM

   

1.- Reglas

2.- Valores

Ken schwaber & Jeff Sutherland Nonaka & Takeuchi
Marco de reglas para desarrollo de software.
Autores: Ken Schwaber y Jeff Sutherland
(Origen: "Scrum Development Process OOPSLA'95" 1995)
Concepto original Scrum.
Autores: Hirotaka Takeuchi e Ikujiro Nonaka
(Origen: "The New New Product Development Game" 1986)
   

Reglas definidas

Valores ágiles...

   
Roles
  • Dueño de producto
  • Equipo de desarrollo
  • Scrum Master
Eventos
  • Sprint
  • Reunión de planificación
  • Scrum diario
  • Revisión de sprint
  • Retrospectiva de sprint
Artefactos
  • Pila de producto
  • Pila de sprint
  • Incremento
  • Personas > procesos
  • Resultado > documentación
  • Colaboración > negociación
  • Cambio > planificación

... "Para avanzar en Scrum"

  • Incertidumbre
  • Autoorganización
  • Fases de desarrollo solapadas
  • "Mutiaprendizaje"
  • Control sutil
  • Difusión del conocimiento
   
Scrum técnico Scrum pragmático
   
Scrum técnico Scrum
Para avanzar guiados por reglas Para avanzar en scrum, sin reglas.
Equipos autoorganizados asesorados por un Scrum Master Equipos autoorganizados sin Scrum Master