Versión final del libro "Mejora de Procesos de Software con Métodos Ágiles y Modelo de Madurez MPS: La Historia de Tahini-Tahini" Para una versión Kindle o en papel, recurrir a Amazon.com.

2. Jorge Luis Boria
Viviana Leonor Rubinstein
Andrés Rubinstein
La Historia de Tahini-Tahini:
Mejora de Procesos de Software con
Métodos Ágiles
y el Modelo de Madurez MPS

3. Boria et al.
PREFACIO
La discusión sobre la posibilidad o no de utilización de métodos ágiles en conjunto con modelos de madurez
de procesos de software es frecuente y actual.
Algunos consideran que las exigencias de los modelos de madurez no pueden ser implementadas en
organizaciones con desarrollo ágil. Otros consideran que la implantación de estos modelos va a lastimar la agilidad
de desarrollo. Esta incompatibilidad es discutida, por lo tanto, por defensores del uso de métodos ágiles y por
defensores de los modelos de madurez.
En este contexto se sitúa el libro “La Historia de Tahini-Tahini: Mejora de Procesos de Software con Métodos
Ágiles y Modelo MPS” de Jorge Boria, Viviana Rubinstein y Andrés Rubinstein.
El libro tuvo origen en una llamada realizada en diciembre de 2011 por la Secretaria de Política de Informática
– SEPIN, del Ministério de Ciência, Tecnologia e Inovação – MCTI, responsable por la conducción del Programa
Brasileiro de Qualidade e Produtividade em Software – PBQP Software, para el Ciclo 2012 del Programa “Série de
Livros do PBQP Software”. Entre varios competidores resultó el texto seleccionado para publicación.
Y fue, sin duda, una excelente elección. En él, los autores, a partir de su riquísima experiencia como
consultores, evaluadores MPS y lead appraisers CMMI, nos muestran que no existen contradicciones entre
modelos de madurez, mejora de procesos y métodos ágiles. Existe, por el contrario, un excelente camino que
puede ser recorrido con éxito por las organizaciones hasta que sean alcanzados niveles muy altos de calidad y
madurez en los procesos de software.
De acuerdo con los autores, el libro tiene como objetivo mostrar cómo se inter-relacionan las técnicas de
consultoría, con los métodos ágiles para alcanzar los resultados esperados del MR-MPS-SW. Para esto utilizan
cuatro métodos ágiles, Kanban, Scrum, XP y FDD (Feature Driven Development), y la historia de Tahini-Tahini, una
empresa ficticia que ciertamente a todos nos gustaría que existiese.
Es un libro técnico, más fascinante y de lectura muy agradable. A veces nos hace reír, tal el buen humor de los
autores al tratar el tema. Ciertamente será un caso de éxito, en esta excelente iniciativa del MCTI.
Agradezco a los autores la invitación a escribir el prefacio de un libro tan interesante y con contribuciones tan
importantes para la calidad y la Ingeniería de Software.
Abril, 2013
Ana Regina Cavalcanti da Rocha
Universidade Federal do Rio de Janeiro
COPPE/UFRJ
Prefacio
iii

4. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
PRÓLOGO - CONSULTORÍA EN MEJORA DE PROCESOS
El Origen del Libro
Este libro se originó en un llamado realizado en Diciembre de 2011 de la Secretaria de Política de Informática
– SEPIN, del Ministerio de Ciencia, Tecnología e Innovación - MCTI, responsable por la conducción del Programa
Brasilero de la Calidad y Productividad en Software - PBQP Software, para su Ciclo 2012 del Programa "Serie de
Libros de PBQP Software". Entre los temas para los cuáles había que presentar propuestas uno nos parecía
sumamente útil a la población de ingeniería de software, la Mejora de Procesos de Software con Métodos Ágiles y
el Modelo MPS. Sobre los otros temas, igualmente de importancia, hay literatura básica y avanzada. Tampoco es
un valor agregado, en un mundo globalizado, escribir un libro en Castellano o Portugués; el Inglés es la nueva
Lingua Franca y los principales cultores de esto son los informáticos. Nos atrajo el desafío de conciliar tres
vertientes, tal la complejidad del tema. Estamos agradecidos a todos los que intervinieron en el proceso que llevó
a la selección, edición y publicación de este libro.
El Propósito del Libro
Este libro se plantea como un libro de cuentos para profesionales. La empresa que se usa como caso de éxito
no existe ni existió, ojalá exista alguna vez. Los personajes surgieron de amigos, conocidos y situaciones que alguna
vez nos tocó vivir, como empleados, consultores o patronal de empresas de software. Su propósito es ilustrar
como se interrelacionan las técnicas de consultoría, siempre una buena facilitación cuando está bien hecha, a
veces enseñanza-aprendizaje, nunca dictadura; con los métodos ágiles, que son muchos más que Scrum; para
cumplir con los resultados esperados del MPS.
Este libro no es un recetario, no hay en él un algoritmo, ni siquiera una heurística que permita a otros
recorrer el mismo camino que el de los protagonistas de nuestra historia. Sin embargo, abrevar en él para
identificar problemas y avizorar soluciones es lo que nos propusimos que fuera su utilización. Esperamos que los
lectores aprecien la historia, porque está ahí para hacerlos pensar en las situaciones que ocurren a diario en la
industria de software.
Por último, este libro no es auto contenido. Requiere que el lector utilice las pautas bibliográficas que les
dejamos, ocho páginas en total de materiales superlativos. Si algo destacamos de este libro es que la bibliografía
de por sí vale la pena.
Las Vertientes del Libro.
El título de este libro mezcla tres ideas poderosas. Habla de mejora de procesos con métodos ágiles y el
modelo de mejora MPS. Cualquiera de las tres ideas merece un libro de por sí, de manera que escribir uno solo, y
en el corto plazo con que contamos los autores, implica una elección de contenidos. Este es un libro sobre las
actividades que se llevan a cabo en consultorías de mejora de procesos. Aunque el principal personaje es una
mujer, Marcela, que trabaja en relación de dependencia con la empresa que nos permite crear el hilo conductor de
la historia, sus actividades son las de un consultor de primer nivel.
Marcela encarna la heroína de la novela romántica Inglesa del siglo XVIII en que es inteligente, sabe lo que
quiere y sabe cómo conseguirlo. Es el ejemplo de liderazgo de este libro, aun cuando los demás socios y
compañeros de ruta son buenos gerentes y excelentes profesionales, cada uno con su vena técnica, es Marcela la
que guía con el ejemplo, la que cuestiona el statu quo, la que, en definitiva, lleva la empresa Tahini-Tahini a la cima
de la calidad. Cuando escribíamos el libro era con Marcela que preferíamos identificarnos, al fin y al cabo es el
personaje más exitoso. Las lecciones que debieran recogerse de este libro se deben a Marcela.
No es un libro de consultoría, los hay, y muy buenos, escritos por consultores mejores que nosotros. Sin
embargo, hay muchos consejos sobre cómo realizar las cosas que importan, las que llevan a los cambios serios,
que están contenidos en las acciones de los personajes. También hay muchísimas técnicas que solemos introducir,
de un modo u otro, en nuestras consultorías. El Capítulo 2 inicia el camino mostrando variantes de métodos de
mejora continua, culminando con el método Lean. Recomendamos lecturas extras para poder entenderlo y
aprovecharlo.
No es un libro sobre el MPS, preferimos que el lector aprenda acerca de este robusto modelo en las guías del
mismo y en los cursos autorizados que se dictan. Sin embargo no hay nada en el libro que no haya sido escrito con
el MPS en mente. Toda la historia de Tahini-Tahini, los vaivenes con las técnicas, a menudo presentadas para su
discusión antes de que puedan ser aprovechadas, ilustra nuestro punto de vista sobre los modelos de madurez,
iv
Prólogo

5. Boria et al.
centrado en el MPS: Hay que tener la visión global del destino para que el camino se pueda transitar con
comodidad.
Tampoco es un curso de métodos ágiles. El lector avisado debe entender que para introducir un método ágil
en una organización hace falta un entrenador o un mentor que guíe la implementación día a día. Producir una
organización ágil a partir de una que no lo es requiere experiencia y adaptación a las necesidades de la
organización.
Y aunque no es un libro sobre cambio organizacional, de esta disciplina sí que toma muchos conceptos
prestados. De todos modos, la literatura de cambio organizacional es muy vasta y muy rica, y le haríamos muy
poca justicia si intentáramos resumirla en estas pocas páginas.
El libro intenta describir las actividades de consultoría que tienen lugar en muchas organizaciones. Los
autores hemos elegido un mecanismo de presentación de los materiales que está a mitad de camino del libro de
texto y la narración de una historia que nos permite divertirnos con los personajes. Esperamos que se entretengan
con su lectura.
Nota de Cautela
Ningún libro de calidad puede dejar de citar a Deming. Este superhombre de la calidad nos dejó decenas de
pensamientos e ideas para andar con mayor comodidad tras sus huellas. En este Prólogo queremos rendirle un
pequeño homenaje a la vez que usar sus palabras para advertir al lector del error que muchas veces se comete en
aras de contener los gastos: “El Obstáculo de Deming, La esperanza de postre instantáneo --- la suposición de que
una o dos consultas con un estadístico competente pondrá a la empresa en el camino a la calidad y la
productividad – postre instantáneo. No es tan simple, siempre será necesario estudiar y ponerse a trabajar.”
No somos estadísticos expertos, pero hemos visto el mismo síntoma en muchas empresas traducido a una
invitación a almorzar a cambio de un consejo gratuito que después se intenta llevar a la práctica sin los
conocimientos necesarios. Los consultores no son irremplazables, pero el conocimiento que traen a las
organizaciones si lo es.
Nota Sobre los Autores
Siempre un libro es una creación colectiva. Tolkien hablaba del ‘humus’ que el autor junta para plantar sus
ideas, humus que le debe a sus lecturas y experiencias. Las musas inspiradoras solo trabajan en mentes abiertas
que han pasado por las experiencias que enriquecen la vida, tantas veces dolorosas. Pero además de la herencia,
los autores siempre están obligados con muchas personas que hicieron lo imposible posible.
Queremos agradecer muy especialmente a Ana Regina Cavalcanti da Rocha por su confianza y amistad, a
Kival Chaves Weber, Nelson Henrique Franco de Oliveira y José Antonio Antonioni por el apoyo y las oportunidades
brindadas y a Richard Denney por prestarnos el material de su autoría usado en algunas partes de este libro.
Prólogo
v

6. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
Autores

Jorge Luis Boria
Master of Engineering in Computer Science por Cornell University, Estados Unidos. Senior Advisor del
Modelo MPS. Evaluador Líder Experimentado MPS. SCAMPI Lead Appraiser para alta madurez. Instructor
certificado de los cursos del modelo CMMI. Fue Visiting Scientist del Software Engineer Institute de
Carnegie-Mellon University. Fue Professor Titular de las Universidades UBA, UNICEN, UNSL, USal, UB y
otras en Argentina. Es autor de otros dos libros relacionados con la industria del software.
Jorge quiere agradecerle particularmente a Joyce Statz por la formación que recibió trabajando para ella
en TeraQuest Metrics. Joyce fue a la vez amiga, formadora, orientadora y entrenadora.

Viviana Leonor Rubinstein
Licenciada en Computación Científica por la UBA. Certified Project Manager, UT-SQI. Evaluadora Líder
Experimentada MPS. SCAMPI Lead Appraiser DEV y SVC para alta madurez. Instructora certificada de los
cursos del modelo CMMI. Fue Profesora Titular en las Universidades UNS en Ushuaia, UBA, UNICEN y
otras en Argentina. Es autora de tres volúmenes para la enseñanza de computación en colegios
secundarios.
Viviana quiere agradecerle a Regina, su mamá, con la que compartió la escritura de su primer libro.

