La gestión de proyectos predictiva afirma que la forma más eficiente de hacer un trabajo es hacerlo bien a la primera. ¿Es más eficiente la gestión de proyectos predictiva que la gesitón de proyectos ágil?.

La ingeniería de software tradicional necesita requisitos detallados y estables.
Para la gestión de requisitos tradicional, (una de las cinco áreas de conocimiento de la ingeniería de requisitos según SWEBOK) cada modificación de requisitos es una "incidencia". Un torpedo contra el éxito del proyecto que requiere un estudio de impacto y medidas de reparación.

Compendio de Ingeniería del Software  I

Sin embargo , los requisitos genéricos y los cambios durante el desarrollo son las premisas del desarrollo ágil, que afirma cosas como "Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente".

La clave de esta aparente contradicción está en los ciclos de vida empleados por unos y por otros: El desarrollo secuencial o en cascada necesita requisitos detallados y estables, algo que no sucede si se usan modelos iterativos.

Requirements Management in an Agile-Scrum

Pero... todo tiene su precio. La agilidad se adapta al cambio y da más valor a la visión del producto, en cada modificación que va descubriendo mientras lo construye... pero claro, los cambios de requisitos repercuten en la eficiencia del equipo y en la calidad entregada.
 Porque es evidente que "La forma más eficiente de hacer un trabajo es hacerlo bien a la primera".
¿Sí?.
¿Alguien lo ha comprobado, o simplemente se da por supuesto porque parece obvio?.

Esto es lo que se plantearon los profesores de la Universidad de San Marcos en Texas Elizabeth Oyeyipo y Carl Mueller, y para comprobarlo han realizado un estudio con 33 alumnos de Ingeniería de Software, formando 8 equipos de 4 ó 5 programadores y cuyos resultados publica la Universidad en el reciente informe "Requirements Management in an Agile Scrum "

Los 8 equipos construyeron el mismo sistema con el mismo product backlog y trabajando con el mismo propietario de producto: un programa de gestión de agendas.

Siete equipos trabajaron con Scrum, admitiendo al propietario de producto realizar cambios en el backlog de requisitos durante la ejecución del proyecto.
Un equipo se empleó como referencia para contrastar los datos, de forma que usó un ciclo de desarrollo iterativo (4 iteraciones en lugar de los 4 sprints)  pero sin modificar los requisitos, para analizar las diferencias de eficiencia y calidad.
Las métricas empleadas en el estudio han sido 29, agrupadas en 4 categorías: Esfuerzo del equipo, Funcionalidad producida, Impacto de los cambios de requisitos y calidad entregada.

(El grupo I trabajaba con Scrum y el II no)

El estudio concluye que los grupos trabajando con Scrum permitiendo cambios en el backlog entregaron más calidad, más funcionalidades e invirtieron menos horas que los que trabajaron con iteraciones sin permitir cambios.

• Página de información del estudio .
• Enlace de descarga .
  

La función de los directivos y gestores en una organización con Scrum es un tema muy interesante del que no hay casi ningún estudio. El documento "Virtual Reality Meets Scrum. How a Senior Team Moved from Management to Leadership" analiza los cambios en las funciones de gestión y los comportamientos en el personal de empresa finlandesa de juegos sociales Sulake, que comenzó a trabajar con Scrum en 2006, y lo institucionalizó a los 6 meses.

El estudio se ha realizado en 2009 con las respuestas de 19 directivos y 36 técnicos.

Los mayores desafíos para los gestores en organizaciones con Scrum consiste en dar autonomía al equipo, y no practicar la micro-gestión.

1998: "No termino de ver por qué tenemos que trabajar con ISO 9000 en el departamento de programación, pero lo recomiendan todos los expertos en calidad, y lo hacen las mejores empresas. Mejor no desentonar, porque soy novato en dirigir equipos de programación, así que vamos a por lo mejor."

2001: "¿Donde vas con una ISO 9000? Para la industria del software lo mejor y lo último es CMM."

2005: "¿Procesos? Los procesos son del siglo pasado." Tienes que usar Scrum. 2007: "¿Scrum o Kanban?...." ¡Eso que tu haces no es así! ¡El proceso tiene que ser así....!

Wikipedia: Conformidad es el grado hasta el cual los miembros de un grupo social cambiarán su comportamiento, opiniones y actitudes para encajar con las opiniones del grupo.

Mecanismos de conformidad: sugestión, imitación, contagio, simpatía, instinto gregario (Psicología de las relaciones de autoridad y poder . 2006. Editorial UOC.)

Los modelos son útiles para dar los primeros pasos, pero después, adoptar mecanismos de conformidad puede bloquear el desarrollo de un criterio profesional propio.

En el último viaje a San Francisco conocí ingenieros tanto de Google y de Apple, como de pequeños proyectos y startup's (La gente de Apple cuenta muy poquito por las cláusulas de confidencialidad de sus contratos).

Aunque son empresas y equipos diferentes,sus formas de trabajar tienen dos cosas en común, que prácticamente ni se las cuestionan: 

La primera: sus prácticas y métodos dan forma a principios ágiles: Trabajan desde una visión conocida y compartida por todo el equipo, no desde requisitos detallados. Avanzan de forma iterativa e incremental en incrementos cortos y breves, tomando feedback continuo...

La segunda: Pasan de metodologías y dogmas ágiles.