Andrés Oscar Rubinstein
Programador y Analista de Sistemas de la Pontifícia Universidade Católica do Rio de Janeiro. Evaluador
Líder Intermedio MPS. SCAMPI Lead Appraiser DEV y SVC. Sócio de TecnoVoz S.A. Argentina. Fue profesor
y auxiliar docente en la PUC-Rio y en la Universidad de Belgrano y el Colegio Nacional de Buenos Aires en
Argentina.
Andrés quiere agradecerle a Viviana y a Jorge por la confianza, a Adri y a los amigos de siempre por el
aguante, y a Male y a Nico por estar.
Finalmente, Jorge y Viviana quieren agradecer a Alma, Beto y Franca por darle un nuevo sentido a sus vidas. Y
Viviana y Andrés agradecen a Jorge por su liderazgo en la confección de este libro, sin el que tendría sido
imposible su realización.
vi
Prólogo

7. Boria et al.
PARTE I – Introducción
CAPÍTULO 1 - INTRODUCCIÓN
1.1 El propósito del libro
Este libro está dirigido a (en orden de interés creciente):
•
implementadores de mejora de procesos de software que quieran conocer mejor los métodos
ágiles para implantarlos en organizaciones de software;
• gerentes de proyecto interesados en conocer mejor los métodos ágiles para desarrollo de
software, sea para adoptarlos o para evaluar su adopción;
• ingenieros de software que intentan trabajar em un proyecto ágil;
• profesores de grado en Computación;
• estudiantes de grado en Computación;
• profesores de postgrado en Ingeniería de Software;
• estudiantes de postgrado en Ingeniería de Software.
En la medida en que los métodos ágiles y los modelos de madurez han sido considerados términos opuestos
en las disciplinas de desarrollo y mantenimiento de software, es difícil concebir un texto que busque alzar un
puente entre los dos mundos. Ya fue hecho, sin embargo, con gran suceso, en el moderno clásico [BOEHM &
TURNER, 2003]. El modelo de referencia para ellos es el CMMI, siendo fácil de imaginar la conversión para el MRMPS-SW, dada la intencional compatibilidad entre los dos.
1.2 Definición de método ágil para este libro
1
Este libro está principalmente enfocado en cuatro métodos ágiles : Kanban, Scrum, XP y FDD (Feature Driven
Development). Esta elección no es por azar. Esos cuatro métodos cubren la mayoría de las implementaciones
ágiles realizadas en el mundo. Además, cubren casi todas, sino todas, las necesidades de uso de métodos ágiles.
Cada uno de estos métodos será debidamente explicado en el capítulo 3, donde se los introduce al lector.
Obviamente, esto ocurrirá en orden creciente de complejidad: Primero el más sencillo y el que tiene el mayor
retorno de la inversión, Kanban. Kanban tiene alto retorno porque al organizar las tareas y detectar los problemas
rápidamente permite al equipo que lo utiliza aumentar el tiempo disponible para mejorar sus procesos e intentar
nuevas mejoras. Scrum, que frecuentemente es el método que se elige desde un principio, acá se ve sólo cuando la
empresa ha conseguido estabilizarse lo suficiente como para tener el tiempo de conseguir que las actividades de
Scrum puedan ser seguidas con la correspondiente disciplina. Las otras dos técnicas se suman a las ya vistas a
medida que la empresa gana en definición de sus procesos y en el número de su personal.
1.3 Si la mejora de procesos de software es la respuesta, ¿Cuál es la pregunta?
El principal enemigo de una empresa desarrolladora de software es la baja calidad. Hasta ahora, nadie tiene
una propuesta válida para mejorar la calidad, salvo la mejora de procesos, que pasa a ser entonces la cuestión
principal. Se puede argumentar que las personas y las herramientas (de software, como CASE) son importantes en
su impulso a la mejora de la productividad. Esto es cierto, pero solo cuando los procesos están en su lugar para
conseguir que se aprovechen las condiciones de los individuos y las herramientas de software. Es común el caso de
2
empresas y organizaciones que desaprovechan sus recursos humanos y tienen licencias que no se usan, por lo que
se deduce que si bien las herramientas y las capacidades de las personas son importantes, son los procesos los que
habilitan realmente el aumento de productividad.
En la Figura 1.1 simbolizamos esto con íconos. En la primera “ecuación” el personal capacitado sumado a
herramientas de software, sumado a procesos bien definidos culmina (después del signo de igualdad) en éxito y
1
2
Las principales referencias de cada uno de los métodos están indicados cuando se describe cada uno en los capítulos
siguientes.
En este libro utilizaremos en lo que sigue el término “organización” para referirnos a todo tipo de grupo humano organizado
para la realización de tareas con un propósito común, sea con o sin fines de lucro.
Capítulo 1
7

8. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
felicidad. En la segunda ecuación la falta de procesos bien definidos incrementa los riesgos y produce frecuentes
problemas en los productos resultantes.
Figura 1.1: Relación entre herramientas y competencia de personas
La disciplina que inducen los procesos es la que permite aprovechar los conocimientos y las herramientas. Sin
esta disciplina no es posible reproducir los éxitos que puedan haber alcanzado los proyectos, porque la memoria
organizacional se pierde.
1.4 El caso de estudio: La empresa Tahini-Tahini
En este libro seguimos el desarrollo de una organización que nace de una idea de estudiantes universitarios.
La empresa que crean es pequeña y por hacerse a sí mismos una broma, la han llamado Tahíni-Tahíni. El nombre
surgió cuando una de las fundadoras llegó a la reunión de creación un poco retrasada y al mirar el número de
personas alrededor de la mesa dijo, “Somos una empresa tiny-tiny”. Sus futuros socios encontraron eso gracioso y
le pusieron de nombre Tahíni-Tahíni, haciendo un doble juego de palabras. En el libro a menudo nos referiremos a
2
la misma con las siglas que sus socios usan para referirse a ella: T , T2 o la Doble T.
Como toda empresa recién nacida, creada por jóvenes emprendedores, no ha seguido un plan de crecimiento
ideal, más bien ha crecido a saltos, y los mares embravecidos que ha tenido que capear la han hecho más fuerte.
Los problemas de la empresa no son poco comunes, son los más frecuentes para una organización de ese tamaño y
con esa historia en cada etapa de su crecimiento. En cada paso los socios han debido tomar decisiones que afectan
los resultados, y en cada oportunidad lo han hecho alterando los procesos que gobiernan el desarrollo del
producto. En cada caso apuntaron a mejorar la calidad y el control de los procesos para mejorar la calidad y el
control sobre el producto.
Durante el desarrollo del caso de estudio utilizaremos la descripción de Kanban para el principio de un
proyecto de mejora de procesos; Scrum en relación a las actividades de gerencia de proyectos más comunes; XP
(Extreme Programming) para lo que constituye la categoría de las áreas de ingeniería de software tratadas en el
nivel D (Ampliamente Definido) del MR MPS SW. Cuando una empresa crece, los métodos anteriores comienzan a
mostrar limitaciones. La coordinación de muchos equipos en Scrum de Scrums presenta mayores limitaciones que
2
los métodos tradicionales. XP ya es difícil de controlar en proyectos medianos. Acompañando el crecimiento de T ,
la propuesta es una metodología conocida como Feature Driven Development (FDD). En torno de la cuestión del
cambio organizacional, seguiremos el camino de la metodología Lean, que se concentra principalmente en la
resolución de problemas a través de la mejora de procesos.
También en este capítulo describimos cada uno de los capítulos restantes. Cada capítulo que hace referencia
a un nivel del MR MPS SW explica los resultados requeridos de los procesos siguiendo las exigencias del modelo. El
libro se divide en cuatro partes, cada una atendiendo una necesidad diferente. En la primera parte (Capítulos 1 a 4)
se sientan las bases para que el lector pueda comprender los métodos y filosofía de trabajo que los autores
proponen. La segunda parte (Capítulos 5 y 6) atiende los temas de baja madurez (Niveles G y F del MPS) e
2
introduce en detalle los primeros dolores de crecimiento de T y la resolución encarada por los socios basada en el
uso de Kanban y Scrum. La tercera parte (Capítulos 7 a 9) desenvuelve la temática de Madurez Media, los niveles E,
D, y C del Modelo MPS, donde aparecen XP y más adelante FDD. Finalmente, la cuarta parte (Capítulos 10 y 11)
2
expone como la madurez definida de T le permite alcanzar un conocimiento profundo del funcionamiento de sus
2
procesos, caracterizándolos cuantitativamente. El libro se cierra con un resumen del viaje de T desde su creación
hasta su venta billonaria.
En el Capítulo 2 explicaremos nuestra filosofía de mejora de procesos. Para ello utilizaremos el método Lean,
palabra inglesa que significa delgado, porque es el que mejor se adapta a nuestras ideas. Adoptando mensajes de
diversas fuentes, explicaremos como es mejor hacer lo menos posible para resolver un problema que hacer
grandes cambios sin efecto aparente. También aprovecharemos el Capítulo 2 para hablar de una visión sistémica
8
Capítulo 1

9. Boria et al.
de las organizaciones y de la relación multicausal de los eventos. De este modo preparamos al lector para que
entienda porque una sola acción puede resolver muchos problemas y como a veces es necesario aplicar múltiples
acciones (y esperar) para obtener resultados. El libro de [POPPENDIECK et al., 2010], Leading Lean Software
Development, es nuestra guía por este territorio. También, donde es útil, citamos material del clásico de
[MEADOWS, 2008] Thinking in Systems, A Primer. Los dos libros revolucionan el pensamiento clásico, lineal, de los
gerentes tradicionales, y abren la puerta a una gerencia más ágil, más integrada y con más posibilidades de éxito.
En el Capítulo 3 introducimos los métodos ágiles propiamente dichos. Si bien Lean es un método ágil según
3
sus creadores y es reconocido como tal por la comunidad ágil , su uso exige mucho conocimiento y está más allá
de los objetivos de este libro. En cambio, las técnicas que proponen Kanban, Scrum, XP (Extreme Programming) y
Feature Driven Development (FDD) son del mismo modo exitosas y mucho más fáciles de adoptar, sobre todo si se
lo hace en el orden en que las proponemos en este libro. Esta es una introducción a los métodos y en ningún
momento pretende remplazar la lectura de los textos clásicos del tema, que se citan en la bibliografía y que
recomendamos fuertemente al lector.
El Capítulo 4 se dedica al eje central de este libro, el modelo de Mejoría de Procesos de Software (MPS). Otra
vez, el libro es incapaz de contener todo el conocimiento necesario para hacer buen uso del modelo, de modo que
referimos al lector a las guías que Softex ha publicado y que se encuentran accesibles en el sitio web de esa
4
organización . Las guías son un material indispensable para el lector que pretenda seguir nuestras sugerencias e
implementar siguiendo el MPS. Lo que sí exploraremos en detalle son las grandes pinceladas que es necesario
comprender para que el modelo tenga sentido y no se pierda en los detalles que, necesariamente, hay que aplicar.
Discurriremos sobre la evolución de la cultura imperante en la empresa que fuera inducida por la maduración de
los procesos, manifiesta en el cambio de los niveles de madurez del modelo, concepto en el que nos detendremos
en este capítulo, así como en la arquitectura del modelo que permite encontrar en él las herramientas para su
implementación. Para concluir el capítulo explicamos el concepto de evaluación y como una organización puede
aplicarlo a sí misma, para entender dónde se encuentra y qué camino le falta recorrer.
2
El Capítulo 5 introduce en detalle los problemas iniciales de T . Utilizando ejemplos que han encontrado en su
actividad como consultores y evaluadores de procesos, los autores introducen al lector a los problemas típicos de
una empresa que funciona bien cuando todas las cosas están en su cauce. Los pequeños problemas cotidianos (un
embarazo, una zona sin recepción telefónica, un cliente apurado) pueden desencadenar una “tormenta perfecta”
2
que arruine la mejor reputación. Es ahí cuando los amigos de T deciden introducir métodos de control y
aconsejados correctamente comienzan a utilizar Kanban. Al mismo tiempo consiguen implantar, sin demasiado
esfuerzo extra, procesos del modelo MPS. Tentados por la facilidad con que implementaron los procesos del Nivel
G, los socios deciden realizar una evaluación formal con un evaluador líder y pasan con éxito. La adopción del MPS
2
por la empresa T es ahora un hecho.
En el Capítulo 6 los autores cuentan como los socios, alentados por el éxito obtenido por sus mejoras de
proceso, deciden profundizar el camino y utilizan el modelo MPS para hacerlo. Los controles establecidos hacen
lugar a la gerencia de configuración, que en germen ya comenzaran a implementar en el nivel G; la medición, que
la formación profesional de los socios hace que sea considerada una actividad fundamental para controlar y dirigir
la empresa; y el control de la calidad, impuesto por la realidad.
La llegada de nuevos clientes con pedidos de proyectos que son a veces de adaptación, a veces nuevos
desarrollos, hace que los procesos de la gerencia de portafolio de proyectos les resulten valiosos para entender
cómo organizar el crecimiento de la demanda. Este crecimiento les lleva a plantearse uno de dos caminos: crecer
internamente, lo que significaría ampliar el espacio físico para admitir más desarrolladores, con la consecuente
inversión fija; o subcontratar parte del trabajo. Para tomar la decisión, los socios se apoyan en los procesos de
adquisición y deciden a favor, lo que les lleva a implementarlos. Aun así, su pequeño equipo inicial debe dividirse
para atender el nuevo volumen de trabajo, e incorporan un número pequeño de desarrolladores. Para organizar
los proyectos, los socios deciden utilizar prácticas de Scrum, que les resultan compatibles con el MPS. Para
2
demostrárselo a sí mismos, la T pasa por una nueva evaluación y alcanza el Nivel F.
En el Capítulo 7 comienza la tercera parte, que desarrolla los procesos intermedios del modelo MPS. A
medida que se expanden los negocios y se abren nuevas oportunidades, los socios se ven obligados a expandir
3
4
La comunidad ágil se reconoce en el sitio web: http://www.agilemanifesto.org/
http://www.softex.br/mpsbr/_guias/default.asp
Capítulo 1
9

10. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
2
asimismo sus oficinas. Una reunión fundamental los pone en la encrucijada: ¿A dónde queremos llevar a T ?
Finalmente se resuelve crear una visión ambiciosa: Ser una de las diez mejores fábricas de software del mundo.
Preparándose para el crecimiento, los socios entienden que su visión se completa con una base de conocimientos
que puedan ser compartidos, usados y expandidos por todos los ingenieros y demás empleados de su empresa.
Sus procesos de gestión evolucionan asimismo para aprovecharse de este conocimiento de manera sistemática. De
manera normal surge en la base de conocimientos la definición de los procesos organizacionales.
Cuando los empleados superan un número considerado crítico de manera arbitraria, las reuniones de proceso
se sistematizan y se formalizan en un proyecto para su evaluación y mejoría permanente. Las constantes
incorporaciones fuerzan asimismo a organizar la identificación, captación, preparación y retención de los recursos
humanos. En todas estas tareas el MPS les resulta fundamental e indispensable, al darles un marco coherente y las
pautas culturales para crecer. El resultado es una organización que aprende, con empleados motivados que
continuamente hacen propuestas de mejora de sus propios procesos y los ajenos. Una iniciativa brillante resulta de
2
una de estas propuestas, y T incorpora prácticas de reuso para mejorar todavía más la calidad de sus productos y
el rendimiento de su personal.
En el segundo Capítulo de la tercera parte, el Capítulo 8, introducimos las técnicas y prácticas de Extreme
Programming (XP) que no se superponen con las anteriores ya incorporadas. Una discusión en una retrospectiva
lleva a identificar la variación en la interpretación de las técnicas de desarrollo en los equipos como la fuente de
diferencias entre las estimaciones iniciales, ahora desarrolladas a partir de la historia, y los resultados reales.
Discutiendo en la reunión del grupo de procesos organizacionales se vincula asimismo a esa indefinición con un
grupo de defectos que están saliendo repetidamente al mercado. Una propuesta de adoptar XP es recibida
tibiamente, pero de todos modos se la implementa, cuidando de que al hacerlo se respeten las condiciones para
seguir cumpliendo con la implementación de procesos de MPS. Esto lleva a algunas variantes, como por ejemplo
que pair programming, la técnica por la cual dos programadores trabajan juntos en un mismo programa, sea
implementada con un coach que registra los defectos encontrados para permitir realizar análisis de los mismos.
Los equipos incorporan asimismo software de control e introducen variantes a los procesos para continuar
avanzando y seguir dentro del marco del MPS.
Enfrentados con la realidad de su crecimiento y los riesgos que trae, los socios incorporan una visión
estratégica de su negocio y una vez más lo hacen siguiendo el modelo. En el Capítulo 9 se introduce la visión del
2
riesgo como constante. La T no se define a sí misma como una empresa que quiere evitar los riesgos, sino
conocerlos y enfrentarlos. De ese modo es capaz de prepararse mejor para afrontar lo que la realidad les coloque
en su camino. Los riesgos así analizados son mejor enfrentados y la capacidad desarrollada de mejora de procesos
es, en eso, una herramienta. Por ejemplo, en vez de aprovechar oportunistamente el reuso cuando aparece una
2
necesidad que puede reusar partes ya existentes en los proyectos concluidos, la T organiza una fábrica de
componentes que se pueden articular rápidamente para formar productos, reduciendo aún más sus defectos por
parte y aumentando a niveles muy altos su productividad. Cada decisión tiene un costo y un beneficio, pero hasta
2
este momento en la historia de la T no se aprendía sistemáticamente de las decisiones ya tomadas. Para evitar
2
que ese conocimiento se pierda, la T incorpora métodos de decisión formales que incluyen varias técnicas que
aprovechan la historia. Pronto los proyectos las usan para tomar decisiones sobre la velocidad, la calidad esperada,
2
el reuso y la subcontratación a terceros. La T es ya una organización con centenares de empleados y una sólida
reputación de calidad. Los llamados por referencias empiezan a ser internacionales. Debido a ese crecimiento y el
2
consecuente alejamiento físico de los clientes, la T añadió a su arsenal el método FDD, que le permite planificar
2
con mayor precisión los sprints. La T decide ser evaluada respecto al Nivel C del modelo MPS y a su vez, en una
evaluación conjunta, respecto al Nivel Definido del modelo CMMI-DEV, cosa que logra con singular éxito.
2
Al ingresar en la Cuarta Parte del libro, encontramos a T en su apogeo. Ha abierto oficinas en varios países
centrales, tiene centros de desarrollo en todas las regiones de Brasil y de Latinoamérica, y disfruta de un bien
ganado prestigio. Sin embargo, los socios no descansan en sus laureles. En el Capítulo 10 vemos cómo se
aprovechan de la base de datos históricos que han amasado a lo largo de los años para utilizarlos en su favor.
Identifican los procesos críticos que se relacionan con sus objetivos de negocio, analizan su estabilidad relativa,
construyen modelos que permiten prever resultados futuros en puntos tempranos de un proyecto y ayudar a
corregir problemas. Extienden las técnicas que emplean en la toma de decisiones para incluir factores cuantitativos
y mejoran sus análisis de causa raíz para que se considere el costo beneficio de las posibles alternativas. La
gerencia de proyectos pasa de ser un arte con partes de ingeniería a ser una ciencia con partes de arte.
El Capítulo 11 cierra el libro con los socios discutiendo sobre la compra de dos líneas de negocios por una
mega empresa. Para que su historia no sea un caso único, el capítulo hace la contabilidad de los factores que
10
Capítulo 1

11. Boria et al.
permitieron su éxito. Revisa entonces Lean, Kanban, Scrum, FDD y XP. También, y muy fundamentalmente, el rol
del MPS como la herramienta de desarrollo organizacional que le permitió realizar este crecimiento en tiempo
récord y con mínimos inconvenientes.
Capítulo 1
11

12. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
CAPÍTULO 2 - EL MÉTODO DE MEJORA CONTINUA
2.1 Mejora de procesos
Si estamos de acuerdo con la literatura existente y la experiencia personal de los autores, la mejora de
procesos es la herramienta que permite a las organizaciones entenderse a sí mismas profundamente, yendo de un
conocimiento intuitivo a uno cuantitativo, pasando por etapas intermedias que sirven tanto para mejorar los
resultados como para apoyar los pasos siguientes. Una anécdota sirve para hacer clara la diferencia entre seguir
procesos acordados por las partes y no seguirlos. Los procesos acordados por las partes cambian cuando las partes
así lo deciden, mientras que no seguir procesos implica que no hay un patrón reconocible que ha sido pactado por
los interesados.
En una organización desarrolladora de software, Pedro, uno de los mejores programadores, era un ferviente
defensor de los procesos. Rápidamente convenció a sus colegas de equipo de trabajo para que adoptaran procesos
en la construcción de diversos documentos y, sobre todo, para definir la secuencia de pases y el criterio de
finalización, basado en la calidad objetiva, de cada producto. Los proyectos en los que Pedro participaba eran
exitosos con más frecuencia que todos los demás, y los clientes de los mismos elogiaban el producto generado.
Finalmente las diferencias llegaron a los oídos de la dirección y nuestro joven programador fue recibiendo
sucesivas promociones a cargos de cada vez mayor responsabilidad. No había pasado mucho tiempo cuando
finalmente lo promovieron a jefe técnico de desarrollo. Convocó a sus hasta entonces colegas y les hizo ver que su
promoción obedecía al reconocimiento que la alta gerencia hacía del trabajo que seguía procesos, por lo que
esperaba que todos colaboraran con él para ampliar su utilización y contribuir a su mejora. Hubo muchas cabezas
que asintieron y tras algunas preguntas y respuestas la reunión se dio por concluida. Solo Pablo, un programador,
que hasta la llegada nuestro héroe era considerado el programador “estrella”, se quedó atrás.
-
“Pedro”, le dijo. “Yo estoy contento por tu nombramiento, pero tú sabes bien que yo no sigo procesos
ajenos y siento que intentar que los demás entiendan mis procesos es una pérdida de tiempo, porque me
sirven a mí y solo a mí. Espero que no lo tomes a mal, pero pienso seguir haciendo lo que hice siempre”.
-
“No esperaba otra cosa”, dijo Pedro.
-
“Qué suerte que lo tomes así, me da gusto”, contestó Pablo.
Satisfecho, tomó sus notas y encaró para la puerta del salón. Pedro lo dejó alcanzar la puerta y lo detuvo:
-
“Eso sí, no fracases. Nunca fracases. Los que siguen procesos pueden tener problemas, porque los
problemas nos enseñan qué partes del proceso hay que cambiar. Pero si tú no sigues procesos, los
fracasos no nos enseñan nada y tú cargarás con toda la responsabilidad. Espero que no lo tomes a mal,
pero es así como pienso seguir haciendo lo que hice siempre”.
Los procesos que se siguen nos permiten identificar defectos tempranamente y detectar su origen. En cierto
sentido, seguir un proceso es como comprar una póliza de seguros: uno no quiere que le pase nada de malo, pero
invierte un poco para el caso en que algo malo ocurra. Lo mismo es con los procesos: Si todos tuviéramos memoria
perfecta, no cometiéramos nunca errores y las especificaciones en lenguaje natural tuvieran un significado único e
inamovible, entonces se relativizaría mucho la necesidad de seguir procesos. Todavía resultarían útiles para
coordinar el trabajo, pero para personas con memoria total se podrían hacer procesos sumamente cortos. La
realidad es bien otra: Los seres humanos erramos, olvidamos y malinterpretamos las comunicaciones en lenguaje
natural. En consecuencia, la única manera de aprender como organización es capturar nuestros procesos para
entender su funcionamiento (datos del proceso) y la calidad de los productos que generan.
No todos los procesos son iguales. Hay procesos administrativos que no nos ocupan en este libro. Hay
procesos extra-organización que tampoco nos interesan. Los procesos que queremos resaltar y mejorar son
aquellos procesos vinculados con el desarrollo de software en las organizaciones. Aun así, es posible obtener más
detalle de lo que plantearemos en este libro en otras fuentes. Los autores nos limitaremos a exhibir el
comportamiento mínimo para organizar proyectos que produzcan sistemas de software de buena calidad.
Las organizaciones que entienden sus procesos y les sacan provecho se dicen ‘maduras’. Una organización
madura persigue sus objetivos con uso de ese conocimiento. Sabe lo que sus equipos son capaces de alcanzar y no
hace promesas que no puede cumplir. Los equipos usan el conocimiento para adentrarse en el desarrollo con
confianza en sus fuerzas y su capacidad de cumplir con sus compromisos. Las organizaciones inmaduras,
entretanto, a veces cumplen con sus compromisos, pero muchas veces no. No conocen su capacidad y hacen
promesas que nacen de su deseo de ganar el cliente. Lo que propondremos en este libro es un camino para llegar a
12
Capítulo 2