Y es que fijarse en la forma (en las prácticas) y no en el fondo (en los principios) es mirar al dedo y no a la luna a la que señala. La agilidad sin flexibilidad acaba siendo un dogma paradógico: enseñar cómo deben organizarse los equipos "auto-organizados" (?).  Es como aquello del "prohibido prohibir"

Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:

- Los mejores equipos no tienen una metodología ni siguen un dogma.

- Los equipos con problemas a menudo intentan seguir una metodología, sin éxito.

- Los mejores equipos exploran nuevas técnicas de trabajo de forma continua.

- Los equipos con problemas tienen un repertorio de técnicas fijo y limitado.

Es una pregunta más ambigua de lo que parece. ¿Vendemos horas de trabajo o sistemas valiosos?. Preguntar cómo se debe facturar el software, es como preguntar cómo se debe facturar la pintura.

Añado Kunagi a la lista de herramientas libres para la gestión de proyectos ágiles.

Es una herramienta gratuita sobre interfaz web para gestión ágil de proyectos que además de los artefactos más frecuentes (pila de producto, pila de sprint y pizarra de trabajo con representación kanban y gráfico burndown) incluye también aspectos interesantes como registro de requisitos no funcionales, riesgos, impedimentos, versiones, wiki o foro.

1.- herramientas para gestión y seguimiento ágil:

• Pizarra de trabajo con gráfico de avance o Burndown.
• Registo de Sprint: Registro y segimiento a nivel de tareas con indicación del estado y tiempo pendiente de cada una que se pueden ver en formato kanban, en el que se agrupan las tareas por historias de usuario, o en formato pila de sprint. En ambos casos con información de tiempos, impedimentos y comentarios.
• Producto: Registro y seguimiento a nivel de historias de usuario en formato pila de producto, con información de estimación, comentarios del equipo, historias y temas relacionados. En este área también se pueden registrar requisitos genéricos de calidad que afectan a varias historias, Temas y versiones.
• Proyecto: Registro y seguimiento de parámetros del proyecto: Impedimentos, Riesgos, Diario del proyecto, fechas e histórico de sprints.

Scrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, que trabajan con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Esta forma de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando cómo trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sus productos("New New Product Development Game"): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de la implementación de Scrum para software que él empleaba en el desarrollo de Delphi.

Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones...) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o "Epics" de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban...

Para tener una visión de retrospectiva, este es el "paper" de Ken Schwber presentado en 1995 su implementación de Scrum en OOPSLA: "SCRUM Development Process " y este otro su artículo del mismo año "Living on the Edge" en el que describía su implementación de Scrum para Software.

Como adelanto, esta sería la traducción de la "metodología" y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.
…
Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-
…
Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte  orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior  de sistemas heredados.
…..

FASES DE SCRUM

SCRUM comprende las siguientes fases:

1.- Pre-juego

Planificación: Definición de una nueva versión basada en la pila actual, junto con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de alcance más limitado.
Arquitectura: Diseño de la implementación de las funcionalidades de la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.

2.- Juego

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con respeto continuo a las variables de tiempo, requisitos, costo y competencia. La interacción con estas variables define el final de esta fase. El sistema va evolucionando a través de múltiples iteraciones de desarrollo o sprints.

3.- Post-juego

Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas antes del lanzamiento de la versión.

Pasos de cada fase

[...]

En 1907, Danielo Ortiz de la Mata Crea en Talavera de la Reina el primer prototipo del invento más extraordinario que haya conocido la humanidad.

Vía:Notodofilmfest

"Somos parte de la tierra como organismo y la diferencia entre un orgnismo y un mecanismo es que en el mecanismo el todo es la suma de las partes, en un organismo cada parte está relacionada con el todo, lo que hace cada una de las células influencia al todo, y cada célula necesita a la totalidad para existir"

La cita no es de del presidente de una asociación de hermandad o una ONG. Es del subdirector de un banco: Joan Melé, subdirector del banco Triodos Bank, en su conferencia en la EOI el 6 de Mayo de 2010. "Dinero y Conciencia".

La idea del planeta o de la humanidad en su conjunto como organismo no es ninguna tontería. Lleva preocupando durante años a científicos como el nobel Edward O. Wilson, el inventor de la sociobiología, que siempre ha creído que los humanos constituimos un superorganismo, pero que tiene unas células extrañas que suelen desarrollar un comportamiento que pese a colaborar con el superorganismo, nunca renuncian del todo a su esfera de intereses individuales, pudiendo éstos llegar a poner en peligro al conjunto.

Una célula centrada en su propio crecimiento, y no en el crecimiento equilibrado de todo el organismo, ¿no es un cáncer?.

Se llama fractalTeams y su autor, Michel Henric-Coll, muestra la antítesis del tecnomanagement poniendo al descubierto sus falacias, y desde ellas extracta un resultado de síntesis para la gestión de personas y equipos, al que llama fractalTeams.

Por el convencimiento personal de que la implantación de agilidad en una empresa debe ser sistémica, esto es: implicando a toda la organización como el sistema de relaciones complejas (no complicadas) que es, y considerando al mismo tiempo que sólo funciona en organizaciones basadas en equipos; ésta es sin duda la mejor descripción que conozco de lo que deberían ser los equipos en una organización ágil.

Por eso el libro con el que describe fractal Teams es un estupenda referencia para gestores, que además además de ser muy bueno, Michel comparte de forma libre. 

Gracias!!

 
¿Queréis hacer ganas de leerlo?...