13. Boria et al.
la excelencia madurando como organización usando métodos ágiles, para lo cual usaremos un caso de ejemplo y
un modelo.
Es el modelo MPS, en nuestro caso, aquél que orienta la secuencia de acciones en lo que hace al crecimiento
de la madurez organizacional. El modelo MPS, que explicaremos con más detalle en el capítulo 4, es un modelo de
desarrollo organizacional por niveles, que define los procesos que la organización debe implementar en su seno y
los resultados esperados de ese accionar, para ir avanzando de nivel a nivel. Aun cuando es la intención de todos
seguir el modelo, es imposible implementar todos los cientos de procesos a la vez, inclusive si nos restringimos a
tomar los niveles de a uno, cosa por otra parte muy saludable, porque los hábitos que se construyen en uno se
aplican en el que le sigue.
Hay necesidad, por lo tanto, de encontrar un método que nos ayude a organizar el crecimiento en términos
más concretos de lo que hace el MPS, y que a su vez se compadezca de las necesidades de la organización en
cuánto a sus negocios. Como se puede imaginar el lector, no hay una única manera de hacer esto. Por ello, hemos
decidido anticipar la presentación de un proceso del MPS, no en detalle, pero si mostrando su uso. Tomando
prestadas técnicas del MPS en su proceso Gerencia de Desiciones (GDE), comenzaremos por definir el problema
que intentamos resolver.
Problema: Si bien en un marco ‘macro’ los niveles del MPS alcanzan para definir las pautas de la mejora
continua, en cada caso es necesario atender a las necesidades de la organización que pretende mejorar sus
5
procesos, teniendo en cuenta el ‘negocio’ de la misma.
Atributos deseables de una Solución: La solución debe de proveer un mecanismo de mejora continua que
permita identificar cada paso sucesivo de un programa de mejora y este debe tener suficiente detalle como para
que sea posible ejecutarlo sin demasiada ambigüedad, pero no tanto que implique una planificación detallada para
cada selección (DETALLE). Debe proveer un marco teórico reconocible que ayude a medir el impacto de las
decisiones sobre el sistema en conjunto, no solo la optimización local (MARCO). Debe permitir deducir las acciones
derivadas que optimicen el sistema (SISTEMA). Debe retroalimentar el mecanismo que permita introducir mejoras
a buen ritmo, sin que interfieran con el trabajo ni con el desarrollo personal de los empleados (NEGOCIOS). Estos
atributos deseables constituyen los criterios bajo los cuales evaluaremos las alternativas de solución. El orden de
su importancia relativa se muestra en la siguiente tabla:
atributos
peso
NEGOCIO
5
DETALLE
4
SISTEMA
3
MARCO
2
suma
Tabla 2.1: Selección del Método de Mejora de Procesos
Alternativas de Solución: La literatura tiene muchos ejemplos de estos métodos. Los siguientes fueron
incluidos en nuestro conjunto de soluciones: Plan-Do-Check-Act [SHEWHART, 1939], IDEAL [McFEELEY, 1996],
Focus-Improve-Sustain-Honor [ARTHUR, 2004], y Lean Simplified [ARTHUR, 2006].
Método de Evaluación: Utilizaremos una matriz de Pugh [PUGH, 1991] para evaluar alternativas cuando los
atributos son múltiples. Usado por Pugh en General Motors y descripto por él en su libro ya citado y previamente
en un artículo [PUGH, 1981], es uno de los métodos de análisis de alternativas más difundidos entre ingenieros.
Cada columna representa una solución y cada fila un atributo. Cada fila tiene un peso específico que representa el
valor relativo de ese atributo frente a los otros. En cada intersección fila/columna se evalúa el aporte que la
solución de esa columna hace al criterio de esa fila. Previamente se ha establecido un mecanismo de evaluación
que permite ajustar la objetividad al respecto de la medición de cada atributo.
5
La referencia a un negocio está entre comillas porque se trata de los motivos de existencia de la organización. Si esa
organización es un hospital público que mide su impacto en la comunidad en la cantidad de curaciones que realiza o el
estado general de salud de la población que atiende, entonces a esos efectos ese es su ‘negocio’. No se debe entender
como que solo aplica a organizaciones con fines de lucro.
Capítulo 2
13

14. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
Criterios de Evaluación por Atributo: DETALLE es medible como 3 (detalle adecuado), 2 (detalle un poco
excesivo o no suficiente), 1 (detalle bastante excesivo, algo así como treinta páginas para entenderlo, o muy
superficial, algo que permite muchas interpretaciones) o 0 (no tiene ninguna explicación clara asociada). MARCO
se mide como 3 (se reconoce en el sistema qué otras cosas hay que atender), 2 (no se analiza el sistema de manera
total, pero es bastante comprehensivo), 1 (hay algunas pistas para analizar acciones derivadas) o 0 (no se apoya
para nada al cambio sistémico. SISTEMA se mide como 3 (las acciones derivadas que impactan al sistemas se
reconocen mediante el método), 2 (hay una visión periférica pero el foco de las acciones es idéntico al foco de la
mejora), 1 (se evalúan resultados globales a nivel sistema aunque no se los prevea en el análisis de impacto), o 0
(ninguna actividad relacionada con el efecto global forma parte del método). NEGOCIOS se mide como 3 (cuando
se enfoca sobre todo en las necesidades del cliente como punto de partida), 2 (hay un alineamiento con el negocio
pero es externo al método), 1 (se puede alinear al negocio pero el método es agnóstico y no lo menciona) o 0 (no
hay ninguna relación evidente entre el método y el negocio).
Describiremos ahora las cuatro opciones, tratando de que el lector mismo pueda juzgar la calificación de cada
una con respecto a cada atributo.
2.2 Plan-Do-Check-Act
Plan-Do-Check-Act (PDCA) es original de [SHEWHART, 1939], y difundido sobre todo por Deming en varias
6
ocasiones . Deming se refería a este procedimiento basado en el método científico como el ‘Ciclo de Shewhart’. La
posteridad lo recuerda a menudo como el ‘Ciclo de Deming’, una de las consecuencias de la notoriedad de este
que es todavía mayor que la de aquél. Hacia el final de su vida Deming cambió el “Check” (validar) por “Study”
(estudiar) para enfatizar que el paso debe ser de análisis más que de inspección.
Puede justificadamente considerarse a Shewhart como el padre de la calidad industrial. Fue él quien
introdujo los diagramas de control estadístico para el análisis de la estabilidad de un proceso a través de la
medición de un atributo. Dada su fecha de origen, es difícil encontrar el material original, pero en la mayoría de las
7
citas el primer paso es identificar el problema y luego analizarlo. No hay una mención explícita de los objetivos de
negocios, aunque es difícil imaginar que Shewhart los haya eludido, leyendo sus otros materiales. Posiblemente se
ha sacado (una vez más) del contexto al método y al hacerlo se perdió parte de su valor sistémico. Por lo tanto, sin
juzgar al método en sí pero si juzgando su uso habitual, podemos decir que PDCA es sencillo, fácil de aplicar pero
es factible de ser usado sin tener en cuenta el impacto en el negocio. Hay en varias versiones del método
referencias a un proceso desarrollado por Deming para la mejora continua, lo que daría una mejor versión
sistémica del mismo, así como un posible vínculo con los objetivos de negocios. A continuación describimos los
pasos de PDCA.
PLAN (Planificar) Paso 1: Identificar el Problema. Actividades: Seleccionar el problema a ser analizado; definir
claramente el problema y redactar un enunciado preciso del mismo; fijar un objetivo medible para el esfuerzo de
resolución del problema; establecer un proceso para la coordinación con, y conseguir la aprobación de, la alta
dirección.
PLAN (Planificar) Paso 2: Analizar el Problema. Actividades: Identificar los procesos que impactan en el
problema y elegir uno; listar los pasos del proceso tal como se ejecutan en este momento; construir un mapa del
proceso; validar el mapa del proceso; identificar posibles causas del problema; juntar y analizar datos relacionados
con el problema; verificar o revisar el enunciado original del problema; identificar las causas raíces del problema;
juntar datos adicionales si es necesario para verificar las causas raíces
DO (Hacer) Paso 3: Desarrollar Soluciones. Actividades: Establecer criterios para elegir una solución; generar
soluciones potenciales que ataquen las causas raíces del problema; elegir una solución; conseguir aprobación y
soporte para la solución escogida; planificar la solución.
DO (Hacer) Paso 4: Implementar la Solución. Actividades: Implementar la solución escogida en un piloto o
ensayo. Si el proceso PDCA está siendo utilizado dentro del Proceso de Mejora Continua, pasar al Paso 6 de ese
proceso. Si se lo está utilizando por separado, continuar con el Paso 5.
CHECK (Verificar) Paso 5: Evaluar los Resultados. Actividades: Juntar datos de la solución; analizar los datos.
¿Se alcanzó el objetivo buscado? Si es así, pasar al Paso 6. Si no es así, volver al Paso 1.
6
7
El libro [SHEWHART W., 1939] fue compilado por Deming con un prefacio de su autoría.
Véase por ejemplo http://quality.enr.state.nc.us/tools/pdca.htm
14
Capítulo 2

15. Boria et al.
ACT (Actuar) Paso 6: Estandarizar la Solución (y Capitalizar Nuevas Oportunidades). Actividades: Identificar
cambios sistémicos y necesidades de entrenamiento necesarias para un implementación completa; adoptar la
solución; planificar y monitorear permanentemente la solución; continuar buscando oportunidades incrementales
para refinar la solución; buscar nuevas oportunidades de mejora.
El método PDCA es sólido, pero su edad ha hecho que varios de los detalles que su autor predicaba hayan
sido dejados de lado en su implementación corriente, que es lo que un buen evaluador juzga: Su uso por encima
de su definición. Eso no quita que para el lector avisado los pasos de PDCA no sigan teniendo utilidad. De hecho,
como veremos en lo que sigue, el ciclo de Shewhart sigue siendo utilizado en diferentes variantes. Tampoco es
frecuente que los usuarios de PDCA lo coloquen en el marco adecuado, simplemente es utilizado como un ciclo
cuya repetición produce los resultados esperados. Recordemos que para Shewhart, y en consecuencia para
Deming, hay un proceso de mejora continua en el que PDCA encaja. De otra manera se pierde parte de su impacto.
Es en ese proceso marco que varias de las iniciativas sistémicas y el vínculo con los objetivos de negocios están
inmersos, de modo que cambiar ese proceso como fuera definido y colocar otro en su lugar puede tener como
consecuencia la pérdida de ese entorno y en consecuencia la desmejora del proceso de mejora. Veamos ahora
como McFeeley lidia con ese problema, incorporando a su método el detalle necesario (en exceso, según nuestro
punto de vista).
2.3 El Método IDEAL
Debido a la enorme influencia que Deming, y en consecuencia Shewhart, a quién aquél citaba
constantemente, tienen sobre la comunidad de mejora de procesos, este método y los que describiremos más
tarde están fuertemente influenciados por PDCA. La Figura 2.1 muestra una descripción gráfica del método IDEAL.
Tiene cinco fases que se corresponden con etapas importantes de una iniciativa de mejora de procesos. Puesto
que la mejora es continua, se espera que se continúe el ciclo una vez alcanzada la 5ª fase. Si bien el autor de IDEAL
[McFEELEY, 1996] aclara que los límites entre fases son más borrosos que los que se describe en la referencia, es
usual que las recomendaciones de éste no se sigan y se ejecute como una secuencia de actividades en un proyecto,
así como otras desviaciones de alto impacto.
Figura 2.1: El Método IDEAL [McFEELEY, 1996]
La primera fase se denomina, con lógica, ‘Initiating,’ que traducido quiere decir Comenzando. Tiene tres
bloques, pero en la descripción detallada no se las considera, siendo descriptas en cambio 10 tareas que se
detallan, algunas hasta el nivel de subtareas. La misma situación de desacople entre la gráfica y la descripción
textual se repite para todas las fases. La fase ‘Initiating’ culmina cuando la infraestructura para la mejora de
procesos se ha construido, se han vinculado los objetivos de negocios al programa de mejoras de proceso, hay un
sistema de recompensas alineado con las mejoras y un plan inicial para el proyecto de mejoras, que contiene el
plan de comunicación de los avances.
La fase que sigue se denomina ‘Diagnosing’ y tiene seis tareas. Se traduce fácilmente, dada la similitud de los
vocablos, por Diagnosticando. En efecto, es la fase en la que se realiza el análisis de la brecha existente entre las
Capítulo 2
15

16. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
necesidades de proceso y los procesos en uso, tal como se usan. El criterio de entrada de la fase no coincide
totalmente con el criterio de salida de la primera fase, por lo que es difícil entender como se consigue llegar a su
ejecución. La fase tiene como criterio de finalización que se hayan entregado las brechas halladas y las
recomendaciones al comité de gestión y hayan sido aceptado, así como que ya haya un boceto del plan estratégico
de acción.
La tercera fase de IDEAL se denomina ‘Establishing’, que quiere decir Estableciendo, pero se refiere acá al
plan y no a los procesos. Si bien es confuso, da una linda sigla (IDEAL) que un nombre más lógico (Planificar, o
Detallar) no conformaría. En esta fase se ajustan prioridades y se forman los equipos que llevarán adelante la
definición y difusión de los cambios y mejoras a los procesos. Notablemente, el método recomienda que la
planificación la realice el comité de gestión, es decir los gerentes que realizan la supervisión estratégica del plan de
mejoras, y no el grupo de procesos. Este excelente consejo es ignorado en la práctica. La fase tiene 14 actividades.
El criterio de finalización es que el plan estratégico se haya completado y aprobado, y que la visión organizacional,
el plan de negocios y el plan estratégico de mejora de procesos tengan sinergia entre sí.
La fase que sigue se denomina ‘Acting,’ que se traduce por Actuando. Esta fase es la más interesante, aunque
el modelo tiene muchas componentes útiles, porque ésta enfoca muy directamente en el negocio. Es cuando las
mejoras se identifican, construyen, despliegan y se ponen práctica. Tiene diez pasos, de los cuales destacaremos
una subtarea del paso 2, Desarrollar Soluciones: Analizar y Arreglar el Problema. Nos interesa porque en muchas
formas anticipa y se parece a Lean, en que el planteamiento es puramente enfocado en el dolor y no en la mejora
de procesos en sí. Se modifican procesos porque los procesos actuales toleran defectos y demoras que no se
deben tolerar, se ataca sus causas, pero se enfoca en los síntomas. Esta fase tiene como criterio de éxito que la
estrategia de despliegue y el plan se han ejecutado plenamente, o están en camino de serlo. Las soluciones que se
han adoptado (o piloteado) se han documentado correctamente y están bajo control del grupo de procesos, y se
tiene claro cómo se las va a mantener. La mejora de procesos ha comenzado a estar institucionalizada en la
organización. Esta fase hace referencia a muchas pequeñas mejoras realizadas en paralelo, bajo un único plan
estratégico y múltiples planes tácticos. Sin embargo, la gran mayoría de las implementaciones de IDEAL adolecen
del mismo defecto: Un enorme plan táctico que nunca termina de ejecutarse y que sufre del síndrome del correo:
las cartas (pedidos de nuevos cambios) siguen llegando y la tarea de planificar nunca se concluye.
La fase final, o si se quiere la que inicia una nueva iteración del ciclo IDEAL, se denomina ‘Leveraging’, que
significa Aprovechando, o Sacando Provecho, en realidad es la variante de la primera fase, puesto que tendría poco
sentido empezar de nuevo sin tener en cuenta lo que ya se avanzó. Se denomina así porque ante la alta gerencia
se afirma el auspicio mediante la muestra del avance. Cuando las organizaciones caen en los errores que
marcamos antes, el resultado es que el proyecto de mejoras tiene poco que mostrar. El ejemplo más común es que
se definen soluciones pero no se las implementa ni en pilotos, lo que se justifica por el síndrome del correo: ya que
se han aceptado nuevos pedidos de cambio, el grupo de mejoras se enfocará en la definición de soluciones y no en
su implementación. Como consecuencia una larga lista de cambios es lanzada simultáneamente sin suficiente
preparación, por la demanda de capacitación que eso conlleva, y el proyecto fracasa. IDEAL no es un mal método,
pero es muy detallado (se describe en un documento de 236 páginas) lo que hace que mucha gente lo haya
8
implementado sin haber leído esos detalles con la consiguiente pérdida de varios elementos fundamentales,
9
como el vínculo con los objetivos de negocios, el paralelismo en la implementación y la visión sistémica
(multicausal, con lazos de retroalimentación y demoras entre causa y efecto visible) que son indispensables para
establecer un programa de mejora continua.
Lo mejor de IDEAL es su visión de la mejora de procesos (Figura 2.2) basada en los objetivos de la
organización y soportada en la visibilidad del proyecto, la comunicación horizontal y vertical entre las partes, la
captura, retención y aprovechamiento de la experiencia (lecciones aprendidas), y una red de soporte de todo el
proyecto. De ese modo se sostiene el plan táctico y el estratégico para culminarlos con éxito.
8
9
Si el lector no se siente cómodo con la afirmación de que un número muy grande de personas no lee los detalles antes de
implementar un modelo, los autores querrían remitirlo al trabajo de Royce, Managing the Development of Large
Software Systems [ROYCE, W., 1970], a quién se considera el padre del ciclo de vida en cascada por ese mismo artículo, y
que lamentablemente está mal citado: Lo que Royce dice en ese trabajo es que esa visión del proceso de desarrollo es
infantil y llena de problemas.
Los usuarios de IDEAL tienden a desarrollar un proyecto secuencial con muchas iniciativas que demoran la fase de aplicación,
una de las maneras de resistir el cambio.
16
Capítulo 2

17. Boria et al.
Figura 2.2: Visión de Mejora de Procesos de IDEAL [McFEELEY, 1996]
2.4 Focus-Improve-Sustain-Honor
Focus-Improve-Sustain-Honor (FISH) de [ARTHUR, 2004] es una variante más de PDCA, con énfasis en las
10.
herramientas de Six-Sigma El ciclo de Arthur se basa en la medición. El uso de los datos disponibles y la
búsqueda tipo “inteligencia de negocios” es el fundamento del análisis, en vez de los defectos o la brecha respecto
de algún ideal. Esto por supuesto no está contra los preceptos de PDCA, pero si influye mucho en el impacto que
tiene cada uno, porque en FISH es indispensable comenzar por el análisis de los datos antes de entrar en el ciclo.
El ciclo tiene cuatro fases, Focus, enfocar, la primera, está basado en un hecho estadísticamente demostrable
por la distribución de los defectos: Unos pocos procesos son responsables de la mayoría de los mismos. Encontrar
esas “fábricas de defectos” enfoca el proceso de mejora en donde más rendimiento tiene. Para Arthur, la
11
aplicación de la ley de Pareto predice grandes ganancias. Su razonamiento es que si el 80% de los defectos son
producidos por el 20% de los procesos, volviendo a aplicar la regla se tiene que el 64% (80% del 80%) de los
defectos proviene del 4% (20% del 20%) de los procesos. De ese modo un minúsculo grupo de procesos permite
eliminar un número sumamente grande de defectos, de donde enfocar es necesario.
La segunda fase, Improve, mejorar, es donde el defecto encontrado se elimina. Esta es la fase donde se
identifican las causas profundas, se eligen las soluciones posibles y se define y lleva adelante su implementación. El
MPS (ver el Capítulo 4) contiene resultados esperados de procesos que ayudan a entender la implementación de
los pasos de mejora por identificación de las causas raíces. Utilizaremos a lo largo del libro esta capacidad de
12
identificar las causas de las cosas para poder mejorarlas o difundirlas . Utilizar el análisis de causa raíz de forma
sistemática es una de las herramientas más poderosas de la mejora de proceso, y una de las tres herramientas
intelectuales (junto con el análisis y gestión de riesgos y la visión sistémica del proceso) que más rendimiento
tienen en los procesos intelectuales que acompañan, o deben acompañar, a la mejora de procesos.
La tercera fase, Sustain, sostener, es donde la mejora se intenta consolidar y mantener, para lo cual Arthur
propone utilizar herramientas de “conocimiento profundo” como fueran introducidas por Shewhart y difundidas
por Deming. Para comenzar, Arthur indica desarrollar el mapa del proceso, utilizando siempre herramientas
10
11
12
Six Sigma es una estrategia de gestión originada en Motorola en 1986 SPC and TQM in Manufacturing and Services
[TENNANT, G., 2001] y usada mundialmente. Trata de mejorar la calidad de los resultados de los procesos identificando y
eliminando las causas de los defectos. Utiliza una variedad de métodos, fundamentalmente estadísticos. El término surgió
del análisis estadístico de la ocurrencia de defectos en manufactura. La madurez de un proceso de fabricación puede
expresarse como la cantidad de desvíos estándar () que se aleja de la media de la población total, o por el porcentaje de
piezas sin defectos que produce. Un proceso seis  es uno que produce 99.99966% de las piezas sin defectos, que fue el
objetivo fijado por Motorola y que dio nombre a los métodos que se conjuntaron en un proceso para alcanzarlo.
Pareto fue un estadígrafo francés del siglo XX que se destacó en el estudio de la distribución de la renta. En 1906 él hizo la
famosa observación de que el veinte por ciento de la población poseía el ochenta por ciento de la propiedad en Italia,
posteriormente generalizada por Joseph M. Juran en el principio de Pareto (también conocida como la regla del 80-20).
Si el evento es un problema o un defecto, intentaremos ubicar su origen para desterrarlo, pero si el evento es un resultado
positivo no planificado, intentaremos entender qué lo provocó para reproducirlo en otros ambientes.
Capítulo 2
17

18. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
simples. En todos los casos, Arthur se inclina por la simplicidad, dedicándole tiempo al proceso intelectual y
utilizando la herramienta que mejor se adapta al menor costo de aprendizaje posible. Por ejemplo, en este caso
13
sugiere utilizar un diagrama de flujo, siendo que hay otras herramientas posibles que son más poderosas e
igualmente difundidas.
Para poder afirmar que los resultados se han alcanzado es necesario saber que el proceso está normalizado,
porque si no es así es imposible establecer comparaciones. Supongamos que el problema es que una receta
culinaria viene dando resultados desparejos. Al analizar la causa profunda nos damos cuenta que diferentes
cocineros le dan diferente interpretación a las instrucciones y que algunos pasos están faltando, porque el autor de
la receta asumió que los que la intentarían ejecutar tenían conocimientos culinarios en grado suficiente, lo que no
resultó una predicción verdadera. Además, hay un error en la receta que sugiere usar un tipo de harina que no es
el correcto, digamos que dice “harina” a secas, que en el contexto de los cocineros que tienen problemas con la
receta se entiende por “harina de trigo,” cuando el que diseñó la receta quería que fuera “harina de maíz”. El
análisis de causa ha detectado estos defectos y se ha sugerido que se hagan cambios a la receta, definiendo con
precisión los pasos para que no haya diferentes interpretaciones, y corrigiendo los errores y ambigüedades.
Un grupo de procesos sin la suficiente experiencia consideraría que ha cumplido su cometido: El proceso, de
ejecutarse correctamente, “debería” funcionar. Jay Arthur (y los autores) no se conforman con esa definición,
incompleta, de la responsabilidad del grupo de proceso: ¿Y si no funciona? Lamentablemente la resultante en esos
casos es que el grupo de procesos le arroja la responsabilidad a los que debiendo ejecutar correctamente el
proceso no lo hacen, sin constatar que, necesariamente, son ellos y no los cambios los que llevan a perpetuar el
problema o introducir otros nuevos.
Por lo tanto, ‘sostener’ implica medir y analizar los resultados. Esto lleva a tener que entender cuándo, dónde
y qué medir. Uno de los pasos más importantes en la definición de procesos y el cambio para la mejora es
identificar los procesos clave y los atributos a medir. Esta capacidad es exigida por el MPS en los niveles más altos
de madurez, a partir del Nivel B, pero es una de las cualidades más valiosas de un gerente. Por ejemplo, si nos
preocupa que la mayoría de los proyectos termina después de su fecha de entrega y hemos hecho cambios en
consecuencia para adelantar la producción de resultados, medir las demoras que se producen en aquellos puntos
es de suma importancia. Medir solo el resultado final, el desvío en la fecha de entrega, es solo parcialmente útil
porque una vez que hemos entregado tarde no se puede modificar el resultado. Arthur introduce acá herramientas
de 6 que el MPS no requiere sino hasta el Nivel B, como ya hemos dicho, y por lo tanto complica un poco más de
lo necesario el análisis de resultados.
La última fase del ciclo es Honor, honrar. Arthur se refiere acá a la necesidad de respetar y premiar los
compromisos con el cambio, con la mejora (no todo cambio es una mejora, pero toda mejora es un cambio). Gran
parte del mensaje sobre la mejora de procesos está contenido en la manera que la organización resalta y
recompensa los esfuerzos de su personal en relación a los cambios y las mejoras. Es importante destacar que no
todos los intentos de mejora, sobre todo en las etapas tempranas del proceso de mejora continua, han de resultar
igualmente exitosos. Algunos serán hasta negativos, pero es indispensable rescatarlos como esfuerzos válidos
porque la organización aprende.
2.5 Lean Simplified
El último método es Lean Simplified [ARTHUR, 2006]. Jay Arthur desarrolló ese método como una extensión
de su anterior FISH que vimos más arriba con el propósito de hacer más clara la aplicación del mismo, enfatizando
la cadena de valor que lleva desde el pedido del cliente a su satisfacción por la entrega del producto. La palabra
inglesa Lean significa delgado, sin peso demás. Arthur elige llamarlo Simplified, simplificado, porque ha reducido la
demanda estadística que su método FISH tiene. Llamaremos a este método LS, para evitar usar términos en inglés.
LS, como lo explica Jay Arthur en [ARTHUR, 2006] es un método para la empresa manufacturera. Sin
embargo, modificando o dejando de lado lo que no aplica para el desarrollo de software, es un método poderoso
para identificar y resolver problemas con vista a la mejora continua. Presentamos acá nuestra versión de LS
adaptada a la producción de software.
13
18
Los diagramas SADT, o IDEF0 en su versión norma internacional, son más detallados y de uso difundido. También los
diagramas de flujo con andariveles que permiten discernir responsabilidades. Asimismo sería posible diseñar el proceso
siguiendo técnicas de flujo de datos del Análisis Estructurado o con herramientas de UML.
Capítulo 2

19. Boria et al.
14
En el corazón de LS está el tema de la velocidad de producción . La velocidad no es apuro, es hacerlo mejor y
sin interrupciones, no es trabajar los fines de semana o hasta altas horas de la noche. La velocidad es
productividad puesta al servicio del producto. En un mundo conectado globalmente por la Internet los clientes
esperan servicios casi inmediatos sin pérdida de calidad ni aumento de los precios. El libro de [RODIN, 2010] es una
visión de cómo la demanda por servicios gratuitos entregados en el momento y sin costo alguno está
revolucionando los negocios. Para las organizaciones que fabrican software el desafío está lanzado: Hay que
eliminar los defectos y todas las demoras para entregar más que a tiempo y con bajos costos.
Las demoras no son justificables. El producto de software puede ser único e irrepetible, pero los procesos por
los cuáles se lo produce no lo son. Cada proyecto se compone de las mismas fases, que realizan las mismas
actividades. La resistencia a ese concepto es notable en empresas de baja madurez, y sin embargo vemos una y
otra vez que la resistencia a hacer las cosas de otra manera es tan arraigada como la necesidad de sostener que
siempre son diferentes. Lo único que se demora en cambiar es la creencia de que la organización está justificada
en actuar como lo hace.
En cada empresa hay dos fábricas, la principal que diseña, vende, factura y entrega el producto, cuya fórmula
es Velocidad con Calidad + Ganancias = Beneficio. La segunda es la fábrica de arreglos, que corrige todos los
errores que se van cometiendo a medida que se diseña, vende y factura el producto. Hay siempre una fábrica de
arreglos visible que se mide y se controla, pero hay otra que es oculta que hace que los errores se corrijan sin que
haya atribución ni contabilización. Esa fábrica tiene otra fórmula: Defectos + Demoras = Pérdidas.
En el fondo, LS se centra en la velocidad de producción. La relación entre las etapas de un proceso es
fundamental. Las etapas y actividades que no agregan valor deben ser eliminadas del proceso. Por eso la primera
actividad en LS es hacer un mapa de la “cadena de valor”, la secuencia de actividades que van desde la recepción
15
del pedido del cliente a la satisfacción de sus necesidades . Una vez más, el mapa tiene que ser sencillo, pero no
tanto que resulte fácil de malinterpretar. Además, puesto que se trata de un sistema de tracción donde la salida
fuerza al proceso anterior y así sucesivamente, este método atiende principalmente la voz del cliente. Hecho
correctamente, esto genera valor para el cliente y en consecuencia, la organización.
Foco en los Defectos
Al intentar reducir la “fricción” que demora los procesos, Toyota descubrió que hay muchas formas de
desperdicio (“muda”).
1.
2.
3.
4.
5.
6.
7.
Exceso de producción (en software, incluir código que no fue solicitado “por si lo vamos a necesitar”)
Inventario excesivo (en software, los procesos que se generan alrededor de la funcionalidad no
requerida, como testeo extra, volumen de manuales, etc.)
Esperas (en software se manifiesta en particular cuando hay que esperar por otro rol a que el personal
esté disponible, o las instalaciones, o cuando el cliente tiene que dar respuesta)
Movimientos innecesarios del producto (en software la ubicuidad de los productos en formato
electrónico hace de esto un problema inexistente, pero si se mantienen planos en papel o en
pizarrones puede llegar a ocurrir)
Movimientos innecesarios del personal (típicamente en la instalación o en la validación, a menudo en la
etapa de generar requisitos)
Procesamiento innecesario o inadecuado (no es muy común, pero en ciertas organizaciones
burocráticas hay ocurrencias de esto)
Defectos que obligan a reparaciones y retrabajo (no hay porqué explicar esto en nuestra profesión)
Si la organización trabaja con plazos cortos y se concentra em mantener la flexibilidad se obtienen beneficios
en calidad y satisfacción del cliente. En el capítulo 3 veremos cómo un grupo de desarrolladores de software
14
15
La empresa Toyota inventó el método de "producción esbelta" (lean production) tomando como referencia los
supermercados de los EEUU, donde percibieron que cuando los anaqueles de los supermercados alcanzan el punto mínimo
del inventario son reabastecidas tan rápidamente como los clientes "quitan" los productos de la góndola. En un sistema de
tracción, el proceso anterior debe siempre hacer lo que el proceso subsecuente le pide. Para ver que el stock está bajo y,
como consecuencia, reponerlo, se coloca una tarjeta que señala el punto exacto. El nombre en japonés de esa tarjeta es
Kanban, palabra que hoy identifica tanto a la tarjeta como al sistema.
No es lo mismo oír y reaccionar que escuchar y satisfacer.
Capítulo 2
19

20. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
construyó métodos que permiten aprovecharse de estos conocimientos. El movimiento que iniciaron se conoce
16
como el Agile Manifesto y ha marcado como se desarrolla software desde su aparición.
LS sigue con la organización del trabajo para eliminar el desperdicio. Son cinco las tareas a realizar: Sort,
ordenar; Straighten, enderezar; Shine, pulir; Standardize, estandarizar; y Sustain, mantener.. Nosotros damos aquí
17
nuestra interpretación de esas tareas en actividades de ingeniería de software . Ordenar significa decidir qué es
útil y qué no lo es y eliminarlo. Esto es la tarea de las personas o roles que identifican las mejoras de proceso. A
menudo los pedidos de cambio de procesos se originan en los equipos, y un rol en particular, llamado afirmación o
aseguramiento de la calidad es quien debiera detectar la necesidad del cambio y transmitirla. Enderezar es colocar
cada cosa en su lugar y tener un lugar para cada cosa. Ese es el rol de la gestión de configuración en la ingeniería
de software. Pulir es mantener el área limpia para exponer defectos y pérdidas. En software esto se manifiesta en
la aplicación de formas y patrones que permiten el análisis y la inspección por terceros, por ejemplo el uso de
estándares de programación que ayudan a leer un programa. Estandarizar es definir sistemas, procesos y
procedimientos que ayuden a mantener las tres reglas anteriores. Este es nuevamente el rol del área de mejora de
procesos. Mantener, por último, es conseguir que el flujo de trabajo sea estable y se respeten las reglas. Entre el
área de mejora de procesos y el grupo de afirmación de calidad esto debiera ser alcanzable.
Otra de las normas que rigen LS es la preminencia de la demanda por sobre la producción. En vez de producir
en anticipación de lo que se demandará se produce a partir de lo que se pide. En nuestra traducción al mundo de
procesos esto significa que no intentaremos mejorar lo que no se siente que está roto. El vocablo inglés “pull” que
significa halar, tirar, representa este pensamiento, contra el vocablo inglés “push” que significa empujar. Es común
en la disciplina de mejora de procesos que se intente ‘empujar’ mejoras desde el centro hacia afuera, o desde
arriba hacia abajo. En nuestra experiencia la resistencia así creada demanda mucho esfuerzo y no justifica el
retorno de la inversión. Por el contrario, un enfoque de ‘halar’ hace que el cambio se vea como algo positivo ya
que, efectivamente, resuelve un problema. Cuando una mejora de procesos se percibe como una eliminación de
un obstáculo a la productividad se gana un aliado para los futuros cambios, que además cuenta ahora con tiempo
extra para apoyar la creación y difusión de nuevos cambios.
LS tiene más para aportar, pero en lo esencial nos alcanza con lo expuesto para entender las ventajas y
desventajas del método. Nuestra matriz de Pugh para los cuatro métodos queda así:
atributos
peso
PDCA
IDEAL
FISH
LS
NEGOCIO
5
1
3
3
3
DETALLE
4
1
1
2
3
SISTEMA
3
2
1
1
3
MARCO
2
2
0
0
3
19
22
26
42
suma
Tabla 2.2: Selección del Método de Mejora de Procesos
Con estos valores es claro que nos inclinamos por LS. Por supuesto, se puede criticar esta decisión, porque los
valores colocados en la intersección son arbitrarios hasta cierto punto. En una decisión de mayor impacto
económico sería deseable que la puntuación estuviera mejor detallada para lograr mayor objetividad.
Puesto que vamos a utilizar LS en nuestros análisis y nuestras propuestas para la empresa que hemos tomado
como caso de ejemplo, es bueno resaltar algunos valores y creencias que se asocian con LS.
1.
2.
3.
4.
5.
16
17
El proceso exacto producirá los resultados exactos.
Desarrollar al personal y a los proveedores agrega valor.
La resolución continua de problemas raíces conduce al aprendizaje organizacional.
El flujo de una pieza aumenta la productividad, el lucro y la calidad.
A los productos no les gusta hacer fila esperando atención. Los materiales, piezas y productos son
impacientes.
http://www.agilemanifesto.org/
Remitimos al el lector interesado en las definiciones originales en manufactura al sitio http://es.wikipedia.org/wiki/5S
20
Capítulo 2

21. Boria et al.
6.
7.
8.
Lo único que agrega valor en un proceso es la transformación física o informacional de la materia-prima
en algo que el cliente quiere.
Los errores son oportunidades para el aprendizaje.
La resolución de problemas es un 20% de herramientas y un 80% de aplicar la inteligencia.
Nuestro enfoque de mejora de procesos va a adoptar muchas de estas máximas, en lo que aplican a las áreas
de desarrollo de software. No vamos a limitarnos a seguir al modelo MPS en su aplicación, vamos a procurar
identificar y resolver los problemas que son comunes en las empresas desarrolladoras de software.
Capítulo 2
21

22. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
CAPÍTULO 3 - LOS MÉTODOS ÁGILES: KANBAN, SCRUM, XP Y FDD
3.1 ¿Qué son los métodos ágiles?
En el capítulo anterior presentamos la mejora continua de procesos y decidimos tomar como referente a LS.
Las ventajas de un método liviano, desprovisto de burocracia, que enfoca directamente en las necesidades de
negocio no pasaron desapercibidas para los “metodólogos” de Ingeniería de Software. Ya en el siglo pasado habían
nacido varios métodos de desarrollo que se apoyaban en las ideas de producción de Toyota, notablemente
Extreme Programming [BECK, 2000], Scrum [SCHWABER, 2002], DSDM [STAPLETON, 1997], Adaptive Software
Development [HIGHSMITH, 1999], Crystal [COCKBURN, 2005], Feature-Driven Development [COAD, 1999],
Pragmatic Programming [HUNT, 1999] y otros más. En un intento de encontrar formas comunes se reunieron
diecisiete de estos creadores en Febrero del 2001 en un centro de esquí en Utah. Lo que surgió fue un manifiesto
18
que marcó la ingeniería de software de modo único, el Agile Software Development Manifesto .
El contenido del manifiesto se puede leer en línea, pero consideramos que su influencia es tan importante, y
sus coincidencias con el método de Toyota TPS son tantas que lo incluimos acá.
Manifiesto para el Desarrollo de Software Ágil
Estamos descubriendo mejores métodos para desarrollar software ejercitándolos y ayudando a
otros a usarlos. A través de este devenir apreciamos:
Los individuos y las interacciones
por sobre los procesos y las herramientas
Software que funciona
por sobre una documentación completa
Colaboración con el cliente
por sobre la negociación del contrato
Responder a cambios
por sobre seguir un plan
Es decir, aunque hay valor en los ítems de la derecha, valoramos los ítems de la izquierda aun
más.
(firman) Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.
Aunque el manifiesto describe las ideas más básicas, hay entre los autores más acuerdos que los allí
expuestos. Muchas de las coincidencias provienen de la misma fuente: El foco en la calidad, con las reglas de
Toyota que mencionáramos ya en el capítulo anterior en la sección “Foco en los Defectos”. Así como Toyota tiene
su método TPS que es una forma de “Kaizen”, los métodos ágiles se apoyan en períodos de producción cortos y
mucha colaboración dentro del equipo de proyecto, apoyado en la sinergia que genera el trabajo en equipo de la
estructura formada para alcanzar las metas establecidas por la dirección de la compañía. En gran parte, su
popularidad entre el personal de desarrollo se deriva de la independencia que los equipos sienten al tomar sus
decisiones en conjunto y en alto grado libres de las redes burocráticas que se tejen en las grandes empresas, lo
que trae consigo resultados concretos, tanto cualitativos como cuantitativos.
Al dejar que el equipo de trabajo tome las decisiones para el próximo período de trabajo, llamado en la jerga
19
20
de los agilistas un “Sprint” , los métodos ágiles consiguen motivar al personal de los proyectos y
comprometerlos con el resultado al permitirles tomar decisiones de peso. Dada la corta duración de un Sprint,
usualmente nunca más de cuatro semanas, los equipos pueden ver sus resultados de inmediato. También es
importante la participación del cliente. Junto con un representante del cliente que esté comprometido a su vez con
18
19
http://agilemanifesto.org/
Usaremos este neologismo para designar a aquellos que adhieren a los métodos ágiles y los practican.
20
22
Los diccionarios definen ‘Sprint’ como la mayor velocidad alcanzada por un corredor en una carrera, especialmente en el
final. Las carreras de hasta 200 metros se consideran todas Sprints, de principio a fin. Por analogía, cada tramo de un
proyecto ágil se considera un Sprint.
Capítulo 3

23. Boria et al.
el resultado, se define el alcance de cada Sprint. Es un deber de los equipos ágiles definir una parte del producto
que en sí misma tenga valor para la organización del cliente. De ese modo el producto parcial es concreto y
mantiene la concentración y el foco en el negocio.
Los métodos ágiles nacieron como respuesta a las burocracias que ignoran las particularidades del desarrollo
de software y en su ignorancia presionan a los equipos a llevar adelante proyectos con compromisos irracionales
realizados por los que no saben. Al poner metas cortas y priorizar la participación del cliente en las decisiones de
negocio, además de poner un freno concreto a los cambios caprichosos, los métodos ágiles rescatan el valor de la
ingeniería de software ante los embates burocráticos de ciertos niveles en las corporaciones. Entre otras virtudes,
la decisión por el equipo es visible para todos, DEBE ser visible para todos. En consecuencia la transparencia de los
proyectos ágiles es uno de sus atributos más valiosos y más revolucionarios.
Los agilistas se consideran un movimiento pro-métodos. Los que creen que la agilidad es contraria a los
procesos y las herramientas, a la documentación o los planes se equivocan. Lo que buscan es que estas entidades
estén al servicio de las actividades del equipo y no a la inversa. Si el lector cree que ser ágil es no planificar, no
seguir procesos por ligeros que estos sean, no tener más herramientas que el ambiente de desarrollo interactivo y
un par de lenguajes, no documentar las decisiones, se equivoca de plano. El que así piensa es un hacker, no un
agilista. Los agilistas piensan que la planificación de detalle no puede llevar más que unas pocas horas y debe
involucrar al equipo, que los procesos son flexibles pero deben de ser acordados por los que los llevan a la práctica,
que la documentación debe ser fácil de mantener y responder a una necesidad orgánica del proyecto y debe ser
hecha cuando esa necesidad se manifiesta y no como una condición contractual después de que el producto se
haya concluido. En cuanto a herramientas, baste recordar que la integración continua, uno de los baluartes de los
métodos ágiles, requiere excelentes herramientas de gestión de configuración con testeo integrado por lo tanto es
claro que los agilistas trabajan en pro de la eficiencia y no en contra de la misma.
21,22
Los cuatro métodos ágiles que encontramos más útiles en diferentes etapas de una empresa son Kanban
,
23
24
25
Scrum , XP y FDD . El orden en que los describiremos va del más sencillo (Kanban) al más complejo (FDD).
Scrum y XP se apoyan en Kanban y en particular describiremos XP en su versión XBREED, que mezcla los conceptos
de XP con las prácticas de Scrum para obtener un proceso más sólido y confiable.
3.2 Kanban: Midiendo el flujo
Quién introdujera Kanban como método ágil fue [ANDERSON, 2011]. El método Kanban es parte de una
familia de sistemas que se denominan “pull”, o de arranque, contra el enfoque tradicional de sistemas “push” o de
empuje. Otra manera de ver la diferencia entre unos y otros sistemas es que el sistema de arranque es guiado por
la demanda mientras que el sistema de empuje es guiado por la producción. En un sistema “pull” el proceso espera
que haya demanda de su producto para producirlo, tratando de que se llegue justo a tiempo con el mismo, de
26
manera de que no haya inventario . El inventario es característico de los sistemas “push” puesto que es el
amortiguador que permite el desacoplamiento entre procesos consecutivos. El problema es que el inventario
consume mucho capital y tiene un alto costo, siendo que además no se sabe si el producto final tiene comprador o
no. De ese modo se desperdicia trabajo y materiales.
El método Kanban permite alcanzar un ritmo de producción sostenible e introducir cambios a los procesos
con muy baja resistencia. Es por eso que lo usamos de preferencia con aquellas organizaciones de muy baja
27
madurez institucional. Como vimos, el método Kanban es uno de los mecanismos que subyace el TPS pero la
adaptación para ingeniería de software es del 2004 y fue realizada por Anderson en Microsoft. Anderson lo
presentó en la conferencia Agile 2007 de Washington y comenzó el entusiasmo por el método, puesto que los
resultados eran muy alentadores.
21
22
23
24
25
26
27
KNIBERG, H. e SKARIN, M., 2010
Cuando usamos Kanban con mayúsculas nos referimos al método Kanban desarrollado por Anderson, cuando se lo usa en
minúsculas, kanban, hace referencia a cualquier otro uso, como el sistema kanban de Toyota o el tablero kanban que
veremos más adelante.
KNIBERG, H., 2007
KNIBERG, H., 2007
PALMER, S. R. e FELSING, J. M., 2002
Esto también es conocido como sistema “Just in Time”, o con las siglas JIT.
Toyota Production System.
Capítulo 3
23

24. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
El método es en sí muy simple, pero al usarlo de determinada manera trae consigo múltiples ventajas que
señalaremos al explicarlo. Si bien el texto [ANDERSON, 2011] es la base que permite entenderlo profundamente,
para el lector que aspira a un manejo más pragmático aconsejamos [KNIBERG & SKARIN, 2010] que se remite a lo
esencial de la implementación, sin por ello dejar de lado lo anecdótico que permite la comprensión, o como se dice
en México, el “aterrizaje” del material.
Un elemento central en el método es el uso del tablero kanban. No se debe confundir el uso del tablero con
la aplicación del método; es posible usar el tablero sin seguirlo, como de hecho se hace en muchas adaptaciones
de Scrum y XP, porque el tablero es un excelente medio para comunicar el progreso de un proyecto.
El tablero kanban es simplemente un registro del avance del proyecto materializado según le convenga al
28
equipo. Lo más frecuente es usar un tablero donde se puedan pegar notas autoadhesivas que llamaremos pósit ,
como en la Figura 3.1, dividido en columnas verticales. Cada columna indica un estado de las tareas. Las pósit
contienen los nombres de las tareas. La primera columna de la izquierda típicamente contiene lo “pendiente”, es
decir la lista de las tareas a realizar que aún no se han comenzado. Cuando un miembro del equipo tiene
disponibilidad para comenzar una tarea, toma de esa columna la tarea que corresponda, ya sea por prioridad
prestablecida o por alguna otra razón que se haya convenido en el equipo, y la corre a la columna siguiente hacia
la derecha. En algunos métodos que usan el tablero kanban el miembro del equipo que hace esto coloca la fecha y
hora del comienzo, su nombre y la fecha estimada de finalización en los rincones del pósit, diseñados para ese uso,
29
como se muestra en la Figura 3.2 . Cuando termina de realizar su tarea, toma el pósit de donde lo colocó y lo
mueve una columna más a la derecha, de donde a su vez lo tomará alguien más para continuar con el proceso
hasta que la tarea alcance el punto donde se acordó se la considerará completa, punto en el cuál alcanza la
columna de la extrema derecha del tablero.
Figura 3.1: Tablero kanban
No hay ningún motivo especial para utilizar tarjetas autoadhesivas o los tableros en sí. Pueden utilizarse
planchas de cartón a las que se pinchan con chinches tarjetas de cartulina, pueden usarse filas horizontales en vez
de columnas o puede utilizarse un tablero virtual de los muchos que se ofrecen por la Internet. El objetivo es el
mismo, dar claridad a las tareas pendientes de resolución y entender tanto el estado actual del proyecto como la
ocupación del personal.
Figura 3.2: Nota pósit del Tablero kanban
28
Pósit es un artículo nuevo en el diccionario de la Real Academia Española, avance de la vigésimatercera edición. Su definición
es (Del ingl. Post-it, marca reg.). 1. m. Hoja pequeña de papel, empleada generalmente para escribir notas, con una franja
autoadhesiva en el reverso, que permite pegarla y despegarla con facilidad.
29
24
En el ejemplo mostrado el rincón superior izquierdo contiene el nombre de la persona responsable, el superior derecho la
fecha y hora de apertura del ítem, el inferior derecho la estimada de finalización y el inferior izquierdo (sin llenar en el
ejemplo) la fecha real de finalización. Cuando se usa esta convención a menudo los pósit se copian y se pegan unos sobre
otros para tener la historia de su desarrollo.
Capítulo 3

25. Boria et al.
En el método Kanban se limita el número de tareas en cada columna. El objetivo es identificar claramente la
capacidad del sistema y balancear la demanda contra la capacidad del equipo. El método Kanban permite
comprender el tiempo de tránsito de cada tarea, desde que ingresa al sistema por la izquierda hasta que culmina
en la columna de la derecha. (Hay algo de satisfacción personal para cada miembro del equipo en mover la tarea
hacia la columna “completado” que motiva a usar kanban). Una vez que se han ajustado los parámetros de
producción, el equipo alcanza un ritmo sustentable, es decir, que puede mantenerse indefinidamente,
consiguiendo en efecto predictibilidad que otros métodos tardan mucho en alcanzar.
Puesto que esa regularidad se hace presente muy rápidamente, toda obstrucción a esa regularidad es
rápidamente visible, potenciando al equipo para detectarlos y, en consecuencia, resolverlos. El impacto que tienen
en la regularidad los defectos, las demoras, los cuellos de botella y la mala estimación del tamaño y la complejidad
del producto aparecen muy pronto en el tablero. Es fácil relacionar estos problemas con el costo del proyecto,
dado que al restringir el número de tareas en cada columna las personas tienen que atender los cuellos de botella
para ayudar a resolverlos. De esta manera el método Kanban vincula rápidamente los problemas técnicos del
proyecto a los resultados de negocio, sin tener que establecer complicados mecanismos de análisis. Este es un
resultado que no se anticipaba al introducir el método pero que es uno de los puntales de su adopción.
Una de las ventajas de Kanban es que al producir con calidad y a tiempo se genera confianza en los clientes,
que reciben productos con regularidad y con la calidad esperada. Otra ventaja es que, al hacer que el equipo
mejore constantemente sus procesos para evitar demoras, las entregas se hacen más frecuentes y con mayor
funcionalidad. A su vez, esta situación hace que el equipo se sienta más a gusto y ponga más ahínco en mejorar el
flujo de trabajo.
Para implementar Kanban el primer paso es identificar el flujo de trabajo, lo que se conoce como la “cadena
de valor” que ya viéramos en el Capítulo anterior en las discusiones sobre el método de mejora de procesos a
seguir. Dado el origen común de esos métodos (las diferentes versiones de calidad total) y el hecho de que el
método Kanban es una adaptación al desarrollo de software de una técnica con el mismo nombre (kanban)
derivada del TPS, a su vez del mismo origen que los anteriores, las coincidencias no deben sorprendernos. Kanban
usa cinco principios para crear comportamientos en las organizaciones donde se lo aplica: Visualizar el Flujo de
Trabajo; Limitar el Trabajo en Realización; Medir y Manejar el Flujo; Explicitar Políticas de Proceso; y Utilizar
30
Modelos para Reconocer Oportunidades de Mejoras.
El primer punto saliente en la construcción de un tablero kanban para el flujo de trabajo es que la columna de
la derecha corresponde al estado de tarea completada. Antes de que se pueda proseguir con la implementación
del método es imprescindible que el equipo, junto con el proveedor de información (más adelante llamaremos a
este rol ‘Dueño del Producto’ siguiendo la costumbre introducida por [SCHWABER & BEEDLE, 2002]) defina los
atributos necesarios de una tarea para que se la considere completada. Por ejemplo, la densidad de defectos
remanentes conocidos, o los estados por los que ha debido pasar (inspecciones, pruebas unitarias, etcétera).
La columna de la derecha está así bien identificada y su sentido es claro. La columna de la izquierda es donde
se colocan los pendientes. Entre medio hay tantas columnas como el equipo quiera y que tengan significado para
ellos. Por ejemplo puede que la siguiente columna a la derecha de “Pendientes” sea “En Análisis”, la que le sigue a
esta sea “Analizado”, la siguiente “En Desarrollo”, la siguiente “Listo para Prueba”, la siguiente “Listo para
Integración”, y así sucesivamente. Por otra parte puede que un equipo determine que todo lo que necesitan saber
se contiene en tres columnas: “Pendiente”, “En Desarrollo”, “Listo para Entregar”. Las decisiones que así se toman
tienen repercusiones muy grandes. Por ejemplo, la primera elección sugiere que dentro del equipo hay
especialidades que van pasando la tarea de una a otra. La abren los analistas que la pasan a los desarrolladores
que la pasan a los testers. La segunda sugiere que el equipo trabaja en células integradas donde todos esos roles se
cumplen dentro de la célula. Un caso extremo poco recomendable es el de la célula unipersonal.
Recomendamos la adopción del tablero más complejo con divisiones técnicas del trabajo, por lo menos
mientras no se incorporen técnicas especiales como programación por pares y diseño dirigido por las pruebas. El
motivo es que las diferentes etapas dentro del proceso permiten avizorar mejor estados intermedios, de modo
que los atrasos potenciales y los cuellos de botella puedan ser rápidamente detectados y la duración de las tareas
mejor estimadas. Además, este esquema de trabajo es muy flexible y permite crecer con facilidad hacia otros
30
Los modelos a que hace referencia Anderson son más generales que los que presentaremos en el próximo Capítulo, pero
dada la apertura que sugiere el texto ya citado, los autores no encontramos contradictorio utilizar el MPS para introducir
mejoras de proceso compatibles con Kanban.
Capítulo 3
25

26. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
métodos, en particular Feature Driven Development, que recomendamos más adelante como un método
ventajoso para proyectos grandes con equipos de mucha personas. Por si estas dos características no fueran
31
suficientes, otra ventaja consiste en que los estados intermedios de pase permiten al proyecto contar con el
apoyo de grupos organizacionales, como Aseguramiento de la Calidad, que puedan tomar esos traspasos como
referencias e intervenir sin violencia en la calidad del proceso.
Hasta acá lo descripto constituye generalidades del uso de un tablero kanban. Para que sea una aplicación del
método Kanban, es necesario limitar el número de pósit en cada columna. Si en una columna hay tantos pósit
como indica el límite, generalmente anotado en el tope de la columna junto a su nombre, no se puede pasar un
pósit más a esa columna. Esto implica que aunque se haya terminado el paso anterior para una tarea la columna
está bloqueada y no se puede hacer avanzar el pósit correspondiente. Claramente las personas que quedan
ociosas notan esto, las personas que están trabajando en las actividades de la columna saturada notan esto y la
cadena de producción se detiene. En esta situación se detecta un cuello de botella, que debe ser resuelto por los
mismos miembros del equipo. A diferencia de la gran mayoría de los métodos existentes, Kanban no es
prescriptivo. En eso lo sigue Scrum, pero Kanban es todavía menos prescriptivo que Scrum. El equipo elige, adapta
y adopta sus procesos según su necesidad.
Lo que diferencia notablemente a Kanban de los otros métodos ágiles es su flexibilidad, pero sobre todo es la
limitación del volumen de trabajo en cada etapa. Es esta restricción la que pone en juego los mecanismos de
adaptación, y en consecuencia los mecanismos de mejora, que en otros métodos quedan a cargo de reuniones
especiales llamadas “retrospectivas”. Lo que en los demás es una visión de lo que pasó, en Kanban es la necesidad
lógica de operar sobre lo que está pasando.
Siguiendo nuestra opción de mejora de procesos que definiéramos en el Capítulo anterior, utilizaremos los
mismos preceptos que usa Anderson para Kanban puesto que son compatibles: Foco en Calidad, Reducción del
Trabajo en Desarrollo, Entregas Frecuentes, Balanceo de la Demanda contra la Producción, Fijación de Prioridades,
y Atacar las Fuentes de Variación para Mejorar la Predictibilidad. La receta de Anderson no sólo es compatible con
la de LS que eligiéramos antes, ¡Es totalmente compatible con el MPS! En el Capítulo 5 expandiremos las técnicas
de Kanban utilizando el ejemplo de Tahini-Tahini.
3.3 Scrum: Organizando el sistema para un estado de equilibrio orgánico
Scrum no debe ser considerado un método, a pesar de que tiene reglas claras que se deben seguir, porque
deja muchas resoluciones abiertas para que el equipo del proyecto las resuelva. Al describir Kanban dijimos que
después del mismo, Scrum es el enfoque ágil menos prescriptivo. Esto es cierto, pero la gran diferencia entre el
número de reglas de uno y otro (3 contra más de 10) hace que estén cerca pero no demasiado.
Para implementar Scrum en una organización hay que hacer cambios profundos antes. Con Kanban los
cambios originales son solo tres: reflejar el flujo en un tablero Kanban, limitar el número de tareas por etapa y
mejorar el flujo total haciendo las alteraciones que demande el proceso. Kanban se adapta fácilmente a cualquier
proceso subyacente, porque las entregas rápidas pueden ser internas al equipo y la participación de los
involucrados externos al mismo es deseable pero no indispensable. En cambio, en Scrum es indispensable
restructurar la organización en varios sentidos: Primero se tiene que contar con una persona que conozca el
producto, o tenga la visión del producto, y que esté disponible para trabajar con el equipo durante la duración del
proyecto. La dedicación que se requiere no es de tiempo completo, pero esta persona debe permanecer accesible
para que el equipo pueda tomar decisiones de negocios conjuntamente con ella. Asimismo, está persona debe
32
poseer la suficiente autoridad para que sus decisiones no se revean . En el lenguaje de Scrum esta persona se
conoce como el “Dueño del Producto”.
En segundo lugar, el personal debe ser dividido en equipos interdisciplinarios pequeños, auto-organizados,
que cuentan con la supervisión y colaboración para allanar problemas de parte de un especialista, llamado en
Scrum el Scrum Master. El Scrum Master se encarga de que se sigan los procesos de Scrum y de mantener la
relación del equipo con el medio que lo rodea. En ese sentido, es mucho más un perro pastor que cuida del ganado
que un gerente que dirige las operaciones. La auto-organización del equipo es fundamental en Scrum. El Scrum
31
En inglés, “hand-off” entre un rol y el otro.
32
26
Esto es lo que [BOEHM, B. e TURNER, R., 2003] llaman un usuario ‘CRACK’ (collaborative, representative, authorized,
committed and knowledgeable) que traducido es colaborativo, representativo, autorizado, comprometido y con
conocimiento.
Capítulo 3