Tahini Tahinispfinalcover A4 131115081722 Phpapp01

Jorge Luis Boria
Viviana Leonor Rubinstein

Andrs Rubinstein
La Historia de Tahini-Tahini:
Mejora de Procesos de Software con
Mtodos giles
y el Modelo de Madurez MPS
Boria et al.
PREFACIO
La discusin sobre la posibilidad o no de utilizacin de mtodos 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 implantacin de estos modelos va a lastimar la agilidad
de desarrollo. Esta incompatibilidad es discutida, por lo tanto, por defensores del uso de mtodos giles y por
defensores de los modelos de madurez.
En este contexto se sita el libro La Historia de Tahini-Tahini: Mejora de Procesos de Software con Mtodos
giles y Modelo MPS de Jorge Boria, Viviana Rubinstein y Andrs Rubinstein.
El libro tuvo origen en una llamada realizada en diciembre de 2011 por la Secretaria de Poltica de Informtica
SEPIN, del Ministrio de Cincia, Tecnologia e Inovao MCTI, responsable por la conduccin del Programa
Brasileiro de Qualidade e Produtividade em Software PBQP Software, para el Ciclo 2012 del Programa Srie de
Livros do PBQP Software. Entre varios competidores result el texto seleccionado para publicacin.
Y fue, sin duda, una excelente eleccin. En l, los autores, a partir de su riqusima experiencia como
consultores, evaluadores MPS y lead appraisers CMMI, nos muestran que no existen contradicciones entre
modelos de madurez, mejora de procesos y mtodos 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 cmo se inter-relacionan las tcnicas de
consultora, con los mtodos giles para alcanzar los resultados esperados del MR-MPS-SW. Para esto utilizan
cuatro mtodos giles, Kanban, Scrum, XP y FDD (Feature Driven Development), y la historia de Tahini-Tahini, una
empresa ficticia que ciertamente a todos nos gustara que existiese.
Es un libro tcnico, ms fascinante y de lectura muy agradable. A veces nos hace rer, 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 invitacin a escribir el prefacio de un libro tan interesante y con contribuciones tan
importantes para la calidad y la Ingeniera de Software.
Abril, 2013
Ana Regina Cavalcanti da Rocha
Universidade Federal do Rio de Janeiro
COPPE/UFRJ
Prefacio
iii
Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS
PRLOGO - CONSULTORA EN MEJORA DE PROCESOS

El Origen del Libro
Este libro se origin en un llamado realizado en Diciembre de 2011 de la Secretaria de Poltica de Informtica
SEPIN, del Ministerio de Ciencia, Tecnologa e Innovacin - MCTI, responsable por la conduccin 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 cules haba que presentar propuestas uno nos pareca
sumamente til a la poblacin de ingeniera de software, la Mejora de Procesos de Software con Mtodos giles y
el Modelo MPS. Sobre los otros temas, igualmente de importancia, hay literatura bsica y avanzada. Tampoco es
un valor agregado, en un mundo globalizado, escribir un libro en Castellano o Portugus; el Ingls es la nueva
Lingua Franca y los principales cultores de esto son los informticos. Nos atrajo el desafo de conciliar tres
vertientes, tal la complejidad del tema. Estamos agradecidos a todos los que intervinieron en el proceso que llev
a la seleccin, edicin y publicacin de este libro.
El Propsito 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 propsito es ilustrar
como se interrelacionan las tcnicas de consultora, siempre una buena facilitacin cuando est bien hecha, a
veces enseanza-aprendizaje, nunca dictadura; con los mtodos giles, que son muchos ms 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 heurstica 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 utilizacin. 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 bibliogrficas que les
dejamos, ocho pginas en total de materiales superlativos. Si algo destacamos de este libro es que la bibliografa
de por s vale la pena.
Las Vertientes del Libro.
El ttulo de este libro mezcla tres ideas poderosas. Habla de mejora de procesos con mtodos 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 eleccin de contenidos. Este es un libro sobre las
actividades que se llevan a cabo en consultoras de mejora de procesos. Aunque el principal personaje es una
mujer, Marcela, que trabaja en relacin 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 herona de la novela romntica Inglesa del siglo XVIII en que es inteligente, sabe lo que
quiere y sabe cmo conseguirlo. Es el ejemplo de liderazgo de este libro, aun cuando los dems socios y
compaeros de ruta son buenos gerentes y excelentes profesionales, cada uno con su vena tcnica, es Marcela la
que gua 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 escribamos el libro era con Marcela que preferamos identificarnos, al fin y al cabo es el
personaje ms exitoso. Las lecciones que debieran recogerse de este libro se deben a Marcela.
No es un libro de consultora, los hay, y muy buenos, escritos por consultores mejores que nosotros. Sin
embargo, hay muchos consejos sobre cmo realizar las cosas que importan, las que llevan a los cambios serios,
que estn contenidos en las acciones de los personajes. Tambin hay muchsimas tcnicas que solemos introducir,
de un modo u otro, en nuestras consultoras. El Captulo 2 inicia el camino mostrando variantes de mtodos de
mejora continua, culminando con el mtodo 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 guas 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 tcnicas, a menudo presentadas para su
discusin antes de que puedan ser aprovechadas, ilustra nuestro punto de vista sobre los modelos de madurez,
iv
Prlogo
Boria et al.
centrado en el MPS: Hay que tener la visin global del destino para que el camino se pueda transitar con
comodidad.
Tampoco es un curso de mtodos giles. El lector avisado debe entender que para introducir un mtodo gil
en una organizacin hace falta un entrenador o un mentor que gue la implementacin da a da. Producir una
organizacin gil a partir de una que no lo es requiere experiencia y adaptacin a las necesidades de la
organizacin.
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 haramos muy
poca justicia si intentramos resumirla en estas pocas pginas.
El libro intenta describir las actividades de consultora que tienen lugar en muchas organizaciones. Los
autores hemos elegido un mecanismo de presentacin de los materiales que est a mitad de camino del libro de
texto y la narracin de una historia que nos permite divertirnos con los personajes. Esperamos que se entretengan
con su lectura.
Nota de Cautela
Ningn 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 Prlogo queremos rendirle un
pequeo 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 Obstculo de Deming, La esperanza de postre instantneo --- la suposicin de que
una o dos consultas con un estadstico competente pondr a la empresa en el camino a la calidad y la
productividad postre instantneo. No es tan simple, siempre ser necesario estudiar y ponerse a trabajar.
No somos estadsticos expertos, pero hemos visto el mismo sntoma en muchas empresas traducido a una
invitacin a almorzar a cambio de un consejo gratuito que despus se intenta llevar a la prctica 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 creacin 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 adems de la herencia,
los autores siempre estn 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 autora usado en algunas partes de este libro.
Prlogo
Autores
Jorge Luis Boria

Master of Engineering in Computer Science por Cornell University, Estados Unidos. Senior Advisor del
Modelo MPS. Evaluador Lder 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 formacin que recibi trabajando para ella
en TeraQuest Metrics. Joyce fue a la vez amiga, formadora, orientadora y entrenadora.
Viviana Leonor Rubinstein

Licenciada en Computacin Cientfica por la UBA. Certified Project Manager, UT-SQI. Evaluadora Lder
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 volmenes para la enseanza de computacin en colegios
secundarios.
Viviana quiere agradecerle a Regina, su mam, con la que comparti la escritura de su primer libro.
Andrs Oscar Rubinstein

Programador y Analista de Sistemas de la Pontifcia Universidade Catlica do Rio de Janeiro. Evaluador
Lder Intermedio MPS. SCAMPI Lead Appraiser DEV y SVC. Scio 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.
Andrs 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 Andrs agradecen a Jorge por su liderazgo en la confeccin de este libro, sin el que tendra sido
imposible su realizacin.
vi
Prlogo
Boria et al.
PARTE I Introduccin
CAPTULO 1 - INTRODUCCIN
1.1 El propsito del libro
Este libro est dirigido a (en orden de inters creciente):
implementadores de mejora de procesos de software que quieran conocer mejor los mtodos
giles para implantarlos en organizaciones de software;
gerentes de proyecto interesados en conocer mejor los mtodos giles para desarrollo de
software, sea para adoptarlos o para evaluar su adopcin;
ingenieros de software que intentan trabajar em un proyecto gil;
profesores de grado en Computacin;
estudiantes de grado en Computacin;
profesores de postgrado en Ingeniera de Software;
estudiantes de postgrado en Ingeniera de Software.
En la medida en que los mtodos giles y los modelos de madurez han sido considerados trminos opuestos
en las disciplinas de desarrollo y mantenimiento de software, es difcil concebir un texto que busque alzar un
puente entre los dos mundos. Ya fue hecho, sin embargo, con gran suceso, en el moderno clsico [BOEHM &
TURNER, 2003]. El modelo de referencia para ellos es el CMMI, siendo fcil de imaginar la conversin para el MRMPS-SW, dada la intencional compatibilidad entre los dos.
1.2 Definicin de mtodo gil para este libro
1
Este libro est principalmente enfocado en cuatro mtodos giles : Kanban, Scrum, XP y FDD (Feature Driven
Development). Esta eleccin no es por azar. Esos cuatro mtodos cubren la mayora de las implementaciones
giles realizadas en el mundo. Adems, cubren casi todas, sino todas, las necesidades de uso de mtodos giles.
Cada uno de estos mtodos ser debidamente explicado en el captulo 3, donde se los introduce al lector.
Obviamente, esto ocurrir en orden creciente de complejidad: Primero el ms sencillo y el que tiene el mayor
retorno de la inversin, Kanban. Kanban tiene alto retorno porque al organizar las tareas y detectar los problemas
rpidamente permite al equipo que lo utiliza aumentar el tiempo disponible para mejorar sus procesos e intentar
nuevas mejoras. Scrum, que frecuentemente es el mtodo que se elige desde un principio, ac se ve slo 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 tcnicas se suman a las ya vistas a
medida que la empresa gana en definicin de sus procesos y en el nmero de su personal.
1.3 Si la mejora de procesos de software es la respuesta, Cul es la pregunta?
El principal enemigo de una empresa desarrolladora de software es la baja calidad. Hasta ahora, nadie tiene
una propuesta vlida para mejorar la calidad, salvo la mejora de procesos, que pasa a ser entonces la cuestin
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 estn en su lugar para
conseguir que se aprovechen las condiciones de los individuos y las herramientas de software. Es comn 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 ecuacin el personal capacitado sumado a
herramientas de software, sumado a procesos bien definidos culmina (despus del signo de igualdad) en xito y
Las principales referencias de cada uno de los mtodos estn indicados cuando se describe cada uno en los captulos
siguientes.
En este libro utilizaremos en lo que sigue el trmino organizacin para referirnos a todo tipo de grupo humano organizado
para la realizacin de tareas con un propsito comn, sea con o sin fines de lucro.
Captulo 1
felicidad. En la segunda ecuacin la falta de procesos bien definidos incrementa los riesgos y produce frecuentes
problemas en los productos resultantes.
Figura 1.1: Relacin 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 organizacin que nace de una idea de estudiantes universitarios.
La empresa que crean es pequea y por hacerse a s mismos una broma, la han llamado Tahni-Tahni. El nombre
surgi cuando una de las fundadoras lleg a la reunin de creacin un poco retrasada y al mirar el nmero de
personas alrededor de la mesa dijo, Somos una empresa tiny-tiny. Sus futuros socios encontraron eso gracioso y
le pusieron de nombre Tahni-Tahni, 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 recin nacida, creada por jvenes emprendedores, no ha seguido un plan de crecimiento
ideal, ms bien ha crecido a saltos, y los mares embravecidos que ha tenido que capear la han hecho ms fuerte.
Los problemas de la empresa no son poco comunes, son los ms frecuentes para una organizacin de ese tamao 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 descripcin de Kanban para el principio de un
proyecto de mejora de procesos; Scrum en relacin a las actividades de gerencia de proyectos ms comunes; XP
(Extreme Programming) para lo que constituye la categora de las reas de ingeniera de software tratadas en el
nivel D (Ampliamente Definido) del MR MPS SW. Cuando una empresa crece, los mtodos anteriores comienzan a
mostrar limitaciones. La coordinacin de muchos equipos en Scrum de Scrums presenta mayores limitaciones que
2
los mtodos tradicionales. XP ya es difcil de controlar en proyectos medianos. Acompaando el crecimiento de T ,
la propuesta es una metodologa conocida como Feature Driven Development (FDD). En torno de la cuestin del
cambio organizacional, seguiremos el camino de la metodologa Lean, que se concentra principalmente en la
resolucin de problemas a travs de la mejora de procesos.
Tambin en este captulo describimos cada uno de los captulos restantes. Cada captulo 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 (Captulos 1 a 4)
se sientan las bases para que el lector pueda comprender los mtodos y filosofa de trabajo que los autores
proponen. La segunda parte (Captulos 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 resolucin encarada por los socios basada en el
uso de Kanban y Scrum. La tercera parte (Captulos 7 a 9) desenvuelve la temtica de Madurez Media, los niveles E,
D, y C del Modelo MPS, donde aparecen XP y ms adelante FDD. Finalmente, la cuarta parte (Captulos 10 y 11)
2
expone como la madurez definida de T le permite alcanzar un conocimiento profundo del funcionamiento de sus
2
procesos, caracterizndolos cuantitativamente. El libro se cierra con un resumen del viaje de T desde su creacin
hasta su venta billonaria.
En el Captulo 2 explicaremos nuestra filosofa de mejora de procesos. Para ello utilizaremos el mtodo 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. Tambin aprovecharemos el Captulo 2 para hablar de una visin sistmica
Captulo 1
Boria et al.
de las organizaciones y de la relacin multicausal de los eventos. De este modo preparamos al lector para que
entienda porque una sola accin puede resolver muchos problemas y como a veces es necesario aplicar mltiples
acciones (y esperar) para obtener resultados. El libro de [POPPENDIECK et al., 2010], Leading Lean Software
Development, es nuestra gua por este territorio. Tambin, donde es til, citamos material del clsico de
[MEADOWS, 2008] Thinking in Systems, A Primer. Los dos libros revolucionan el pensamiento clsico, lineal, de los
gerentes tradicionales, y abren la puerta a una gerencia ms gil, ms integrada y con ms posibilidades de xito.
En el Captulo 3 introducimos los mtodos giles propiamente dichos. Si bien Lean es un mtodo gil segn
3
sus creadores y es reconocido como tal por la comunidad gil , su uso exige mucho conocimiento y est ms all
de los objetivos de este libro. En cambio, las tcnicas que proponen Kanban, Scrum, XP (Extreme Programming) y
Feature Driven Development (FDD) son del mismo modo exitosas y mucho ms fciles de adoptar, sobre todo si se
lo hace en el orden en que las proponemos en este libro. Esta es una introduccin a los mtodos y en ningn
momento pretende remplazar la lectura de los textos clsicos del tema, que se citan en la bibliografa y que
recomendamos fuertemente al lector.
El Captulo 4 se dedica al eje central de este libro, el modelo de Mejora 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 guas que Softex ha publicado y que se encuentran accesibles en el sitio web de esa
4
organizacin . Las guas 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 evolucin de la cultura imperante en la empresa que fuera inducida por la maduracin de
los procesos, manifiesta en el cambio de los niveles de madurez del modelo, concepto en el que nos detendremos
en este captulo, as como en la arquitectura del modelo que permite encontrar en l las herramientas para su
implementacin. Para concluir el captulo explicamos el concepto de evaluacin y como una organizacin puede
aplicarlo a s misma, para entender dnde se encuentra y qu camino le falta recorrer.
2
El Captulo 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 tpicos de
una empresa que funciona bien cuando todas las cosas estn en su cauce. Los pequeos problemas cotidianos (un
embarazo, una zona sin recepcin telefnica, un cliente apurado) pueden desencadenar una tormenta perfecta
2
que arruine la mejor reputacin. Es ah cuando los amigos de T deciden introducir mtodos 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 evaluacin formal con un evaluador lder y pasan con xito. La adopcin del MPS
2
por la empresa T es ahora un hecho.
En el Captulo 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 configuracin, que en germen ya comenzaran a implementar en el nivel G; la medicin, que
la formacin 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 adaptacin, a veces nuevos
desarrollos, hace que los procesos de la gerencia de portafolio de proyectos les resulten valiosos para entender
cmo organizar el crecimiento de la demanda. Este crecimiento les lleva a plantearse uno de dos caminos: crecer
internamente, lo que significara ampliar el espacio fsico para admitir ms desarrolladores, con la consecuente
inversin fija; o subcontratar parte del trabajo. Para tomar la decisin, los socios se apoyan en los procesos de
adquisicin y deciden a favor, lo que les lleva a implementarlos. Aun as, su pequeo equipo inicial debe dividirse
para atender el nuevo volumen de trabajo, e incorporan un nmero pequeo de desarrolladores. Para organizar
los proyectos, los socios deciden utilizar prcticas de Scrum, que les resultan compatibles con el MPS. Para
2
demostrrselo a s mismos, la T pasa por una nueva evaluacin y alcanza el Nivel F.
En el Captulo 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
Captulo 1
asimismo sus oficinas. Una reunin fundamental los pone en la encrucijada: A dnde queremos llevar a T ?
Finalmente se resuelve crear una visin ambiciosa: Ser una de las diez mejores fbricas de software del mundo.
Preparndose para el crecimiento, los socios entienden que su visin se completa con una base de conocimientos
que puedan ser compartidos, usados y expandidos por todos los ingenieros y dems empleados de su empresa.
Sus procesos de gestin evolucionan asimismo para aprovecharse de este conocimiento de manera sistemtica. De
manera normal surge en la base de conocimientos la definicin de los procesos organizacionales.
Cuando los empleados superan un nmero considerado crtico de manera arbitraria, las reuniones de proceso
se sistematizan y se formalizan en un proyecto para su evaluacin y mejora permanente. Las constantes
incorporaciones fuerzan asimismo a organizar la identificacin, captacin, preparacin y retencin 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 organizacin 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 prcticas de reuso para mejorar todava ms la calidad de sus productos y
el rendimiento de su personal.
En el segundo Captulo de la tercera parte, el Captulo 8, introducimos las tcnicas y prcticas de Extreme
Programming (XP) que no se superponen con las anteriores ya incorporadas. Una discusin en una retrospectiva
lleva a identificar la variacin en la interpretacin de las tcnicas 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 reunin del grupo de procesos organizacionales se vincula asimismo a esa indefinicin con un
grupo de defectos que estn 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 implementacin de procesos de MPS. Esto lleva a algunas variantes, como por ejemplo
que pair programming, la tcnica por la cual dos programadores trabajan juntos en un mismo programa, sea
implementada con un coach que registra los defectos encontrados para permitir realizar anlisis 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 visin
estratgica de su negocio y una vez ms lo hacen siguiendo el modelo. En el Captulo 9 se introduce la visin 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 fbrica de
componentes que se pueden articular rpidamente para formar productos, reduciendo an ms sus defectos por
parte y aumentando a niveles muy altos su productividad. Cada decisin tiene un costo y un beneficio, pero hasta
2
este momento en la historia de la T no se aprenda sistemticamente de las decisiones ya tomadas. Para evitar
2
que ese conocimiento se pierda, la T incorpora mtodos de decisin formales que incluyen varias tcnicas que
aprovechan la historia. Pronto los proyectos las usan para tomar decisiones sobre la velocidad, la calidad esperada,
2
el reuso y la subcontratacin a terceros. La T es ya una organizacin con centenares de empleados y una slida
reputacin de calidad. Los llamados por referencias empiezan a ser internacionales. Debido a ese crecimiento y el
2
consecuente alejamiento fsico de los clientes, la T aadi a su arsenal el mtodo FDD, que le permite planificar
2
con mayor precisin los sprints. La T decide ser evaluada respecto al Nivel C del modelo MPS y a su vez, en una
evaluacin 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 pases
centrales, tiene centros de desarrollo en todas las regiones de Brasil y de Latinoamrica, y disfruta de un bien
ganado prestigio. Sin embargo, los socios no descansan en sus laureles. En el Captulo 10 vemos cmo se
aprovechan de la base de datos histricos que han amasado a lo largo de los aos para utilizarlos en su favor.
Identifican los procesos crticos 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 tcnicas que emplean en la toma de decisiones para incluir factores cuantitativos
y mejoran sus anlisis de causa raz para que se considere el costo beneficio de las posibles alternativas. La
gerencia de proyectos pasa de ser un arte con partes de ingeniera a ser una ciencia con partes de arte.
El Captulo 11 cierra el libro con los socios discutiendo sobre la compra de dos lneas de negocios por una
mega empresa. Para que su historia no sea un caso nico, el captulo hace la contabilidad de los factores que
10
Captulo 1
Boria et al.
permitieron su xito. Revisa entonces Lean, Kanban, Scrum, FDD y XP. Tambin, y muy fundamentalmente, el rol
del MPS como la herramienta de desarrollo organizacional que le permiti realizar este crecimiento en tiempo
rcord y con mnimos inconvenientes.
Captulo 1
11
CAPTULO 2 - EL MTODO 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 ancdota 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 patrn reconocible que ha sido pactado por
los interesados.
En una organizacin desarrolladora de software, Pedro, uno de los mejores programadores, era un ferviente
defensor de los procesos. Rpidamente convenci a sus colegas de equipo de trabajo para que adoptaran procesos
en la construccin de diversos documentos y, sobre todo, para definir la secuencia de pases y el criterio de
finalizacin, basado en la calidad objetiva, de cada producto. Los proyectos en los que Pedro participaba eran
exitosos con ms frecuencia que todos los dems, y los clientes de los mismos elogiaban el producto generado.
Finalmente las diferencias llegaron a los odos de la direccin y nuestro joven programador fue recibiendo
sucesivas promociones a cargos de cada vez mayor responsabilidad. No haba pasado mucho tiempo cuando
finalmente lo promovieron a jefe tcnico de desarrollo. Convoc a sus hasta entonces colegas y les hizo ver que su
promocin obedeca al reconocimiento que la alta gerencia haca del trabajo que segua procesos, por lo que
esperaba que todos colaboraran con l para ampliar su utilizacin y contribuir a su mejora. Hubo muchas cabezas
que asintieron y tras algunas preguntas y respuestas la reunin se dio por concluida. Solo Pablo, un programador,
que hasta la llegada nuestro hroe era considerado el programador estrella, se qued atrs.
-
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 dems entiendan mis procesos es una prdida 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 saln. 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 ensean qu partes del proceso hay que cambiar. Pero si t no sigues procesos, los
fracasos no nos ensean nada y t cargars 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 pliza 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 tuviramos memoria
perfecta, no cometiramos nunca errores y las especificaciones en lenguaje natural tuvieran un significado nico e
inamovible, entonces se relativizara mucho la necesidad de seguir procesos. Todava resultaran tiles para
coordinar el trabajo, pero para personas con memoria total se podran 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 organizacin 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-organizacin 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 ms
detalle de lo que plantearemos en este libro en otras fuentes. Los autores nos limitaremos a exhibir el
comportamiento mnimo 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 organizacin
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
Captulo 2
Boria et al.
la excelencia madurando como organizacin usando mtodos giles, para lo cual usaremos un caso de ejemplo y
un modelo.
Es el modelo MPS, en nuestro caso, aqul que orienta la secuencia de acciones en lo que hace al crecimiento
de la madurez organizacional. El modelo MPS, que explicaremos con ms detalle en el captulo 4, es un modelo de
desarrollo organizacional por niveles, que define los procesos que la organizacin debe implementar en su seno y
los resultados esperados de ese accionar, para ir avanzando de nivel a nivel. Aun cuando es la intencin 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 hbitos que se construyen en uno se
aplican en el que le sigue.
Hay necesidad, por lo tanto, de encontrar un mtodo que nos ayude a organizar el crecimiento en trminos
ms concretos de lo que hace el MPS, y que a su vez se compadezca de las necesidades de la organizacin en
cunto a sus negocios. Como se puede imaginar el lector, no hay una nica manera de hacer esto. Por ello, hemos
decidido anticipar la presentacin de un proceso del MPS, no en detalle, pero si mostrando su uso. Tomando
prestadas tcnicas 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 organizacin que pretende mejorar sus
5
procesos, teniendo en cuenta el negocio de la misma.
Atributos deseables de una Solucin: La solucin 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 ambigedad, pero no tanto que implique una planificacin detallada para
cada seleccin (DETALLE). Debe proveer un marco terico reconocible que ayude a medir el impacto de las
decisiones sobre el sistema en conjunto, no solo la optimizacin 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 solucin. El orden de
su importancia relativa se muestra en la siguiente tabla:
atributos
peso
NEGOCIO
DETALLE
SISTEMA
MARCO
suma
Tabla 2.1: Seleccin del Mtodo de Mejora de Procesos
Alternativas de Solucin: La literatura tiene muchos ejemplos de estos mtodos. 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].
Mtodo de Evaluacin: Utilizaremos una matriz de Pugh [PUGH, 1991] para evaluar alternativas cuando los
atributos son mltiples. Usado por Pugh en General Motors y descripto por l en su libro ya citado y previamente
en un artculo [PUGH, 1981], es uno de los mtodos de anlisis de alternativas ms difundidos entre ingenieros.
Cada columna representa una solucin y cada fila un atributo. Cada fila tiene un peso especfico que representa el
valor relativo de ese atributo frente a los otros. En cada interseccin fila/columna se evala el aporte que la
solucin de esa columna hace al criterio de esa fila. Previamente se ha establecido un mecanismo de evaluacin
que permite ajustar la objetividad al respecto de la medicin de cada atributo.
La referencia a un negocio est entre comillas porque se trata de los motivos de existencia de la organizacin. Si esa
organizacin es un hospital pblico que mide su impacto en la comunidad en la cantidad de curaciones que realiza o el
estado general de salud de la poblacin que atiende, entonces a esos efectos ese es su negocio. No se debe entender
como que solo aplica a organizaciones con fines de lucro.
Captulo 2
13
Criterios de Evaluacin 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 pginas para entenderlo, o muy
superficial, algo que permite muchas interpretaciones) o 0 (no tiene ninguna explicacin 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 sistmico. SISTEMA se mide como 3 (las acciones derivadas que impactan al sistemas se
reconocen mediante el mtodo), 2 (hay una visin perifrica pero el foco de las acciones es idntico al foco de la
mejora), 1 (se evalan resultados globales a nivel sistema aunque no se los prevea en el anlisis de impacto), o 0
(ninguna actividad relacionada con el efecto global forma parte del mtodo). 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 mtodo), 1 (se puede alinear al negocio pero el mtodo es agnstico y no lo menciona) o 0 (no
hay ninguna relacin evidente entre el mtodo y el negocio).
Describiremos ahora las cuatro opciones, tratando de que el lector mismo pueda juzgar la calificacin 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 refera a este procedimiento basado en el mtodo cientfico 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 todava mayor que la de aqul. Hacia el final de su vida Deming cambi el Check (validar) por Study
(estudiar) para enfatizar que el paso debe ser de anlisis ms que de inspeccin.
Puede justificadamente considerarse a Shewhart como el padre de la calidad industrial. Fue l quien
introdujo los diagramas de control estadstico para el anlisis de la estabilidad de un proceso a travs de la
medicin de un atributo. Dada su fecha de origen, es difcil encontrar el material original, pero en la mayora de las
7
citas el primer paso es identificar el problema y luego analizarlo. No hay una mencin explcita de los objetivos de
negocios, aunque es difcil imaginar que Shewhart los haya eludido, leyendo sus otros materiales. Posiblemente se
ha sacado (una vez ms) del contexto al mtodo y al hacerlo se perdi parte de su valor sistmico. Por lo tanto, sin
juzgar al mtodo en s pero si juzgando su uso habitual, podemos decir que PDCA es sencillo, fcil de aplicar pero
es factible de ser usado sin tener en cuenta el impacto en el negocio. Hay en varias versiones del mtodo
referencias a un proceso desarrollado por Deming para la mejora continua, lo que dara una mejor versin
sistmica del mismo, as como un posible vnculo con los objetivos de negocios. A continuacin 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
resolucin del problema; establecer un proceso para la coordinacin con, y conseguir la aprobacin de, la alta
direccin.
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 races del problema;
juntar datos adicionales si es necesario para verificar las causas races
DO (Hacer) Paso 3: Desarrollar Soluciones. Actividades: Establecer criterios para elegir una solucin; generar
soluciones potenciales que ataquen las causas races del problema; elegir una solucin; conseguir aprobacin y
soporte para la solucin escogida; planificar la solucin.
DO (Hacer) Paso 4: Implementar la Solucin. Actividades: Implementar la solucin 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 solucin; 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 autora.
Vase por ejemplo http://quality.enr.state.nc.us/tools/pdca.htm
14
Captulo 2
Boria et al.
ACT (Actuar) Paso 6: Estandarizar la Solucin (y Capitalizar Nuevas Oportunidades). Actividades: Identificar
cambios sistmicos y necesidades de entrenamiento necesarias para un implementacin completa; adoptar la
solucin; planificar y monitorear permanentemente la solucin; continuar buscando oportunidades incrementales
para refinar la solucin; buscar nuevas oportunidades de mejora.
El mtodo PDCA es slido, pero su edad ha hecho que varios de los detalles que su autor predicaba hayan
sido dejados de lado en su implementacin corriente, que es lo que un buen evaluador juzga: Su uso por encima
de su definicin. 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 repeticin 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 sistmicas y el vnculo con los objetivos de negocios estn
inmersos, de modo que cambiar ese proceso como fuera definido y colocar otro en su lugar puede tener como
consecuencia la prdida de ese entorno y en consecuencia la desmejora del proceso de mejora. Veamos ahora
como McFeeley lidia con ese problema, incorporando a su mtodo el detalle necesario (en exceso, segn nuestro
punto de vista).
2.3 El Mtodo IDEAL
Debido a la enorme influencia que Deming, y en consecuencia Shewhart, a quin aqul citaba
constantemente, tienen sobre la comunidad de mejora de procesos, este mtodo y los que describiremos ms
tarde estn fuertemente influenciados por PDCA. La Figura 2.1 muestra una descripcin grfica del mtodo 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 contine el ciclo una vez alcanzada la 5 fase. Si bien el autor de IDEAL
[McFEELEY, 1996] aclara que los lmites entre fases son ms 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 Mtodo IDEAL [McFEELEY, 1996]
La primera fase se denomina, con lgica, Initiating, que traducido quiere decir Comenzando. Tiene tres
bloques, pero en la descripcin detallada no se las considera, siendo descriptas en cambio 10 tareas que se
detallan, algunas hasta el nivel de subtareas. La misma situacin de desacople entre la grfica y la descripcin
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 comunicacin de los avances.
La fase que sigue se denomina Diagnosing y tiene seis tareas. Se traduce fcilmente, dada la similitud de los
vocablos, por Diagnosticando. En efecto, es la fase en la que se realiza el anlisis de la brecha existente entre las
Captulo 2
15
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 difcil entender como se consigue llegar a su
ejecucin. La fase tiene como criterio de finalizacin que se hayan entregado las brechas halladas y las
recomendaciones al comit de gestin y hayan sido aceptado, as como que ya haya un boceto del plan estratgico
de accin.
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 ms lgico (Planificar, o
Detallar) no conformara. En esta fase se ajustan prioridades y se forman los equipos que llevarn adelante la
definicin y difusin de los cambios y mejoras a los procesos. Notablemente, el mtodo recomienda que la
planificacin la realice el comit de gestin, es decir los gerentes que realizan la supervisin estratgica del plan de
mejoras, y no el grupo de procesos. Este excelente consejo es ignorado en la prctica. La fase tiene 14 actividades.
El criterio de finalizacin es que el plan estratgico se haya completado y aprobado, y que la visin organizacional,
el plan de negocios y el plan estratgico de mejora de procesos tengan sinergia entre s.
La fase que sigue se denomina Acting, que se traduce por Actuando. Esta fase es la ms 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 prctica. 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 sntomas. Esta fase tiene como criterio de xito que la
estrategia de despliegue y el plan se han ejecutado plenamente, o estn en camino de serlo. Las soluciones que se
han adoptado (o piloteado) se han documentado correctamente y estn bajo control del grupo de procesos, y se
tiene claro cmo se las va a mantener. La mejora de procesos ha comenzado a estar institucionalizada en la
organizacin. Esta fase hace referencia a muchas pequeas mejoras realizadas en paralelo, bajo un nico plan
estratgico y mltiples planes tcticos. Sin embargo, la gran mayora de las implementaciones de IDEAL adolecen
del mismo defecto: Un enorme plan tctico que nunca termina de ejecutarse y que sufre del sndrome 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 iteracin del ciclo IDEAL, se denomina Leveraging, que
significa Aprovechando, o Sacando Provecho, en realidad es la variante de la primera fase, puesto que tendra 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 ms comn es que
se definen soluciones pero no se las implementa ni en pilotos, lo que se justifica por el sndrome del correo: ya que
se han aceptado nuevos pedidos de cambio, el grupo de mejoras se enfocar en la definicin de soluciones y no en
su implementacin. Como consecuencia una larga lista de cambios es lanzada simultneamente sin suficiente
preparacin, por la demanda de capacitacin que eso conlleva, y el proyecto fracasa. IDEAL no es un mal mtodo,
pero es muy detallado (se describe en un documento de 236 pginas) lo que hace que mucha gente lo haya
8
implementado sin haber ledo esos detalles con la consiguiente prdida de varios elementos fundamentales,
9
como el vnculo con los objetivos de negocios, el paralelismo en la implementacin y la visin sistmica
(multicausal, con lazos de retroalimentacin y demoras entre causa y efecto visible) que son indispensables para
establecer un programa de mejora continua.
Lo mejor de IDEAL es su visin de la mejora de procesos (Figura 2.2) basada en los objetivos de la
organizacin y soportada en la visibilidad del proyecto, la comunicacin horizontal y vertical entre las partes, la
captura, retencin y aprovechamiento de la experiencia (lecciones aprendidas), y una red de soporte de todo el
proyecto. De ese modo se sostiene el plan tctico y el estratgico para culminarlos con xito.
Si el lector no se siente cmodo con la afirmacin de que un nmero muy grande de personas no lee los detalles antes de
implementar un modelo, los autores querran remitirlo al trabajo de Royce, Managing the Development of Large
Software Systems [ROYCE, W., 1970], a quin se considera el padre del ciclo de vida en cascada por ese mismo artculo, y
que lamentablemente est mal citado: Lo que Royce dice en ese trabajo es que esa visin 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 aplicacin,
una de las maneras de resistir el cambio.
16
Captulo 2
Boria et al.
Figura 2.2: Visin 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 ms de PDCA, con nfasis en las
10.
herramientas de Six-Sigma El ciclo de Arthur se basa en la medicin. El uso de los datos disponibles y la
bsqueda tipo inteligencia de negocios es el fundamento del anlisis, en vez de los defectos o la brecha respecto
de algn 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 anlisis de los datos antes de entrar en el ciclo.
El ciclo tiene cuatro fases, Focus, enfocar, la primera, est basado en un hecho estadsticamente demostrable
por la distribucin de los defectos: Unos pocos procesos son responsables de la mayora de los mismos. Encontrar
esas fbricas de defectos enfoca el proceso de mejora en donde ms rendimiento tiene. Para Arthur, la
11
aplicacin 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 minsculo grupo de procesos permite
eliminar un nmero 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 implementacin. El
MPS (ver el Captulo 4) contiene resultados esperados de procesos que ayudan a entender la implementacin de
los pasos de mejora por identificacin de las causas races. Utilizaremos a lo largo del libro esta capacidad de
12
identificar las causas de las cosas para poder mejorarlas o difundirlas . Utilizar el anlisis de causa raz de forma
sistemtica es una de las herramientas ms poderosas de la mejora de proceso, y una de las tres herramientas
intelectuales (junto con el anlisis y gestin de riesgos y la visin sistmica del proceso) que ms rendimiento
tienen en los procesos intelectuales que acompaan, o deben acompaar, 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 gestin 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 mtodos, fundamentalmente estadsticos. El trmino surgi
del anlisis estadstico de la ocurrencia de defectos en manufactura. La madurez de un proceso de fabricacin puede
expresarse como la cantidad de desvos estndar () que se aleja de la media de la poblacin 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 mtodos que se conjuntaron en un proceso para alcanzarlo.
Pareto fue un estadgrafo francs del siglo XX que se destac en el estudio de la distribucin de la renta. En 1906 l hizo la
famosa observacin de que el veinte por ciento de la poblacin posea el ochenta por ciento de la propiedad en Italia,
posteriormente generalizada por Joseph M. Juran en el principio de Pareto (tambin 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.
Captulo 2
17
simples. En todos los casos, Arthur se inclina por la simplicidad, dedicndole 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 ms 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 interpretacin a las instrucciones y que algunos pasos estn faltando, porque el autor de
la receta asumi que los que la intentaran ejecutar tenan conocimientos culinarios en grado suficiente, lo que no
result una prediccin verdadera. Adems, 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 quera que fuera harina de maz. El
anlisis de causa ha detectado estos defectos y se ha sugerido que se hagan cambios a la receta, definiendo con
precisin los pasos para que no haya diferentes interpretaciones, y corrigiendo los errores y ambigedades.
Un grupo de procesos sin la suficiente experiencia considerara que ha cumplido su cometido: El proceso, de
ejecutarse correctamente, debera funcionar. Jay Arthur (y los autores) no se conforman con esa definicin,
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 cundo, dnde
y qu medir. Uno de los pasos ms importantes en la definicin 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 ms altos
de madurez, a partir del Nivel B, pero es una de las cualidades ms valiosas de un gerente. Por ejemplo, si nos
preocupa que la mayora de los proyectos termina despus de su fecha de entrega y hemos hecho cambios en
consecuencia para adelantar la produccin de resultados, medir las demoras que se producen en aquellos puntos
es de suma importancia. Medir solo el resultado final, el desvo 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 ms de
lo necesario el anlisis 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 organizacin resalta y
recompensa los esfuerzos de su personal en relacin 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 sern hasta negativos, pero es indispensable rescatarlos como esfuerzos vlidos
porque la organizacin aprende.
2.5 Lean Simplified
El ltimo mtodo es Lean Simplified [ARTHUR, 2006]. Jay Arthur desarroll ese mtodo como una extensin
de su anterior FISH que vimos ms arriba con el propsito de hacer ms clara la aplicacin del mismo, enfatizando
la cadena de valor que lleva desde el pedido del cliente a su satisfaccin por la entrega del producto. La palabra
inglesa Lean significa delgado, sin peso dems. Arthur elige llamarlo Simplified, simplificado, porque ha reducido la
demanda estadstica que su mtodo FISH tiene. Llamaremos a este mtodo LS, para evitar usar trminos en ingls.
LS, como lo explica Jay Arthur en [ARTHUR, 2006] es un mtodo para la empresa manufacturera. Sin
embargo, modificando o dejando de lado lo que no aplica para el desarrollo de software, es un mtodo poderoso
para identificar y resolver problemas con vista a la mejora continua. Presentamos ac nuestra versin de LS
adaptada a la produccin de software.
13
18
Los diagramas SADT, o IDEF0 en su versin norma internacional, son ms detallados y de uso difundido. Tambin los
diagramas de flujo con andariveles que permiten discernir responsabilidades. Asimismo sera posible disear el proceso
siguiendo tcnicas de flujo de datos del Anlisis Estructurado o con herramientas de UML.
Captulo 2
Boria et al.
14
En el corazn de LS est el tema de la velocidad de produccin . 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 prdida de calidad ni aumento de los precios. El libro de [RODIN, 2010] es una
visin de cmo la demanda por servicios gratuitos entregados en el momento y sin costo alguno est
revolucionando los negocios. Para las organizaciones que fabrican software el desafo est lanzado: Hay que
eliminar los defectos y todas las demoras para entregar ms 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 cules 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 organizacin est justificada
en actuar como lo hace.
En cada empresa hay dos fbricas, la principal que disea, vende, factura y entrega el producto, cuya frmula
es Velocidad con Calidad + Ganancias = Beneficio. La segunda es la fbrica de arreglos, que corrige todos los
errores que se van cometiendo a medida que se disea, vende y factura el producto. Hay siempre una fbrica 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 atribucin ni contabilizacin. Esa fbrica tiene otra frmula: Defectos + Demoras = Prdidas.
En el fondo, LS se centra en la velocidad de produccin. La relacin 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 recepcin
15
del pedido del cliente a la satisfaccin de sus necesidades . Una vez ms, el mapa tiene que ser sencillo, pero no
tanto que resulte fcil de malinterpretar. Adems, puesto que se trata de un sistema de traccin donde la salida
fuerza al proceso anterior y as sucesivamente, este mtodo atiende principalmente la voz del cliente. Hecho
correctamente, esto genera valor para el cliente y en consecuencia, la organizacin.
Foco en los Defectos
Al intentar reducir la friccin que demora los procesos, Toyota descubri que hay muchas formas de
desperdicio (muda).
1.
2.
3.
4.
5.
6.
7.
Exceso de produccin (en software, incluir cdigo 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
electrnico hace de esto un problema inexistente, pero si se mantienen planos en papel o en
pizarrones puede llegar a ocurrir)
Movimientos innecesarios del personal (tpicamente en la instalacin o en la validacin, a menudo en la
etapa de generar requisitos)
Procesamiento innecesario o inadecuado (no es muy comn, pero en ciertas organizaciones
burocrticas hay ocurrencias de esto)
Defectos que obligan a reparaciones y retrabajo (no hay porqu explicar esto en nuestra profesin)
Si la organizacin trabaja con plazos cortos y se concentra em mantener la flexibilidad se obtienen beneficios
en calidad y satisfaccin del cliente. En el captulo 3 veremos cmo un grupo de desarrolladores de software
14
15
La empresa Toyota invent el mtodo de "produccin esbelta" (lean production) tomando como referencia los
supermercados de los EEUU, donde percibieron que cuando los anaqueles de los supermercados alcanzan el punto mnimo
del inventario son reabastecidas tan rpidamente como los clientes "quitan" los productos de la gndola. En un sistema de
traccin, 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 seala el punto exacto. El nombre en japons de esa tarjeta es
Kanban, palabra que hoy identifica tanto a la tarjeta como al sistema.
No es lo mismo or y reaccionar que escuchar y satisfacer.
Captulo 2
19
construy mtodos 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 aparicin.
LS sigue con la organizacin 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 interpretacin de esas tareas en actividades de ingeniera 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 afirmacin 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 gestin de configuracin en la ingeniera
de software. Pulir es mantener el rea limpia para exponer defectos y prdidas. En software esto se manifiesta en
la aplicacin de formas y patrones que permiten el anlisis y la inspeccin por terceros, por ejemplo el uso de
estndares de programacin 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 afirmacin de calidad esto debiera ser alcanzable.
Otra de las normas que rigen LS es la preminencia de la demanda por sobre la produccin. En vez de producir
en anticipacin de lo que se demandar se produce a partir de lo que se pide. En nuestra traduccin al mundo de
procesos esto significa que no intentaremos mejorar lo que no se siente que est roto. El vocablo ingls pull que
significa halar, tirar, representa este pensamiento, contra el vocablo ingls push que significa empujar. Es comn
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 inversin. 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 eliminacin de
un obstculo a la productividad se gana un aliado para los futuros cambios, que adems cuenta ahora con tiempo
extra para apoyar la creacin y difusin de nuevos cambios.
LS tiene ms para aportar, pero en lo esencial nos alcanza con lo expuesto para entender las ventajas y
desventajas del mtodo. Nuestra matriz de Pugh para los cuatro mtodos queda as:
atributos
peso
PDCA
IDEAL
FISH
LS
NEGOCIO
DETALLE
SISTEMA
MARCO
19
22
26
42
suma
Tabla 2.2: Seleccin del Mtodo de Mejora de Procesos
Con estos valores es claro que nos inclinamos por LS. Por supuesto, se puede criticar esta decisin, porque los
valores colocados en la interseccin son arbitrarios hasta cierto punto. En una decisin de mayor impacto
econmico sera deseable que la puntuacin estuviera mejor detallada para lograr mayor objetividad.
Puesto que vamos a utilizar LS en nuestros anlisis 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 resolucin continua de problemas races 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 atencin. 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
Captulo 2
Boria et al.
6.
7.
8.
Lo nico que agrega valor en un proceso es la transformacin fsica o informacional de la materia-prima

en algo que el cliente quiere.
Los errores son oportunidades para el aprendizaje.
La resolucin 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 mximas, en lo que aplican a las reas
de desarrollo de software. No vamos a limitarnos a seguir al modelo MPS en su aplicacin, vamos a procurar
identificar y resolver los problemas que son comunes en las empresas desarrolladoras de software.
Captulo 2
21
CAPTULO 3 - LOS MTODOS GILES: KANBAN, SCRUM, XP Y FDD

3.1 Qu son los mtodos giles?
En el captulo anterior presentamos la mejora continua de procesos y decidimos tomar como referente a LS.
Las ventajas de un mtodo liviano, desprovisto de burocracia, que enfoca directamente en las necesidades de
negocio no pasaron desapercibidas para los metodlogos de Ingeniera de Software. Ya en el siglo pasado haban
nacido varios mtodos de desarrollo que se apoyaban en las ideas de produccin 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 ms. 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 ingeniera de software de modo nico, el Agile Software Development Manifesto .
El contenido del manifiesto se puede leer en lnea, pero consideramos que su influencia es tan importante, y
sus coincidencias con el mtodo de Toyota TPS son tantas que lo incluimos ac.
Manifiesto para el Desarrollo de Software gil
Estamos descubriendo mejores mtodos para desarrollar software ejercitndolos y ayudando a
otros a usarlos. A travs de este devenir apreciamos:
Los individuos y las interacciones
por sobre los procesos y las herramientas
Software que funciona
por sobre una documentacin completa
Colaboracin con el cliente
por sobre la negociacin 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
ms.
(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 ms bsicas, hay entre los autores ms 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 mencionramos ya en el captulo anterior en la seccin Foco en los Defectos. As como Toyota tiene
su mtodo TPS que es una forma de Kaizen, los mtodos giles se apoyan en perodos de produccin cortos y
mucha colaboracin 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 direccin de la compaa. 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 burocrticas 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 prximo perodo de trabajo, llamado en la jerga
19
20
de los agilistas un Sprint , los mtodos giles consiguen motivar al personal de los proyectos y
comprometerlos con el resultado al permitirles tomar decisiones de peso. Dada la corta duracin de un Sprint,
usualmente nunca ms de cuatro semanas, los equipos pueden ver sus resultados de inmediato. Tambin es
importante la participacin 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 mtodos 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 analoga, cada tramo de un
proyecto gil se considera un Sprint.
Captulo 3
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 organizacin del cliente. De ese modo el producto parcial es concreto y
mantiene la concentracin y el foco en el negocio.
Los mtodos 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 participacin del cliente en las decisiones de
negocio, adems de poner un freno concreto a los cambios caprichosos, los mtodos giles rescatan el valor de la
ingeniera de software ante los embates burocrticos de ciertos niveles en las corporaciones. Entre otras virtudes,
la decisin 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 ms valiosos y ms revolucionarios.
Los agilistas se consideran un movimiento pro-mtodos. Los que creen que la agilidad es contraria a los
procesos y las herramientas, a la documentacin o los planes se equivocan. Lo que buscan es que estas entidades
estn 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 ms 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 planificacin de detalle no puede llevar ms 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 prctica,
que la documentacin debe ser fcil de mantener y responder a una necesidad orgnica del proyecto y debe ser
hecha cuando esa necesidad se manifiesta y no como una condicin contractual despus de que el producto se
haya concluido. En cuanto a herramientas, baste recordar que la integracin continua, uno de los baluartes de los
mtodos giles, requiere excelentes herramientas de gestin de configuracin 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 mtodos giles que encontramos ms tiles en diferentes etapas de una empresa son Kanban
,
23
24
25
Scrum , XP y FDD . El orden en que los describiremos va del ms sencillo (Kanban) al ms complejo (FDD).
Scrum y XP se apoyan en Kanban y en particular describiremos XP en su versin XBREED, que mezcla los conceptos
de XP con las prcticas de Scrum para obtener un proceso ms slido y confiable.
3.2 Kanban: Midiendo el flujo
Quin introdujera Kanban como mtodo gil fue [ANDERSON, 2011]. El mtodo 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 produccin. 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 caracterstico 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 adems no se sabe si el producto final tiene comprador o
no. De ese modo se desperdicia trabajo y materiales.
El mtodo Kanban permite alcanzar un ritmo de produccin 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 mtodo Kanban es uno de los mecanismos que subyace el TPS pero la
adaptacin para ingeniera 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 mtodo, puesto que los
resultados eran muy alentadores.
21
22
23
24
25
26
27
KNIBERG, H. e SKARIN, M., 2010

Cuando usamos Kanban con maysculas nos referimos al mtodo Kanban desarrollado por Anderson, cuando se lo usa en
minsculas, kanban, hace referencia a cualquier otro uso, como el sistema kanban de Toyota o el tablero kanban que
veremos ms adelante.
KNIBERG, H., 2007
KNIBERG, H., 2007
PALMER, S. R. e FELSING, J. M., 2002
Esto tambin es conocido como sistema Just in Time, o con las siglas JIT.
Toyota Production System.
Captulo 3
23
El mtodo es en s muy simple, pero al usarlo de determinada manera trae consigo mltiples ventajas que
sealaremos al explicarlo. Si bien el texto [ANDERSON, 2011] es la base que permite entenderlo profundamente,
para el lector que aspira a un manejo ms pragmtico aconsejamos [KNIBERG & SKARIN, 2010] que se remite a lo
esencial de la implementacin, sin por ello dejar de lado lo anecdtico que permite la comprensin, o como se dice
en Mxico, el aterrizaje del material.
Un elemento central en el mtodo es el uso del tablero kanban. No se debe confundir el uso del tablero con
la aplicacin del mtodo; 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 segn le convenga al
28
equipo. Lo ms frecuente es usar un tablero donde se puedan pegar notas autoadhesivas que llamaremos psit ,
como en la Figura 3.1, dividido en columnas verticales. Cada columna indica un estado de las tareas. Las psit
contienen los nombres de las tareas. La primera columna de la izquierda tpicamente contiene lo pendiente, es
decir la lista de las tareas a realizar que an 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 razn que se haya convenido en el equipo, y la corre a la columna siguiente hacia
la derecha. En algunos mtodos 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 finalizacin en los rincones del psit, diseados para ese uso,
29
como se muestra en la Figura 3.2 . Cuando termina de realizar su tarea, toma el psit de donde lo coloc y lo
mueve una columna ms a la derecha, de donde a su vez lo tomar alguien ms para continuar con el proceso
hasta que la tarea alcance el punto donde se acord se la considerar completa, punto en el cul alcanza la
columna de la extrema derecha del tablero.
Figura 3.1: Tablero kanban
No hay ningn motivo especial para utilizar tarjetas autoadhesivas o los tableros en s. Pueden utilizarse
planchas de cartn 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 resolucin y entender tanto el estado actual del proyecto como la
ocupacin del personal.
Figura 3.2: Nota psit del Tablero kanban

28
Psit es un artculo nuevo en el diccionario de la Real Academia Espaola, avance de la vigsimatercera edicin. Su definicin
es (Del ingl. Post-it, marca reg.). 1. m. Hoja pequea 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 rincn 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 finalizacin y el inferior izquierdo (sin llenar en el
ejemplo) la fecha real de finalizacin. Cuando se usa esta convencin a menudo los psit se copian y se pegan unos sobre
otros para tener la historia de su desarrollo.
Captulo 3
Boria et al.
En el mtodo Kanban se limita el nmero de tareas en cada columna. El objetivo es identificar claramente la
capacidad del sistema y balancear la demanda contra la capacidad del equipo. El mtodo Kanban permite
comprender el tiempo de trnsito de cada tarea, desde que ingresa al sistema por la izquierda hasta que culmina
en la columna de la derecha. (Hay algo de satisfaccin 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 parmetros de
produccin, el equipo alcanza un ritmo sustentable, es decir, que puede mantenerse indefinidamente,
consiguiendo en efecto predictibilidad que otros mtodos tardan mucho en alcanzar.
Puesto que esa regularidad se hace presente muy rpidamente, toda obstruccin a esa regularidad es
rpidamente 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 estimacin del tamao y la complejidad
del producto aparecen muy pronto en el tablero. Es fcil relacionar estos problemas con el costo del proyecto,
dado que al restringir el nmero de tareas en cada columna las personas tienen que atender los cuellos de botella
para ayudar a resolverlos. De esta manera el mtodo Kanban vincula rpidamente los problemas tcnicos del
proyecto a los resultados de negocio, sin tener que establecer complicados mecanismos de anlisis. Este es un
resultado que no se anticipaba al introducir el mtodo pero que es uno de los puntales de su adopcin.
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 ms frecuentes y con mayor
funcionalidad. A su vez, esta situacin hace que el equipo se sienta ms a gusto y ponga ms ahnco 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 viramos en el Captulo anterior en las discusiones sobre el mtodo de mejora de procesos a
seguir. Dado el origen comn de esos mtodos (las diferentes versiones de calidad total) y el hecho de que el
mtodo Kanban es una adaptacin al desarrollo de software de una tcnica 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 Realizacin; Medir y Manejar el Flujo; Explicitar Polticas de Proceso; y Utilizar
30
Modelos para Reconocer Oportunidades de Mejoras.
El primer punto saliente en la construccin 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 implementacin
del mtodo es imprescindible que el equipo, junto con el proveedor de informacin (ms adelante llamaremos a
este rol Dueo 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, etctera).
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 Anlisis, la que le sigue a
esta sea Analizado, la siguiente En Desarrollo, la siguiente Listo para Prueba, la siguiente Listo para
Integracin, 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 eleccin 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 clulas integradas donde todos esos roles se
cumplen dentro de la clula. Un caso extremo poco recomendable es el de la clula unipersonal.
Recomendamos la adopcin del tablero ms complejo con divisiones tcnicas del trabajo, por lo menos
mientras no se incorporen tcnicas especiales como programacin por pares y diseo 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 rpidamente detectados y la duracin de las tareas
mejor estimadas. Adems, este esquema de trabajo es muy flexible y permite crecer con facilidad hacia otros
30
Los modelos a que hace referencia Anderson son ms generales que los que presentaremos en el prximo Captulo, 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.
Captulo 3
25
mtodos, en particular Feature Driven Development, que recomendamos ms adelante como un mtodo
ventajoso para proyectos grandes con equipos de mucha personas. Por si estas dos caractersticas 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 aplicacin del
mtodo Kanban, es necesario limitar el nmero de psit en cada columna. Si en una columna hay tantos psit
como indica el lmite, generalmente anotado en el tope de la columna junto a su nombre, no se puede pasar un
psit ms 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 psit correspondiente. Claramente las personas que quedan
ociosas notan esto, las personas que estn trabajando en las actividades de la columna saturada notan esto y la
cadena de produccin se detiene. En esta situacin se detecta un cuello de botella, que debe ser resuelto por los
mismos miembros del equipo. A diferencia de la gran mayora de los mtodos existentes, Kanban no es
prescriptivo. En eso lo sigue Scrum, pero Kanban es todava menos prescriptivo que Scrum. El equipo elige, adapta
y adopta sus procesos segn su necesidad.
Lo que diferencia notablemente a Kanban de los otros mtodos giles es su flexibilidad, pero sobre todo es la
limitacin del volumen de trabajo en cada etapa. Es esta restriccin la que pone en juego los mecanismos de
adaptacin, y en consecuencia los mecanismos de mejora, que en otros mtodos quedan a cargo de reuniones
especiales llamadas retrospectivas. Lo que en los dems es una visin de lo que pas, en Kanban es la necesidad
lgica de operar sobre lo que est pasando.
Siguiendo nuestra opcin de mejora de procesos que definiramos en el Captulo anterior, utilizaremos los
mismos preceptos que usa Anderson para Kanban puesto que son compatibles: Foco en Calidad, Reduccin del
Trabajo en Desarrollo, Entregas Frecuentes, Balanceo de la Demanda contra la Produccin, Fijacin de Prioridades,
y Atacar las Fuentes de Variacin para Mejorar la Predictibilidad. La receta de Anderson no slo es compatible con
la de LS que eligiramos antes, Es totalmente compatible con el MPS! En el Captulo 5 expandiremos las tcnicas
de Kanban utilizando el ejemplo de Tahini-Tahini.
3.3 Scrum: Organizando el sistema para un estado de equilibrio orgnico
Scrum no debe ser considerado un mtodo, 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
despus del mismo, Scrum es el enfoque gil menos prescriptivo. Esto es cierto, pero la gran diferencia entre el
nmero de reglas de uno y otro (3 contra ms de 10) hace que estn cerca pero no demasiado.
Para implementar Scrum en una organizacin hay que hacer cambios profundos antes. Con Kanban los
cambios originales son solo tres: reflejar el flujo en un tablero Kanban, limitar el nmero de tareas por etapa y
mejorar el flujo total haciendo las alteraciones que demande el proceso. Kanban se adapta fcilmente a cualquier
proceso subyacente, porque las entregas rpidas pueden ser internas al equipo y la participacin de los
involucrados externos al mismo es deseable pero no indispensable. En cambio, en Scrum es indispensable
restructurar la organizacin en varios sentidos: Primero se tiene que contar con una persona que conozca el
producto, o tenga la visin del producto, y que est disponible para trabajar con el equipo durante la duracin del
proyecto. La dedicacin 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 Dueo del Producto.
En segundo lugar, el personal debe ser dividido en equipos interdisciplinarios pequeos, auto-organizados,
que cuentan con la supervisin y colaboracin 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
relacin del equipo con el medio que lo rodea. En ese sentido, es mucho ms un perro pastor que cuida del ganado
que un gerente que dirige las operaciones. La auto-organizacin del equipo es fundamental en Scrum. El Scrum
31
En ingls, 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.
Captulo 3
Boria et al.
Master no dicta lo que debe de hacerse, sino que allana el camino para que se lo pueda hacer. De ese modo es el
propio equipo quin fija las reglas de colaboracin y produccin, y estas son flexibles y modificables. Esta es la
base para que no haya colas de espera en el equipo y que cuando se abren oportunidades de trabajar juntos se las
aproveche, en aras de mejor productividad y calidad.
Tercero, el trabajo a realizar, los requerimientos, deben ser partidos en un conjunto de entregables concretos
y pequeos, no una funcionalidad excesiva sino pequeas parcelas de trabajo que tengan sentido para el negocio y
puedan ser ordenadas por su prioridad, fijada en conjunto entre el usuario Dueo del Producto y el Scrum Master.
Se fijan objetivos, llamados del release, que establecen plazos de larga duracin (meses) para la entrega del
producto completo. Luego el tiempo de duracin del proyecto se parcela en hitos pequeos, llamados Sprints.
Cada Sprint tendr una duracin fija, usualmente entre 1 y 4 semanas. Los equipos de trabajo elegirn de la lista de
requerimientos priorizados (Backlog) aquellos que entran en el Sprint (Sprint Backlog). El equipo invierte un da de
trabajo en planificar el Sprint. Hay reglas claras sobre como planificar, y varios mtodos que han sido probados y
adoptados por muchos equipos. Fundamentalmente, la estimacin se basa en la historia de trabajo del equipo, la
velocidad con que se construye en general el producto.
El equipo se rene todos los das por un perodo corto, no ms de quince minutos, para revisar las tareas del
da anterior y el plan del da. El Scrum Master dirige y facilita esta reunin. Es a estas reuniones que se denomina
Scrum y que dan el nombre al mtodo.
El objetivo de un Sprint es entregar una parte del producto al finalizar cada Sprint, lo que se manifiesta por
una demostracin hecha al cliente. El fragmento de funcionalidad que se entrega el cliente se llama sashimi, por
analoga con el plato de pescado crudo japons donde cada trozo es un plato en s mismo pero tambin una
componente del plato total. Cada demostracin permite al cliente entender mejor el producto que pidi, y hacer
los ajustes necesarios para obtener el mejor retorno de la inversin en el menor plazo posible, cambiando
prioridades del Backlog si fuera til.
Figura 3.3: Proceso Scrum
Puesto que hay mucha libertad para realizar las tareas durante un Sprint, es posible que haya que realizar
ajustes. En general se espera a terminar un Sprint y antes de empezar el siguiente para introducir cambios a los
procesos. Para decidir sobre los cambios, el equipo realiza reuniones llamadas retrospectivas para analizar el
comportamiento de los procesos e intentar mejorarlo.
Momentos de Verdad en Un Scrum
Hay muchas oportunidades de hacer mal las cosas intentando hacer Scrum. Llamamos a esos puntos crticos:
33
momentos de verdad, por analoga con el mismo concepto en Marketing .
33
[CARLZON, 1989] Moments of Truth.
Captulo 3
27
El primer sntoma de que no debemos implementar Scrum es el del Dueo Desconocido. Se manifiesta
cuando se inicia el proyecto usando las herramientas tradicionales de planificacin y no se identifica al Dueo del
34
Producto. Esto tiene inmediatas consecuencias. Al no tener la gua de un usuario CRACK , el proyecto adolecer
de falta de visin del producto, falta de claridad en las prioridades, mala conduccin del juego de planificacin al
entrar a los Sprints, que sern definidos con falta de objetivos claros, contribuyendo a que se soliciten cambios de
requerimientos en medio de Sprints. En ese caso queda desvirtuada la validez de Scrum, por lo que es inaceptable
continuar con el proyecto utilizndolo. Hay que volver a mtodos tradicionales, como el ciclo en cascada, o usar
otros como Rational Unified Process. Si esto no es deseable, hay que esperar para comenzar el proyecto cuando ya
haya un Dueo del Producto. Si esto es imposible pero se puede generar un sosas interno a la empresa, siempre
fuera del equipo, sta es una solucin aceptable. NUNCA un miembro del equipo puede ser Dueo del Producto,
puesto que esto origina conflicto de intereses.
Aun cuando haya un Dueo del Producto, ste puede adolecer de diferentes problemas: falta de visin del
producto, prioridades poco claras, ser muy inflexible o tener los objetivos poco claros. En todos los casos es
deseable intentar educar al Dueo del Producto para conseguir el comportamiento deseado, o si esto no es
posible, cambiar de Dueo del Producto. Sin un Dueo del Producto CRACK, el equipo queda a la deriva y la calidad
del producto se compromete mucho.
No slo el Dueo del Producto puede ser la causa del desbarrancamiento del proyecto. Tambin es necesario
que el Scrum Master conozca los procesos y sepa cmo actuar en cada caso. El Scrum Master es responsable de
que se elija el juego de planificacin correcto, salvando los problemas cuando falta historia del equipo. Si bien el
Dueo del Producto y el Scrum Master participan en ese juego, su intervencin es limitada. El Dueo del Producto
puede pedir explicaciones o explicar lo que est esperando como resultado, pero no puede fijar el valor de los
estimados. El Scrum Master facilita la reunin, pudiendo pedir precisiones (por ejemplo, la definicin de
completo) pero no influir en la eleccin de valores. De todos modos, es til recordar que la estimacin del
equipo es sobre tiempo ideal, es decir, sin interrupciones ni otras tareas. El Scrum Master debe ajustar ese
tiempo ideal a tiempo real, multiplicando por el factor correspondiente.
El Scrum Master es responsable que se adopte tempranamente la definicin correcta de cuando un producto
est completo. Si el Scrum Master es demasiado flexible puede ceder ante presiones del Dueo del Producto,
como cambios en medio de un Sprint, que no son beneficiosos para nadie. Si el Scrum Master es demasiado rgido,
puede degenerar en dirigir los Scrums, tratndolos en efecto cmo reuniones de avance. El Scrum Master tiene
que impulsar asimismo la mejora de procesos, a travs de retrospectivas frecuentes o cuando la ocasin las exija.
En el comienzo de las actividades con Scrum, es muy posible que se elijan las duraciones de los Sprints muy largas
o muy cortas. Esto no es problema, se puede ajustar la duracin de los Sprints en una retrospectiva.
Un problema comn es que se entienda gil como codificar y arreglar. No hay documentacin ni siquiera
mnima, faltan mtodos de ingeniera de software en la confeccin de modelos o en la prueba de los programas.
Se olvidan todas las buenas prcticas aprendidas, al adoptar gil. Se asocia a estos defectos el declarar que se
adopt algo como Scrum, pero, a diferencia de lo que ocurre en Scrum, no se conoce realmente el status de un
requerimiento individual. Si la organizacin se miente a s misma sobre lo que constituye adoptar Scrum, se
remplaza la estructura inflexible por el caos, se pierde el control del proyecto, las iteraciones resultan de muy baja
calidad y el sistema es frgil ante cambios.
Otra crtica con fundamento del mtodo Scrum es que no hace referencia a mtodos o tcnicas de ingeniera
a ser utilizadas en medio del Sprint. Por supuesto, esto es as por diseo, pero sigue siendo cierto que se deben
adoptar herramientas de ingeniera de software que apoyen las tareas del equipo. Un equipo gil reconoce
tcnicas giles, como Test Driven Development (TDD), refactoring, requerimientos iterados, y otras igualmente
tiles, y las aplica. En lo que sigue veremos algunas de estas tcnicas, de uso comn en equipos de Scrum.
3.4 XP: Inspecciones, Diseo, Cooperacin, y Muchas Pruebas
Extreme Programming, usualmente conocida como XP, es un conjunto de tcnicas condensadas de la
ingeniera de software tradicional, adaptadas para su uso en equipos pequeos que iteran rpidamente sus ciclos
35
de desarrollo. De hecho, Kent Beck , el pionero de XP, fue de los primeros en sugerir iteraciones cortas con
34
35
Usuario CRACK (collaborative, representative, authorized, committed and knowledgeable) que traducido es colaborativo,
representativo, autorizado, comprometido y con conocimiento [BOEHM e TURNER, 2003].
BECK, K., 2000, Extreme Programming Explained, Addison-Wesley.
28
Captulo 3
Boria et al.
participacin intensa del usuario en las mismas. En el libro citado, Beck explica su posicin extrema, diciendo que
si las tcnicas de la ingeniera de software son buenas, hacerlas todo el tiempo es mejor.
XP se apoya en cuatro valores: Comunicacin, Simplicidad, Retro-alimentacin y Coraje. De esos cuatro
valores Beck deriva cinco principios, ms prcticos y cercanos a la produccin que los valores: Retroalimentacin
rpida, para acelerar el aprendizaje; Presuncin de Simplicidad, para buscar la solucin ms simple; Cambio
Incremental, para reducir el impacto del cambio en las organizaciones; Adopcin del Cambio, contrariamente a
intentar controlarlo; y Trabajo con Calidad, para que tanto el cliente como los desarrolladores se sientan
gratificados por la experiencia.
XP no intenta resolver todos los aspectos de la ingeniera de software, centrndose fundamentalmente en
cuatro actividades: Codificar, Testear, Escuchar y Disear. Dice Beck: Se codifica porque si no se codifica, no se ha
hecho nada. Se testea porque si no se testea, no se sabe si se ha terminado de codificar. Se escucha porque si no
se escucha, no se sabe qu codificar o qu testear. Y se disea para poder seguir codificando, testeando y
36
escuchando indefinidamente . Beck ofrece un repertorio de tcnicas que funcionan bien en equipos chicos y han
sido ampliamente adoptadas, muchas veces con xito, pero tambin a veces criticadas.
Las tcnicas de Beck son: El Juego de la Planificacin; Pequeas Entregas (de producto); Metfora; Diseo
Simple; Prueba; Refactoreo; Programacin en Parejas (o de a Pares); Propiedad Colectiva (de los productos por el
equipo); Integracin Continua; Semana de 40 Horas (hoy llamada Paso Sostenible); Cliente Presente; y Estndares
de Cdigo. Puesto que son de uso comn en muchas aplicaciones de gil, sea que adoptan conscientemente XP o
no, daremos ac una sntesis de su contenido, intentando explicar lo suficiente como para que aquellas que
despierten el inters del lector puedan ser investigadas en la bibliografa ofrecida. Recomendamos al lector
[KNIBERG, 2007], Scrum and XP from the Trenches. How we do Scrum, por su estilo prctico y abarcador.
El Juego de la Planificacin.
Beck intenta balancear las necesidades del negocio con las necesidades (tcnicas) del equipo. Ninguna, para
l, debe dominar a la otra. Propone un dilogo donde la organizacin cliente define el alcance, prioridades y la
programacin y composicin de las entregas (releases) de cdigo. Michael Cohn, en [COHN, 2006], y Anderson en
[ANDERSON, 2011], describen en detalle una variante que se llama el juego de planificacin. Bsicamente es
similar a lo que Barry Boehm hizo popular como Wide Band Delphi en [BOEHM, 1981], es decir, una estimacin
hecha por los expertos, en este caso, los miembros del equipo, que converge a partir de discutir el primer
resultado viendo el rango y el promedio de lo estimado. Se itera hasta que la diferencia entre los extremos sea
aceptable, reducindola en cada iteracin mediante la justificacin de cada uno sobre su pronstico. Es importante
que los equipos discutan con el cliente sus estimaciones, pero no para que el cliente arbitrariamente fije la
duracin de las tareas. El equipo tcnico tiene la responsabilidad de alertar sobre consecuencias de elegir ciertos
diseos o elementos tcnicos.
Entregas Rpidas
Todas las entregas en XP se hacen en perodos cortos, idealmente cada dos semanas. Esto mantiene al cliente
interesado y comprometido, puesto que la retroalimentacin as obtenida aumenta el valor del producto.
Metfora
En vez de esperar que la arquitectura brinde cohesin a la estructura del producto, XP utiliza una metfora,
una explicacin de muy alto nivel de lo que se espera producir. Por ejemplo, en vez de documentar en un diagrama
las interfaces con usuarios y las componentes esperadas, en XP se habla del comportamiento Como si fuera una
terminal de cajero automtica. Esto debiera ser suficiente para que se deduzcan propiedades y atributos del
producto, como que habr un administrador y clientes de diferentes tipos. De ese modo se reduce la necesidad de
refrescar la memoria de cada programador cuando produce el diseo.
Diseo Simple
Segn Beck, el mejor diseo es el que mejor se ajusta a los casos de prueba, los ejecuta todos, no tiene lgica
duplicada, contiene todos los atributos e intenciones que los programadores quieren del producto, y lo hace con la
menor cantidad de clases posible.
36
BECK, K., 2000, op. cit. Chapter 9, Back to Basics, pag. 49. Traduccin de los autores.
Captulo 3
29
Prueba Dirigiendo el Desarrollo

En XP cualquier caracterstica del programa que no tenga una prueba asociada, no existe. Los programadores
escriben sus pruebas para ganar y mantener la confianza en el cdigo que generan, los clientes lo hacen con el
mismo motivo. Al ir acrecentando la cantidad de pruebas asociadas con el cdigo es imposible romper el cdigo al
introducir cambios sin que los defectos salten a la vista. De hecho, se realiza la prueba de regresin
permanentemente. En XP el programador primero escribe el caso de prueba del cambio que quiere implementar, y
lo ejecuta contra el cdigo actual, o sea sin modificar, asegurndose que no pasa. De ese modo prueba el caso de
prueba. Luego escribe el cdigo correspondiente hasta que el caso de prueba no encuentra defectos.
Figura 3.4: Ciclo de Desarrollo de XP
Refactoreo
Este enfoque de cambios pequeos puede tener un efecto indeseado, puesto que optimiza localmente el
cdigo, pudiendo anular otras optimizaciones locales y perdiendo de vista la optimizacin global A veces es
necesario realizar cambios al diseo porque surgen ciertos patrones de comportamiento indeseables. Una de las
tareas a realizar al cambiar el cdigo es investigar la existencia de patrones que no son considerados buena
programacin, como cdigo duplicado, datos vagabundos, y otros ms que se pueden encontrar en la pgina
37
citada en las referencias .
Programacin en Parejas (o de a Pares)
La programacin en parejas o de a pares, como su nombre lo indica, es una tcnica en la cual dos o a veces
tres personas trabajan juntas en el desarrollo de un segmento del cdigo. Es de ese modo que justifica el xito de
38, 39
productividad de su tcnica particular de programacin por pares
. Son varios los sitios de web que discuten los
pro y los contra de la programacin por pares. Los autores nos inclinamos sobre todo a creer que la socializacin
de la tarea entre dos evita interrupciones y permite a los dos programadores a entrar en flow segn la definicin
del mismo en [CSIKSZENTMIHALYIS, 1991], de modo que la tarea misma fluye (de ah el nombre) y se extrae
placer en llevarla adelante. Estudios realizados hace ya muchos aos por [DE MARCO & LISTER, 1987] muestran
que una persona en un ambiente con baja cantidad de interrupciones es hasta 3,8 veces ms productiva que otra
de la misma capacidad en un ambiente con las interrupciones habituales. Este estudio precede al asalto a los
sentidos que se desat con la internet, de modo que el ambiente normal de hoy en da es mucho ms ruidoso
que su contrapartida de fines de los 80.
37
Vase code smells, http://c2.com/cgi/wiki?CodeSmell
38
39
30
Los autores argumentan adems que al trabajar en un equipo de dos personas (o tres, si hay un coach), las interrupciones
usuales de correos electrnicos, conversaciones en lnea y otras distracciones que se pueden notar en los cubculos de los
programadores, desaparecen por completo.
http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html cita varias fuentes que atacan la creencia de que
hacer muchas cosas a la vez sirve para ganar tiempo.
Captulo 3
Boria et al.
Es poco probable que un par de personas trabajando ostensiblemente acepten interrupciones, mientras que
una persona sola en su escritorio es vctima del correo electrnico, el Messenger y hasta el celular, en sus
distintas variantes. Por si esto fuera poco, las empresas fabricantes de telfonos se aprestan a agregar ms
inteligencia a sus productos, lo que har que recibamos ms interrupciones todava: El vuelo de Dorita la
Exploradora est saliendo con retraso, mi ta Rosita se compr nuevos zapatos y lo public en Facebook, y as
sucesivamente. La programacin en parejas nos ahorra la humillacin de sucumbir a todas esas tentaciones y nos
permite gozar del flow.
Una variante importante de la programacin en parejas es cuando deja de serlo, al participar un tercero. Este
suele ser el lder tcnico, o el programador ms respetado por el equipo. Su participacin tiene intenciones
formativas. Generalmente participa cuando uno o los dos programadores carecen de experiencia en esta tcnica.
En lo que sigue la aprovecharemos para juntar estadsticas que se puedan usar en la recoleccin y anlisis de datos
de revisiones por pares.
Propiedad Colectiva (de los productos por el equipo)
Si dos personas pueden participar en el evento de programacin, y estas parejas pueden rotar, Quin es el
dueo del producto? Obviamente, el programa pertenece al equipo en su totalidad. Cada uno participa en la
responsabilidad de mejorar el producto y ayudar al equipo a que se apropie del producto.
Integracin Continua
Parte de la posibilidad de que se pueda tener propiedad colectiva del cdigo es el hecho de que la calidad del
mismo se pone a prueba todo el tiempo, dejando en evidencia cualquier defecto casi tan rpido como se incurre
en l. Para empezar, el diseo guiado por las pruebas inicia un camino basado en la calidad como meta, y para
seguir la integracin continua aprovecha la generacin de los casos de prueba para que se verifique cada cambio
contra la base de datos de prueba, asegurando que no hay regresin de defectos anteriores. Esto implica que cada
nuevo aadido de cdigo es integrado tan pronto como se pueda al producto en evolucin. Para concluir, el
equipo presenta con regularidad en perodos cortos su producto parcial al cliente, de modo que la
retroalimentacin es frecuente y se hace sentir. A menudo se generan reglas en los equipos relacionadas con esta
integracin continua, que requiere un software especializado y una disciplina de gestin de la configuracin y del
control de cambios muy estricta.
Semana de 40 Horas (hoy llamada Paso Sostenible)
A pesar de tener muchas reglas que lo diferencian de los equipos comunes, un equipo XP es susceptible de los
mismos problemas derivados de las presiones del ambiente. Es posible que se capitule ante un cliente locuaz y
persistente, dejando al equipo con una tarea de mayor envergadura que la que puede hacer razonablemente. La
regla es que no se trabaja fuera de horario, pero si ocurre, es menester que no se trabaje fuera de horario ms de
una semana. Algunos equipos llevan esto a un Sprint, otros a dos semanas, pero todos tienen claro que el personal
cansado introduce demasiados defectos y stos introducen demasiada desconfianza, retrabajo e interrupciones.
Cliente Presente
Gran parte del xito de un proyecto, sea gil o no, se basa en la participacin del cliente. Ya vimos (nota 32 de
este captulo) que un usuario colaborativo, representativo, autorizado, comprometido y con conocimiento es
primordial para el xito de un proyecto. Pero si esto es cierto para los proyectos tradicionales, es indispensable
para XP, an ms que para Scrum. Durante el Sprint, en Scrum el Dueo del Producto est ausente y slo participa
convocado por el equipo. En XP es parte del equipo, convive con ellos. Esto permite validar ideas rpidamente y
contar con una voz que permita seguir caminos alternativos cuando sea necesario.
Estndares de Cdigo
El ltimo punto que tocaremos ac es sobre estndares de cdigo. Si los programadores eligen el cdigo que
quieren modificar, trabajan con distintos colegas varias veces por da, y el cdigo tiene que ser ledo y entendido
por todos, ms vale que haya un nico estilo de programacin. Hace muchos aos que [KERNIGHAN & PLAUGER,
1974] hablan del estilo de programacin. Nosotros aconsejamos mucho ms que un estndar. El equipo tendra
que leer el libro sobre estilos de programacin y adoptar sus propias reglas. La manera de introducirlas es siendo
fiel a la programacin por parejas, con o sin el coach presente.
Captulo 3
31
Escalamiento
Casi desde el principio de su existencia, la ingeniera de software se ocupa de dos problemas ligados entre s:
40
Programming in the Large y Programming in the Many . El primer problema es el de atacar proyectos
grandes. El concepto de grande es relativo a la media que produce la organizacin. Si una organizacin
habitualmente genera 100.000 lneas de cdigo por ao, un incremento de 10.000 lneas para un ao es un
problema logstico pero no uno que cambia radicalmente la naturaleza del asunto. En cambio, para la organizacin
que habitualmente genera 6.000 lneas de cdigo anuales, 10.000 lneas ms pueden resultar en un salto
cuantitativo imposible de absorber. Por supuesto, una parte de la solucin consiste en agregar gente, lo que se
conoce como Programming in the Many. Como es conocido, el aprendizaje de la programacin es un proceso
individual. Por lo tanto, aprender a programar con muchos y entre muchos es un ejercicio disciplinario importante.
En el caso de los mtodos giles existen autores que se han abocado a resolver estos problemas, notablemente
[COCKBURN, 2005] y [PALMER & FELSING, 2002], estos ltimos sobre ideas originales de Peter Coad [COAD et al.,
1999]. En el caso de Cockburn, su mtodo Crystal Clear es en realidad una familia de mtodos crecientemente ms
complejos. Las ideas de Coad, en cambio, estn basadas en slidos argumentos arquitectnicos; las usaremos
porque lo enunciado hasta aqu no es til para sistemas grandes y complejos a ser desarrollados entre muchos.
Ninguno de los tres mtodos esbozados en este Captulo escala bien, en el sentido de que a medida que es
necesario un equipo de mayor tamao para poder entregar un sistema ms grande y complejo en tiempos de
mercado razonables, todos ellos comienzan a perder propiedades que son manifiestas cuando el equipo es
pequeo. Kanban es aqul que por tener menos reglas tambin tiene menores expectativas, pero ocurre que su
propio objetivo, el de reducir el nmero de componentes en desarrollo al mismo tiempo, conspira contra su uso en
sistemas grandes y complejos.
3.5 Feature Driven Development
Feature Driven Development, o FDD, es una alternativa interesante porque combina la velocidad y flexibilidad
de los mtodos giles con alta escalabilidad. Utilizando algunas tcnicas de alto impacto extradas de las buenas
prcticas de ingeniera de software, FDD consigue armonizar el uso de modelos y planificacin con prcticas giles.
FDD en realidad consigue ponerse en el medio de las facciones que apoyan a uno u otro lado en la guerra
religiosa entre los agilistas y los tradicionalistas.
Contado en pocas palabras, FDD consiste en desarrollar un modelo del dominio entre el equipo de desarrollo
y los expertos en el mbito. Sacando la informacin del desarrollo del modelo y otras actividades que pudieran
haber tenido lugar respecto a la identificacin de requisitos, el equipo construye una lista de particularidades y
caractersticas del producto (features) expresndola como funciones formuladas bajo un patrn <accin>
<resultado> <objeto>. Por ejemplo, Calcular el total de horas trabajadas por los consultores, o Devolver el valor
de la hora promedio de esfuerzo por punto funcin.
Cada una de estas funciones es suficientemente pequea y un equipo la puede implementar en dos semanas
o menos de trabajo. Sin embargo tampoco es deseable que sean muy fragmentadas. Es deseable que las funciones
slo se dividan en otras ms pequeas cuando se intuye que en dos semanas no van a poder ser implementadas,
de otro modo se las mantiene en ese nivel de abstraccin.
Ahora se puede seguir el modelo para hacer una planificacin rpida y poner a trabajar en paralelo varios
equipos que coordinen sus interfaces a travs del mismo modelo, asignndoles las funciones de la lista. Mediante
este simple procedimiento se ahorran muchsimos dolores de cabeza posteriores, muchas horas de Refactoreo, y
muchos defectos entregados al cliente.
El ciclo de desarrollo de FDD es muy formal, de todos los que hemos visto es el que tiene la definicin ms
parecida a los procesos tpicos de las organizaciones grandes. Puede que sea porque los autores quieren una clara
definicin de los pasos y los roles, puede que haya sido una exigencia del ambiente para conseguir su adopcin en
las primeras implementaciones. El caso es que los cinco procesos que mostraremos en la Figura 3.5 estn
perfectamente definidos, as como los roles de los actores que los ejecutan.
40
[BORIA, J., 1987, Ingeniera de Software, Kapelusz]
32
Captulo 3
Boria et al.
Figura 3.5: Ciclo de Desarrollo de FDD
Entremos en un poco de detalle en los cinco procesos.

El primer proceso comienza cuando se han determinado los principales actores para todos los roles
requeridos. Los roles que resultan clave en FDD son seis. El principal rol es el de Gerente de Proyecto. Es
responsable administrativo del proyecto y debe mantener el sistema proyecto andando. Muy a la manera del
Scrum Master, el Gerente de Proyecto FDD se ocupa de que se siga el proceso y que su equipo pueda funcionar
libe de interrupciones. A diferencia del Scrum Master, el Gerente de Proyectos FDD tiene la ltima palabra en
alcance, presupuestos mensuales y dotacin del proyecto.
El segundo rol fundamental es el de Arquitecto en Jefe. Este rol es la contrapartida tcnica del Gerente. Si
bien el Arquitecto es responsable del resultado del diseo, sus tareas incluyen facilitar talleres que permitan a los
expertos en el dominio y miembros escogidos del equipo disear las caractersticas del producto. Sin embargo, el
cargo implica tener la experiencia necesaria para poder realizar la decisin definitiva sobre el diseo
arquitectnico. Si el proyecto es muy simple y la persona est capacitada, los roles de Gerente de Proyecto y
Arquitecto en Jefe pueden ser acumulados en una misma persona. Si el proyecto es muy complejo tcnicamente y
requiere mucha experiencia en el dominio o mucho tiempo con el cliente, el rol de Arquitecto en Jefe puede ser
compartido por dos personas.
Un tercer rol requerido es el de Gerente de Desarrollo. Dada la naturaleza de FDD, varios equipos desarrollan
simultneamente, lo que puede traer conflictos sobre el uso de recursos. El Gerente de Desarrollo tiene como
principal tarea resolver esos conflictos utilizando criterios tcnicos y conocimiento de las necesidades del cliente. A
menudo el rol es adjudicado al Gerente de Proyecto o al Arquitecto en Jefe. Ntese que el rol demanda
conocimiento tcnico, del dominio del cliente y mucha capacidad de mediar, buscar el ganar-ganar y resolver
conflictos, o hasta evitar que se produzcan.
El cuarto rol es adjudicado a mltiples profesionales, de hecho uno por cada equipo que se forma, y su
41
nombre es Programador en Jefe . El Programador en Jefe es una persona de grandes habilidades tcnicas que ha
pasado por varias iteraciones del ciclo de vida de desarrollo varias veces y es capaz de liderar un grupo pequeo.
Responde al plan general del Arquitecto y coordina con el Gerente de Desarrollo y los dems Programadores en
Jefe.
El quinto rol es el de los que hacen el desarrollo cotidiano, a lo que se llama Dueo de Clase en FDD. Cada
Dueo de Clase es un programador de mrito (en FDD no hay lugar para la mediocridad) y tiene a su cargo el
desarrollo, prueba y documentacin de una parte del producto final, siguiendo la gua y a veces colaborando con el
Programador en Jefe.
El sexto y ltimo de los roles requeridos es el de Experto en el Dominio. No por ser el ltimo en nuestra lista
es el menos valioso, de hecho puede ser el que ms impacto tenga en la calidad final del producto y el xito del
proyecto. Adems de contar con la obvia experiencia en el dominio, que puede estar dividida entre varios
protagonistas, es necesario que los Expertos en el Dominio tengan las otras caractersticas de CRACK que ya
mencionramos (ver la nota 34). Sin disponibilidad de estos usuarios es muy difcil que el equipo concrete un
producto exitoso.
41
Los equipos de Programador en Jefe estn descriptos por [BROOKS, F. P., 1995] siguiendo la implementacin que en IBM
hiciera Harlan Mills.
Captulo 3
33
Una vez que los protagonistas quedan determinados para todos los roles, con la posible excepcin de los
Dueos de Clase que pueden no participar, puede comenzar el proceso. En el primer proceso se desarrolla un
modelo global del producto a implementar. Es importante remarcar que, a la manera de la cita que se atribuye a
Eisenhower, Los planes no sirven, pero la planificacin lo es todo, el modelo no es lo que importa en esta etapa.
Es mucho ms importante usar la construccin del modelo para construir una relacin con el cliente e investigar las
reas grises del conocimiento del dominio. Esta etapa es importante no porque el resultado es un diagrama que
define con exactitud la naturaleza y los objetivos del producto, sino porque ilumina al equipo respecto de quines
son los expertos en el dominio, con qu apoyo pueden contar y cules son las grandes ideas que guan al cliente.
De todos modos, si no hay un producto no hay un criterio de finalizacin, y como ya dijimos, FDD tiene muy
claramente definidos cada uno de ellos para cada uno de los cinco procesos, a diferencia de los mtodos
anteriores que dejan la definicin del criterio de finalizacin de cada elemento al equipo. Para dar por concluido el
primer proceso, el Arquitecto en Jefe del proyecto debe de estar conforme con el modelo resultante. El modelo
debe de haber sido construido con el auxilio de todas las partes involucradas, esto incluye claramente al equipo de
Expertos en el Dominio, pero de ser posible la participacin de los Dueos de Dlase, stos debieran rotar entre los
equipos para ir empapndose de los conocimientos de los expertos y tratarlos personalmente.
FDD tiene su propia descripcin de las tareas a realizar, lo que no obsta para que los autores recomienden
fuertemente hacer una lectura de los libros de [ANDRIOLE, 1993] y [WOOD & SILVER, 1995], y sobre todo del
artculo de [ZAHNISER, 1995] en su sitio de internet, para tener una idea clara de las opciones, tcnicas a emplear y
resultados esperados.
Una vez que se ha llegado al modelo que representa lo bastante bien el producto, el equipo pasa al segundo
42
proceso, construir la lista de funciones . En este paso el equipo se reduce a los Programadores en Jefe. Partiendo
de la particin arquitectnica inicial resultante del primer paso, los Programadores en Jefe, o el equipo de la lista
de funciones, construye la lista de las caractersticas que se van a implementar. El proceso es iterativo. Se juntan
alrededor del diseo arquitectnico, para el cual ya hay una lista preliminar de tareas asignadas, y las reasignan en
reas. Cada rea es un conjunto afn de funcionalidad, posiblemente con sus propios requerimientos no
funcionales (seguridad, velocidad de respuesta, disponibilidad, legibilidad, mantenibilidad, y otros del estilo). Las
reas, una vez acordadas estables, se vuelven a desagregar en actividades, donde cada actividad es un conjunto
ms detallado y reducido de la funcionalidad de un rea.
Por ejemplo, al nivel ms alto, la arquitectura tiene una componente con el nombre Administracin, debajo
de la cual se listan ciertas actividades: administrar clientes, cuentas, revisiones, arreglos, etc. Al definir reas,
administracin global puede ser una de ellas, conteniendo una lista de funciones relacionadas a la vez con todas
las otras reas. Habra asimismo reas para clientes, cuentas y ajustes, la ltima categora siendo una sntesis de las
dos actividades listadas en la arquitectura como separadas. Es decir, la creacin de reas no est en modo alguna
limitada por la lista inicial de la arquitectura, sino que es el resultado de la experiencia de los Programadores Jefe
con dominios semejantes.
Una vez que las actividades se han definido en las reas, cada paso dentro de ellas es una funcin. Por
ejemplo, la actividad de administrar clientes en el rea de administracin puede tener pasos: Crear Cliente, Ajustar
datos del Cliente, Balancear datos del Cliente, Dar de baja Cliente. El resultado de este proceso es una lista
derivada de la arquitectura y vinculada a ella que adopta la forma de un rbol. Recorrer el rbol desde la raz hasta
el nodo ms profundo de una rama implica pasar por los tres niveles: Arquitectura Base, reas, Actividades y Pasos
(Figura 3.6). La lista entonces no solo contiene todas las funciones a implementar sino que, al ser un rbol, permite
asignar a nodos intermedios requerimientos no-funcionales, de modo que se tiene en efecto una muy buena
descripcin arquitectnica del producto. Siguiendo a [HOFMEISTER et al., 2000] el nivel base es el nivel
Conceptual, las reas constituyen el Nivel Modular, y las funciones son la base para los dos siguientes niveles:
Ejecucin y Cdigo.
El lector interesado puede combinar las tcnicas de FDD con las sugeridas en el libro Applied Software
Architecture [HOFMEISTER, 1999] para obtener resultados superlativos en aplicaciones crticas.
42
Estamos usando funciones, o caractersticas, para traducir el original en ingls features.
34
Captulo 3
Boria et al.
Figura 3.6: rbol de Funciones derivada de la Arquitetura
El tercer paso de FDD es la aplicacin del proceso de hacer el plan del proyecto completo contemplando cada
funcin. El Gerente de Proyecto, el Gerente de Desarrollo y los Programadores en Jefe se renen con la lista de
funciones delante de ellos y asignan cada una de las funciones a los programadores, que se convierten as en
Dueos de Clase. Cada programador puede ser dueo de muchas clases, dependiendo de su experiencia, la
complejidad y granularidad de las mismas y el grado de conocimiento que tenga del dominio. Los Programadores
en Jefe son considerados, a estos efectos, programadores y por lo tanto acumulan al rol de Programador en Jefe el
de Dueos de Clase.
La asignacin de las funciones tiene en cuenta muchsimas variables, tales como la prioridad del cliente para
la implementacin de reas, la interdependencia de las funciones, su complejidad y su tamao, la facilidad con que
se pueden probar dependiendo del orden de implementacin y la disponibilidad de personal. El proceso itera
sobre reas y va reasignando tareas a medida que las prioridades que se analizan van siendo cambiadas. Al
finalizar el paso cada Programador en Jefe tiene asignadas tareas y un calendario para llevarlas a cabo.
Con sus tareas en la mano, cada Programador en Jefe arma su equipo de desarrollo. En el cuarto paso, ya no
una ocupacin global del proyecto sino asociada a cada tarea de la lista, busca las clases asociadas a cada una y a
travs de ellas reconoce los programadores que van a participar. Si hubiera nuevas clases las asigna. Este proceso
se aplica a una o ms de las tareas cada vez, considerando todas aquellas que vale la pena implementar en un ciclo
de a lo sumo dos semanas en un equipo. Si el dominio asociado es sencillo y bien conocido, el Programador en Jefe
puede proceder a disear el trabajo. Esto implica desarrollar la documentacin que le permita al Dueo de Clase
modificar, extender o crear el cdigo correspondiente sin intervencin de expertos en el dominio. En el caso
contrario, el Programador en Jefe pide ayuda a los Expertos para realizar una revisin del dominio correspondiente
al conjunto de funciones a implementar.
El Experto, o los Expertos, recorren el dominio en una presentacin hecha al equipo donde cubren las reglas
del negocio, los algoritmos de aplicacin y los datos necesarios para realizar las funciones. Si hubiera documentos
asociados a las funciones, los menciona y aclara. El equipo entonces los estudia para desarrollar en primer lugar el
diagrama de secuencia que define la funcionalidad. Previa definicin de los tems de configuracin, el equipo se
aboca a refinar las clases para acomodar la funcionalidad, lo que permite al Programador en Jefe publicar un
modelo actualizado para que todo el equipo lo comparta. Usando herramientas CASE el Programador en Jefe
actualiza el esqueleto de programa para que se ajuste al modelo. Luego cada Dueo de Clase toma sus clases y las
actualiza para reflejar los cambios en el modelo y aade los comentarios, el prlogo y si se acuerda hacerlo as, el
43
invariante que resulta de la ejecucin de los mtodos de la clase . Finalmente el equipo revisa el diseo resultante
para garantizar su completitud, consistencia y que se puede realizar segn el plan. Este es el criterio de salida de la
44
fase .
El ltimo paso es la fase de construccin de cada paquete. El paquete ha de haber quedado definido en el
paso anterior. En esta fase se escribe o modifica el cdigo necesario, se hace una inspeccin de cdigo y se realiza
la prueba unitaria, para comprobar que el producto que se va construyendo no pase a la lnea base del cdigo con
43
44
Para ver el uso del invariante de clase en ingeniera de software, ver [BORIA, J., 1987] o para un tratamiento ms profundo y
sistemtico, [GRIES, D., 1987]
Usamos indistintamente fase, paso y proceso para referirnos a las cinco fases de FDD.
Captulo 3
35
defectos conocidos. Al aprobarse el producto se lo integra siguiendo los procedimientos habituales de gestin de
configuracin.
3.6 Resumen
Este Captulo ha cubierto cuatro de los mejores mtodos giles que se usan en la disciplina. Es habitual que se
tomen prcticas de uno y se las utilice en otro. Tan es as que existi un nombre propio para la combinacin de
Scrum con XP, XBREED, que ya no denota nada (el sitio ha sido ocupado por un abogado especialista en daos por
accidente). Kanban es especial para empezar un proceso de mejoras. La visibilidad que brinda y la bajsima
exigencia de cambio hacen que el peso de la responsabilidad por la calidad quede en el equipo de desarrollo y no
en un equipo organizacional de procesos. En nuestra experiencia, es la mejor forma de conseguir adopcin de
mejoras. Scrum sube las exigencias, pero su reputacin est justificada: Es un mtodo que acelera dramticamente
la produccin de software y genera sistemas de buena calidad. Como tambin deja mucha libertad al equipo al
respecto de las tcnicas de ingeniera, es muy frecuente que se le adopte junto con XP, RUP u otra (as llamada)
metodologa. Todas estas prcticas son sumamente tiles pero escalan relativamente mal: puesto que los lmites
al crecimiento son muy rgidos, la adopcin de un mtodo ms formal, pero que intenta aprovechar los mejores
consejos de los agilistas, se hace necesaria para esos proyectos que o bien atacan un volumen grande de cdigo o
bien se ocupan de mantener un producto de gran porte con mucha complejidad. Hemos elegido FDD por nuestra
afinidad con la corriente de Cutter Consortium, pero igualmente podramos haber escogido Crystal Clear. FDD es
45
para los autores el formato ideal para encajar con los modelos de madurez inspirados en CMM , tales como el
MPS o el CMMI.
45
[PAULK, M., WEBER, C., CURTIS, B., 1994] siguiendo a [HUMPHREY, W., 1989]
36
Captulo 3
Boria et al.
CAPTULO 4 - EL MODELO DE MEJORA DE PROCESOS DE SOFTWARE MPS-SW

4.1 Competir con la excelencia
Entre las muchas variables que componen el xito de una empresa de desarrollo de software la calidad es una
de las pocas que se cuentan dentro del rango de lo alcanzable. Pocas son las empresas que obtienen sus ganancias
de productos realmente novedosos, para la mayora el negocio es producir mejor que la competencia a menor
costo. Utilizan su conocimiento del dominio para mejorar la satisfaccin de sus clientes y ampliar su cartera,
haciendo cada vez ms caro el costo de transferencia hacia productos competidores y reteniendo y ampliando su
cuota de mercado. En ese contexto los costos de desarrollo son ms importante que los precios, porque la falta de
monopolio hace que la competencia intente entrar en el mercado bajndolos.
Para la empresa pequea y mediana que lucha por mantener su lugar en el mercado, la calidad es primordial,
porque los costos de desarrollo se opacan ante los costos de rehacer el trabajo. En [DIAZ & KING, 2002] se muestra
que la rehechura supera la quinta parte del esfuerzo total de un proyecto (Figura 4.1). Puesto en trminos que la
persona de la calle puede entender, el ingeniero de software tira una de cada cinco cosas que hace. Si fuera una
lavandera, una de cada cinco prendas que lava debe volver a la lavarropas.
Tabla 1: Desempeo de Proyectos de los Sistemas de Decisin de
General Dynamics Contra el Nivel CMM
Nivel Porciento Efectividad
CMM
de
de la
Retrabajo Contencin
en Fase
2
3
4
5
23.2%
14.3%
9.5%
6.8%
25.5%
41.5%
62.3%
87.3%
Densidad de Productividad (x
Defectos
factor relativo
nicos
al nivel 2)
Reportados
por el Cliente
por KSLOC
3.20
0.90
0.22
0.19
1x
2x
1.9 x
2.9 x
Figura 4.1: Relacin del Retrabajoo vs. Nivel de CMM [DIAZ & KING, 2002]
Las pequeas y medianas organizaciones no pueden soportar un costo tan excesivo. Como ya explicramos
en el Captulo 2, cuando propusimos el uso de LS (Lean Simplified) como el mtodo de acercamiento al problema,
es necesario identificar las fuentes de defectos y removerlas. Si bien es posible hacer uso de LS sin ningn otro
apoyo, la bsqueda de los defectos es un arte no menor. La mayora de nosotros nos encontramos ms cmodos
siguiendo una gua que nos oriente en el sondeo de la organizacin. La gran contribucin de Watts Humphrey
46
[HUMPHREY, 1989] consiste en la creacin de un modelo de estados que ofrecen precisamente esa gua .
47
De hecho, los modelos de estado son anteriores al trabajo de Humphrey. En un trabajo eminente , Richard
Nolan introduce un modelo de estados para la gestin del recurso de cmputos. Como preludio, Nolan describe
diferentes usos de los modelos de estados, en campos tan diversos como la astronoma (la formacin de estrellas,
galaxias y sistemas solares), biologa, ecologa y desde el siglo XIX la economa de los pases. En particular hace
48
referencia a dos criterios para la buena formacin de modelos de estados, descriptos por Simon Kuznets : los
estados deben estar bien definidos y ser claramente distintos y demostrables empricamente; y la relacin analtica
de cualquier estado a su predecesor o sucesor debe estar bien definida, debe ser posible identificar los procesos
que causan a un objeto moverse de un estado al otro. Siguiendo nuestro derrotero, intentaremos demostrar que el
MPS es un slido modelo de estados.
46
47
48
Una ancdota que circulaba en TeraQuest a finales de la ltima dcada del Siglo pasado relataba que Watts Humphrey haba
tenido su Eureka a bordo de un avin que lo llevaba de vuelta a Pittsburgh desde un seminario del Instituto Juran.
Fervoroso admirador de las teoras de Deming, Juran y Crosby, Humphrey se puso como objetivo eliminar la dificultad de
aplicar las tcnicas de la calidad total, incluyendo las cartas de comportamiento de procesos, a la ingeniera de software. Su
revelacin vino de comprender la necesidad de establecer procesos comunes que puedan ser analizados estadsticamente.
De ah su modelo de estados.
[NOLAN, R., 1973]. Ntese el homenaje implcito a este artculo como fuente de inspiracin en el nombre del libro de
Humphrey op.cit.
[KUZNETS, S., 1966]
Captulo 4
37
4.2 Un camino para la excelencia organizacional

El Modelo de Referencia MPS (MR-MPS-SW) [SOFTEX, 2012a] es un modelo de madurez de procesos,
inspirado y compatible con el CMMI [SEI, 2010] y adherente a las normas internacionales ISO/IEC 12207 [ISO/IEC,
2008] e ISO/IEC 15504 [ISO/IEC, 2003]. Histricamente la mayora de los enfoques sobre calidad han desarrollado
normas de buenas prcticas a ser aplicadas. Si bien stas cumplen una funcin importante al difundir mtodos
probados y ayudar a enfocar esfuerzos en calidad, se centran en su cumplimiento y no en el desenvolvimiento de
la organizacin.
LAS NORMAS EXIGEN CUMPLIMIENTO
LOS MODELOS BUSCAN DESENVOLVIMIENTO
La ventaja de un modelo de mejora de procesos es que indica un camino deseable para alcanzar la excelencia.
Las normas se pueden cumplir, pero si se las ve como una lista de reglas a seguir, pueden no ser ms que la suma
de las partes. En cambio, un modelo, cuando se lo interpreta bien, adems de indicar las mejores prcticas
tambin ensea los posibles ordenamientos al presentar la secuencia ms lgica de implementacin. Los modelos
ms tiles tienen formas de evaluar el grado de implementacin que una empresa lleva del mismo. El MPS-SW no
es una excepcin, y esta valiosa herramienta le permite a la empresa interesada en la mejora de sus procesos
entender lo que ya tiene implementado y lo que le falta, adems de sugerir los prximos pasos. La desventaja de
un modelo es que los caminos de implementacin son mltiples y dependen de la empresa en cuestin.
En cierto modo la articulacin de Lean Simplified con un modelo del tipo del MPS es la herramienta ideal,
puesto que permite identificar los cambios ms significativos con LS y utilizar recomendaciones del modelo para
llevarlos a cabo. En tanto que si bien las normas son mucho ms fciles de interpretar e implementar, el efecto
sinrgico que poseen es muy escaso y difcil de encontrar aun con mucha experiencia.
La competencia de una empresa que busca la excelencia es ella misma. Los competidores que se centran en
lo que hace el otro no pueden competir, a la larga, con aquellos que persiguen la excelencia a travs de la mejora
continua. En particular, Se intenta que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaos
y caractersticas, pblicas y privadas, si bien con especial atencin a las micro, pequeas y medianas empresas.
Tambin se espera que el modelo MPS sea compatible con los padrones de calidad aceptados internacionalmente
y que tenga como prerrequisito el aprovechamiento de toda competencia existente en las normas y modelos de
mejora de procesos ya disponibles. De esa forma, tiene como base los requisitos de procesos definidos en los
modelos de mejora de proceso y responde a la necesidad de implantar los principios de ingeniera de software de
forma adecuada al contexto de las empresas, estando en consonancia con los principales abordajes
49
internacionales para definicin, evaluacin y mejora de procesos de software .
Figura 4.2: Organizacin del MPS.BR [SOFTEX, 2011l]
En particular, el MPS se ajusta al nomenclador internacional de guas. Hay una Gua General MPS de
50
Software, MR-MPS-SW [SOFTEX, 2012a], ya citada, cuya lectura es indispensable para entender la gnesis , los
objetivos del modelo y el modelo de negocios. Hay una Gua General MPS de Servicios [SOFTEX, 2012b], una Gua
de Adquisicin [SOFTEX, 2011a] y una Gua de Evaluacin [SOFTEX, 2012c]. A esta ltima la volveremos a ver antes
de cerrar este captulo. Hay tambin una Gua de Implementacin para cada nivel [SOFTEX 2011b; SOFTEX, 2011c;
SOFTEX, 2011d; SOFTEX, 2011e; SOFTEX, 2011f; SOFTEX, 2011g; SOFTEX, 2011h;] adems de las guas de
49
50
[SOFTEX, 2012a], pgina 6

[SOFTEX, 2012a], pgina 15, Apartado 7, Base tcnica para a definio do modelo MPS
38
Captulo 4
Boria et al.
implementacin para Fbrica de Software [SOFTEX, 2011j], para Fbrica de Pruebas [SOFTEX, 2011k] y para
empresas que hacen adquisicin de software [SOFTEX, 2011i], uno ms con orientaciones para la implementacin
y evaluacin de MR-MPS-SW en conjunto con CMMI-DEV [SOFTEX, 2012d], otro [SOFTEX, 2012e] con un anlisis de
adherencia del MR-MPS-SW en relacin a la NBR ISO/IEC 29110-4-1 [ABNT, 2012] y otro [SOFTEX, 2012f] con el
mapeo y sistemas de equivalencias entre el MR-MPS-SW y el MoProSoft [OKTABA et al., 2005]. El modelo de
negocios del MPS divide claramente los roles y responsabilidades, definiendo en los extremos a los clientes,
usuarios finales del modelo, por un lado, y al otro el Programa MPS.BR coordinado por Softex, el organismo que
maneja el modelo y a las instituciones habilitadas para implementarlo y evaluarlo. Estos dos grupos, no
excluyentes, deben ser acreditados por Softex para actuar dentro de los lmites del modelo.
Figura 4.3: Componentes del Modelo MPS [SOFTEX, 2012a]
4.3 Arquitectura del MPS

El MPS tiene una arquitectura muy simple. Por un lado se describen los procesos que componen el modelo.
Cada proceso tiene su propsito y sus resultados esperados. Es posible entender cada proceso por separado, pero
no reside ah el valor del modelo: Como modelo de estados de madurez, el MPS organiza el desarrollo a travs de
grupos de procesos. En el MPS los niveles de madurez son siete, del G al A. Para alcanzar un cierto nivel de
madurez la organizacin debe cumplir con todos los resultados esperados de los procesos definidos hasta e
incluyendo el nivel de madurez en cuestin. Los niveles de madurez son incluyentes, es decir, para alcanzar el F se
debe completar el G. Para completar el E se debe completar el F, lo que implica completar el G.
Para alcanzar un nivel hay que mostrar que se han alcanzado todos los resultados de todos los procesos
definidos para ese nivel y todos los que estn por debajo. Puede el lector imaginar a los niveles como muecas
rusas, uno dentro del otro. Adems, hay que mostrar que los Atributos de Proceso correspondientes al nivel en
cuestin tambin estn cubiertos. Estos Atributos de Proceso se muestran en la Figura 4.4 en las columnas de la
derecha y se denominan AP (Atributos de Proceso). Los Atributos de Proceso definen la Capacidad del Proceso y
tambin estn descriptos en trminos de resultados esperados, como los procesos en s. La Capacidad del Proceso
expresa el grado de refinamiento e institucionalizacin con que el proceso se ejecuta en la organizacin.
Captulo 4
39
Figura 4.4: Niveles de Madurez del MR-MPS-SW [SOFTEX, 2012a]
En el Modelo de Referencia MPS, a medida que la organizacin evoluciona por los niveles de madurez, la
capacidad para realizar los procesos debe mejorar asimismo. Sin embargo, los beneficios en trminos de
desempeo no surgen del rigor con que se implementan stos sino de la cultura que se genera por su aplicacin
correcta y consistente. La capacidad para realizar los procesos queda manifestada por la implementacin de los
Atributos de Proceso (AP), que a su vez queda manifestado por la implementacin de los Resultados esperados de
los Atributos de Proceso (RAP). La figura 4.5 describe la arquitectura grficamente.
Figura 4.5: Estructura del MPS [SOFTEX, 2011l]
Los detalles de cada proceso y los Atributos de Proceso de cada nivel sern discutidos en ms detalle en los
respectivos captulos que tratan, uno a uno, el desarrollo organizacional de la empresa Tahini-Tahini. Mientras
tanto, nos enfocaremos en la promesa que hicimos al comenzar este Captulo.
4.4 Los Niveles de Madurez del MPS
Los dos criterios para la buena formacin de modelos de estados definidos por Kuznets son que los estados
deben estar bien definidos y ser claramente distintos y demostrables empricamente; y que la relacin analtica de
cualquier estado a su predecesor o sucesor debe estar bien definida, debe ser posible identificar los procesos que
causan a un objeto moverse de un estado al otro. Para ver que el MPS cumple con la primera condicin basta
revisar con detalle la Figura 4.4. Los diferentes niveles tienen cada uno perfectamente definidos los procesos que
los constituyen y estos procesos son diferentes, aun cuando los haya con el mismo nombre, puesto que esos son
evolucin de los homnimos anteriores y, por ende, diferentes. Los niveles adems estn bien definidos en que se
diferencian por los Atributos de Proceso que corresponde implementar en cada caso.
Veamos qu caracteriza a cada nivel. Imaginemos una empresa que no tiene proyectos bien definidos y
hagmosla madurar a travs de los niveles del MPS, empezando por el nivel G: la empresa tiene que tomar
primero el control de las tareas, a partir de los requerimientos, para poder cumplir sus compromisos. En vez de
correr a implementar lo que el cliente quiere, el equipo hace una pausa para planificar y entre lo que se planifica
40
Captulo 4
Boria et al.
est el monitoreo. Aparece la cultura bsica de proyectos. Los beneficios del Nivel G se manifiestan en un mejor
foco en el negocio, porque se comprenden y honran los compromisos asumidos. Hay suficiente entendimiento del
estado del proyecto para manejar las expectativas de los clientes. Hay asimismo una mayor transparencia. El
estado del proyecto se comunica y comparte. Se documentan y explican las expectativas. La alta gerencia trabaja
con informacin verdica. El otro resultado importante de este nivel es la institucin de una nueva disciplina, por la
cual los equipos revisan y actualizan los compromisos. Los compromisos se respetan y se hacen todos los esfuerzos
para hacerlo son transparentes.
Para pasar del Nivel G al F, la organizacin tiene que tomar conciencia del valor de hacer las cosas de forma
repetible y debe comenzar a cuidar de sus activos organizacionales. Tiene que comenzar a medir para entender y
poder mejorar su sistema de decisin. Es en el Nivel F que se inicia la cultura de la objetividad. Esto se manifiesta
en un Sistema de Mediciones, por el cual se distingue entre medir y usar indicadores de gestin. El Sistema de
Mediciones est alineado con las necesidades de informacin de los distintos niveles y provee de
retroalimentacin veraz a los que toman decisiones. Adems, la organizacin encara la proteccin de sus activos:
Se reconoce a los productos de trabajo como activos organizacionales y se los protege. Se controlan los cambios y
se versionan los productos del equipo como parte integral del proceso. Es en el Nivel F que se adopta una mejor
estrategia con los proveedores. Los acuerdos se arman para beneficiar a todas las partes, no slo al adquirente. Se
comienza a integrar a los proveedores dentro de la lnea de produccin con el propsito de eliminar esperas y
disminuir costos. Se comienza a entender que los empleados no son un costo hundido, sino que son un activo que
se puede emplear de distintas maneras que se pueden medir y comparar. La nocin de portafolio de proyectos
permite aprovechar al mximo los esfuerzos de la organizacin.
Del F al E: El valor de lo repetible pasa a ser el valor de lo compartible. La organizacin se enfoca en el
aprendizaje y crea los activos para que los proyectos puedan trabajar sobre procesos comunes. Nace la cultura del
aprendizaje. A partir de que se enfatizan los procesos organizacionales, se discute qu, y no quin, es responsable
de problemas y se mejora el proceso para incrementar los mrgenes del negocio. Estos procesos estndares de la
organizacin permiten compartir las mejores prcticas en aras de mejorar la eficiencia y la efectividad de los
proyectos. Acompaados de los correspondientes activos de proceso, cultivan la mejora a travs de la
experimentacin controlada y el compartir experiencias. Se facilita y estimula el ajuste de los procesos a las
necesidades individuales de los proyectos. Como esto requiere nuevas habilidades bsicas, se forma al personal de
manera sistemtica para que apliquen los procesos. Los actores son entonces efectivos y eficientes. Los procesos
compartidos facilitan las mejoras al facilitar la comunicacin y el compartir experiencias. Se trata de una verdadera
organizacin que aprende, la organizacin como un todo se aboca a hacer las cosas bien de entrada, mejorando la
calidad y eliminando retrabajo costoso. Estos cambios permiten asimismo una mejor integracin. Se atiende al
ciclo de vida completo del empleado, desde la definicin de los cargos a la seleccin, contratacin y preparacin
del personal. Se crean los equipos tomando en cuenta la eficiencia de su funcionamiento futuro. Se establece y
mantiene la coordinacin entre equipos. Se identifica el trabajo a realizar y se definen activos que pueden ser
reutilizados para incrementar el reuso y bajar los costos. An antes de pensar en diseo de detalle se empieza a
pensar en arquitecturas de lneas de producto.
Del E al D: La organizacin pasa a centrarse en la ingeniera. Culturalmente empieza la cultura de los grupos
de inters y las especializaciones funcionales basadas en las experiencias conjuntas de los proyectos. El
rendimiento individual y colectivo aumenta, y con ello el sentido de pertenencia. Baja la rotacin de personal y
aumenta la productividad. Los equipos se integran an ms y es usual apoyar al otro en su tarea, sea sta de mi
especialidad o no (ingenieros de prueba integrando equipos de inspecciones, ingenieros de desarrollo
entrevistando al cliente).
Del D al C: La organizacin se orienta a la proactividad. Comienza la cultura de previsin y calidad total. Puede
empezarse a hablar de cero defectos y de la bsqueda de la excelencia. La mentalidad de eso ac no puede pasar
deja paso a que vamos a hacer para evitar que pase y que podemos hacer si pasa de todas maneras. Mientras
que en el nivel F se identifican activos que merecen ser considerados para su reutilizacin, basndose en criterios
de oportunidad y calidad, en este nivel, dada su caracterstica de mirar hacia adelante, se identifican
oportunidades de generar activos para la reutilizacin. De ese modo la organizacin se vuelca ms y ms hacia una
lnea de produccin de software.
Del C al B: Nace la cultura del conocimiento profundo a travs del conocimiento de la variacin y la
estabilidad. Aparece la cultura de la previsin mediante conocimiento estadstico. La institucionalizacin de la
gestin cuantitativa tiene a todos pensando cmo podan vivir sin este conocimiento antes.
Captulo 4
41
Del B al A: De la previsin se pasa a la competencia con la excelencia. La organizacin busca limar cada costo,
mejorar cada da ms.
Es importante entender el porqu de esta secuencia. Lo que las empresas no poseen cuando inician su
camino de mejora de procesos es la disciplina de proyectos, lo que s tienen es la ingeniera. De nada vale la
ingeniera sin disciplina. Es por eso que Scrum es tan reverenciado, porque consigue atrapar la imaginacin de las
personas que creen que al hacer Scrum no siguen procesos. De hecho es sumamente disciplinado y tiene claros
procesos, slo que algunos son meta-procesos y el propio equipo los puede modificar.
Para resumir lo expuesto:
Nivel G: Disciplina de Proyectos (ordenar el trabajo)
Nivel F: Disciplina de Calidad Inicial (ordenar la organizacin)
Nivel E: Disciplina de Conocimiento Compartido (aprender de las buenas prcticas y compartirlas)
Nivel D: Disciplina de Ingeniera (ordenar el desarrollo a nivel de detalle)
Nivel C: Disciplina de Previsin (cultivar el pensamiento proactivo)
Nivel B: Disciplina de Calidad Total (entender los procesos crticos cuantitativamente y prever su
comportamiento en un proyecto)
Nivel A: Disciplina de la Excelencia (buscar el panten de la disciplina).
Tomando esto a una granularidad un poco mayor, G y F estabilizan al paciente para que pueda ser tratado,
E, D y C arman la fbrica para que se puedan entender los procesos cuantitativamente.
4.5 Para que el Cambio Tenga Lugar
Las organizaciones que sobreviven son aqullas que mejor se adaptan al cambio. La mejora de procesos no es
la modificacin de los documentos que describen los procesos, es la modificacin de la conducta de las personas
que deben seguir esos procesos. Esto no es un tema sencillo, por el contrario es algo muy difcil de lograr y
requiere profunda atencin. Dependiendo del alcance y profundidad de un cambio es ms difcil conseguir que
llegue a buen xito. Si el alcance es individual, como cuando hay un cambio menor en un procedimiento, la
difusin e instalacin del cambio es sencilla y se puede realizar a nivel individual. Cuando el alcance supone la
modificacin del comportamiento de equipo el cambio es no trivial. El cambio ms difcil de lograr es el cambio de
cultura. Pocas veces esto resulta en una situacin de fcil adopcin, siendo que la mayora de las veces las
organizaciones que lo intentan sin la adecuada planificacin fracasan. Visto desde el punto de vista del desarrollo
organizacional, la maduracin de una organizacin puede o no suponer el cambio de cultura de la misma.
En realidad, no es que el cambio en s sea difcil, es el cambio orientado a ciertos objetivos lo que es
complicado. Si miramos a nuestro alrededor nada permanece esttico, inmutable, todo cambia permanentemente.
Pero ese cambio espontneo no es equivalente a mejora. Lo que buscamos es orientar el cambio hacia la mejora
de desempeo. Cuando queremos que las personas realicen algo de manera diferente a lo que lo estn realizando
en la actualidad, el cambio produce una disrupcin con lo conocido. Ms all de que las ventajas del cambio sean
evidentes, lo familiar es el presente, el ahora. Aun cuando las personas estn de acuerdo con la necesidad del
51
cambio, esto no es equivalente a decir que estn de acuerdo con la direccin que se le quiere dar al cambio .
Lo desconocido causa temor, o al menos, resquemor. Esperar que todos entiendan el cambio de entrada y lo
adopten por sus ventajas es iluso, la mayora ignorar o resistir el cambio. Elizabeth Kubler Ross [KUBLER-ROSS,
1997] estudi la secuencia de comportamientos que se sigue normalmente (pero no siempre) al enfrentar un
cambio de profundo impacto en nuestras vidas.
51
42
"... Ntese bien que no hay cosa ms ardua de manejar, ni que se lleve a cabo con ms peligro, ni cuyo acierto sea ms
dudoso que el obrar como jefe, para dictar estatutos nuevos, pues tiene por enemigos activsimos a cuantos sacaron
provecho de los estatutos antiguos, y aun los que puedan sacarlo de los recin establecidos, suelen defenderlos con tibieza
suma, tibieza que dimana en gran parte de la escasa confianza que los hombres ponen en las innovaciones, por buenas que
parezcan, hasta que no hayan pasado por el tamiz de una experiencia slida. De donde resulta que los que son adversarios
de tales innovaciones lo son por haberse aprovechado de las antiguas leyes, y hallan ocasin de rebelarse contra aquellas
innovaciones por espritu de partido, mientras que los otros slo las defienden con timidez cautelosa, lo que pone en
peligro al prncipe ... " El Prncipe, Nicols Maquiavelo, Captulo VI, DE LOS PRINCIPADOS QUE SE ADQUIEREN POR EL VALOR
PERSONAL Y CON LAS ARMAS PROPIAS (agradecemos a Kival Weber la cita).
Captulo 4
Boria et al.
Figura 4.6: Secuencia de Resistencia al Cambio [KUBLER-ROSS, 1997]
En lo que sigue evitaremos discutir cambios culturales profundos, para lo que hemos reservado una seccin al
final de este Captulo.
Para que un cambio planificado tenga xito es til contar con todos los elementos de partida. Tiene que
haber un auspiciante del cambio en una posicin que permita a las personas alterar sus prioridades sin violentar su
posicin en la organizacin. Ese auspiciante de alto nivel tiene que contar con el apoyo, o ganarse el apoyo de los
gerentes por debajo de l. A stos los llamaremos auspiciantes reforzantes. Tiene que haber quines conduzcan
efectivamente las actividades del cambio. stos son nuestros agentes de cambio. A veces se cuenta con personas
de mucho prestigio que entienden y apoyan el cambio. A stos se los llama campeones del cambio y son muy
importantes para acelerar la transicin.
Hablando de la transicin, se habla mucho del cambio, pero es indispensable entender que el cambio no es
52
un objeto, sino un proceso, un devenir , algo que ocurre a travs del tiempo. Hay un estado inicial real y un
estado final deseado, que debe por fuerza ser diferente del actual, puesto que si no es as no hay un cambio. Este
estado final no puede ser accedido de inmediato y sin esfuerzo, o no estaramos describindolo ac. Es un estado
que requiere cambios conductuales de grupos de personas y que lleva su tiempo implementar e implantar. El
pasaje del estado actual al estado final es llamado transicin y es el que causa todos los problemas, en general
fruto de malas interpretaciones sobre que es la transicin.
La Figura 4.7 muestra una visin muy cndida sobre la transicin. En ella la transicin es dibujada como una
lnea recta entre el estado inicial y el deseado. Se supone entonces que la introduccin del cambio es gradual y no
ofrece problemas mayores.
Figura 4.7: Modelo de Transicin Ilusoria (1)
La realidad es que no es posible conseguir el cambio de esa manera. Al menos es necesario tomar en
consideracin la curva de aprendizaje, como lo muestra la Figura 4.8.
52
Movimiento por el cual las cosas se transforman.
Captulo 4
43
Figura 4.8: Modelo de Transicin Ilusoria (2)
Esta ilusin est menos errada que la anterior, pero sigue siendo una visin altamente optimista de la
realidad. Cuando hay una transicin importante lo nuevo es desconocido y debe ser aprendido. El aprendizaje s
sigue la curva S, pero la productividad baja durante el perodo de aprendizaje. De hecho hay que planificar una
estrategia que haga que la transicin sea tan breve como sea posible y tenga tanto apoyo como sea posible para
que el proyecto de cambio no muera. La Figura 4.9 ilustra el verdadero comportamiento de la transicin cuando es
planificada y llevada adelante con una estrategia adecuada.
Figura 4.9: Modelo de Transicin Administrada
Si no se planifica el cambio, si se considera que la adopcin est asegurada por la auto-evidencia de su

necesidad, lo que probablemente obtengamos sea un gradualismo que mantenga la productividad en baja durante
un perodo que haga el cambio insostenible y el resultado sea la cancelacin del proyecto de mejora y la
conformidad con un nuevo status quo de menor productividad, como muestra la Figura 4.10.
Dos son las herramientas principales para reducir el impacto del cambio: Una es dividir el cambio en etapas
tan pequeas como sea sustentable. La otra es brindar apoyo para la instalacin de las nuevas conductas a los
equipos que tienen que llevarlas a cabo. Esto se traduce en entrenamiento en el trabajo, sobre el trabajo, en el
53
momento que se lo necesita y con los procesos reales .
Figura 4.10: Modelo de Transicin Sin Administrar
Durante la transicin cada persona tiene que ser ayudada para construir su propio compromiso personal con
el cambio. Conner y Patterson estudiaron esto en [CONNER & PATTERSON, 1982]. Es de destacar que el proceso
54
individual no alcanza para conseguir el cambio de la organizacin. Como dice Peter Senge en [SENGE, 2006],
Cuando pensamos en la organizacin que aprende, son los equipos los que aprenden. Dicho de otra manera, no
53
54
En TeraQuest llambamos a esto por las siglas JIT, OTJ, JET, (Just in Time, On The Job, Just Enough Training)
When we think of a learning organization, it is the teams that learn. Peter Senge, The fifth Discipline
44
Captulo 4
Boria et al.
es hasta que los equipos modifican su comportamiento que los procesos se institucionalizan en una organizacin.
La Figura 4.11 muestra los diferentes pasos, umbrales y estados en el proceso de construccin de compromiso
personal con el cambio. Ms abajo elaboraremos cmo se combinan el compromiso individual con el aprendizaje
del equipo.
Figura 4.11: Pasos del Compromiso (adaptado de [CONNER 1982])
La primera fase es la preparacin para la aceptacin. Slo cuando el individuo acepta el cambio puede
intentarlo y slo intentndolo puede construir su compromiso. El primer paso es siempre el contacto. Este
contacto tiene que ser repetido y variado, por ejemplo comunicaciones orales, escritas, en boletines de la
organizacin, en reuniones mensuales con la alta gerencia, en reuniones de avance de proyecto, en donde sea
posible, para que no pueda ser ignorado. Es fcil ignorar un cambio: Basta pensar que no se me aplica. Una vez que
no tengo recurso a la ignorancia el prximo paso es la toma de conciencia. Al darme cuenta de que el cambio es
inevitable es cuando aflora la resistencia. No debiera ser un tema para la confrontacin, la resistencia puede ser
intil pero no por ello ser ilegtima. Confrontado con la resistencia del personal, un agente de cambio debe ser
paciente e intentar entender los motivos que la generan. ste es uno de esos momentos en los cules es bueno
recordar que la percepcin del hecho es igual al hecho para quin lo percibe. En otras palabras: No importa quin
tiene razn, lo percibido es cierto para quin lo percibe. Aceptando que no hay cambio que por bueno que sea no
tenga su lado malo, el agente debe escuchar y negociar. Por ejemplo, si la dificultad pasa porque no hay tiempo
para el aprendizaje de los nuevos procesos o herramientas, el agente debe responder haciendo que ese tiempo
aparezca. De ese modo colabora con el individuo para que pueda pasar el umbral de la disposicin, evitando caer
en la confusin y llevndolo a la comprensin.
Que el individuo comprenda el cambio no implica que se sienta favorecido por l. Si no se contina
trabajando con la persona, sta caer en la desconfianza. Para ayudarlo a avanzar hacia el prximo paso, la
decisin, es imprescindible allanarle el camino, escuchando sus objeciones y reducindolas con acciones concretas.
No hay sustituto para el xito, si se abandona al individuo a sus propios medios el cambio es muy improbable, de
modo que es necesario continuar con el proceso influyendo en el resultado. En este paso es probable que se
comience con la primera parte del entrenamiento en los nuevos procesos, a un nivel alto para generar el
vocabulario comn. Llegado a la decisin la persona est lista para cruzar el umbral del compromiso.
No es lo mismo estar dispuesto a pasar a la instalacin que hacerlo efectivamente. Este es el momento en
que JIT-OTJ-JET (ver nota 53) es indispensable. Un coach con profundos conocimientos debe unirse al equipo en
el momento justo para que la experiencia de instalacin sea positiva y no traumtica. De ese modo se evita caer en
el desengao y se le permite, ahora a los equipos, avanzar del compromiso hacia la adopcin. La adopcin puede
caer en el desuso o seguir hasta la institucionalizacin, pero desde el punto de vista de la estrategia del cambio la
adopcin es el punto de llegada.
4.6 Cuando el Cambio es Cultural
Hasta ac hemos considerado a los cambios estrictamente como cambios de conducta individuales o cambios
de comportamiento del equipo. Si adoptamos la definicin de [CAMERON & QUINN, 2011] para hablar de tipos de
Captulo 4
45
cultura, encontramos que son cuatro dimensiones, como muestra la Figura 4.12, derivadas de los dos ejes sobre
55
los que se apoya una organizacin :
En la direccin horizontal el eje se mueve desde adentro hacia afuera, segn el nfasis que la organizacin
pone hacia adentro o hacia afuera de s. Hacia la izquierda la empresa enfoca sus esfuerzos hacia adentro,
mientras que hacia la derecha la atencin es hacia su ambiente, sus clientes y proveedores. Un enfoque hacia
adentro sirve cuando hay una creencia firme en que los procesos internos son la manera de congraciarse con el
cliente y esto da resultado.
El eje vertical muestra cmo se toman las decisiones en la organizacin. La estabilidad o flexibilidad de la
cultura depende de si las decisiones dentro de la organizacin se toman en el punto ms alto posible, en este caso
representado por la parte inferior del eje; o si se toman en el punto ms bajo posible, en este caso representado
por la parte superior del grfico. Las organizaciones del segundo tipo tienen cuidado de dar a sus empleados claras
consignas para conseguir que su toma de decisiones sea en pro del conjunto. [CAMERON & QUINN, 2011]
denominaron a ese eje el eje de la estabilidad / flexibilidad.
Figura 4.12: Valores en Competencia (adaptado de [CAMERON & QUINN, 2011])
Los cuatro cuadrantes definidos as son los tipos culturales bsicos. Toda organizacin muestra hasta cierto
punto variantes e integraciones de estos, pero para los efectos del anlisis es importante entender los tipos
puros.
El Clan es el fruto de una cultura donde el foco es interno y las decisiones se delegan a los equipos. Es capaz
de adaptarse muy rpido a cambios y hay mucha participacin colectiva. Son capaces de mantener la calidad de un
servicio por mucho tiempo y mejorarla indefinidamente. Es difcil para el clan construir productos muy grandes y
complejos. ste es el arquetipo de cultura que intenta desarrollar el movimiento de los agilistas.
La Jerarqua es la estructura que todos mejor conocemos. El foco es en el respeto a lo establecido y los
cambios son resistidos hasta por los que los proponen. Son organizaciones muy estables que pueden crear
productos muy complejos y con altsima calidad, como las fbricas de aviones o trasbordadores espaciales, o
ciertas instituciones gubernamentales. Tienen una tendencia a degenerar en burocracias.
El Mercado no es una referencia al mercado externo de la organizacin, aunque hay una relacin, sino a que
la empresa en s a todos sus niveles opera como un mercado, realizando transacciones internas y externas para
55
La afirmacin de que los ejes son dos no es caprichosa, proviene de un estudio de ms de 1500 empresas que respondieron
con un total de ms de 50.000 datos, que analizados estadsticamente mostraron que la cultura se puede explicar por estos
cuatro cuadrantes respecto de los dos ejes.
46
Captulo 4
Boria et al.
satisfacer al cliente. En un mercado no hay privilegios para amigos y la competencia lo es todo, de ah el nombre.
Las empresas financieras suelen mostrar ejemplos de esta cultura.
Por ltimo, una Ad-hocracia es una cultura que favorece la diferenciacin de su personal. En una Adhocracia se da ms mrito a las invenciones y las patentes que a los ascensos y promociones.
Cambiar de cuadrante, o moverse significativamente en la direccin del cambio, es muy costoso. Para hacerlo
conscientemente es necesario hacer un diagnstico profundo y planificar las actividades con aun ms cuidado de
lo que enunciamos en el apartado anterior. Es conveniente contratar un consultor que tenga experiencia en el
tema y buscar intensamente la participacin de todos los involucrados.
4.7 Evaluacin del Estado de Madurez
Durante el devenir del proyecto de mejora de procesos es necesario conocer los avances realizados, tanto
para poder juzgar su xito parcial como para apoyar el cambio con retroalimentacin positiva. Esta tarea es difcil e
ingrata. El responsable o responsables de llevar adelante el proyecto de mejoras es el encargado natural de
realizar esta actividad, pero la auto-evaluacin no es un camino fcil, as como se desaconseja a los mdicos (y a
los no-mdicos ms aun) auto-medicarse o a los programadores verificar su propio trabajo, es necesario contar
con una visin externa, objetiva, para verificar el grado de implementacin de los resultados esperados.
El MPS tiene una Gua [SOFTEX, 2012c] para la evaluacin de los procesos de una organizacin. Esta gua tiene
como objetivo permitir la evaluacin objetiva de los procesos de software de una organizacin/unidad
56
organizacional ; permitir la atribucin de un nivel de madurez del MR-MPS basndose en el resultado de la
evaluacin; ser aplicable a cualquier dominio en la industria de software; ser aplicable a organizaciones y unidades
57
organizacionales de cualquier tamao . El documento aclara que est destinado fundamentalmente a las
instituciones que realizan evaluaciones o implementaciones del MPS bajo su auspicio. Quizs, como en algunas
publicidades de la televisin, debiera advertirse al pblico que este material es para uso profesional, y que la autoevaluacin es una mala idea.
Para sustentar esta afirmacin, veamos el trabajo que tiene que realizar el equipo de la evaluacin: examina
una planilla, construida por la organizacin siendo evaluada, para verificar la evidencia de implementacin de los
resultados esperados para cada proceso y de los Atributos de Proceso, segn le sean asignados por el evaluador
lder. Entre otras consideraciones, la Gua no permite participar en el equipo a socios de la organizacin a la que
pertenece la unidad organizacional, parientes en grado alguno de los socios de la empresa, o de la direccin de la
empresa. El motivo es claro: los conflictos de inters impiden ejercer la tarea de juzgar el grado de implementacin
de los resultados esperados. En nuestra experiencia, es difcil para los empleados de la organizacin ser totalmente
objetivos, sin por ello juzgar mala voluntad de su parte. A menudo son ms exigentes ellos que los evaluadores
externos.
Por lo tanto, el monitoreo y control de un plan de mejoras debiera incluir frecuentes y peridicas visitas de
una persona experta en evaluaciones para garantizar que no haya sorpresas llegado el momento de la evaluacin
formal. Estas evaluaciones son aconsejables desde el primer momento. Conocidas como anlisis de brecha son
evaluaciones cortas que permiten a la organizacin contar con una versin objetiva de su programa de
implementacin de mejoras de procesos y a la vez recibir consejos de una persona con mucho ms conocimiento y
diferentes experiencias.
56
57
La frase unidad organizacional denota el rea de una organizacin que representa el alcance de la evaluacin. Puede ser
parte de la empresa o toda ella, un rea particular (por ejemplo, la fbrica de pruebas) o un sector (nuevos productos). El
evaluador lder y el auspiciante de la evaluacin de parte de la organizacin son quienes definen el alcance al contratar la
evaluacin.
SOFTEX, 2012i
Captulo 4
47
PARTE II Primeros Pasos

CAPTULO 5 - UNA ORGANIZACIN CON PROBLEMAS (NIVEL G DE MPS-SW)
5.1 La Pequea Historia de Tahini-Tahini
2
La empresa Tahini-Tahini, internamente conocida como T , como la denominaremos tambin nosotros en lo

que sigue, es una pequesima empresa de una ciudad de Latinoamrica. Trabajan en ella siete profesionales que
se conocieron en las aulas del Instituto Politcnico local. Todos los empleados son socios con mayor o menor
participacin, y las tareas administrativas, as como los cargos representativos (Presidencia, Secretarias, Gerencias)
son ejercidos rotativamente. La empresa se fund basada en la tesis de graduacin de dos de los ingenieros y
fundamentalmente ofrece ciertos servicios de liquidacin de haberes para empresas muy pequeas por medio de
la Internet en la modalidad Software as a Service (SaaS).
En un principio se quisieron llamar ISP, por Internet Sueldos Provider, que es el nombre original del sistema,
concebido como un gracejo, y que todava se usa internamente, pero no pudiendo obviamente registrar la sigla,
cambiaron por Tahini-Tahini, que es un juego de palabras con el nombre de la harina con que se fabrica el hummus
y que suena en castellano homnimo al ingls tiny (pequeo). El chascarrillo lo invent una de las socias,
Marcela, cuando dijo juntando el ndice y el mayor de la mano derecha en el smbolo universal de pequeez
Somos una empresa tiny tiny.
Los siete profesionales son: Alfredo y Ana, casados entre s y los que idearon el servicio; Claudio, hermano
mayor de Ana; Mariano, el amigo de la infancia de Alfredo; Marcela, la amiga de ambos del secundario; y los
gemelos Galarraga, Paco y Saco. Los siete se conocen muy bien, por lo menos desde el primer ao de la
universidad de cada uno. Algunos fueron ayudantes de ctedra en materias en las que otros cursaban, otros
2
fueron compaeros de clase. Al momento en que los encontramos T est alcanzando sus veinte meses de
funcionamiento continuo y los gemelos estn por dar su ltimo examen para graduarse.
2
En un principio T tena un mercado nico, el de los negocios de ropa de mujer con uno o dos locales a lo
sumo. En ese mercado continan siendo hegemnicos, pero en previsin de que les pueda surgir competencia,
han comenzado a expandirse a otro tipo de empresas. Debido a las diferencias entre convenios laborales, cada
nuevo rubro que agregan significa incorporar cambios en el sistema.
Hasta ac el modelo de negocios de la organizacin consiste en tomar un cliente para que pague el desarrollo.
El cliente queda asociado a un oficial de cuenta, asignado en general en la reunin semanal, generalmente aqul
que atendi el llamado o hizo el contacto inicial. Esta persona se encarga de elaborar los requerimientos de
cambios y genera una lista de funcionalidades que deben ser atendidas.
Una vez que se confirman los requerimientos con el cliente el oficial de cuenta elige una persona del equipo
para trabajar con l o ella. Se juntan en la sala de diseo frente al mapa del sistema ISP y usando tarjetas
autoadhesivas del tipo de Post-It Notes, adjudican los requerimientos a diferentes mdulos. Cuando se agota la
lista, revisan los mdulos para evaluar el trabajo que dar modificarlos para ajustarlos a los nuevos
requerimientos. Se prepara un presupuesto muy somero que es enviado al cliente y qu, si resulta aprobado, inicia
2
lo que en T pasa por ser un proyecto.
El proyecto, en realidad, slo tiene de proyecto el nombre. Hay un responsable nominal, pero se
sobrentiende que de haber problemas o emergencias todos estarn obligados a actuar. El responsable define
prioridades sobre la marcha. Este proceso es as: cuando una persona termina de implementar un requerimiento
lo anuncia al grupo, vocalmente. El oficial de cuenta que es propietario de la tarea toma el cdigo del ambiente de
la persona que lo desarroll y lo copia en el archivo propio, donde realizar las pruebas de programa. Quin
desarroll solicita entonces otra tarea. Esto a veces lleva a dos o tres proyectos a disputarse los servicios de
alguno de los miembros del equipo, lo que internamente se conoce como el remate. El que gana el remate
adjudica uno o ms requerimientos a la persona que qued libre. Es la persona que recibe la tarea quin elige al
ganador.
Cuando el oficial de cuentas siente que hay suficiente cantidad de producto, comienza a probarlo con
2
pruebas ad-hoc. Cuando no encuentra fallas, libera el producto, subindolo al sitio de T , de donde el cliente puede
hacer uso del mismo.
48
Captulo 5
Boria et al.
En el momento en que nuestro equipo es llamado a colaborar con ellos para realizar mejoras a sus procesos,
2
T est a punto de concretar un lanzamiento importante en el rea de los dentistas.
5.2 Quin Est A Cargo?
2
Hoy es un gran da en T . Despus de asistir a una clase en el Politcnico sobre la calidad total, los gemelos
indujeron a todos a tener una reunin plenaria con nuestra empresa, Vitalera, empresa oficialmente reconocida
por Softex como implementadora del MPS. Nuestro equipo de consultora llega a la reunin temprano, como es su
costumbre, y se va empapando de las novedades internas: en veinticinco das se debe concretar la entrega del
sistema ajustado para odontlogos. Es viernes y los gemelos, pese a haber llamado a la reunin, se tomaron el da
porque el lunes tienen su ltimo examen. Ana acaba de descubrir que est encinta y se qued en casa,
descompuesta. No va a venir por la tarde, tiene cita con su ginecloga. Alfredo est, pero est muy nervioso por la
noticia. Marcela va a llegar tarde, avis, para pasar por lo de Ana a ayudarla en la casa. Claudio est de viaje. Por
suerte Mariano no tiene problemas y est sentado en su escritorio, trabajando.
Estamos sentados a la mesa de la sala de diseo, tomando caf con Mariano y Alfredo y a punto de empezar
a hablar de nuestra propuesta, cuando llama el contacto con los clientes odontolgicos, el Doctor Molar Corona
Puente, Presidente de la Asociacin Odontolgica local. La Asociacin ha recibido una oferta de una importante
empresa consultora internacional para instalar un sistema centralizado de ERP que resolvera tambin algunos de
los problemas de los asociados que se quieren resolver con el ISP para Odontlogos. El Doctor Molar no est muy
2
dispuesto a conceder ante la presin de algunos de sus miembros para cancelar el contrato con T pero necesita de
nuestra ayuda para resistir los embates. La consultora est haciendo promesas de entrega en tiempos imposibles,
ignorando la necesidad de adaptacin del ERP en cuestin, lo que adems seguramente obligar a algunos cambios
2
importantes en las interfaces de los futuros clientes. Por todo eso, el Doctor Molar le pide a T que:
1.
2.
Indique el estado actual del proyecto de adaptacin de ISP a los problemas de los odontlogos;
Dedique un par de horas, hacia mediados de semana, a hacer una demostracin del producto cmo sea
2
que est, al efecto de convencer a los asociados a que esperen el lanzamiento antes de cortar con T ;
3. Estime que porcentaje del producto va a estar listo para la demostracin.
Alfredo le da garantas al cliente, dicindole en un par de horas lo llamo, Doctor, no se preocupe, saluda y
corta. Se para y se asoma a la zona de trabajo. Le pregunta a Mariano:
-
Ests con el programa de los odontlogos?.
Mariano contesta que no, y que eso es de exclusiva responsabilidad de Marcela y los gemelos. Alfredo nos
pide perdn por interrumpir la reunin y llama al celular de Marcela. Le responde un aviso que dice que el celular
est apagado. Con cierta preocupacin llama a su casa, donde lo atiende el contestador. Deja un mensaje en el que
pide que lo llamen urgente. Llama al celular de Ana y encuentra que est derivado al nmero de telfono de su
casa. Comienza a desesperarse.
Este es el momento donde un consultor tiene que mostrar que sirve: un cliente est en problemas y sus
rasgos denotan ansiedad, un estado negativo. La ansiedad se manifiesta fsicamente, es fcil de leer y nuestros
consultores saben hacerlo. Una fina lnea de transpiracin aparece en el labio superior de Alfredo, respira con
mayor dificultad, sus mandbulas estn tensas, hay un leve temblor en sus manos al llevarla a la taza de caf, que
traga con dificultad, sonoramente, y pide una aspirina para su incipiente dolor de cabeza. Ansiedad, sin duda.
Nuestros consultores saben que lo primero que hay que hacer es dar vuelta el pensamiento negativo,
identificar la fuente de preocupacin, eliminar el temor que provoca, crear un plan que lo pase de la inseguridad
que siente a una situacin creativa, donde haya esperanza. Tambin saben que tienen que tomar la decisin sobre
el plan ellos, porque las personas ansiosas tienen en ese estado dificultad para decidir, debido a que el miedo que
sienten es paralizante, les genera pensamientos negativos sobre ellos mismos. Deben hacerlo firmemente pero a la
vez con mucha empata, enfatizando el ganar-ganar, porque en la ansiedad el que la siente tiene temor a que se
den cuenta de sus dificultades, temor a la prdida del control, pese a que es consciente de estar pasando por
dificultades para pensar.
El primer paso en toda resolucin de un problema es identificarlo con claridad. Nuestro consultor lder,
Mximo, hace un resumen de su entendimiento del problema: hay un cliente importante (el Doctor Molar) en
situacin crtica (la presin externa de la consultora que ofrece el ERP) y al que hay que dar una respuesta sobre el
estado del proyecto (las dos preguntas). Ese es el detonante. El problema es que no hay ninguna forma objetiva de
entender el estado, porque las personas que estn a cargo, por una serie de circunstancias totalmente fortuitas, no
estn presentes. Alfredo asiente tibiamente al anlisis presentado. Mariano coincide con ms inters que Alfredo.
Captulo 5
49
El segundo paso es encontrar las causas raz del problema. Para garantizar la participacin y compromiso de
Alfredo y Mariano, Mximo se para y va a la pizarra blanca. Con un rotulador divide la pizarra en dos y en uno de
los lados dibuja un diagrama de espina de pescado (Figura 5.1) con cuatro espinas y coloca en la cabeza del
pescado el nombre que le da al problema: no hay forma objetiva de entender el estado del proyecto. Las espinas
reciben sus nombres: Proceso, Personal, Herramientas, y Capacitacin. Los nombres y la cantidad de
espinas pueden cambiar, siendo esta eleccin en parte dependiente de la percepcin del problema al enfrentarlo.
De todos modos, esta es una emergencia y es ms importante mostrar iniciativa que una precisin total. Ahora que
ya tiene la audiencia siguindole, Mximo empieza a indagar a los dos socios usando otras tcnicas.
Figura 5.1: Causas de la Falta de Conocimiento del Estado del Proyecto
Primero comienza con los Cinco Porqu.

-
"Falta Conocimiento del Estado de las Tareas. Porqu?, pregunta Mximo.
No se trata de identificar ms sntomas, o porqu se reconoce la existencia del problema. Se trata de indagar
sobre la naturaleza de las causas. A la pregunta Porqu es que hay falta de conocimiento del estado del
proyecto? es incorrecto responder con porque no sabemos contestarle a los clientes cuando nos preguntan
sobre esto. Si la respuesta obtenida tambin responde a la pregunta Cmo s qu hay falta de conocimiento del
estado del proyecto? hay que desecharla. Lo que se busca es el origen del problema, no otras manifestaciones del
mismo. De ah que Mximo haya elegido las categoras correspondientes en el diagrama. Las respuestas a la
pregunta se orientan a esos ejes, las espinas del pescado en el diagrama.
Siendo que el personal de la empresa es un grupo de ingenieros, a lo sumo a menos de una materia para su
graduacin, ni el personal ni la capacitacin merecen mayor atencin. El pequeo grupo se centra en procesos y
herramientas. La primera respuesta es que los procesos actuales no que registran el estado. Los siguientes porqu
continan indagando hasta que se llega a detectar la causa raz. Puede que se requiera preguntar cinco veces
Porqu? o puede que se arribe antes a una causa raz. Es fcil detectar una causa raz porque generalmente es
inmediato ofrecer una solucin. Por ejemplo, al segundo porqu se contesta que los procesos existentes no estn
preparados para identificar tareas, responsables ni estado del proyecto. la solucin es obvia, si bien no sea fcil de
implementar: modificar los procesos para que se pueda identificar las tareas, los responsables y el estado del
proyecto. Siguiendo con las preguntas de porqu, Mximo pasa a la espina de las herramientas. Tambin aqu es
fcil ver que las herramientas con que se cuenta no dan el soporte necesario para el proceso que se piensa
implementar.
Una vez que una de las espinas genera una sensacin de que es inmediato reconocer la solucin (por
ejemplo, nos falta un proceso genera la respuesta pongamos un proceso y lo mismo con las herramientas), el
ejercicio se suspende y se pasa a la discusin de las soluciones. La aplicacin de los cinco porqus no es el nico
camino posible, puesto que parte de nuestro repertorio es una alternativa llamada las Ocho Disciplinas:
D1: Formacin de un equipo de expertos que en su conjunto cubran todas las funciones;
D2: Identificacin y definicin completa del problema;
D3: Implementacin y verificacin de una accin de freno provisional para que el dao no se propague;
D4: Identificacin y verificacin de la causa raz;
D5: Determinacin y verificacin de acciones correctivas permanentes;
D6: Implementacin y verificacin de las acciones correctivas permanentes;
D7: Prevencin de la re-ocurrencia del problema y/o su causa raz; y
D8: Reconocimiento de los esfuerzos del equipo.
50
Captulo 5
Boria et al.
Como nuestros consultores son eclcticos, no desdean ninguna enseanza que sea til. En este caso
Mximo reconoce la necesidad de aplicar D3: es necesario detener la propagacin del efecto del problema. Antes
de ponerse a escribir el proceso que imposibilite la recurrencia del mismo pero cuando ya se haya perdido el
cliente, Mximo se pone a trabajar con los socios para hacer un plan de emergencia. Coordina con Alfredo para
que salga de inmediato a buscar a su mujer y a Marcela. Mariano y Mximo se comunican con los gemelos y
acuerdan en una reunin de exploracin ni bien terminen de festejar, el martes a primersima hora. Mariano llama
al Doctor Molar y le anuncia que el mircoles antes del medioda recibir una propuesta completa para invitar a los
interesados a una demostracin, propuesta que incluir la proporcin del sistema que se demostrar.
Una vez detenida suficientemente la hemorragia, y ya identificadas claramente las causas, Mariano y Mximo
2
definen un proceso que solucione la causa y evita que se repita. Nuestro hombre en T parte por definir, siguiendo
el mtodo, las caractersticas deseables del proceso:
Evitar que se repita el problema en el futuro

2
Ser muy fcil de implementar (dos o tres das en T )
Contar con soporte en software existente en la empresa, o fcil de conseguir (freeware, Open software o
semejante) o de desarrollar entrecasa (sobre todo en la nube).
Nuestro consultor trabaja sobre la base de que Mariano es una persona inteligente y con conocimientos, no
lo subestima ni es condescendiente para con l. Tampoco le dicta los resultados, pero al ir apareciendo la
oportunidad (un problema para el cul conoce una respuesta) le hace propuestas para que las valore. Dado el
anlisis inicial que realizaron con la espina de pescado, sabe que la base de todas las propuestas siempre tiene que
tener en su centro un sistema que permita ingresar tareas y asignarlas, a la vez que se va actualizando
permanentemente su estado. El mtodo de funcionamiento es simple y, lo que es muy importante, pude
considerarse una evolucin de lo que hacen hoy en da. Cuando Mariano describe el remate por el que se
adjudican prioridades, Mximo asocia con el libro de Kanban y Scrum y sugiere dar juntos una leda a [KNIBERG &
SKARIN, 2010]. Una rpida lectura de los materiales de Kanban les hace tomar conjuntamente la decisin de
2
buscar en la red herramientas de software que se ajusten a las necesidades de T para llevar el tablero Kanban en
la nube o en servidores locales, gratuitamente. Hay suficientes como para que Mariano se entretenga por varios
das comparndolos. Revisan juntos varios de ellos y, si bien no toman la decisin avanzan mucho en el tema.
Tres horas ms tarde, Mariano y nuestro consultor se despiden. Han recibido una llamada tranquilizadora de
Alfredo: Marcela y Ana adelantaron la visita a la ginecloga, donde est prohibido el uso de celulares, de ah que
2
no hubiera respuesta de ninguna de las dos. Todo est bien en el universo de T . Mximo se despide dicindole a
Mariano que si quieren continuar con un contrato permanente las horas que trabaj se considerarn inversin de
marketing. Mariano no da garantas, pero expresa que lo discutirn en la reunin semanal y que la mocin contar
con su apoyo.
QUE HA PASADO HASTA AHORA
1.
El consultor Mximo ha establecido el contacto inicial con el cliente, coincidentemente con un

problema grave y facilit su identificacin.
2.
Introdujo una primera tcnica de anlisis de causa, el diagrama de Ishikawa.
3.
Utilizando la tcnica lleg junto a los clientes a la conclusin de que sus procesos dejaban
mucho lugar a los problemas como el detectado, la falta de control de las tareas.
4.
A pesar de tener un diagnstico concreto que ya apunta a la mejora de procesos Mximo se ha

concentrado en el problema inmediato para evitar uno mayor, comenzando por definir las
caractersticas (o atributos) deseables de la solucin.
5.
Mximo ha sugerido el mtodo Kanban, sin imponerlo, y se lo ha escuchado.
5.3 Mostrando la Carga de Trabajo y el Estado de las Tareas

El lunes siguiente nuestra consultora es llamada por Alfredo para que proveamos a Mximo como consultor,
para que facilite la reunin semanal con presencia de todos los miembros de la cooperativa. El objetivo es armar el
tablero Kanban de lo que queda por realizar hasta ese momento en el proyecto y cargarlo en el software que ya
bajaron el fin de semana. Alfredo le indica que los honorarios que pasen deben asimismo incluir las cuatro horas
de trabajo del viernes. Estamos gratamente sorprendidos, porque nos damos cuenta de que los jvenes
emprendedores han recibido el mensaje y estn muy satisfechos de poder contar con nuestros servicios.
Captulo 5
51
Llegada la maana del martes, todos los miembros del equipo estn sentados alrededor de la mesa de
diseo. Ana est un poco plida, todava el embarazo no le sienta bien, pero por lo dems hay efervescencia y
energa a derrochar. Apreciando el lugar, nuestro consultor elogia la disposicin de la sala: hay cuatro pizarras para
usar con rotuladores, una de ellas todava muestra el diagrama de espina de pescado, dos de las otras muestran
una la arquitectura conceptual y la otra la modular del ISP. La cuarta pizarra es electrnica y sirve para registrar
decisiones mediante la simple pulsacin de un botn que transcribe lo escrito en la pizarra a un archivo en PDF que
se puede imprimir. Es la que usa el grupo para llevar la memoria de las reuniones semanales. El modelo de la
arquitectura modular est decorado con notas psit, representando historias de cliente por ser
implementadas.
Mximo se dirige hacia esa pizarra y llama la atencin sobre las psit, solicitando una explicacin de su uso.
Marcela se la ofrece, detallando como se mueven las notas de la columna de la izquierda, ahora vaca, a los
diferentes mdulos, para ms adelante realizar el remate. Mximo saca una fotografa de la arquitectura con su
laptop y aprovechando el proyector la muestra a la audiencia. Mximo indica que las notas asignadas a los
mdulos van a ser el punto de partida. Aclara que si bien se puede usar el software para Kanban que ya instalaron,
piensa que lo mejor es hacer el ejercicio a la antigua para que la percepcin sea ms completa.
Tomando una pila de psit la pasa a los participantes. Cada uno, dice, tiene que quedarse con unas cinco o
seis notas. Una vez que todos tienen su material, por orden, empezando por Ana y en el sentido de las agujas del
reloj alrededor de la mesa, Mximo dicta rpidamente los contenidos de cada psit, pidiendo que escriban
claramente y en el centro del papel. Como a la vez los est proyectando, no se detiene a esperar que se copien
totalmente, de modo que en pocos minutos todas las historias de cliente, por lo menos sus nombres, estn
copiadas. Las recoge y las coloca en la pizarra que usara el viernes. Borra su diagrama y dibuja un tablero Kanban
elemental, por ahora con tres columnas: Pedidas, a la izquierda, donde estn todas las historias. Completas, a la
derecha, que est vaca. La gran columna del medio est vaca y sin ttulo, por ahora (Figura 5.2).
Figura 5.2: Tablero kanban elemental
Mximo solicita entonces que cada uno, por turno, diga una tarea derivada de implementar esa funcin. Ana
empieza por decir Codificar las pruebas y Mximo lo escribe en un psit, que acto seguido pega debajo del
original. Marcela aade, casi sin pausa: Disear las pruebas. Esto tambin va a la pizarra. Es el turno de Sancho,
que viene sacudiendo la cabeza: Investigar la historia dice, y Pancho amplifica con el cliente y romperla en
funciones y caractersticas. Todos ren, claro. Mximo pregunta entonces cul es el ciclo de vida de una historia.
Resulta ser que es analizada, desglosada en funciones, se construyen las pruebas de cada funcin, se codifica y se
prueba. Mximo hace notar que las funciones pueden ya estar claras y que no siempre, necesariamente, hay
anlisis. Los presentes asienten. Modifica entonces el tablero para incluir esa informacin (Figura 5.3) y quita las
notas que haba agregado, puesto que las tareas son parte del ciclo.
Figura 5.3: Tablero kanban con ciclo de vida de las historias -1-
52
Captulo 5
Boria et al.
Quin es el dueo del producto?, pregunta Mximo.
Yo, dice Marcela.
No el Doctor Molar?, vuelve a preguntar Mximo.
No, dice Marcela, el Doctor no conoce los detalles de las liquidaciones, yo estudi la legislacin vigente
y soy la que sabe cmo se debe hacer para pagar los sueldos y qu opciones tiene el odontlogo
individual.
Felicitaciones!, dice Mximo. Entonces, el primer paso es que entre todos, y bajo tu direccin,
prioricemos las historias.
Marcela se para y comienza a mover las historias que ahora estn en la fila de ms abajo del tablero. Mximo
interrumpe.
-
Cuntanos tu criterio, Marcela.
Marcela comienza a explicar las prioridades y los gemelos intervienen casi a coro, recordndoles a todos la
inminencia de la demostracin pedida por el grupo de clientes. Pronto todos estn parados alrededor de la pizarra
y moviendo las notas para adelante y para atrs. La primera prioridad resulta para la historia Modificar Interfaces
con el Usuario por el impacto que tiene en una demostracin. Cuando por fin se estabiliza la lista, Mximo
aprueba.
-
Perfecto, tenemos un Backlog de producto. Ahora, a estimar el tamao.
Escribe en la pizarra electrnica una tabla que diferencia entre tamaos de tarea (Tabla 5.1). Aclara que las
definiciones no son las de lo que corresponde a tamao en el idioma Castellano, pero que es un buen lugar para
empezar. Enfatiza asimismo que la tabla intenta que las categoras, si bien son atributos ordinales, tengan relacin
entre s, de modo que la diferencia entre muy sencillo y sencillo resulte comparable con la diferencia entre
normal y ms que normal. El propsito es que las categoras, cuando ms adelante sean remplazadas por
mediciones objetivas, puedan servir de base para las mismas. Con esta tabla frente a todos, toma la primera de las
historias Modificar Interfaces con el Usuario. Le dibuja un cuadrado en cada una de las esquinas y con lpiz
escribe tamao estimado en el cuadrado superior de la izquierda (Figura 5.4) y pide que se haga una estimacin
del tamao de esta historia. Hay un gran silencio, roto por Ana, quin, sacudiendo la cabeza en negacin, dice:
-
Esta no es una historia de usuario, es una tarea transversal a todas las historias.
Tamao
Categoria
muy
sencillo
Sencillo
menos que
normal
normal
ms que
normal
complicado
muy
complicado
Funciones
Derivadas
5a6
7 a 10
ms de 10
1a2
2a4
ms de 4
Das
en el da
Tabla 5.1: Tamaos de Tareas
Con el consentimiento de todos, Mximo la coloca en la columna En Proceso por debajo de la mitad y toma la
siguiente historia de la fila de Solicitadas y la lee en voz alta. Agregar un mdulo de Liquidacin de Horas Extra.
Figura 5.4: Historia en el Tablero kanban
Captulo 5
53
Vuelve a pararse en frente de la tabla de tamaos y pide que se haga una estimacin del tamao de esta
historia. Hay una discusin de pocos minutos, antes de que los participantes converjan a que el tamao es ms
que normal. Mximo pregunta entonces si no sera mejor romper esa historia en sub-historias, dado que son cinco
o seis funciones derivadas las que estn pensando.
Toma un paquete de notas autoadhesivas de otro color al que ya se us y repite la solicitud de que se
enuncien las funciones derivadas de esa historia. Esta vez escribe los requisitos derivados a medida que Marcela,
con la ayuda de todos, los va exponiendo: Aadir Opcin de Cargar Horas Extras al Mdulo de Liquidacin
Mensual, Aadir una Frmula de Clculo al Mdulo del Empleado, Modificar Secuencia de Liquidacin para
Incluir Horas Extra, Modificar la Liquidacin del Salario Extra para Admitir Horas Extras y, claro, Modificar
Interfaces con el Usuario.
58
Ahora tenemos una pica !, intervienen los mellizos.
picas, historias, sub-historias, temas, funciones, caractersticas, casos de uso, casos de usuario; son
todos nombres que les ponemos a las cosas. Ustedes elijan los que les sirvan. Lo importante es que
tengamos claro que hay una raz y que de esa raz se derivan otros requisitos, y que de esos se pueden
derivar otros ms, formando una jerarqua. Cuando los requisitos ya llegan a un nivel donde sabemos que
se pueden implementar, derivaremos de ese nivel las tareas. Todo este conjunto es una jerarqua que nos
sirve para identificar las historias y los usuarios que las generan. Podramos usar un patrn que diga
Como usuario X, en este caso un odontlogo, quiero poder hacer Y, en este caso liquidar las horas extras
que trabaja mi personal. Pero lo importante es que tengamos claro qu hay que hacer y controlarlo, dice
Mximo.
Basados en los datos que se aportan, los gemelos estiman que si se ponen a trabajar en ese momento, con la
ayuda de Marcela y Ana, pueden tener la demo en tiempo para presentarla el jueves despus del horario de
oficina, de aquellas funciones que no requieren nuevas API. Alfredo respira aliviado y Claudio llama al Doctor
Molar para pasarle las novedades.
6.
Mximo ha inducido el uso del tablero Kanban, sin dictarlo.
7.
Introdujo los conceptos de sub-historia y estimacin por tamao.
8.
Hay una clara definicin del alcance del trabajo a realizar, encarnado en la lista de historias, con
su correspondiente estimacin de tamao.
9.
Se ha hecho una desagregacin de las historias, donde el tamao de estas la haca til.
10. Los conceptos de historia, sub-historia, desagregacin y tarea se han entendido en la prctica y
han sido aplicados. Se distingue entre tarea y sub-historia.
5.4 Planificacin, Monitoreo y Control del Proyecto en Dosis Homeoptica
2
La reunin contina a pedido de Mximo, por media hora ms. Antes de dejar a T librada a sus esfuerzos,
Mximo quiere dejar clara la definicin de LISTA para cada etapa del tablero.
-
Cundo se puede afirmar, pregunta, que el anlisis de la historia est concluido?.
Las caras de los asistentes lo dicen todo: Nunca lo haban pensado. Se aventuran tibiamente algunas
definiciones, hasta que Mariano da en la tecla: la realidad es que el anlisis, pese a la tradicin en contrario, no se
hace por separado. Es parte del Diseo. Mximo borra la columna de ANALISIS del tablero y redistribuye las
dems, cada una tiene dos sub-columnas: EP, que se lee En Proceso, y LISTA. Las definiciones de lista para Diseo,
Cdigo, Desarrollo de Pruebas y Completas queda as definida:
Diseo: El diseo est LISTO cuando hay un diagrama de cambio de estados que ha sido aprobado por el
Dueo del Producto, el que se encargue del desarrollo del cdigo y el que se encargue del desarrollo de las
pruebas.
58
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
54
Captulo 5
Boria et al.
El Cdigo est LISTO cuando se ha hecho la revisin con un colega y se han corrido las pruebas unitarias del
propio codificador y no se han encontrado defectos; si los hubiera habido, se demuestra que estos han sido
corregidos.
El Desarrollo de Pruebas est LISTO cuando se ha hecho la revisin de todas las pruebas con un colega y se
han cargado las pruebas unitarias en la herramienta de monitoreo de las pruebas automticas.
La historia en s est LISTA cuando se la ha probado contra todas las pruebas, se la ha integrado y no se han
encontrado defectos ni con las nuevas pruebas ni contra las pruebas de regresin.
Todo esto induce un ltimo cambio del da en el tablero Kanban: la columna A Probar pasa a llamarse
Integracin y Completa pasa a llamarse LISTA. Mximo borra todo el tablero, ingresa una nueva columna a la
izquierda llamada En Espera, donde se pondrn las dos historias de mayor prioridad, y las columnas Diseo,
Desarrollo, Integracin y Listas. El tablero se ve ahora como en la Figura 5.5.
Figura 5.5: Tablero kanban con ciclo de vida de las histrias -2-
A continuacin, Mximo trabaja con Marcela y los mellizos en definir el procedimiento para el uso del tablero
en las actividades de los prximos das. Cada vez que alguien est libre se acercar a Marcela y elegirn entre
ambos una tarea a llevar adelante. Esa tarea ser despegada de la columna En Espera y se la colocar en la
columna EP de Diseo. La persona que se haga cargo de la tarea escribir su nombre en el cuadrado superior
derecho de la nota correspondiente. En el cuadrado inferior izquierdo colocar la fecha y hora de comienzo y en el
inferior derecho la fecha y hora de terminacin, cuando la tarea est concluida. Una vez que est completa segn
el autor, se espera que alguien tome la tarea de codificar y de disear los casos de prueba. Si se trata de la misma
persona (aunque se procurar que se involucre alguien ms, para tener ms ojos en el proyecto) lo revisar con
Marcela y la nota pasar a EP bajo Codificacin y una copia a EP bajo Desarrollo de Casos de Prueba. Siempre se
evitar que la persona que codifique desarrolle los casos de prueba. Por ltimo, se define que la integracin la
realizar la persona a cargo del proyecto, en este caso, Marcela. Muy satisfechos, se cierra la sesin, y todava
queda poco ms de una hora para trabajar en la maana.
11. Mximo ha mostrado que el uso del tablero Kanban es dinmico y que se lo puede modificar.
12. Qued aclarado lo que significa que una tarea est LISTA, para cada etapa del ciclo de vida de la
tarea.
13. Se visualiza fcilmente el ciclo de vida de una historia en el tablero.
14. El control del estado general de una historia y las tareas asociadas se puede leer del tablero.
5.5 El Cliente quiere Cambios
El jueves de la misma semana los gemelos marchan con sus tabletas y laptops a la sala de conferencias de la
Sociedad de Odontlogos Profesionales en Actividad (SOPA) local. La demostracin del producto convence a casi
2
todos, y la simpata y juventud de los profesionales hacen el resto y se firma un memorndum de acuerdo entre T
y la SOPA. Lo que piden algunos de los menos entusiastas es que se demuestre la capacidad de modificar el
servicio, para lo cul han encargado algunos cambios, la mayora cosmticos, pero algunos que afectan los
2
mdulos de clculo. T tiene una semana para responder con un plan y una propuesta de honorarios. Establecida
2
ya una buena relacin entre T y Mximo, lo llaman directamente para que facilite otra reunin para dar la
respuesta.
Captulo 5
55
Mximo hubiera preferido seguir con sus planes de implementacin de las prcticas de MPS, pero los
negocios de su cliente siempre tienen prioridad para l, por poltica de Vitalera. De todas maneras, nada de un
negocio de software es totalmente ajeno al MPS, de modo que siempre echar mano a soluciones nacidas de sus
2
prcticas. Adems, ni ha sacado el tema del MPS con T , algo que tiene pensado hacer ms adelante, cuando la
ocasin para hacer una evaluacin exitosa pueda avizorarse cercana. As que ordena su calendario y, moviendo
2
una cita ac y otra all, por la tarde del viernes est de nuevo en la sala de diseo de T con los mismos actores del
martes.
Mximo repasa con los asistentes los pasos que llevaron al pequesimo plan de implementacin del martes
2
pero utiliza esta vez la herramienta de software (sprint.er) que instalaron en T . La secuencia de pasos es la misma:
identificar el Backlog, hacer la asignacin a las componentes, ordenar las historias por prioridades, estimar el
volumen del trabajo, desagregar las historias demasiado voluminosas en pequeas historias y tareas derivadas,
2
revisar y cerrar. Pero esta es la primera propuesta con desarrollo a medida que T va a firmar; hasta aqu solo han
vendido servicios de un producto relativamente estable con modificaciones que no alteraban el esquema de
trabajo, basado sobre todo en correcciones al cdigo para eliminar errores o adecuaciones a cambios en la
legislacin. Es por eso que el equipo no posee un patrn de presentacin de planes para propuestas.
Mximo introduce ahora la plantilla para la definicin de historias que ha desarrollado Vitalera. Los
asistentes sugieren pequeos cambios y la plantilla queda aprobada, aceptada y adoptada (Figura 5.6). Utilizando
las facilidades de diseo en la herramienta sprint.er ingresa los campos necesarios. Sobre la base de la plantilla se
rearma el Backlog, ahora mucho ms completo, y se realiza la estimacin con sprint.er. Los resultados arrojan la
necesidad de utilizar tres sprints de dos semanas. El primero implementar los cambios ms de fondo, el segundo
introducir los cambios de interface sugeridos, y el tercero servir de garanta de estabilidad. Sobre la base de lo
planificado se agregan costos a la estimacin.
PLANTILLA DE DEFINICION DE HISTORIAS
ID NOMBRE
IMPORTANCIA TAMAO VALIDACION
1
RIESGOS ASOCIADOS
CAPACIDADES REQUERIDAS
2
3
4
5
Figura 5.6: Plantilla para Definicin de Historias
Para poder medir el posible impacto de algn riesgo que se materialice, Mximo introduce una planilla de
definicin y anlisis de riesgos (Figura 5.7). Toda esta documentacin es simple y no lleva tiempo extra para ser
llenada, mientras que s arroja mucha luz sobre el proyecto, obligndoles a los miembros del equipo a pensar
59
sobre lo que hacen usando otras facultades adems de su capacidad de construir .
Planilla de Definicin y Control de Riesgos
Nombre del Proyecto:

Fecha:
Preparado por:
ID - identificador del riesgo

Aada las columnas que sean necesarias para monitorear la evolucin de los riesgos.
Descripcin del Riesgo - problema potencial ( condicin y consecuencia)
Prob - probabilidad de que el riesgo se transforme en un problema
Perd - Prdida - potencial relativo de la prdida (monetaria) o un nmero entre 1 y Exp
100)- Exposicin - producto entre prob y perd
Prioridad en este anlisis - ranking pro exposicin
Prioridad la ltima vez - muestra el cambio ocurrido
# Veces en la lista - resistencia a las acciones
Accin - acciones a llevar a cabo para lidiar con el riesgo
Quin - persona responsable por las acciones
Cuando - fecha en la que se revisarn las acciones
Descripcin del Riesgo
Prob Perd Exp
ID
Condicin
Prioridad Prioridad # Veces

en este la ltima
en la
anlisis
vez
lista
Accin
Quin
Cuando
Consecuencia
1
2
3
4
5
6
7
8
9
10
Figura 5.7: Plantilla para Definicin y Anlisis de Riesgos
Llegado este punto Mximo introduce la plantilla que Vitalera usa para sus propuestas de consultora, que
sigue una estructura que contiene el Backlog del producto, el plan de sprints y el tablero original del primer sprint.
Tambin se explicitan en ella tiempos y costos, as como un resumen extrado de la planilla de anlisis de riesgos y
un listado de las responsabilidades mutuas (ver Figura 5.8).
59
56
[DE BONO, E., 1985]. El libro hace referencia a cinco maneras de pensar acerca de un problema. Informacin: (blanco),
Emociones (Rojo), Discernimiento (Negro), Optimista (Amarillo),Creativo (Verde). Tambin hay un sombrero Azul para
discutir las reglas del juego en s.
Captulo 5
Boria et al.
Introduccin
Resumen Ejecutivo de la Propuesta
Alcance del Proyecto
Mtodo de Desarrollo de las actividades
Descripcin general
Ciclo de vida de cada actividad
Preparacin del personal involucrado
Historias <link al documento Historias>
Identificador
Nombre
Importancia
Tamao
Validacin
Riesgos <link a la planilla de riesgos>
Capacidades Requeridas
Calendario de Trabajo
Sprint 1
Sprint 2
Sprint
Sprint de estabilizacin
Presupuesto econmico y financiero
Riesgos previstos
Obligaciones mutuas
Comunicaciones
Entregas
Aprobaciones
Pagos
Figura 5.8: Plantilla de Propuesta de Proyecto
La nueva estructura, con las correspondientes ligas a los productos vinculados (Backlog en la herramienta de
software y planilla de riesgos) constituye una evidencia til de las resoluciones aprobadas en equipo. En menos de
una hora de trabajo sobre esta planilla se llega a un acuerdo y se disponen a mandarlo al cliente. Mximo pide dos
cosas: una es que los presentes se comprometan a firmar su acuerdo con la propuesta, la segunda es que el cliente
tambin lo haga. Los gemelos lo miran un poco raro, pero Mximo explica que los clientes que no quieren firmar
no quieren comprometerse, siendo que el resultado es que no va a haber acuerdo en el momento de la entrega.
15. Mximo ha incorporado mejoras al documento del Backlog, hacindolo ms slido y ms til.
16. Utilizando una plantilla de riesgos se analizaron los posibles efectos indeseados asociados con
las historias del proyecto.
17. Se incorpor una plantilla de propuestas que permite aunar en un documento dinmico al
Backlog y el presupuesto y aadir responsabilidades de las partes contractuales.
18. Los compromisos mutuos de cliente y proveedor quedan documentados, en particular el
alcance del proyecto, representado en el Backlog.
Sin ms que tratar, se disuelve la reunin. Mximo es llevado aparte por Claudio. En el saln de las
conversaciones privadas le explica que la empresa tiene pocos fondos y que le gustara mucho contar con su apoyo
como consultor, pero que carecen de presupuesto para ello. Quizs, a pesar de ello, esta intervencin haya sido la
ltima.
Mximo sonre con afabilidad, porque esperaba que este problema se presentara.
Captulo 5
57
Justamente de eso quera que hablramos, dice. Hay un programa

recibir fondos del estado para hacerlo.
60
que permite invertir en calidad y
Mximo explica el programa y los ojos de Claudio se abren cada vez ms.
-
De nuestra experiencia, pese a ser relativamente nuevo en el ambiente, el modelo ms adecuado para
2
empresas como T es el MPS.
Qu es el MPS?, pregunta Claudio.
Sigue una precisa explicacin de parte de Mximo sobre las ventajas del modelo, matizada con conceptos
2
como evaluaciones, evidencia directa y otros trminos que hoy son nuevos en T pero que se van a convertir, con
el paso del tiempo, en moneda corriente. Claudio queda con la tarea de contar el resumen de lo ac hablado a
2
todos los socios, mientras que Mximo tiene que hablar en Vitalera para que se ingrese a T en la lista de
empresas que aspiran al soporte para implementacin.
5.6 Avances en la Implementacin del MPS
2
Unas semanas despus T est preparando su evaluacin de Nivel G del MPS. La primera actividad en el plan
que Vitalera prepar con ellos es la realizacin de un anlisis de la brecha que media entre los procesos, como
estn implementados, y los resultados esperados de implementacin de procesos del MPS. Para ello, es til contar
con la tabla de los resultados esperados en el nivel G (Tabla 5.2) y compararlos contra lo que est implementado
2
en T :
Gestin de Proyectos (GPR) en el Nivel G
60
GPR 1
El alcance del trabajo para el proyecto est definido;
GPR 2
Las tareas y los productos de trabajo del proyecto son dimensionados, utilizando mtodos
apropiados;
GPR 3
El modelo y las fases del ciclo de vida del proyecto son definidos;
GPR 4
El esfuerzo y el costo para la ejecucin de las tareas y de los productos de trabajo son estimados
con base en datos histricos o referencias tcnicas;
GPR 5
El presupuesto y el cronograma del proyecto, incluyendo la definicin de marcos (hitos) y puntos

de control, son establecidos y mantenidos;
GPR 6
Los riesgos del proyecto son identificados y su impacto, probabilidad de ocurrencia y prioridad de
tratamiento son determinados y documentados;
GPR 7
Los recursos humanos para el proyecto son planificados considerando el perfil y el conocimiento
necesarios para llevarlo a cabo;
GPR 8
Los recursos y el entorno de trabajo necesarios para llevar a cabo el proyecto son planificados;
GPR 9
Los datos relevantes del proyecto son identificados y planificados respecto a la forma de
recoleccin, almacenamiento y distribucin. Un mecanismo es establecido para su acceso,
incluyendo, en caso de que sea pertinente, cuestiones de privacidad y seguridad;
GPR 10
Un plan general para la ejecucin del proyecto es establecido con la integracin de planes
especficos;
GPR 11
La viabilidad de lograr las metas del proyecto es explcitamente evaluada considerando

restricciones y recursos disponibles. En caso necesario, ajustes son realizados;
GPR 12
El Plan del Proyecto es revisado con todos los interesados y el compromiso con l es obtenido y
mantenido;
GPR 13
El alcance, las tareas, las estimativas, el presupuesto y el cronograma del proyecto son
supervisados con relacin a lo planificado;
GPR 14
Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados
con relacin a lo planificado;
GPR 15
Los riesgos son supervisados con relacin a lo planificado;
GPR 16
La participacin de las partes interesadas en el proyecto es planificada, supervisada y mantenida;
En varios pases de Latinoamrica esto es una realidad. La forma que adopta el programa vara de pas en pas, por lo que se
evit en este texto hacer una referencia ms explcita. Los programas suelen pagar a las empresas una parte sustancial de
los egresos en consultora cuando la empresa acredita o certifica bajo un modelo internacional, como el MPS, el CMMI o
ISO.
58
Captulo 5
Boria et al.
Gestin de Proyectos (GPR) en el Nivel G

GPR 17
Revisiones son realizadas en marcos (hitos) del proyecto y conforme lo establecido en los planes;
GPR 18
Registros de problemas identificados y el resultado del anlisis de cuestiones pertinentes,

incluyendo dependencias crticas, son establecidos y tratados con las partes interesadas;
GPR 19
Acciones para corregir desvos de lo planificado y para prevenir la repeticin de los problemas
identificados son establecidas, implementadas y acompaadas hasta su conclusin.
Tabla 5.2 Proceso GESTIN DE PROYECTOS en el Nivel G [SOFTEX, 2012a]
El Backlog permite conocer el alcance del trabajo (GPR1) y junto con el tablero define las tareas y los
productos asociados, con sus correspondientes esfuerzos que se estimaron por el consenso de los participantes
(GPR2). El plan de los sprints define el modelo a seguir en el proyecto y las fases corresponden a los sprints,
asimismo el tablero muestra en las tareas el ciclo de vida de cada historia (GPR3). En la propuesta se incluye un
anlisis de costos y el cronograma previsto (GPR2, GPR4 y GPR5). El Backlog identifica los riesgos y la planilla de
riesgos los analiza (GPR6). En el Backlog tambin se identifican las habilidades y conocimientos necesarios para
realizar las tareas relacionadas con cada historia y al asignarse la tarea se considera esto (GPR7). La nueva plantilla
de la propuesta funciona como el plan integrado, cuando se incluyen las ligas a los documentos perifricos como
los que estn almacenados en la herramienta sprint.er y la planilla de riesgos (GPR10). En cada sprint se realiza el
anlisis del esfuerzo necesario y se revisan estimaciones para garantizar que se termina con las historias (GPR11).
Las firmas de los participantes en el proyecto, externos e internos, evidencia que los involucrados asumen el
compromiso con el mismo (GPR12).
2
De las tareas de planificacin solo faltan GPR 8 y GPR 9. Mximo y el equipo de T tendrn que trabajar en
generar los cambios para que los procesos los implementen. Mientras tanto, es ms productivo abocarse a la tarea
de garantizar que los procesos de monitoreo y control estn siendo implementados.
La primera accin ya realizada en la primera semana del contrato ha sido incorporar al repertorio de
actividades el Scrum diario. Siguiendo los lineamientos generales ya vistos en el Scrum: Organizando el sistema
para un estado de equilibrio orgnico del Captulo 3, Marcela pasa a cumplir funciones de Scrum Master y junto
con los gemelos y Ana, como equipo del sprint, se renen diariamente en la sala de diseo para evaluar los
avances del da anterior y el estado general del sprint, incluidos los riesgos asociados. Esta reunin no es
exactamente un Scrum de acuerdo con las reglas de [SCHWABER & BEEDLE, 2002], pero sirven a los efectos de
controlar el proyecto. Continuando con el anlisis de la brecha entre lo implementado y lo que es requerido por el
MPS, las componentes del modelo que el Scrum diario contribuye a evidenciar son entonces GPR 13, puesto que
en esta reunin el alcance, las tareas, las estimaciones, el presupuesto y el cronograma del proyecto son
supervisados con relacin a lo planificado; GPR 14, porque los recursos materiales y humanos as como los datos
relevantes del proyecto son supervisados con relacin a lo planificado para el sprint; GPR 15, dado que se
supervisan las tareas relacionadas con los riesgos y GPR 16 porque la participacin de las partes interesadas en el
proyecto es planificada, supervisada y mantenida.
Enseguida se agregan al proceso demostraciones de producto que se realizan con el cliente al final de cada
sprint, y de ese modo la participacin de todos los interesados est completamente evidenciada. Con todos estos
elementos Mximo construye un proceso que vuelca en un diagrama de andariveles (un ejemplo de este tipo de
diagramas se muestra en la Figura 5.9).
Figura 5.9: Diagrama de Andariveles
Todava faltan implementar varios resultados esperados del MPS para Nivel G, incluso no se han discutido
todos los procesos correspondientes, dado que la Gerencia de Requisitos (GRE) es parte de lo que es necesario
hacer para alcanzar el Nivel, pero Mximo tiene la seguridad de que lo que se ha hecho hasta ahora alcanza para
cubrir ese proceso en particular. Analiza entonces los resultados esperados de GRE siguiendo la tabla
Captulo 5
59
correspondiente (Tabla 5.3) y comprueba que la propuesta, en tanto documento integrador del proyecto, contiene
las historias, y dado que est siendo firmada para mostrar su aprobacin por los clientes, cubre de ese modo el
resultado esperado GRE 1; que la revisin que hace el equipo de las historias para estimarlas y revisar los riesgos y
habilidades requeridas cubre GRE 2, que el tablero Kanban, como est siendo utilizado, permite rastrear las
historias a travs de los productos del proyecto, cubriendo as GRE 3, que en las reuniones diarias se introducen
tareas derivadas que afectan las estimaciones de las historias y disparan nuevos anlisis que determinan que se
cubre GRE 4, y que entre estos cambios que se generan desde el equipo y los cambios que pueden surgir por
pedido del cliente de un sprint al siguiente, provocados o no por la demostracin de lo realizado, surge la evidencia
necesaria para GRE 5. El prximo paso para Mximo es completar los resultados esperados con los dos faltantes en
GPR y analizar e implementar los resultados esperados para los atributos de proceso correspondientes, AP 1.1 y AP
2.1.
Gestin de Requisitos (GRE)
GRE 1
El entendimiento de los requisitos es obtenido en conjunto con los proveedores de requisitos;
GRE 2
Los requisitos son evaluados con base en criterios objetivos y el compromiso del equipo tcnico
con estos requisitos es obtenido;
GRE 3
La rastreabilidad bidireccional entre los requisitos y los productos de trabajo es establecida y

mantenida;
GRE 4
Revisiones en planes y productos de trabajo del proyecto son realizadas con el objetivo de
identificar y corregir inconsistencias relacionadas a los requisitos;
GRE 5
Cambios en los requisitos son gestionados durante el proyecto.

Tabla 5.3 Proceso GESTIN DE REQUISITOS [SOFTEX, 2012a]
Conforme con los resultados hasta este momento, Mximo introduce un corto procedimiento para definir la
estructura de carpetas de un proyecto en el sitio de cada proyecto, y se sienta junto a Marcela y uno de los
gemelos para escribir el script que automatice su ejecucin. Con la conformidad de la organizacin, la estructura
contiene una carpeta para cada uno de los pasos del proceso que la organizacin sigue, ms unas carpetas de
comunicaciones y acciones a tomar. Dentro de cada carpeta el equipo puede encontrar las plantillas
correspondientes a utilizar en el proceso. De ese modo Mximo est seguro que los dos resultados faltantes de
GPR han quedado cubiertos.
19. Mximo ha introducido el Scrum diario para evaluar los avances da a da y el estado general del
sprint, incluidos los riesgos asociados, para con ello mejorar el control y brindar evidencias de
varios resultados esperados del MPS.
20. La organizacin incorpora una demostracin del producto al final de cada sprint como criterio
de aceptacin por el usuario que sirve para evidenciar su participacin.
21. El anlisis de brecha ejercido como actividad continua muestra que los resultados esperados
para GRE surgen de los procesos ya implementados.
22. Mximo ha introducido un corto procedimiento para definir la estructura de carpetas de un
proyecto en el sitio de cada proyecto, que evidencia la implementacin de GPR 8 y GPR 9.
5.7 Preparando la Evaluacin
Para alcanzar el nivel G del MPS quedan por definir las actividades que planifiquen y pongan al alcance de los
interesados los recursos y el ambiente de trabajo necesarios para ejecutar el proyecto y los datos relevantes del
mismo. Para estos ltimos hay que definir como se los junta, almacena y distribuye. Tambin hay que definir el
mecanismo para acceder a ellos incluyendo cuando fuera necesario restricciones de acceso. Adems es necesario
revisar los atributos de los procesos GPR y GRE, esos que hablan de la capacidad de la organizacin para llevarlos
adelante. Estos son abreviados como AP y tienen a su vez resultados esperados que se abrevian RAP.
En primer lugar, dado que AP 1.1 es simplemente El proceso es ejecutado, con un nico resultado
esperado, RAP 1, El proceso logra sus resultados definidos, lo que Mximo tiene en cuenta es que los resultados
definidos, salvo los ya identificados, estn implementados, luego no hay acciones relacionadas.
La cosa cambia cuando se trata del segundo atributo, AP 2.1 El proceso es gestionado, porque los
resultados esperados son nueve:
60
Captulo 5
Boria et al.
RAP 2 Existe una poltica organizacional establecida y mantenida para el proceso;

RAP 3 La ejecucin del proceso es planificada;
RAP 4 La ejecucin del proceso es supervisada y se realizan los ajustes necesarios;
RAP 5 Las informaciones y los recursos necesarios para la ejecucin del proceso son identificados y puestos
a disposicin de los interesados;
RAP 6 Las responsabilidades y la autoridad para ejecutar el proceso se definen, atribuyen y comunican;
RAP 7 Las personas que ejecutan el proceso son competentes en trminos de formacin, entrenamiento y
experiencia relacionados;
RAP 8 La comunicacin entre las partes interesadas en el proceso se planifica y ejecuta de modo que se
asegure su participacin;
RAP 9 Los resultados del proceso son revisados con la alta gerencia para proporcionar visibilidad sobre su
situacin en la organizacin;
RAP 10 El proceso planificado para el proyecto es llevado a cabo.
Mximo produce una poltica sobre las actividades de un proyecto de Nivel G que dice lo siguiente: Los
proyectos de Tahini-Tahini se originan de requerimientos del cliente y aprobados por este, son analizados para
asegurar su factibilidad y viabilidad, estimados y costeados. Los costos se basan en estimaciones de tamao y
esfuerzo, y las etapas en las que se realizarn se planifican y se coordinan con los clientes. El personal que se
escoge para las tareas es idneo, basado en su capacidad objetiva. Los planes que se aprueban son utilizados como
la base para controlar y monitorear el proyecto. Todo cambio que impacte en los compromisos internos o externos
debe contar con las mismas aprobaciones que el proyecto original. Cualquier violacin a esta regla ser
considerada motivo de sanciones y eventualmente suspensin de los que la violen reiteradamente. En discusiones
con los gemelos, que se oponan a una mencin de sanciones, Mximo logr convencerlos de que una regla sin
sancin ms que una regla es un deseo, y que adems la sancin era discrecional, si la razn por detrs de la
violacin era atendible, no haba porqu llegar a la sancin. Este enunciado aparece hoy encabezando la pgina de
2
procesos de T . Con esto ya se tiene evidencia de la implementacin de RAP 2.
Luego Mximo atac los siguientes RAP, uno a uno: planificar, supervisar la ejecucin y ajustar si es necesario,
poner a disposicin de aquellas personas y roles responsables los recursos, datos e informaciones necesarias para
llevarlo adelante y otorgarles autoridad para hacerlo, brindndole capacitacin cuando no tengan la competencia
adecuada, o nombrar a quin la tenga en el rol, garantizar la participacin de las partes interesadas, revisar con
alta gerencia para proporcionar visibilidad sobre su situacin en la organizacin y por ltimo, llevar a cabo todo lo
anterior.
Incorpor un proceso de iniciacin de proyectos que describe como se debe completar una propuesta,
obviamente basndose en el proceso que describi para llevar adelante un proyecto usando el tablero virtual, pero
extendindolo para que se cubran todas las etapas de planificacin, control y gestin de requisitos. En el ms alto
nivel describe la secuencia de procesos de manera grfica. Para cada actividad usa la plantilla de procedimiento
(Figura 5.10) y un diagrama de andariveles que dibuja usando un programa grfico.
Por ahora deja de lado las mediciones de cada actividad pero s incluye el diagrama. El proceso incluye todas
2
las actividades de generar el plan, definiendo los roles y funciones de cada actor e interesado. Cuando T comience
su prximo proyecto el proceso se ejecutar y generar la propuesta con todas las planillas correspondientes, as
como las actividades de Gerencia de Requisitos necesarias y las actividades de control del proyecto. El proceso as
definido cubre la planificacin de la planificacin, dado que identifica quin o quines son responsables por
2
generar la propuesta, cmo se adjudica la responsabilidad y que recursos le dan soporte. De este modo T atiende
a los resultados esperados de los Atributos de Proceso.
Captulo 5
61
PLANTILLA DE DETALLE DE PROCEDIMIENTO

Nombre de la Actividad:
Propsito. (Qu se espera lograr con esta actividad?)
Involucrados (al menos el responsable)
Entradas requeridas
Productos de trabajo creados (salidas)
Criterio de Ingreso (Cmo se sabe cuando comenzar esta actividad?)
Criterio de Salida (Cmo se sabe que la actividad ha concluido satisfactoriamente?)
Sub-actividades. (3 a 6 sub-actividades [si las hay] para llevar a cabo esta actividad, que sern incorporadas en
el diagrama de andariveles)
Mediciones. (Cmo se puede medir el rendimiento de esta actividad?)
Secuencia. (Qu actividades se llevan a cabo antes y despus de esta?)
Figura 5.10: Planilla de Detalle de un Procedimiento
Uno de los principales impulsores de la mejora continua en una organizacin es la realizacin de reuniones
peridicas que analicen lo actuado y sugieran cambios a los procesos para mejorar. Esas reuniones reciben el
2
61
nombre de retrospectivas, y T las adopta bajo la preparacin y supervisin de Mximo.
Lo ms importante de las retrospectivas es que tengan lugar. Sin ellas los equipos repiten sus errores en vez
de aprender de ellos. La responsabilidad del Scrum Master, por lo tanto, es que se planifiquen entre sprints y se
lleven a cabo. Es posible que una situacin crtica en el medio de un Sprint invite a llamar una retrospectiva de
emergencia, pero su lugar natural es entre Sprints. Se deben apartar entre una y tres horas del equipo con este
propsito, siendo que la duracin justa depende de la participacin y de la cantidad de temas que se anticipan
sern discutidos en la reunin. Es importante que participen todos los interesados, incluido el Dueo del Producto.
El lugar de la reunin no puede ser la misma sala de trabajo, porque es sumamente importante no sufrir
interrupciones. Mximo eligi la sala de diseo porque tiene los tableros que permiten trabajar cmodos y no
tiene telfonos ni pantallas de computadoras. No se permiten las laptops en la reunin de anlisis retrospectivo.
Se divide el tablero en tres columnas: Qu Anduvo Bien, Qu Hay que Mejorar y Sugerencias. Primero se
completan las dos primeras columnas y cuando ya no haya ms propuestas para ninguna de ellas, se inician las
rondas de sugerencias.
Las tcnicas para esto son mltiples y es valioso conocer tantas como sea posible. Ya hemos mencionado el
diagrama de Ishikawa, o de espina de pescado, as como los cinco porqus, y las ocho disciplinas. Existen
mecanismos de pensamiento, como mencionamos ya el de los sombreros de colores de [DE BONO, 1985] que
permiten ejercitar el pensamiento crtico. Estas y muchas otras tcnicas tienen mrito y su aplicacin medida da
excelentes resultados.
El informe de Mximo para su jefe incluye la siguiente tabla (Figura 5.11), que muestra las evidencias que se
tienen de la obtencin de los resultados esperados por la implementacin del proceso GPR del modelo. Las
columnas definen la documentacin existente, de izquierda a derecha: Tablero Kanban, Plantilla de Historias,
Propuesta, Script de Definicin de Carpetas y Recursos, Demostracin Final de Cada Sprint, Plantilla de Riesgos,
Informe de la Retrospectiva y el Scrum Diario. Cada una de esas evidencias contribuye a que la totalidad de los
resultados esperados se cubran en la implementacin elegida. Asimismo hay otras tablas de cobertura para GRE y
las RAP.
61
62
Hemos elegido preparacin y supervisin para englobar el significado de coaching, que lamentablemente no tiene una
buena traduccin en un solo vocablo en Castellano.
Captulo 5
Boria et al.
Figura 5.11: Evidencias para GPR en el Nivel G

23. Mximo ha definido y codirigido varias implementaciones del procedimiento de anlisis
retrospectivo, que brinda evidencia de GPR 17, GPR 18 y GPR 19.
24. Mximo ha redactado una poltica que la organizacin aprob para establecer los lineamientos
2
de lo que se espera del personal de T .
25. 25. Mximo ha desarrollado un proceso que permite evidenciar las capacidades de proceso de
Nivel G del MPS para las actividades de planificacin, a travs de la propuesta, y gestin de
requisitos, a travs del Backlog del producto y la evolucin del tablero Kanban.
2
Dejamos a Mximo y T organizando la evaluacin formal de Nivel G del modelo MPS.
Captulo 5
63
CAPTULO 6 - UNA ORGANIZACIN EN CRECIMIENTO (NIVEL F DE MPS-SW)

Este captulo tiene como objetivo discutir la implementacin de prcticas que se requieren en el nivel F del
modelo de referencia MPS. En el nivel F, Gestionado, los procesos son Adquisicin (AQU), Gestin de la
Configuracin (GCO), Garanta de la Calidad (GQA), Gestin de Portafolios de Proyectos (GPP) y Medicin (MED).
Ntese lo que dice el modelo:
La implementacin de los procesos para el nivel F puede hacerse en cualquier secuencia, visto que los
procesos de ese nivel son de apoyo a la gestin del proyecto, suministrando mayor calidad y control a los productos
de trabajo. Una vez que necesitan de procesos de apoyo, las organizaciones pueden tener la necesidad de
incorporar a su equipo algunos nuevos perfiles para realizar actividades de aseguramiento de la calidad, gestin de
configuracin, medicin, gestin de portafolio de proyecto y adquisicin de productos. Sin embargo, note que la
existencia de un nuevo perfil no obliga necesariamente a la contratacin de nuevas personas, sino ms bien, a la
62
definicin de nuevas competencias necesarias y delimitacin de nuevas responsabilidades .
2
26. T ha alcanzado el nivel G del MPS - SW en una evaluacin oficial

6.1 Crecen los pedidos
Tahini-Tahini ha pasado a constituir el bien ponderado crculo de empresas que han sido evaluadas en el Nivel
G del MPS. Aunque hubo algunos detalles aqu y all descubiertos por el equipo de evaluacin, fueron arreglados
2
prontamente por el personal de T y la organizacin recibi su diploma en el congreso anual del Simpsio Brasileiro
2
de Qualidade de Software (SBQS). La noticia circul rpidamente en los medios locales y T tuvo sus quince
2
minutos de notoriedad. Por breve que haya sido esa notoriedad los amigos de T , como el Doctor Molar, se
sintieron obligados a compartir el orgullo que les trajo la noticia. La consecuencia inmediata es que otros clientes
2
se acercaron a T para inquirir sobre sus servicios.
Una oferta muy tentadora lleg desde el Consejo Profesional de Contadores Pblicos (CoProCoP) para que se
brinden los tradicionales servicios de liquidacin de salarios a los miembros del CoProCoP, y al mismo tiempo
trabajar para y con ellos (los miembros del Consejo) extendiendo esos servicios para ellos y otros clientes
potenciales con el conocimiento colectivo del consejo en ciertas aplicaciones contables y de administracin. La
oferta es sumamente interesante, porque aumentara de inmediato la facturacin con clientes existentes al
ofrecer las nuevas funcionalidades y tambin ampliara el mercado potencial.
2
Tras unas breves charlas iniciales con CoProCoP se hace una reunin plenaria de T para tomar una decisin
sobre el camino a seguir. Esta reunin es crucial porque la oferta plantea una encrucijada real: Crecer o no crecer.
Sin duda crecer es algo a lo que toda organizacin cree aspirar. Ms clientes, ms facturacin, mejores salarios,
vacaciones pagas, un futuro venturoso. Pero tambin implica dejar de lado la cotidianeidad de los amigos,
profesionalizar la administracin, despegarse de las tareas divertidas o tener que hacerlas de otro modo. Las
emociones entre asistentes a la reunin oscilan desde los que estn asustados a los que estn eufricos. Las vas
de crecimiento se les antojan extraas y complicadas. Tras dos horas de reunin no se llega a ninguna conclusin.
Es entonces que uno de los gemelos propone llamarlo a Mximo.
6.2 Buscando Ayuda Fuera de Tahini-Tahini
2
Dos das ms tarde, Mximo facilita la reunin plenaria de T en la sala de diseo. Esta vez ha trado consigo
seis sombreros de diferentes colores: [De Bono, 1985] Los colores son Azul, Blanco, Rojo, Negro, Amarillo y Verde.
Cada color representa una modalidad de pensamiento de la que es capaz nuestro cerebro. Se dice que una
persona se pone el sombrero Azul cuando quiere expresar pensamientos alrededor del mtodo que se sigue, es
decir, pensamientos sobre el mtodo de trabajo. El sombrero Blanco se usa para trabajar con los datos concretos,
con la informacin disponible. Con el sombrero Rojo se expresan los sentimientos. No hace falta alguna
justificarlos. La lgica de la cautela se expresa con el sombrero Negro. Tiende a mostrar los problemas, de ah el
color. El Amarillo expresa la lgica del optimismo, lo que puede ocurrir que nos gustara que pase. El Verde es para
provocar. No hay un orden predeterminado de su uso, en general se comienza a usarlos para alentar la discusin y
evitar que el pensamiento se estanque en la lgica de lo que puede andar mal. Se puede especificar un orden
inicial y todos usan ese color por una ronda, por ejemplo el sombrero Azul. Tambin es posible que una persona
62
SOFTEX, 2012c, pgina 7
64
Captulo 6
Boria et al.
tome el sombrero que corresponde a lo que quiere expresar antes de decirlo, de modo que todos sepan que est
haciendo esa comunicacin desde el punto asociado al color.
Mximo se calza el sombrero Azul y explica los roles de los colores y propone usarlos en ronda. Primero todos
usarn el Amarillo, luego el Rojo y luego el Negro. Cuando llega el momento de expresar la negatividad ya todos
han analizado las posibilidades y sus sentimientos respecto de los cambios, y los han compartido. Mximo los ha
ido registrando en la pizarra electrnica y cuando llegan al Negro cambia de pizarra y en vez de anotarlos en una
lista hace dos columnas (Tabla 6.1)
No estamos listos para
crecer
Crecimiento demasiado
rpido
Muchas lneas de producto
Prdida del control
Tabla 6.1: Pensamientos Negativos sobre el Cambio
Mximo ha copiado los pensamientos negativos de todos. Algunos fueron repetidos o suficientemente
relacionados como para ser expresados en una sola oracin. Los ha sintetizado en las oraciones que escribi. Como
todos ya conocen el diagrama de Ishikawa de espina de pescado, lo utiliza para dar comienzo a la sesin de anlisis
de lo enunciado para llegar a una estrategia de crecimiento. Dibuja con gracia un esqueleto de sardina y escribe la
primera oracin en la cabeza del pescado (Figura 6.1):
Figura 6.1: Diagrama Ishikawa sobre Crecimiento 1
Las risas dejan lugar a caras preocupadas. Hay preguntas, discusiones entre los socios. Mximo los deja seguir
un par de minutos y luego interrumpe.
-
Para qu sirve el diagrama de Ishikawa?.
La pregunta es retrica, pero tiene su resultado. De inmediato todos caen en la cuenta de que se han vuelto a
poner el sombrero Negro, algunos tambin el Rojo. Haciendo que vuelvan al ejercicio de bsqueda de soluciones,
escribe l mismo la solucin. (Figura 6.2)
Figura 6.2: Diagrama Ishikawa sobre Crecimiento 2
Se hace un silencio de asentimiento. Mximo deja que la idea se vaya haciendo fuerte en los socios y
encabeza su lista con este ttulo: Preparndonos Para Crecer y borra la primera fila. La reunin se anima de a
poco, y donde se vean problemas se ven ahora soluciones. Algunas se descartan, por ejemplo el crecimiento
acelerado puede ser controlado mediante la contratacin de personal, pero el costo en esfuerzo del personal
actual y la inversin en facilidades es demasiado grande. En cambio, es posible considerar la contratacin de
servicios de desarrollo de un proveedor establecido. La tabla completa ha quedado as constituida (Tabla 6.2):
PREPARANDONOS PARA CRECER
Crecimiento demasiado
implica contratar servicios externos
rpido
Muchas lneas de producto implica contar con gestin de configuracin
implica seleccionar entre opciones de inversin
Captulo 6
65
Prdida del control
implica controlar objetivamente mediante

decisiones basadas en datos
implica controlar objetivamente la aplicacin
de normas y polticas
Tabla 6.2: Preparndonos para Crecer
Ahora Mximo sugiere atacar uno a uno los riesgos, empezando por la contratacin de una empresa
proveedora. Produce una lista de riesgos que proyecta en la pared, que dice as:
Contratacin de Proveedores, Riesgos:
1. se contratan los servicios equivocados
2. se contratan los proveedores equivocados
3. se elije de un subconjunto inadecuado de proveedores
4. se elije subjetivamente
5. se hace un contrato que no le sirve a las dos partes
6. se cierra el contrato sin que se hayan cumplido con todos los requisitos.
Los socios los revisan con Mximo, uno a uno. Van asintiendo, con algunas preguntas. El tem 5 se discute un
poco ms que los dems. Claudio quiere saber por qu es importante hacer un contrato que sirva a las dos partes,
adems de las consideraciones ticas. Mximo explica que si el contrato no le sirve a cliente y proveedor es posible
que el proveedor no pueda entregar su producto, arrastrando en consecuencia al cliente en su cada.
Mximo pregunta si alguien quiere agregar algn riesgo ms, y espera la respuesta. Despus de un silencio
suficientemente largo, sigue con mitigaciones.
-
Bien, dice, ahora podemos ver qu tenemos que hacer para que estos riesgos no se materialicen o si es
que ocurren, que tengan bajo impacto.
Mximo no se preocupa en definir los trminos de manera formal, ya llegar el momento de hacerlo. Por
ahora solo necesita que colaboren con l. Usando los diagramas de pescado de manera muy rudimentaria, puesto
que las soluciones son obvias, se llega a la siguiente conclusin para cada uno de los riesgos:
Para no contratar los servicios equivocados hay que planificar la adquisicin, determinando qu se adquirir y
porqu se va a producir la misma.
Para no contratar los proveedores equivocados hay que establecer claramente, antes de salir a buscarlos,
cules son los atributos que debern poseer para participar en la compulsa de precios.
Para no elegir de un subconjunto inadecuado de proveedores hay que investigar el mercado basndonos en
el tipo de adquisicin y los atributos requeridos de los proveedores.
Para no elegir subjetivamente entre los candidatos hay que construir un modelo de decisin que permita
elegir entre ellos basndose en datos objetivos en todo lo posible.
Para no hacer un contrato que no le sirve a las dos partes hay que negociar con buena disposicin y buscando
el ganar-ganar con coraje, madurez, imaginacin e integridad. El contrato debe permitir manejar procesos
conjuntos.
Para que no se cierre el contrato sin que se hayan cumplido con todos los requisitos es necesario que haya un
acuerdo claro sobre qu se debe entregar, cundo y en qu condiciones.
-
Esta es una buena lista, dice Mximo. Lo ms interesante es que se pueden implementar estas
acciones de manera de cumplir con la implementacin de todos los resultados de proceso
correspondientes a Gerencia de Adquisicin del MPS, y sonre al decirlo.
Proyecta entonces esos resultados:

Adquisicin (AQU)
66
AQU 1
Las necesidades de adquisicin, las metas, los criterios de aceptacin del producto, los tipos de
adquisicin y la estrategia de adquisicin son definidos;
AQU 2
Los criterios de seleccin del proveedor son establecidos y usados para evaluar los proveedores en
potencial;
AQU 3
El proveedor es seleccionado con base en la evaluacin de las propuestas y de los criterios

establecidos;
Captulo 6
Boria et al.
Adquisicin (AQU)
AQU 4
Un acuerdo que expresa claramente las expectativas, las responsabilidades y las obligaciones de
ambas partes (cliente y proveedor) es establecido y negociado entre ellas;
AQU 5
Un producto que satisfaga la necesidad expresada por el cliente es adquirido con base en el anlisis
de los potenciales candidatos;
AQU 6
La adquisicin es supervisada de modo que se cumplan las condiciones especificadas, tales como:
costo, cronograma y calidad, generando acciones correctivas cuando necesario;
AQU 7
El producto es entregado y evaluado con relacin a lo acordado y los resultados son

documentados;
AQU 8
El producto adquirido es incorporado al proyecto, en el caso de que sea pertinente.

Tabla 6.3: Proceso ADQUISICIN [SOFTEX, 2012a]
Los socios se abocan a la creacin de guas, criterios y procesos para realizar adquisiciones. Rpidamente
algunos criterios surgen claramente: la adquisicin debe quedar claramente delimitada en la arquitectura, con
interfaces bien definidas; los proveedores deben ser suficientemente experimentados como para poder entregar
un producto de calidad pero no tan grandes que el acuerdo de negocios resulte totalmente unilateral; la visibilidad
dentro de los procesos del proveedor y la colaboracin que estn dispuestos a prestar para ello sern objeto de
anlisis y se dar importancia a quines demuestren esa voluntad. Esos y otros van dando forma a los procesos de
adquisicin. Las primeras dudas y los miedos se disipan en la actividad creativa.
Queda la duda, sin embargo, sobre la decisin de fabricar o comprar, ya que hay que considerar factores
como las caractersticas del producto que los proveedores ofrecen y cmo encaja cada uno en el proyecto, la
disponibilidad de recursos y perfiles de proyectos, porque hay que balancear entre lo que se har internamente
con los recursos que no se necesitarn por ser del proveedor, ms la administracin del contrato, el costo de
adquirir versus el costo del desarrollo interno; las fechas crticas de entrega e integracin; la posibilidad de
implementar una estrategia de alianzas, incluyendo los requisitos de negocio de alto nivel. Se proponen investigar
los productos en desarrollo y los que ya estn en el mercado, buscando entender la funcionalidad y la calidad de
esos productos, el impacto sobre la competencia, licencias, permisos, responsabilidades y limitaciones asociadas a
los productos que se estarn comprando, as como la disponibilidad del producto, las cuestiones relacionadas con
63
la propiedad y si la decisin aumenta o disminuye los riesgos. Mximo propone crear una matriz de Pugh que
contenga las alternativas y usarla cuando se necesite. Con esa tarea pendiente se levanta la reunin.
27. Mximo ha utilizado la tcnica de los sombreros de colores para sembrar el camino de ideas y
con el diagrama de Ishikawa ayudar a los socios a dilucidar cual camino seguir en la empresa
(crecer o no crecer).
28. Mximo ha ayudado a revisar los riesgos de contratacin de proveedores y estudiar las
alternativas de comprar, reusar o fabricar introduciendo la tcnica de la matriz de Pugh.
6.3 Qu deberamos fabricar?
Al da siguiente Mximo recibe un llamado de Claudio. Un acontecimiento inesperado ha tenido lugar: A la
propuesta de trabajo conjunto del CoProCoPse ha sumado otra de una empresa que mantiene y vende un sistema
de manejo de stock para farmacuticos al que no le vendra mal un sistema de liquidacin de salarios. La pregunta
es cuando puede Mximo ayudarlos a resolver ese tema facilitando la reunin de los socios. Cuando Mximo llega
2
a las oficinas de T ya hay dos propuestas ms de trabajo conjunto: a los contadores y los fabricantes de software
para farmacias se agregaron un llamado de la asociacin de servicios de salud, que est interesada en desarrollar
2
un sistema nuevo, en la nube, por lo que la experiencia de T les es sumamente apetecible, y un proveedor de
servicios a agentes de seguros que tambin quiere mudarse a la nube para integrar ms fcilmente nuevas
tecnologas (laptops, tabletas, netbooks, y tambin telfonos inteligentes) a la oferta. Las cuatro propuestas estn
siendo evaluadas como proveedores usando la matriz de Pugh que dejara como tarea Mximo.
-
63
Un momento, pide Mximo. No se trata de proveedores alternativos del mismo producto. No compiten
por un nico espacio Porqu no es posible pensar en dos o tres proyectos paralelos?.
Ver Captulo 2.
Captulo 6
67
El silencio es casi audible. La seleccin de proyectos que una organizacin encara debe resultar de un
profundo conocimiento del mercado y la visin del rumbo que llevar el crecimiento de la organizacin. La
gobernanza de los recursos a nivel de organizacin, por encima del nivel de los proyectos, es esencial para el
mximo aprovechamiento de los patrimonios colectivos. Cualquier otra forma de definir la asignacin de recursos
a los proyectos puede dar lugar a adjudicaciones inadecuadas. La falta de visin es un primer obstculo. Mximo se
2
dirige a la pizarra y escribe: Visin para T : En los prximos dos aos nos comprometemos a y deja el escenario.
Claudio habla el primero:
-
Me gustara que furamos una fuerza decisiva en el mercado de SaaS.
Mximo le pasa el marcador y Claudio pasa a la pizarra y escribe su oracin textualmente. Mximo se levanta,
toma el marcador y corrige la oracin. Ahora se lee En los prximos dos aos nos comprometemos a ser una
fuerza decisiva en el mercado de SaaS para Latinoamrica. Ahora se levanta Marcela, toma el marcador de manos
de Mximo y tacha fuerza decisiva y arriba de ello escribe referente entre las cinco mejores empresas. Un
gemelo se levanta a su vez y con el dedo borra la palabra una y escribe el en su lugar. La visin dice entonces En
los prximos dos aos nos comprometemos a ser el referente entre las cinco mejores empresas en el mercado de
SaaS para Latinoamrica. El silencio ahora es solemne.
-
Si ese es el caso, interrumpe Mximo, vender sistemas contables con liquidacin de salarios no
alcanza. Tenemos que tener una cartera de productos y manejar los proyectos como un portafolios de
inversiones.
Se puede entender a un portafolios, o cartera, segn el [PMI, 2008], como (...) un conjunto de proyectos,
programas y otros trabajos que se agrupan para facilitar la gestin efectiva del conjunto del trabajo para cumplir
con los objetivos estratgicos especficos. Los componentes de la cartera no necesariamente tienen que tener
alguna relacin de dependencia o estar directamente relacionados. Adems, se puede entender que gestin de la
cartera se refiere a la gestin centralizada de una o ms carteras, lo que incluye la identificacin, priorizacin,
autorizacin, administracin y control de proyectos, programas y otros trabajos relacionados, para alcanzar los
objetivos estratgicos especficos" [PMI, 2008].
-
Entonces, pregunta Mximo, Cules de las propuestas estn alineadas con la visin?.
Todas, menos la de los agentes de seguros, responde con seguridad Marcela.
Mximo tacha de la matriz de Pugh a esa oferta y borra todos los atributos deseables de la solucin de la
matriz, dejando en blanco la columna de la izquierda.
-
NOOOO!, gritan todos.
El trabajo no haba sido copiado a ningn lado todava. Por suerte Mariano tiene la costumbre de sacar
fotografas de lo escrito en las pizarras cada tanto, y se puede recrear la informacin borrada sin demasiado
esfuerzo. Mximo entonces escribe los atributos de la nueva matriz, la de seleccin de aliados. Los atributos que
pone son: esfuerzo (demandado por el proyecto), dominio (de aplicacin), sinergia (con los otros proyectos),
inversin (monto de la misma), alineamiento (con la visin estratgica) y mercado pot. (mercados de potencial
venta del producto resultante). Llenan la matriz y el resultado parcial es el siguiente:
1 sistema
completo
software para
farmacias
1 sistema migracin a
SaaS
Asociacin servicios de
salud
1 sistema integrado para
hospitales
domnio
contabilidad
manejo de stocks
ERP completo
sinerga
buena
mediana
Total
Inversin
media
media
Enorme
alineamiento
Bueno
mediano
atributo
contadores
Esfuerzo
mercado pot.
Enorme
hospitales, farmacias,
muy ampilo
Farmacias
mdicos
Tabla 6.4: Matriz de Pugh sobre Propuestas
servicios a
agentes de seguros
????????
Los signos de pregunta los escribieron los mellizos Galarraga, que de repente se levantaron al unsono y se
disputaron el marcador.
-
68
Qu pasa si, dijo Alberto,
Captulo 6
Boria et al.
La tecnologa que quieren usar los de los agentes de seguros la empleamos, sigui Armando,
la usamos para conectar a los mdicos, enfermeros y administrativos del hospital?, continu Alberto,
y a los pacientes, las salas de primeros auxilios, las historias clnicas, termin Armando.
Los ojos de todos brillaban de excitacin. Mximo fue el encargado de echar un baldazo de agua fra al
conjunto:
-
Esperen, esperen. Nada de soluciones todava. Tomemos un caf y pensemos la estrategia entre todos.
Mximo ha utilizado ac una tctica de facilitacin que consiste en romper la reunin en pequeos grupos
para que las ideas se crucen. Esta tctica es una de las variantes de lo que se llama polinizacin cruzada que
adopta varias formas pero que en su centro consiste en activar la participacin de todos para cruzar ideas. Algunas
otras formas son ms divertidas, como El Cctel, donde se entregan consignas y los asistentes circulan
cambiando ideas entre ellos de a pares como en un evento social. Los resultados alcanzados se ponen en comn.
Mximo ha quitado todo formalismo a la situacin para permitir un intercambio menos rgido, pero espera que la
falta de consignas no derive en otros temas dado el inters manifiesto de todos los presentes.
De vuelta alrededor de la mesa de diseo, cada uno con su cafecito, Mximo pregunta:
-
Qu vamos a hacer?.
Marcela y Claudio se miran. Ambos han estado charlando en los cinco minutos del intervalo. Claudio es el
mayor de todos en el grupo y pide la palabra gravemente:
-
Marcela y yo pensamos que hay que crecer, y hay que crecer rpido. El dolor del crecimiento se va a
compensar con la magnitud de la recompensa, y si perdemos ahora no perdemos mucho, podemos volver
a empezar con lo que hayamos aprendidos en esta aventura. Para crecer as de rpido hay que tomar
riesgos. En particular, hay que conseguir capital.
Otra vez el silencio es incmodo. Claudio mira uno por uno a todos para enfatizar las ideas y contina:
-
Para conseguir capital hay que tener un plan de negocios. Tenemos que considerar expandir nuestro
propio capital humano, por ejemplo contratando ms profesionales que trabajen a nuestras rdenes. Esto
nos va a llevar a una divisin tcnica del trabajo y a la especializacin. Podemos rotar posiciones si
alguien est incmodo con la que le puede llegar a tocar, pero no vemos otra solucin. Si nos detenemos,
desapareceremos.
Alfredo y Ana se miran.

-
Estamos de acuerdo, dice Alfredo. Levante la mano el que est de acuerdo.
Todas las manos se levantan. Mximo vuelve a intervenir:

-
Hagamos el plan.
Y acto seguido arma una nueva planilla, que al cabo de unos minutos queda as completada (Tabla 6.5)
riesgo:
mitigacin:
elegimos las lneas de producto sin base en una visin

estratgica
seguimos un proceso ordenado para fijar la visin, la

estrategia y las lneas de negocio
no hay suficiente presupuesto para todas las lneas de

producto
las lneas de producto elegidas son financiadas

proporcionalmente a su importancia estratgica
nadie queda a cargo de cumplir la visin estratgica
adjudicamos claramente la responsabilidad por cada

lnea de produto con nfasis en los resultados de
negocio
con el tiempo se pierde la visin estratgica
controlamos que la lnea elegida es la lnea seguida
la escasez de recursos implica desbalances entre lneas
Captulo 6
cuando hay desvos de la estrategia implementamos

acciones correctivas
utilizamos la visin estratgica para resolver conflictos
de recursos y dependencias crticas
69
riesgo:
mitigacin:
ciertos proyectos pierden valor para la estrategia
revisar la visin estratgica peridicamente y redefinir

las lneas de producto, cancelando o continuando
proyectos
la organizacin en su conjunto no visualiza las decisiones

comunicar la visin y el estado de los proyectos
estratgicas
Tabla 6.5: Riesgos del Crecimiento
Bueno, dice Mximo, ya estamos preparados para implementar el proceso de gerencia de cartera.
Proyecta entonces la siguiente tabla (Tabla 6.6)
Gestin de Portfolio de Proyectos (GPP)
GPP 1
Las oportunidades de negocio, las necesidades y las inversiones son identificadas, calificadas,
priorizadas y seleccionadas con relacin a los objetivos estratgicos de la organizacin por medio
de criterios objetivos;
GPP 2
Los recursos y presupuestos para cada proyecto son identificados y atribuidos;
GPP 3
La responsabilidad y la autoridad por la gestin de los proyectos son establecidas;
GPP 4
El portafolio es supervisado con relacin a los criterios que fueron utilizados para la priorizacin;
GPP 5
Acciones para corregir desvos en el portafolio y para prevenir la repeticin de los problemas
identificados son establecidas, implementadas y acompaadas hasta su conclusin;
GPP 6
Los conflictos sobre recursos entre proyectos son tratados y resueltos, de acuerdo con los criterios
utilizados para la priorizacin;
GPP 7
Proyectos que cumplen con los acuerdos y requisitos que llevaron a su aprobacin son mantenidos,
y los que no cumplen son re -direccionados o cancelados;
GPP 8
La situacin del portafolio de proyectos es comunicada a las partes interesadas, con periodicidad
definida o cuando el portafolio es alterado.
Tabla 6.6: Proceso GESTIN DE PORTFOLIO DE PROYETOS [SOFTEX, 2012a]

29. Para poder desarrollar ms opiniones en paralelo Mximo ha inducido la tcnica de
polinizacin cruzada mediante un oportuno corte en la actividad.
30. Utilizando el anlisis de riesgo como herramienta de exploracin, Mximo induce las prcticas
que implementan los resultados esperados del MPS correspondientes a la gestin de portafolio
(o cartera) de proyectos.
6.4 Midiendo resultados
La primera consecuencia de la decisin de crecer es un nuevo organigrama (Figura 6.3). Alfredo y Ana
compartirn la conduccin de la empresa hacia afuera y coordinarn las actividades de los dems hacia adentro.
Ana ser la Arquitecta en Jefe, dada su posicin como docente de la ctedra de Arquitectura de Software,
mientras que Marcela ser el soporte de ellos en lo administrativo y contable, con inclusin de la gestin de
personal, y adems la gerente de calidad. Claudio har las veces de Gerente de Finanzas, los gemelos manejarn
los equipos de desarrollo (uno de ellos) y soporte y mantenimiento (el otro gemelo). Los socios renunciaron a
nombrar quin ocupar cada cargo porque de todos modos no pueden distinguir entre ellos. Mariano, finalmente,
se ocupar de atencin al cliente. Esta funcin se encarga de marketing, ventas, desarrollo de nuevos productos y
la verificacin y validacin de las versiones antes de su lanzamiento al pblico. Toda una reorganizacin. Para
facilitar la definicin, Mximo comparte con el grupo su planilla de Misin y Funciones (Tabla 6.7).
70
Captulo 6
Boria et al.
Figura 6.3: Organigrama Tahini-Tahini
Establecidas las funciones y los canales de comunicacin orgnicos, es necesario contar con un sistema de
decisin. Las decisiones deben ser lo ms objetivas posible. La objetividad surge de la existencia de datos que
soporten la decisin. Sin el soporte de datos, la informacin no existe, es simplemente una opinin y no es
realmente informacin. Un sistema de decisin debe basarse en un sistema de informacin, y un sistema de
informacin debe de estar sustentado por datos colectados de la ejecucin de los procesos. Hay dos lugares donde
ya vimos la necesidad de recolectar datos: en la plantilla de procesos, para poder medir como se estn
comportando los procesos cuando son ejecutados, y otro en los indicadores de gestin que ocupan una columna
en la planilla de la Tabla 6.7.
Nombre del
cargo
Nombre del cargo

al cual reporta
Experiencia
Funciones del
cargo
Que hace
Como lo hace
Formacion
Contactos dentro
profesional
de la organizacion
deseable o requerida
Contactos fuera
de la organizacion
Mision del cargo

Con quien lo hace
Indicadores de
gestion
Habilidades
requeridas
Tabla 6.7: Misin y Funciones
Hemos hablado de datos, de informacin y de decisin. Aclaremos ahora lo que queremos decir. Un dato es
simplemente una secuencia de smbolos, gramaticalmente bien formada, pero cuya interpretacin es poco clara. El
ejemplo ms extremo de esto es una cadena de unos (1) y ceros (0) que codificados en la memoria de una
computadora puede ser una instruccin, un dato numrico o un carcter que se puede imprimir. Menos extremo
que eso es, por ejemplo, una celda de una planilla de clculo que nos indica $118. Si en el contexto de la planilla el
smbolo $ indica dlares de los Estados Unidos de Norteamrica, se puede entender el contenido de la celda: Es un
dato que significa ciento dieciocho dlares de EEUU. Pero ese es un nivel sintctico, muy poco til, no nos sirve
para entender mucho. Necesitamos ms contexto para subir de ese nivel sintctico a un nivel semntico. En un
contexto, ese dato se convierte en un mensaje. Digamos que ese dato est en una celda que est en una columna
bajo el ttulo Precio a Futuro del Barril de Crudo en Tirkit. Ahora la combinacin del valor de la celda con el valor
del ttulo nos dan una interpretacin vlida y posiblemente nica del mensaje. De todos modos, sin un propsito
para la decisin nos quedamos en el mensaje. Para que el mensaje tenga informacin es necesario que nos sirva
para la decisin. As, si la decisin es vender o no vender mis valores a futuro en petrleo, este mensaje contiene
informacin.
Captulo 6
71
Figura 6.4: Datos vs. Informacin
Un buen sistema de informacin se apoya tanto en datos fidedignos como en la construccin de indicadores
que permitan visualizar fcilmente la decisin. Por ejemplo, para la decisin que hemos usado como ejemplo en
esta seccin, una lnea paralela al eje X del tiempo por el punto 105 del eje de los Precios Futuros constituye un
indicador del punto de venta segn un criterio fijado de antemano. Cuando el grfico de los precios pasa la recta la
decisin es automtica, o por lo menos, se puede automatizar.
Figura 6.5: Grfico sobre Precios Futuros del Petrleo
Partiendo de las decisiones que se deben tomar se define qu indicadores permiten tomar la decisin con
confianza. Por ejemplo, una decisin tpica de un lder de proyecto es si debe redefinir el alcance en trminos de
los requerimientos que ha comprometido. Para poder decidir eso necesita un indicador que le seale si a la fecha
de entrega el producto estar completado con la calidad prevista. Un posible indicador surge de un mtodo
conocido como valor ganado, EVM. Lo interesante de EVM es que es ms sencillo de lo que se lo presenta en la
literatura. Imaginemos que (a) son las seis de la tarde y Usted est solo en su oficina, listo para volver a su casa, (b)
recibe un llamado de su primo y mejor amigo: Ha tenido un accidente con su automvil y est detenido en una
poblacin distante 375 Kilmetros de donde Usted se encuentra al recibir el llamado. Si Usted no llega a la
comisara en menos de cuatro horas, su primo pasar la noche en la crcel. Si llega antes y paga la fianza, su primo
dormir en su casa.
Su propio automvil tiene el tanque parcialmente lleno y Usted cree que la autonoma y velocidad necesaria
para que pueda llegar a tiempo. Baja a su banco para retirar el dinero de un cajero automtico y en minutos est
en camino. Qu puede pasar? En realidad, puede que el trnsito de hora pico haga que llegue despus de cerrada
la comisara y su primo pasar una noche entre cucarachas y otras sabandijas. Puesto que no quiere perder
tiempo, puede que en el camino se le acabe el combustible lejos de una bomba de combustible, y tenga que
caminar perdiendo valioso tiempo y posiblemente adems le roben su automvil a la vera del camino. Cmo
saber si esto puede pasar?
Los indicadores son dos: Cuntos kilmetros recorre por hora su automvil, y cunto combustible consume,
ya sea por kilmetro o por hora. Por supuesto, el primer indicador se conoce como la velocidad y lo volveremos
a encontrar en este Captulo cuando hablemos en ms detalle de la estimacin. El segundo es el consumo, pero es
diferente considerarlo por kilmetro que por hora. Por ejemplo es posible bajar el consumo a cero si uno detiene
el automvil, pero entonces se pierde el objetivo de rescatar al primo de la crcel. Con EVM se calculan estos dos
indicadores. El primero es el desempeo calendario y es el equivalente de la velocidad. El segundo es el
desempeo de costos y es el equivalente del consumo.
72
Captulo 6
Boria et al.
En un automvil medimos los kilmetros recorridos, mientras que en un proyecto de software hemos de
medir el avance mediante el tamao del producto o el nmero de tareas que se completan. Como las tareas no
son todas idnticas y a veces cuesta compararlas, es mejor tomar una medida del tamao (veremos una ms
adelante). Un buen indicador nos dira a golpe de vista si estamos llegando a tiempo o no. En EVM se calculan
ndices, entre lo avanzado y lo planificado, un valor exactamente igual a 1 se interpreta como estar justo sobre el
plan, mientras que un valor mayor que 1 significa que estamos adelantados al plan y uno menor que 1 que
estamos atrasados.
Idealmente para cada tarea existe un producto que resulta de la ejecucin de la misma. Definimos aqu cinco
medidas bsicas [PUTNAM & MYERS, 2003] que deben estar presentes desde el primer momento, en la definicin
inicial de los procesos. Lo que vamos a medir, y para qu, tiene que ser parte integral de la definicin de las tareas.
De ese modo se establecen de inmediato las condiciones para controlar los procesos (una tarea no es ms que la
encarnacin, instanciacin, o ejecucin de un paso de un proceso). Esas mediciones son: tamao y nmero de
2
defectos relacionados con el producto, y duracin, esfuerzo y costo de la tarea. Con esto en mente, T ha
comenzado la revisin de sus procesos y completado la definicin de mediciones que dejara pendiente en ese
nivel.
El siguiente nivel es el de los indicadores de gestin que requieren los nuevos roles. Otra vez la sala de diseo
ve a nuestros viejos conocidos reunidos. Mximo facilita la creacin de una tabla de riesgos asociados (Tabla 6.8) a
64
una posible mala definicin del sistema de decisin que los lleva a establecer medidas para evitarlos o
minimizarlos.
riesgo:
mitigacin:
el sistema de decisin se define arbitrariamente sin

considerar la visin estratgica
establecer objetivos de medicin que correspondan a

la visin estratgica, considerando las decisiones
derivadas
las mediciones que se usan en los proyectos son
decididas en conjunto por la gerencia del proyecto y la
PMO
se especifica claramente el procedimiento de
medicin con responsabilidades y controles
las mediciones e indicadores que se utilizan en los

proyectos son decididos sin consideracin a las
necesidades organizacionales
cada proyecto tiene una versin distinta del sistem de
decisin
se tiene un sistema de decisin pero no se tienen datos
se controla que los datos requeridos son colectados y

analizados
no se puede reproducir una decisin basada en datos

porque los datos no se guardan
no todos los interesados entienden el porqu de las
decisiones
se guardan los datos y los resultados de los anlisis de

manera de que puedan ser recuperados
se difunden a los interesados los resultados y el
anlisis de las mediciones obtenidas
Tabla 6.8: Riesgos Asociados
Como siempre que Mximo facilita la reunin, los resultados coinciden con los esperados por el MPS-SW:
Medicin (MED)
64
MED 1
Objetivos de medicin son establecidos y mantenidos a partir de los objetivos de negocio de la

organizacin y de las necesidades de informacin de procesos tcnicos y gerenciales;
MED 2
Un conjunto adecuado de medidas, orientado por los objetivos de medicin, es identificado y

definido, priorizado, documentado, revisado y, cuando pertinente, actualizado;
MED 3
Los procedimientos para la recoleccin y el almacenamiento de medidas son especificados;
MED 4
Los procedimientos para el anlisis de las medidas son especificados;
MED 5
Los datos requeridos son recolectados y analizados;
T ha decidido que su sistema de apoyo a la decisin basado en datos, que otras empresas llaman su sistema de medicin, se
denomine en cambio sistema de decisin. Es en parte un nombre que no representa completamente la realidad, pero por
ahora veamos a donde los lleva.
Captulo 6
73
Medicin (MED)
MED 6
Los datos y los resultados de los anlisis son almacenados;
MED 7
Los datos y los resultados de los anlisis son comunicados a los interesados y son utilizados para
apoyar decisiones.
Tabla 6.9: Proceso MEDICIN [SOFTEX, 2012a]
Mximo comparte con el grupo dos activos ms, la plantilla de definicin de mediciones (Tabla 6.10) y la
plantilla de definicin de indicadores (Tabla 6.11).
La situacin respecto de las expansiones queda entonces as: Se trabajar con los contadores internamente.
Los gemelos conducirn sendos equipos para desarrollar el nuevo sistema e integrarlo al existente, al que a su vez
darn mantenimiento. No buscarn nuevos clientes para el sistema actual, la financiacin deber proveer la
2
liquidez para mantener a T funcionando. Se buscar una alianza con la empresa de SaaS para servicios de salud. A
cambio de poner el know-how de SaaS y la arquitectura se espera participacin en el negocio y las patentes que
2
puedan surgir. Con la empresa que quiere fundir su software para farmacias con el existente de T se llevar
adelante un convenio por el cul ambas partes contribuirn para la generacin del cdigo requerido.
Nombre de la Medicin
Estado de la Codificacin
Cuenta el nmero de programas que han completado la codificacin y el test unitario. Se la utiliza
durante la etapa final para entender el trabajo que resta por hacer, comparndolo al estimado
inicialmente. Permite planificar nuevas fechas de entrega con cierta anticipacin
Mediciones Bsicas
Fuente de Datos
Criterio de Validez
Fecha Planificada de finalizacin del
Planilla de construccin de
El plan est aprobado y
Programa
programas del lder tcnico de
bajo control de
proyecto
configuracin
Fecha Real de finalizacin del
Subversion
La fecha de ingreso es
programa
generada
automticamente por la
herramienta
Atributos
Identificador nico de Programa (UPI)
Nombre del programador responsable
Fecha estimada de comienzo de la programacin
Fecha real de comienzo de la programacin
Fecha estimada de finalizacin de la programacin
Fecha real de finalizacin de la programacin
Mediciones Derivadas
Programas Acumulados Planificados
para la Semana
Programas Acumulados Realizados en
la Semana
Clculos utilizados
Cuenta; el nmero de programas cuya fecha de finalizacin
segn el plan cae dentro de la semana en cuestin.
Cuenta; el nmero de programas cuya fecha de finalizacin
segn Subversin ocurri dentro de la semana en cuestin.
Tabla 6.10: Definicin de Mediciones

31. Mximo ha contribuido a la definicin de roles aportando la plantilla con la misin y funcin y la
comunicacin entre ellos.
32. Mximo ha hecho nfasis en la definicin de los indicadores de gestin que requieren los
nuevos roles basndose en los riesgos.
33. Mximo ha compartido con el grupo dos activos: la plantilla de definicin de mediciones y la
plantilla de definicin de indicadores.
74
Captulo 6
Boria et al.
El trabajo es intenso pero prolfico. La nueva estructura comienza a dar frutos en forma de acciones paralelas.
2
El ambiente se electrifica y T comienza a preparar su despegue. Claudio inicia acciones que incorporarn apoyo
financiero a la empresa. Marcela prepara los procesos con ayuda de una pasante de la Politcnica. Los gemelos
cursan un taller de Scrum Master en California. Alfredo firma acuerdos y estrecha lazos. Mariano mantiene la
2
continuidad con los clientes. Prcticamente, l solo sintetiza lo que T era hasta una semana antes. Ana ocupa sus
ltimas semanas antes de ser madre en dejar todas las decisiones arquitectnicas bien documentadas.
Fecha de creacin
Especificacin del Indicador
Para
<fecha>
<nombre del indicador, explica su uso>
Muestra del Indicador
Modelo de Anlisis
Describe las acciones necesarias a seguir cuando el indicador muestra ciertos

patrones de comportamiento. Por ejemplo, "si dos valores sucesivos del indicador
son menores que el valor anterior en la serie, es necesario realizar una actividad de
anlisis de causa profunda y notificar de la situacin a la Alta Gerencia, el Comit
de Control del Producto y el rea de Gestin de la Calidad".
xxx
Criterio de Decisin
Identifica los umbrales que disparan nuevas acciones o sirven para determinar
futuras investigaciones
xxx
Mediciones Utilizadas
Identifica las mediciones bsicas o derivadas que se usan en la construccin del

indicador
Medicin Derivada: xxx
Medicin Derivada: yyy
Medicin Bsica: zzz
Medicin Bsica:aaa
Construccin del Indicador
Describe los pasos a seguir en la construccin del indicador, por ejemplo: "Calcule
cada mes el ndice xxx a partir de los valores promedio de zzz y aaa. Haga lo mismo
para la medicin derivada yyy, que es la media ponderada del valor hora del
personal de proyectos. Grafique en diagrama de barras como se ejemplifica ms
arriba. Puede utilizar la planilla 'muestra' para generar el grfico".
Medicin Derivada: xxx

Medicin Derivada: yyy
Medicin Bsica: zzz
Medicin Bsica:aaa
Tabla 6.11: Definicin de Indicadores
6.5 Protegiendo los Activos

Si se van a mezclar los productos que se tienen con componentes o sistemas ajenos se los debe proteger. Aun
si no fuera un programa tan extenso, las ramas de un solo producto se van expandiendo a medida que surgen
variantes en el cdigo y hay diferentes versiones instaladas. Los riesgos de no controlar los activos de la empresa
son varios:
Captulo 6
75
riesgo:
mitigacin:
si no sabemos donde se almacenan los productos y los

resultados, perdemos tiempo y posiblemente trabajo
si "no se puede encontrar una hoja en particular en el
bosque" se pierde mucho tiempo identificando cada
parte
si los documentos se actualizan sin que los interesados
se enteren pueden haber choques entre cambios
se adopta un sistema de gestin de documentacin

se adopta un sistema de clasificacin de los tems
almacenados
se adopta un criterio de lnea base donde solo se
puede modificar un documento de la lnea base bajo
estrictas reglas de control
se lleva la historia de los cambios de lnea base
se sigue un proceso estricto para cambiar un producto
si no sabemos quin cambi qu ni cuando puede ser

difcil reproducir los motivos y decisiones alrededor de
un cambio
si las personas no respetan las reglas y los activos se
se controla que los productos de trabajo sean
almacenan en cualquier parte y cualquiera los accede y
almacenados, ledos y liberados al uso siguiendo las
modifica se puede introducir mucho retrabajo
formas del proceso
Tabla 6.12: Riesgos Derivados de la Falta de Control de Activos
65
Mximo introduce al grupo la nocin de lnea base de productos . Una lnea base es un conjunto de
especificaciones o productos de trabajo que han sido formalmente revisados y acordados, que sirven como base
para un desarrollo posterior y que slo pueden ser modificadas por medio del procedimiento establecido de
control de cambios. El propsito de definir una lnea base es el acuerdo que la produce, no el fijar un cepo
alrededor de los productos para que nunca cambien, sino el de protegerlos de cambios no comunicados. Para que
se pueda generar la lnea base es necesario definir claramente las responsabilidades respecto del producto en
2
cuestin. Para T hay tres tipos de archivos, segn su contenido. Los hay de cdigo, de documentacin de lnea
base y de comunicacin. Cada uno tiene su tipo y sus propiedades, que hacen que se les proteja de diferente
manera. Ciertos documentos, como los casos de prueba, el documento de arquitectura, la especificacin funcional,
tienen una versin nica que se mantiene simplemente con restricciones de acceso: Un dueo nico, o al menos
un rol nico que puede modificarlo. En otros el dueo nico es indeseable, en particular cuando se trata de cdigo,
donde es deseable que coexistan varias versiones. En definitiva la Tabla 6.13 muestra las propiedades de cada tipo.
TIPO
Dueo
acceso
actualizacin
versiones
cdigo
Mltiples
check out
check in y merge
mltiples
lnea base
nico (por rol)
read only
write del dueo
nica en vigencia
comunicacin
Nadie
read only
no aplica
no se versionan
Tabla 6.13: Propiedades de Cada Tipo de tem de Configuracin
Para almacenar cada uno de los diferentes tipos, el grupo tiene que tomar decisiones sobre el sistema que
utilizarn. En principio adoptan para el cdigo el modelo de [MOREIRA, 2010] de integracin continua. El mismo
producto freeware que estaban utilizando les sirve para almacenar el cdigo con las caractersticas definidas en la
Tabla 6.13. Hay varias posibilidades para los otros dos tipos: lnea base y comunicaciones. Pueden usarse
productos denominados DMS (Document Management Systems) o soluciones ms simples como un disco virtual
con una estructura de carpetas que se defina a partir de la estructura y tipo del proyecto. Por ejemplo, un proyecto
que adopte la estructura de Scrum es posible que haya carpetas para el Backlog del Producto, el Backlog del Sprint,
las comunicaciones del Dueo del Producto, las mediciones, el cdigo y los casos de prueba. Puede que las
carpetas a su vez estn subdivididas. Cada carpeta tendr su control de lectura y escritura de acuerdo a los roles y
las necesidades detectadas. Por ejemplo, el ingeniero de pruebas puede escribir y borrar en la carpeta de casos de
prueba, pero el Scrum Master no. Sin embargo, el Scrum Master podr acceder a los casos de prueba para leerlos,
y en cambio personal ajeno al equipo no podr hacerlo.
Otro tema a decidir son las auditoras. Hay auditoras fsicas que controlan que en un repositorio no hay
menos de lo que tiene que haber ni ms de lo que tiene que haber. De este modo se protege la integridad de la
organizacin: No queremos distribuir caballos de Troya con nuestro software. Tambin hay auditoras lgicas. En
este caso lo que se pone en juego es la secuencia con que se lleg al producto. Por ejemplo, si para subir el cdigo
fuente al rea de pruebas antes debe de haber pasado por tres etapas (digamos que primero se dise el caso de
prueba que tena que sealar un defecto, por falta del cdigo a agregar; luego se codific este cdigo y se confirma
65
Hay otras lneas base: las de un cronograma y las de comportamiento de un proceso que veremos ms adelante.
76
Captulo 6
Boria et al.
que ya no lo rompa y en un tercer paso se lo integr corrindolo contra el conjunto de casos de regresin), la
auditora lgica buscara evidencia de que todos los pasos se han cumplido antes de aceptar que se suba el cdigo
en cuestin.
Otra vez la responsabilidad de escribir los procesos y catalogarlos cae en manos de Marcela, pero ya su
experiencia le hace fcil lo que al principio le costaba esfuerzo. Marcela sigue utilizando los materiales que
introdujera Mximo, definiendo los productos de cada procedimiento y las mediciones e indicadores pertinentes.
La nomenclatura de los productos surge de las prcticas habituales, lo dems se ha decidido entre todos. La
pasante ayuda a escribir y corregir los procesos.
El conjunto de prcticas as definidas cuando sea implementado cubre los resultados esperados de Gerencia
de Configuracin:
Gestin de Configuracin (GCO)
GCO 1
Un Sistema de Gestin de Configuracin es establecido y mantenido;
GCO 2
Los elementos de configuracin son identificados con base en criterios establecidos;
GCO 3
Los elementos de configuracin sujetos a un control formal son colocados bajo una lnea base;
GCO 4
La situacin de los elementos de configuracin y de las lneas base es registrada a lo largo del
tiempo y colocada a disponibilidad;
GCO 5
Cambios en elementos de configuracin son controlados;
GCO 6
El almacenamiento, la manipulacin y la entrega de elementos de configuracin y lneas base son

controlados;
GCO 7
Auditorias de configuracin son realizadas objetivamente para asegurar que las lneas base y los
elementos de configuracin estn ntegros, completos y consistentes.
Tabla 6.14: Proceso GESTIN DE CONFIGURACIN [SOFTEX, 2012a]

34. Como van a crear productos con sistemas externos y usar otros en varios subsistemas Mximo
ha inducido el uso de prcticas de gestin de configuracin como medida para proteger los
distintos activos.
6.6 Garantizando la Calidad de los Procesos y Productos
Han pasado tres meses y los nuevos procesos estn en su fase de implementacin. Hay doce personas nuevas
2
trabajando en T y la sala de diseo ha pasado a ser la sala de uno de los dos equipos de Scrum. Media calle ms
2
hacia el rio se abri la sucursal de T , con la direccin general y financiera, y el lugar que antes ocupaban los
escritorios de Alfredo, Ana y Claudio ahora es un pequeo laberinto de puestos de trabajo. Las ruedas de la
produccin giran aceleradas. Marcela tiene una preocupacin: Poder juzgar si el crecimiento altera la calidad de los
productos, para lo cul necesita revisar lo que se produce y como se lo produjo.
Pudiramos pensar que en una cultura que respeta la decisin de elegir los propios procesos no es necesario
que alguien verifique que se los sigue, pero es el conjunto de la organizacin quin as lo requiere. Marcela conoce
la tcnica de las auditoras pero lucha contra el problema de su carencia de valor agregado. Para qu, se
pregunta, le sirve el resultado de auditora a la organizacin? Y al proyecto auditado? Marcela ve que recolectar
datos sobre las disconformidades con las normas y procesos es un buen modo de empezar a entender cmo se
usan los procesos y qu normas se aplican, pero vacila ante el retorno que pueda tener para el proyecto individual.
2
Cuando Mximo explic la escritura de procesos a T parti de la plantilla de la Figura 5.12, pero luego utiliz
una planilla de hoja de clculo, una lnea para cada paso de proceso. Las columnas ahora representan los tems de
la plantilla: Propsito, Involucrados, Entradas Requeridas y as sucesivamente, incluso con la secuencia en previsin
de que algunos pasos sean condicionales o se puedan ejecutar en paralelo con otros y no sean todos simplemente
secuenciales. Con esa hoja de clculo en la mano, Marcela tuvo una inspiracin. Buscando entre sus carpetas en la
66
computadora, encontr un webinar que baj de SlideShare . Volvi a leerlo y decidi montar auditoras
proactivas, una contradiccin en trminos, pero que parece sugerido por el webinar. En vez de establecer un
programa de auditoras frecuentes, Marcela se propone participar en eventos de lanzamiento de etapas, como el
comienzo de cada sprint y las presentaciones al dueo del producto, y hacer la apertura recordndoles a todos los
66
http://www.slideshare.net/jorgeboria/qa-3-best-practices
Captulo 6
77
pasos que han elegido para el proceso. En ese momento se pueden modificar decisiones, otorgar dispensas y
revisar lo actuado. Por supuesto, Marcela participar en todas las retrospectivas.
2
Puesto que el Dueo del Producto es interno a T , Marcela decide utilizarlo en funcin de auditor de cierre.
Adems, los miembros del equipo recibirn aleatoriamente mensajes de correo electrnico pidindoles que
confirmen la ejecucin del proceso en todos sus pasos. De ese modo las auditoras tendran lugar sin entorpecer el
desarrollo y slo sobre aquellos puntos donde Marcela, como gerente de calidad, sienta necesidad de enfatizar.
Para introducir sus procesos de afirmacin de calidad, Marcela le roba una tcnica a Mximo y presenta los
riesgos de no seguir sus procesos:
riesgo:
mitigacin:
si no se puede compartir los productos porque tienen

verificar que los productos se adhieren a las reglas
diferentes formatos es posible que cometamos muchos
que son polticas de la organizacin
errores involuntarios
si las personas no siguen los procesos que hemos
verificar que las personas siguen las reglas y los
establecido no es posible asegurar que lo que sucede es
procesos que son poltica de la organizacin
lo que se espera y adems de no aprender de los errores
es probable que cometamos muchos
si detectamos problemas pero no los comunicamos no
comunicar los problemas y las disconformidades para
van a resolverse solos y es posible que todos les pierdan
que se puedan resolver
el respeto a los procesos
si no nos ponemos de acuerdo con las acciones a seguir
cuando haya disconformidades o problemas hay que
para arreglar disconformidades o las que se acuerdan no
acordar un plan de accin para que se mantengan las
se controlan es posible que se abandonen las buenas
buenas prcticas o se corrija el proceso
prcticas
Tabla 6.15: Riesgos de no Auditar
Con esos riesgos presentes, los asistentes a la reunin aprueban el proceso de auditora que presenta
Marcela: Para cada proyecto,
1.
2.
3.
4.
5.
6.
7.
revisar los riesgos

revisar el plan
seleccionar procesos crticos
seleccionar productos crticos
planificar auditoras
realizar auditoras
analizar resultados
Marcela tambin ha definido una escala de severidad de las inconsistencias entre lo actuado y las normas y
patrones (Tabla 6.16).
SEVERIDAD
SEV 1
INSALVABLE: Arreglar de inmediato, escalar de inmediato;
SEV 2
GRAVE: Arreglar antes del prximo hito, escalar si no se arregl;
SEV 3
NEGOCIABLE: (a) Arreglar antes del prximo hito o (b) auditar en la prxima
oportunidad, escalar si (a) y no se arregl;
SEV 4
SALVABLE: Otorgar dispensa, registrar inconsistencia, cerrar;
SEV 5
RECONVENIBLE: Advertir, cerrar.

Tabla 6.16: Severidad de Inconsistencias en Auditoras
El procedimiento realizar auditoras contiene un mtodo de escalamiento que tambin es sometido al juicio
de los socios. Dependiendo de la severidad, el procedimiento permite alcanzar niveles de direccin ms y ms
altos cuando una inconsistencia no se cierra. El procedimiento de escalamiento se completa cuando la
inconsistencia se resuelve o la persona a la que se escala decide cerrarlo sin que haya necesidad de que se arregle
la inconsistencia. La Figura 6.6 muestra el proceso que dise Marcela.
78
Captulo 6
Boria et al.
Figura 6.6: Proceso de Auditora de Calidad
Para completar la reunin, el equipo de conduccin revisa los resultados esperados correspondientes al
proceso de Garanta de la Calidad.
Aseguramiento de la Calidad (GQA)
GQA 1
La adherencia de los productos a los estndares, procedimientos y requisitos aplicables es evaluada

objetivamente, antes de que los productos sean entregados y en hitos (marcos) predefinidos a lo
largo del ciclo de vida del proyecto;
GQA 2
La adherencia de los procesos ejecutados a las descripciones de proceso, estndares y

procedimientos es evaluada objetivamente;
GQA 3
Los problemas y las no conformidades son identificados, registrados y comunicados;
GQA 4
Acciones correctivas para las no conformidades son establecidas y supervisadas hasta sus efectivas
conclusiones. Cuando necesario, el escalamiento de las acciones correctivas para niveles superiores
es realizado, de modo que se asegure su solucin.
Tabla 6.17: Proceso ASEGURAMIENT DE LA CALIDAD [SOFTEX, 2012a]

35. Marcela ha utilizado la tcnica de identificar riesgos para inducir la introduccin de prcticas de
aseguramiento de la calidad.
6.7 La pequea fbrica de software con Scrum
Los mellizos han hecho progresos enormes con el desarrollo de software utilizando las prcticas de Scrum,
2
poniendo a buen uso la inversin de T en su formacin como Scrum Master. Se han reunido con los
programadores, ingenieros de prueba y documentadores que contact Marcela y tras dos semanas de faena han
seleccionado dos equipos de trabajo. Los equipos van a utilizar las tcnicas de Scrum, pero con el aadido de un
sprint corto de anlisis que requerir la intervencin de Ana, para que la arquitectura sea bien clara para todos. El
equipo de mantenimiento se dedicar en exclusiva a arreglar defectos encontrados y proveer al otro equipo de
mejoras a la tecnologa de desarrollo, por ejemplo creando un framework para scripts de pruebas y diversas
extensiones a la herramienta de integracin continua. El equipo de desarrollo puro se encargar de introducir
mejoras sistemticas, como nuevas funcionalidades y Refactoreo del cdigo, para el contrato con los contadores.
Dada la aceptacin del tablero Kanban, los gemelos lo mantienen dentro del grupo de tcnicas que van a aplicar en
los sprints. Para aumentar la visibilidad y transparencia, los equipos utilizarn tambin un grfico de quemado
que muestre los avances y retrocesos en un sprint.
Captulo 6
79
Asimismo, los gemelos han compilado una lista de las componentes ms importantes de Scrum y las han
transformado en una lmina que cuelga en cada una de las salas. En el estilo propio de ellos, es una imagen muy
fuerte que lleva claramente el mensaje. La llaman: La Muerte del Scrum (Figura 6.7).
Figura 6.7: La Muerte del Scrum
GPR 1
GPR 2
GPR 3
GPR 4
GPR 5
GPR 6
GPR 7
GPR 8
GPR 9
GPR 10
GPR 11
GPR 12
GPR 13
GPR 14
GPR 15
GPR 16
GPR 17
GPR 18
GPR 19
El alcance del trabajo para el proyecto est definido

Las tareas y los productos de trabajo del proyecto son dimensionados, utilizando mtodos apropiados
El modelo y las fases del ciclo de vida del proyecto son definidos
El esfuerzo y el costo para la ejecucin de las tareas y de los productos de trabajo son estimados con base en
El presupuesto y el cronograma del proyecto, incluyendo la definicin de hitos (marcos) y puntos de
Los riesgos del proyecto son identificados y su impacto, probabilidad de ocurrencia y prioridad de
Los recursos humanos para el proyecto son planificados considerando el perfil y el conocimiento necesarios
Los recursos y el entorno de trabajo necesarios para llevar a cabo el proyecto son planificados
Los datos relevantes del proyecto son identificados y planificados respecto a la forma de recoleccin,
Un plan general para la ejecucin del proyecto es establecido con la integracin de planes especficos
La viabilidad de lograr las metas del proyecto es explcitamente evaluada considerando restricciones y
El Plan del Proyecto es revisado con todos los interesados y el compromiso con l es obtenido y mantenido
El alcance, las tareas, las estimativas, el presupuesto y el cronograma del proyecto son supervisados con
Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados con
Los riesgos son supervisados con relacin a lo planificado
La participacin de las partes interesadas en el proyecto es planificada, supervisada y mantenidao
Revisiones son realizadas en hitos (marcos) del proyecto y conforme lo establecido en los planes
Registros de problemas identificados y el resultado del anlisis de cuestiones pertinentes, incluyendo
Acciones para corregir desvos de lo planificado y para prevenir la repeticin de los problemas identificados
a
a
a
a
a
o
D ia ri
Demo
a
a
a
a
a
a
Scr um
da d H
istri
ca
Ta sa
de "Q
u ema
do"
Retr o
spect
iva
Juego
de Pla
nif.
Veloci
Ka nb
an
Gerencia de Proyectos en los Niveles G y F
Ba cklo
g
Tomando en cuenta las tcnicas que han incorporado, los gemelos realizan una autoevaluacin del grado de
2
cobertura que tienen los resultados esperados del MPS-SW en T . Revisan los resultados con Mximo y con
2
satisfaccin reafirman que el camino elegido es el correcto. (Figura 6.8). T comienza a preparar su evaluacin nivel
F.
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
Figura 6.8: Cobertura de los Resultados Esperados con Scrum y Kanban

37. Los gemelos han implementado Scrum en dos equipos conservando los tableros Kanban para
entender el estado del trabajo, aadiendo el grfico de quemado de tareas y el Backlog del
sprint como herramientas de control del proyecto.
38. Tahini-Tahini se prepara para la evaluacin de Nivel F.
80
Captulo 6
Boria et al.
QUE HA PASADO HASTA AHORA DESDE EL PRIMER DIA

1.
El consultor Mximo ha establecido el contacto inicial con el cliente, coincidentemente con un

problema grave y facilit su identificacin.
2.
Introdujo una primera tcnica de anlisis de causa, el diagrama de Ishikawa.
3.
Utilizando la tcnica lleg junto a los clientes a la conclusin de que sus procesos dejaban
mucho lugar a los problemas como el detectado, la falta de control de las tareas.
4.
A pesar de tener un diagnstico concreto que ya apunta a la mejora de procesos Mximo se ha

concentrado en el problema inmediato para evitar uno mayor, comenzando por definir las
caractersticas (o atributos) deseables de la solucin.
5.
Mximo ha sugerido el mtodo Kanban, sin imponerlo, y se lo ha escuchado.
6.
Mximo ha inducido el uso del tablero Kanban, sin dictarlo.
7.
Introdujo los conceptos de sub-historia y estimacin por tamao.
8.
Hay una clara definicin del alcance del trabajo a realizar, encarnado en la lista de historias, con
su correspondiente estimacin de tamao.
9.
Se ha hecho una desagregacin de las historias, donde el tamao de estas la haca til.
10. Los conceptos de historia, sub-historia, desagregacin y tarea se han entendido en la prctica y
han sido aplicados. Se distingue entre tarea y sub-historia.
11. Mximo ha mostrado que el uso del tablero Kanban es dinmico y que se lo puede modificar.
12. Qued aclarado lo que significa que una tarea est LISTA, para cada etapa del ciclo de vida de la
tarea.
13. Se visualiza fcilmente el ciclo de vida de una historia en el tablero.
14. El control del estado general de una historia y las tareas asociadas se puede leer del tablero.
15. Mximo ha incorporado mejoras al documento del Backlog, hacindolo ms slido y ms til.
16. Utilizando una plantilla de riesgos se analizaron los posibles efectos indeseados asociados con
las historias del proyecto.
17. Se incorpor una plantilla de propuestas que permite aunar en un documento dinmico al
Backlog y el presupuesto y aadir responsabilidades de las partes contractuales.
18. Los compromisos mutuos de cliente y proveedor quedan documentados, en particular el
alcance del proyecto, representado en el Backlog.
19. Mximo ha introducido el Scrum diario para evaluar los avances da a da y el estado general del
sprint, incluidos los riesgos asociados, para con ello mejorar el control y brindar evidencias de
varios resultados esperados del MPS.
20. La organizacin incorpora una demostracin del producto al final de cada sprint como criterio
de aceptacin por el usuario que sirve para evidenciar su participacin.
21. El anlisis de brecha ejercido como actividad continua muestra que los resultados esperados
para GRE surgen de los procesos ya implementados.
22. Mximo ha introducido un corto procedimiento para definir la estructura de carpetas de un
proyecto en el sitio de cada proyecto, que evidencia la implementacin de GPR 8 y GPR 9.
23. Mximo ha definido y codirigido varias implementaciones del procedimiento de anlisis
retrospectivo, que brinda evidencia de GPR 17, GPR 18 y GPR 19.
24. Mximo ha redactado una poltica que la organizacin aprob para establecer los lineamientos
2
de lo que se espera del personal de T .
25. Mximo ha desarrollado un proceso que permite evidenciar las capacidades de proceso de Nivel
G del MPS para las actividades de planificacin, a travs de la propuesta, y gestin de requisitos,
a travs del Backlog del producto y la evolucin del tablero Kanban.
2
26. T ha alcanzado el nivel G del MPS - SW en una evaluacin oficial

27. Mximo ha utilizado la tcnica de los sombreros de colores para sembrar el camino de ideas y
con el diagrama de Ishikawa ayudar a los socios a dilucidar cual camino seguir en la empresa
(crecer o no crecer).
Captulo 6
81
QUE HA PASADO HASTA AHORA DESDE EL PRIMER DIA

28. Mximo ha ayudado a revisar los riesgos de contratacin de proveedores y estudiar las
alternativas de comprar, reusar o fabricar introduciendo la tcnica de la matriz de Pugh.
29. Para poder desarrollar ms opiniones en paralelo Mximo ha inducido la tcnica de
polinizacin cruzada mediante un oportuno corte en la actividad.
30. Utilizando el anlisis de riesgo como herramienta de exploracin, Mximo induce las prcticas
que implementan los resultados esperados del MPS correspondientes a la gestin de portafolio
(o cartera) de proyectos.
31. Mximo ha contribuido a la definicin de roles aportando la plantilla con la misin y funcin y la
comunicacin entre ellos.
32. Mximo ha hecho nfasis en la definicin de los indicadores de gestin que requieren los
nuevos roles basndose en los riesgos.
33. Mximo ha compartido con el grupo dos activos: la plantilla de definicin de mediciones y la
plantilla de definicin de indicadores.
34. Como van a crear productos con sistemas externos y usar otros en varios subsistemas Mximo
ha inducido el uso de prcticas de gestin de configuracin como medida para proteger los
distintos activos.
36. Los gemelos han implementado Scrum en dos equipos conservando los tableros Kanban para
entender el estado del trabajo, aadiendo el grfico de quemado de tareas y el Backlog del
sprint como herramientas de control del proyecto.
37. Tahini-Tahini se prepara para la evaluacin de Nivel F.
82
Captulo 6
Boria et al.
Parte III Evolucin

CAPTULO 7 - ORGANIZANDO LA ORGANIZACIN (NIVEL E DE MPS-SW)
Este captulo tiene como objetivo discutir la implementacin de procesos que se requieren en el nivel E del
modelo de referencia MPS-SW. Para alcanzar el nivel E de madurez es necesario conservar o alcanzar los niveles de
madurez anteriores (G y F), e implementar los procesos Evaluacin y Mejora del Proceso Organizacional (AMP),
Definicin del Proceso Organizacional (DFP), Gestin de Recursos Humanos (GRH) y Gestin de Reutilizacin (GRU).
Asimismo el proceso de Gestin de Proyectos (GPR) sufre su primera evolucin, pasando a tener como propsito el
utilizar un proceso definido para el proyecto como la base de la gestin, a travs de planes bien integrados.
Tambin se evoluciona en cuanto a los atributos de procesos, puesto que a los ya expresados atributos de proceso
AP 1.1, AP 2.1, y AP 2.2 se agregan AP 3.1 y AP 3.2. (Ver Captulo 4 para mayores detalles de estos atributos de
proceso).
7.1 Una Empresa en Crecimiento Franco
Ni bien se terminan los mensajes de felicitacin por haber alcanzado el Nivel F del MPS los avances realizados
son puestos a prueba. Las tareas de desarrollo se multiplican y los ajustes al sistema para nuevos y viejos clientes
tambin. Alberto Galarraga requiere duplicar el nmero de equipos para desarrollo y mantenimiento, para lo cul
utiliza el anlisis de cartera que ya se aplicara para decidir el crecimiento. Trabajando con Marcela, que ha
comenzado hace meses una maestra en ciencias de administracin, intentan duplicar el proceso de seleccin de
personal que funcionara relativamente bien en la creacin de los dos primeros equipos de Scrum, pero agotada la
cantera de jvenes del ltimo ao de la carrera de Sistemas del Politcnico, se ven en figurillas para conseguir
personal idneo. Incluso cuando alguna persona est capacitada y su perfil es promisorio la incorporacin es larga
y dolorosa.
Acostumbrados ya a las tcnicas de Mximo, se juntan con Marcela para analizar los problemas e identificar
las causas raz de los mismos. El tema de la reunin es el esfuerzo que demanda incorporar nuevos empleados:
1.
2.
No se tiene bien definido el perfil de empleado que se solicita

No hay un repositorio de conocimientos que ayude a minimizar el aprendizaje individual de tcnicas y
mtodos
3. No hay una definicin del ambiente de trabajo que permita solicitar los recursos necesarios con
anticipacin para que el recurso humano entre en accin de inmediato
2
4. No hay una induccin a los procesos de T que acelere la formacin de equipos
5. No se toma en cuenta para la seleccin de personal el retardo que requiere el anlisis de los
candidatos.
Como resulta ya tradicin, se listan las medidas que se van a tomar, claramente en este caso alcanza con la
negacin de los problemas: Definir bien los perfiles, armar un repositorio de conocimiento, definir el ambiente de
trabajo, etctera.
Marcela es la encargada de realizar las bsquedas, seleccin y contrataciones en la nueva estructura y por
ende le corresponde la mayora de las actividades que surgen de la reunin. Trabaja con los gemelos en elaborar
67
un modelo de competencias para miembros del equipo, para eliminar rpidamente la primera parte del
problema. Sobre la base de lo as realizado piensa extender el modelo a todos los roles que existen dentro de la
2
organizacin. Comienza utilizando el formulario de misin y funciones de T que es una variante de la plantilla que
presentramos en el Captulo anterior. Como ejemplo damos ac el formulario completado para el cargo de
Ingeniero de Pruebas.
Misin y Funciones
Nombre del Cargo
Ingeniero de Pruebas
67
The Art and Science of Competency Models. Pinpointing Critical Success Factors in Organizations LUCIA, A.D., LEPSINGER, R.,
2007
Captulo 7
83
Nombre del Cargo al Que Reporta
Gerente de Pruebas (matricialmente), Scrum Master (tcnicamente), Equipo de Scrum

(funcionalmente)
Misin (Porqu existe el cargo)
La misin de los Ingenieros de Pruebas es detectar e informar de errores y problemas en los

productos de la empresa, para que sta pueda tomar correctamente las decisiones de negocio
sobre la calidad de los productos en lo que hace al estar listo para ser librado al uso. Es nuestra
poltica exceder la satisfaccin del cliente en nuestros envos.
Factor(es) Crtico(s) de xito (Los aspectos ms visibles del cargo)
1.
2.
3.
4.
Fallas detectadas por el usuario (previo a y en los primeros seis meses tras el
lanzamiento)
Satisfaccin de los ingenieros de software con los informes recibidos
Efectividad de los casos de prueba diseados (rendimiento en errores por caso sobre
total de errores)
Eficiencia en la corrida de casos de prueba e informe de los resultados
Mediciones de Desempeo (Como se puede medir el xito del cargo)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Nmero de errores no previamente detectados que se encontraron en el test de

aceptacin
Nmero de errores detectados por los usuarios en los primeros seis meses de uso que
no fueron previamente detectados
Nmero de errores informados no reproducibles a partir del informe
Nmero de informes rechazados por los ingenieros de software
Nmero de defectos que pasan de abierto a cerrado sin pasos intermedios despus
del informe
Rendimiento promedio de los casos de prueba diseados
Nmero total de informes no rechazados por los ingenieros de software
Nmero de casos corridos por unidad de tiempo
Nmero de defectos reportados por unidad de tiempo
Funciones (Qu hace el ocupante del cargo para cumplir con la misin)
1.
2.
Interpreta el Plan de Pruebas de Software

Revisa y prueba documentos de requisitos (con tcnicas como Grficos de Causa y
Efecto)
3. Disea Procedimientos de Prueba
4. Disea Casos de Prueba
5. Ejecuta los procedimientos de prueba usando los casos de prueba
6. Informa los resultados de cada prueba
7. Disea casos de prueba crticos para asegurar la identificacin del error
8. Ejecuta los casos de prueba bajo un arns de monitoreo de cobertura y analiza las
mediciones resultantes
9. Escribe scripts de casos de prueba para automatizar su ejecucin
10. Entiende las prioridades entre casos y optimiza el tiempo para aumentar el rendimiento
Comunicacin dentro de la organizacin
84
Con los ingenieros de software, para expandir lo realizado en pruebas ejecutadas y los
respectivos informes
Con el gerente de pruebas, para recibir instrucciones acerca de las tareas a realizar e
informar actividades realizadas y situaciones excepcionales
Con los analistas de negocios, para desarrollar requerimientos verificables por pruebas y
recibir sugerencias para el desarrollo de casos de prueba
Con los analistas de negocios, para expandir sobre lo informado de los documentos de
requisitos
Con el Scrum master y el equipo del Scrum, para priorizar y clasificar los defectos
encontrados (leve, serio, fatal, etc.)
Captulo 7
Boria et al.
Comunicacin fuera de la organizacin
En casos particulares, con los usuarios finales o un representante de ellos, para planificar y
realizar la prueba de aceptacin del usuario
Calificacin para el cargo
Tres o ms aos en posiciones tcnicas relacionadas (redactor tcnico, programador) o dos

aos de experiencia de prueba en proyectos similares
Experiencia con integracin continua
Experiencia con automatizacin de pruebas de software
Claridad de pensamiento y capacidad de comunicacin
Buena memoria visual
Atencin a los detalles
Experiencia en TDD deseable
Experiencia en mtodos giles deseable
Educacin formal
Ttulo superior o terciario tcnico relacionado con la profesin

Certificaciones profesionales MS o semejantes, deseables.
Figura 7.1: Formulario Misin y Funcin
Esta es la definicin del cargo. Para construir el modelo de competencias, Marcela tiene que considerar tres
dimensiones de cada rol: Las competencias bsicas, las competencias tcnicas y las competencias especficas. Las
mismas competencias bsicas son requeridas para todas las posiciones. Una competencia bsica, tambin llamada
nuclear o elemental, se define como un conocimiento, habilidad o comportamiento esencial para que uno pueda
2
actuar correctamente como personal efectivo de T . Las competencias bsicas aplican generalmente a todos los
cargos de igual manera. Una competencia tcnica es una habilidad particular relacionada especficamente con el
rol en cuestin, por ejemplo el ingeniero de pruebas tiene que ser capaz de realizar el diseo de un caso de
2
pruebas. Las competencias especficas de un cargo son aquellas que son distintivas de los procesos de T , por
ejemplo un Scrum Master debe poseer las competencias que le permitan hacer funcionar a su equipo pero adems
2
debe hacerlo de la manera que se espera en T , es decir siguiendo sus polticas, procesos y procedimientos.
Tpicamente las competencias bsicas y las tcnicas son utilizadas en el proceso de seleccin, aunque a veces los
empleados pueden acceder a capacitacin para adquirir o extender sus competencias tcnicas, y existen
programas de sensibilizacin respecto de las competencias bsicas.
A continuacin se presenta una lista de las competencias bsicas que Marcela y los gemelos entienden son
2
indispensables para trabajar en T , con la descripcin del comportamiento esperado en cada una:
tica e Integridad: Constantemente se comporta con honradez y admite los errores cuando le son
sealados, no hace pasar ideas ajenas por propias;
Servicio al Cliente: Consistentemente cumple con los objetivos del proyecto respecto de los niveles
de servicio al cliente, esforzndonos constantemente para alcanzarlos y hasta superarlos;
Comunicacin: Se comunica efectivamente verbalmente y por escrito;
Resolucin de problemas: Desarrolla estrategias eficaces ajustadas a las necesidades del negocio, y
resuelve problemas;
Flexibilidad: Demuestra flexibilidad en los roles de trabajo y gestiona sus cambios de forma que
resultan en un desempeo productivo;
Tecnologa: Utiliza el equipamiento y la tecnologa de manera segura, eficiente y eficaz;
Seguridad: Cumple con las normas de seguridad, observa las prcticas de trabajo seguras, y
proporciona informacin sobre cuestiones de seguridad;
Autogestin: Maximiza el tiempo propio y aprovecha su talento para alcanzar los objetivos de la
organizacin;
Crecimiento: busca oportunidades para innovar y mejorar continuamente;
Adaptacin: desarrolla enfoques eficaces para la gestin de s mismo en el cambio organizacional;
Trabajo en equipo: Trabaja efectivamente con el equipo de trabajo y an con aquellos que estn
fuera de la lnea formal de autoridad para lograr los objetivos organizacionales;
Prudencia: Utiliza los recursos basndose sensatamente en las prioridades de la organizacin.
Captulo 7
85
Adems, el modelo que desarrollan contiene las competencias tcnicas para cada uno de los cargos. Todava
no han desarrollado un modelo completo, que debiera contener un mecanismo de evaluacin del grado de
adecuacin del personal al modelo, as como las competencias especficas, cuyos detalles surgirn de los procesos
que deban seguir los roles. Por ahora, Marcela se conforma con tener una descripcin de lo que busca en cada
actividad que forma parte de la cadena de valor que es atendida por el cargo, lo que constituye suficiente materia
para sus bsquedas tcnicas.
Por ejemplo, para el cargo de Ingeniero de Pruebas, en el proceso de Diseo de la Estrategia de Pruebas el
propsito es encontrar la mejor estrategia posible para el rendimiento de las pruebas. Un ingeniero de Pruebas
debe ser capaz de Interpretar el Plan de Pruebas de Software y elegir una estrategia de las mismas basada en los
objetivos de negocios y los riesgos. Cuando participa en el Anlisis de Requisitos se espera que sea capaz de
encontrar un alto porcentaje de inconsistencias e incompletitudes, lo que consigue al revisar y probar documentos
de requisitos, con tcnicas como Grficos de Causa y Efecto. Utiliza estas tcnicas de generacin sistemtica de
pruebas para identificar requisitos faltantes o encontrados entre s. Estos son los elementos tcnicos que servirn
para la seleccin, las entrevistas y los exmenes de aptitud de los aspirantes.
Armada con estas definiciones, Marcela sale a buscar personal para cubrir ocho cargos de ingeniero de
software y cinco de ingenieros de prueba, de estos ltimos al menos uno de ellos deber tener experiencia en
documentacin de software. Buscando en un el mercado, las etapas de difusin del llamado, los filtros iniciales de
las respuestas, las comunicaciones, las entrevistas, la preparacin de ofertas y la contratacin resultaron en una
demora de varias semanas. Marcela vuelve a reunir a los socios para proponerles una actitud proactiva en la
bsqueda. Usando los nmeros de sus bsquedas y datos del estudio de bsqueda de personal que la auxilia,
advierte sobre las demoras que se presentan en la contratacin y tomando como riesgo el no contar con el
personal necesario al comienzo de un proyecto, lo que impide grandemente alcanzar los objetivos y cumplir con
los compromisos con los clientes, propone una actividad de mitigacin que consiste en ir generando una base de
datos de candidatos. Su mecanismo ser el que sigue: una vez por mes se renen los socios para revisar la cartera
de proyectos y hacer ajustes al plan estratgico. En esa reunin se establecern los potenciales cargos a cubrir. Con
ese fundamento, Marcela armar un plan tctico de incorporaciones.
Marcela presenta la tabla (Tabla 7.1) con las actividades del proceso de reclutamiento e incorporacin de
personal. Adems, como datos de ajuste, Marcela tiene dos tablas, una para desarrolladores y otra para personal
de pruebas, que miden el porcentaje de respuestas positivas a un evento (por ejemplo, cuntas bsquedas de
currculo en una base de datos de personal dan resultados positivos para cada tipo de cargo) y el tiempo de
demora de cada actividad. Como ejemplo Marcela presenta una tabla con varios cargos y las respuestas positivas
porcentuales en cada evento que lo amerite, para un conjunto de posiciones relacionadas con el desarrollo, que
consigui en la agencia que la ayuda en sus bsquedas (Tabla 7.2). De ese modo puede calcular cuntas instancias
de cada actividad tiene que realizar en cada caso y con qu anticipacin. Viendo los datos de la tabla para personal
de prueba se deduce que hace falta realizar seis ofertas (5,6 para ser precisos) para obtener cinco aceptaciones, lo
que exige que se hagan 5,7 entrevistas tcnicas, 6,4 entrevistas funcionales, que se envan a 12,9 candidatos
seleccionados entre 143,2 curriculum vitae de la base de datos. Si las oportunidades no se concretan la bsqueda
puede igual ser til si surgen nuevas del mismo tipo, o sino simplemente enfriarse hasta que aparezca algo. El
precio que se paga es menor que el de las postergaciones.
Actividad
1
Filtrar los candidatos de la BD
2
Elegir entre los filtrados
3
Agendar entrevistas funcionales
4
Realizar entrevistas funcionales
5
Agendar entrevistas tcnicas
6
Realizar entrevistas tcnicas
7
Realizar oferta inicial
8
Obtener aprobacin
9
Realizar oferta final
10 Contratar
11 Inducir conocimiento empresa
12 Capacitar en el rol
Tabla 7.1: Actividades de Reclutamiento e Incorporacin de Personal
86
Captulo 7
Boria et al.
De este modo Marcela tiene un proceso de incorporacin de personal y un sistema de medicin que permiten
anticipar el tiempo y esfuerzo del reclutamiento. Esto permite cubrir las previsiones para la seleccin, ahora falta
eliminar los riesgos en el proceso de incorporacin, que se sintetizan en que se demoran los proyectos porque se
demora demasiado en llevar al personal incorporado a un nivel de rendimiento aceptable dado el exceso de
entrenamiento requerido para incorporar a los nuevos empleados a los equipos.
Tabla 7.2: Porcentaje de xito en Actividades Seleccionadas por Tipo de Cargo
En primersimo lugar, Marcela propone reforzar la estructura y rol de su Gerencia de Recursos Humanos. He
2
aqu sus argumentos, nuevamente analizados como riesgos a T :
Desarrollo de Recursos Humanos
riesgo:
mitigacin:
si crecemos sin previsin de recursos humanos vamos a

tener mucha demora en ingresar personal y no siempre
podremos responder a la demanda
Estudiar las necesidades estratgicas de la

organizacin y prever las necesidades de recursos,
anticipndonos a ellas
Identificar los candidatos a ocupar puestos y
desarrollar relaciones para reclutarlos
dados nuestros particulares procesos es probable que el

2
perodo de aprendizaje y ajuste a las necesidades de T
sea demasiado largo para nuestros negocios
identificar las necesidades estratgicas de

capacitacin de personal
generar un plan de largo plazo para cubrir las
necesidades de capacitacin
implementar las partes principales del plan en el
corto y mediano plazo
llevar claros registros de los entrenamientos
realizados
es probable que haya entrenamientos que no tengan el

valor esperado y perdamos dinero
validar que los entrenamientos cumplen con su

propsito
si queremos ser proactivos en la mejora de desempeo

debemos entender como evaluarlo y mejorarlo
constantemente o corremos el riesgo de invertir en lo
que no rinde
definir mtodos objetivos de medir desempeo y

utilizarlos para mejorar el rendimiento del personal e
identificar oportunidades de mejoras
si desperdiciamos el conocimiento deberemos recrearlo

cada tanto, a un costo muy alto
generar una estrategia para generar, captar, difundir

y aprovechar el conocimiento
generar una corriente de grupos de inters en cada
disciplina y apoyarla
generar medios de difundir y compartir conocimiento
y habilidades entre pares
Tabla 7.3: Riesgos a T Derivados de Polticas Pobres en Recursos Humanos
Por suerte para todos, varias de las actividades ya estn en marcha. Por ejemplo, el mtodo adoptado para
revisar la cartera de proyectos incluye ya estudiar las necesidades estratgicas de la organizacin y prever las
necesidades de recursos, cosa que Marcela propone profundizar an ms utilizando las herramientas de un
modelo de competencias. Tambin el modelo de competencias, junto con el proceso de reclutamiento, va a ayudar
en la identificacin de los candidatos a ocupar puestos y desarrollar relaciones para reclutarlos. Marcela se
Captulo 7
87
propone contratar una persona de recursos humanos que tenga conocimientos de modelos de competencias y
diseo instruccional, una combinacin no frecuente pero tampoco extravagante. Juntando esto con el anlisis
mensual de cartera se pueden identificar las necesidades estratgicas de capacitacin de personal y de ese modo
generar un plan de largo plazo para cubrir las necesidades de capacitacin e implementar las partes principales del
plan en el corto y mediano plazo, como plan tctico. Por supuesto, habr que llevar claros registros de los
entrenamientos realizados y validar que los entrenamientos cumplen con su propsito.
En ese sentido el modelo de competencias adoptado permite, o deber permitir, el definir mtodos objetivos
de medir desempeo y utilizarlos para mejorar el rendimiento del personal e identificar oportunidades de mejoras.
Midiendo ese desempeo antes y despus del entrenamiento realizado permite adjudicar la mejora de desempeo
a la capacitacin. Puesto que Marcela tiene en mente un modelo de personal que llega a costos individuales (el
costo derivado del salario incluyendo cargas sociales y los costos que provienen de mantener el cargo en
funcionamiento, como electricidad, licencias de software y hardware, amortizacin de los metros cuadrados
ocupados, etctera) y desempeo individual (el ingreso que se puede adjudicar al desempeo de la persona en el
cargo), es posible adjudicar un valor monetario a la diferencia de rendimiento, que se puede entonces medir
contra el costo de la capacitacin.
Se pueden asimismo hacer anlisis del perodo de repago, el valor presente de la capacitacin y otros anlisis
financieros. A punto de recibir su ttulo de Magister en Ciencias de la Administracin, Marcela confa en que los
anlisis de tipo financiero aplicados a todo tipo de inversiones les rendirn beneficios a la hora de tomar
decisiones. Si bien esto puede parecer una forma de cazar mosquitos a caonazos, es una necesaria pauta
cultural para tomar decisiones basadas en datos y no en sensaciones. En las palabras de D. Edwards Deming, In
68
God we trust, all the others bring data (En Dios confamos, los dems vengan con datos) .
Fase
Tarea
Apoyo a la Venta
Participa de la
reunin inicial
COMPETENCIA POR NIVELES DE UN GERENTE DE CUENTAS

COMPETENCIA
1
2
3
4
Lego
Principiante
Junior
Senior
No tiene idea
sobre qu se
espera de l o ella
Toma apuntes y
hace preguntas de
seguimiento
Toma apuntes,
hace preguntas de
seguimiento y
desambiguacin
Realiza la
presentacin del
mtodo de
desarrollo de T2
No conoce el
material y no es
capaz de
presentarlo
Ayuda en la
explicacin sobre
el uso de los
materiales en el
ejercicio
Presenta el
material con
mnimos
problemas y
conduce los
ejercicios
Realiza ajustes a la
propuesta frente
al cliente ante
pedidos expresos
de cambio
No sabe como
manejarse con
cambios al
proyecto
Intenta seguir el
proceso de control
de cambios pero
se pierde y no
consigue
resultados
Evala cambios
midiendo su
impacto en costo
y tiempo de
entrega y gestiona
los cambios en s
Toma apuntes,
hace preguntas de
seguimiento y
desambiguacin; y
participa en las
discusiones
Prepara la
presentacin,
presenta el
material sin
problemas y
conduce los
ejercicios
Mantiene la
integridad de la
propuesta sin
confrontar al
cliente y se
asegura que los
cambios de
impacto se
reflejan en el
alcance
5
Experto
Conduce y facilita
la actividad
Prepara la
presentacin,
presenta el
material con
aplomo y
conduce los
ejercicios
Coordina los
cambios con
todos los
interesados y
balancea los
intereses
colectivos para
llegar al ganarganar
Tabla 7.4: Primera Parte de un Modelo de Competencias
Para mostrar que un modelo de competencias es posible, Marcela ofrece un ejemplo parcialmente completo
para el cargo de gerente de cuentas, que le envi Mximo. En la versin utilizada, cada paso crtico del proceso de
ventas de un proyecto nuevo es listado en la primera columna. Luego hay cinco columnas representando el grado
de competencia del gerente de cuentas, desde el lego al experto. Debajo de cada grado hay una descripcin de
lo que se entiende por ese grado (Tabla 7.4). Asimismo, la Tabla 7.5 muestra la lista evaluativa correspondiente
68
88
En realidad no hay confirmacin de que haya sido Deming quin dijo esto, pero es parte del mito que le acompaa. Ver
http://en.wikipedia.org/wiki/W._Edwards_Deming
Captulo 7
Boria et al.
para la primera tarea. De ese modo es posible relacionar el rendimiento con los individuos y medir el resultado de
la capacitacin como la diferencia de productividad antes y despus del evento.
LISTA DE EVALUACIN
Fase
de Apoyo
a la
Venta
Participa de
reunin inicial
la
Tarea
Toma notas
Hace preguntas
adecuadas para
que todos
entiendan mejor
la discusin
Participa y
facilita la
reunin
Es capaz de
sintetizar los
resultados
alcanzados
Casi Nunca
(0% - 10%)
Muy Poco
(1% - 33%)
A Menudo
(34% - 66%)
Casi Siempre
(67% - 95%)
Sistemticamente
(96% - 100%)
Tabla 7.5: Lista evaluativa Correspondiente a la Primera Tarea
Marcela implementa las acciones y llama a Mximo para revisar su pertinencia. Mximo se muestra
complacido de los progresos logrados y sugiere evaluar las prcticas contra los resultados del modelo MPS, esta
vez contra el proceso de Gestin de Recursos Humanos:
Gestin de Recursos Humanos (GRH)
GRH 1
Las necesidades estratgicas de la organizacin y de los proyectos son revisadas para

identificar recursos, conocimientos y habilidades requeridos y, de acuerdo con la necesidad,
desarrollarlos o contratarlos;
GRH 2
Individuos con las habilidades y competencias requeridas son identificados y reclutados;
GRH 3
Las necesidades de entrenamiento que son responsabilidad de la organizacin son

identificadas;
GRH 4
Una estrategia de entrenamiento es definida, con el objetivo de atender a las necesidades de

entrenamiento de los proyectos y de la organizacin;
GRH 5
Un plan tctico de entrenamiento es definido, con el objetivo de implementar una estrategia

entrenamiento;
GRH 6
Los entrenamientos identificados como responsabilidad de la organizacin son conducidos y

registrados;
GRH 7
La efectividad de los entrenamientos es evaluada;
GRH 8
Criterios objetivos para evaluacin del desempeo de grupos e individuos son definidos y
supervisados para proveer informaciones sobre este desempeo y mejorarlo;
GRH 9
Una estrategia apropiada de gestin de conocimiento es planificada, establecida y mantenida

para compartir informaciones en la organizacin;
GRH 10
Una red de especialistas en la organizacin es establecida y un mecanismo de apoyo al

intercambio de informaciones entre los especialistas y los proyectos es implementado;
GRH 11
El conocimiento es colocado a disponibilidad y compartido en la organizacin.

Tabla 7.6: Proceso GESTIN DE RECURSOS HUMANOS [SOFTEX, 2012a]
Mximo est contento, sus ahijados estn resultando mejores que el profesor.
38. Tahini-Tahini alcanza el nivel F del modelo MP SW.
39. Marcela y los gemelos analizan las causas-raz de las dificultades para contratar personal idneo
y hacerlos rendir en corto plazo.
40. Marcela y los gemelos comienzan la construccin de un modelo de competencias para TahiniTahini.
Captulo 7
89

41. Marcela propone un mecanismo de seleccin proactivo para la contratacin de personal.
42. Mximo revisa y aprueba la implementacin elegida de los procesos de Gestin de Recursos
Humanos.
7.2 La Necesidad de Activos de Proceso
Al hacer el anlisis de las necesidades de capacitacin es frecuente encontrarse que algunos de los recursos
necesarios para ayudar al personal en la realizacin de sus tareas estn faltando: Planes, herramientas de
software, guas de apoyo, formularios tipo, estndares de trabajo, evidencia anecdtica y numrica del desempeo
de los procesos, materiales de entrenamiento y de apoyo a los usuarios de los propios productos, entre otros,
todos estos auxilian en las decisiones y facilitan la realizacin de las tareas cotidianas. Su ausencia representa una
mala inversin, puesto que el conocimiento no capturado debe ser reproducido, con los consiguientes riesgos, o
compartido por los que ya lo tienen, con las consiguientes demoras.
La capacitacin centralizada es solo una parte de la solucin: La organizacin que aprende lo hace
constantemente, por designio de su estructura. Hay que crear una estrategia para generar, captar, difundir y
aprovechar el conocimiento en cada uno de los roles y funciones de la organizacin, una corriente de grupos de
inters en cada disciplina y apoyarla con mltiples medios de difusin y compartir conocimiento y habilidades
entre pares, como blogs internos, frums internos, wikis para almacenar conocimiento, refuerzo de las actitudes
de compartir con los que saben menos, etctera. Marcela elige una herramienta de gestin de conocimientos
69
entre varias opciones y con la ayuda de Armando la implementan en la organizacin. De inmediato se produce
una corriente de inters que empieza a generar artefactos que poco a poco se van agregando a aquellos activos
2
que ya hemos descripto, almacenados en la red interna de T .
Con el crecimiento organizacional una empresa que alcanz esto por estar relativamente bien organizada,
puede encontrar que en realidad esa evolucin la ha hecho retroceder, empujada por el influjo de personal nuevo
y la multiplicacin del nmero de proyectos, hasta recalar en un mundo de procesos caticos. La solucin es
sencilla, pero demandan organizarse para que pueda aplicarse y tener paciencia para que con el tiempo d sus
frutos: Se trata de definir procesos organizacionales adaptables, adoptables y con activos fciles de usar, aun
cuando se deben detallar los procesos para que se pueda evaluar fcilmente su aplicacin o falta de ella en cada
proyecto individual, segn sus caractersticas. Un proceso demasiado flexible no es un proceso evaluable. Ya vimos
en el Captulo 5 qu atributos describen un proceso, con la plantilla que introdujo Mximo. Sin cambiar esa
estructura, lo que se pide es que los pasos para su ejecucin sean muy concretos y que sea posible evaluar su
seguimiento o la falta del mismo.
Marcela se aboca a construir una arquitectura para organizar los activos que se van generando, as como a
construir aquellos que no solo le den marco a los que surgen espontneamente de los equipos de proyecto, sino
sobretodo incorporando otros que inspiren a continuar creciendo. Por ejemplo, est segura que Kanban y Scrum
no van a ser las nicas fuentes de inspiracin para la gestin de proyectos, por lo que decide que en su biblioteca
2
de procesos habr siempre lugar para definir ciclos de vida en uso en T y hacerlos adaptables a los procesos. En
particular est pensando en algunas ideas que discute con Ana, que sigue trabajando desde su casa desde las
ltimas semanas de su embarazo mientras cuida del recin nacido, y que tienen que ver con Feature Driven
70
Development .
Dada su experiencia con el reclutamiento de nuevos empleados y los objetivos fijados para controlar
desempeo, sobre todo como medida de la efectividad de los entrenamientos, Marcela est segura de la utilidad
de mantener un repositorio de datos de desempeo de los procesos. La plantilla de definicin de procesos ya
incorpora mediciones, pero Marcela va agregando indicadores de desempeo, a nivel individual y por equipos, que
sirven para tomar decisiones al momento de hacer ofertas de trabajo con conocimiento de la capacidad para
realizarlo. Para evitar que las mediciones no tengan ningn sentido, Marcela propone que slo bajo excepciones
justificadas y aprobadas por la direccin (de la que forma parte) se pueden utilizar procedimientos que no hayan
sido sancionados previamente. De ese modo, y dado que los procesos son evaluables en cuanto a su
69
70
http://bsix12.com/knowledge-sharing-tools/ es un buen punto para empezar la bsqueda.

Ver Captulo 3
90
Captulo 7
Boria et al.
71
seguimiento , se pueden comparar resultados. Si los caminos para ejecutar los procesos fueran individuales la
comparacin de resultados no sera posible.
La sancin de un proceso, segn piensa Marcela, se efectiviza en la publicacin en la Biblioteca de Activos de
Procesos, BiPro como se la denomina en la intranet. Como parte de las medidas para acelerar el rendimiento de
personal recientemente incorporado, Marcela ha detectado que es necesario definir patrones de los ambientes de
trabajo, puesto que la compra de nuevos equipos y licencias no es un asunto tan inmediato como se quisiera. Para
poder conseguir buenos precios en el mercado es necesario contar con cierta anticipacin para la compra. Por otra
parte, la experiencia muestra que la incorporacin de personal con experiencia en otro tipo de proyectos a los
proyectos giles es dificultosa, por lo que un patrn de la capacitacin a recibir es sumamente til. Marcela opta
por un mecanismo que hace la incorporacin menos traumtica: Cada nuevo empleado, en lo sucesivo, contar
con el apoyo de otro empleado, ya experimentado, que le ayudar en sus primeros pasos: Cada uno de los cinco
2
primeros das en T estn pautados en la Gua de Incorporaciones, desde la presentacin a la direccin, el recorrido
de las instalaciones, las pautas de uso de la BiPro, los cursos en lnea y el ambiente de trabajo.
La BiPro contiene prcticamente cualquier cosa. Marcela ha ido acumulando experiencias propias y ajenas,
filtrando los mejores activos de la herramienta de gestin de conocimientos y la lista del contenido es larga: en
principio contiene el Plan Organizacional de Mejora de Procesos, que discutiremos en detalle en la seccin que
sigue. Este plan permite a cualquiera que est interesado conocer las necesidades de mejoras de procesos que han
sido reconocidas por la organizacin y como se propone sta cubrirlas, identificando las estrategias, enfoques y
acciones para encarar mejoras de procesos.
En el nivel ms alto hay una descripcin de la arquitectura de los procesos organizacionales, que se instancian
2
en el Proceso Maestro de T , con su Gua de Adaptacin para su uso en los proyectos. Marcela ya ha incorporado
algunas Polticas Organizacionales, para comunicar los principios gua de la organizacin, y Descripciones
Organizacionales de Ciclos de Vida, que permiten guiar la determinacin de las fases principales de un proyecto o
producto sobre las cuales se pueda determinar el alcance del planeamiento.
Tambin hay un Ejemplo de Plan de Proyecto, que ilustra el nivel apropiado de estimacin, definicin de
roles, y otros atributos crticos relacionados al planeamiento de un proyecto, y Definiciones Operacionales de
Mediciones para proveer descripciones precisas e inequvocas de los atributos de las entidades que puedan ser
tiles medir en un proceso. Para auxiliar en la estandarizacin de los procesos hay plantillas y guas de uso, como
las Plantillas para Procedimientos y Criterios de Pruebas de Validacin y Verificacin, y Normas de Desarrollo de
Producto. En general hay claras definiciones de las expectativas de la organizacin para procesos, herramientas,
tcnicas y mtodos a ser usados en el ambiente de desarrollo. Hay tambin otras guas particulares, como las
Guas de Anlisis de Decisin para guiar la seleccin de temas que deben ser sometidos a evaluaciones formales.
Ilustrar varios atributos que deberan considerarse en la evaluacin de diseo de componentes de producto
Hay asimismo materiales para ayudar en la seleccin y uso de tcnicas y herramientas, como los Ejemplos de
Tcnicas de Extraccin de Requerimientos para proveer apoyo con ejemplos de tcnicas para la recoleccin de
necesidades, expectativas, restricciones e interfaces de los interesados, lo mismo que la plantilla para
especificaciones de requerimientos que ayuda a comunicar efectivamente los compromisos y productos del
proyecto a todos los interesados ms relevantes. Hay ms, pero para muestra basta con sealar estos. El criterio es
que si es til para alguien se lo almacena para que pueda ser accedido y el conocimiento reusado. Cada elemento
tiene su gua de uso y los criterios asociados para su eleccin ante alternativas.
Puesto que algo tan diverso y amplio es difcil de utilizar, una parte corresponde a los activos recomendados
necesarios para el uso cotidiano, pero la BiPro tiene capacidades de wiki auto organizadas basadas en un algoritmo
de redes neuronales que fue desarrollado por uno de los nuevos programadores como su tesis de ingeniero en
72
aplicaciones para reuso de conocimiento. Desarrolladas en primera instancia para el reuso de software , las wiki
semnticas, como se las llama, simplifican el almacenamiento de informacin al utilizar algoritmos que relacionan
los contenidos de manera automtica, incrementando la usabilidad de los mismos. Un problema conocido de los
wikis es que al principio, cuando hay poco contenido, la usabilidad es muy alta. Al aumentar el contenido la
usabilidad comienza a decrecer rpidamente. Por eso el uso de auto organizacin disminuye el esfuerzo y permite
71
72
Ver en Captulo 6 Aseguramiento de la Calidad

DECKER, B., et al, 2005.
Captulo 7
91
que una empresa pequea como T pueda almacenar con facilidad el aprendizaje que se genera a partir de la
herramienta de gestin de conocimiento.
Marcela mantiene un indicador de uso de los elementos de la BiPro. Por las herramientas de soporte
elegidas, es siempre ms fcil acceder al documento o conocimiento en la biblioteca que guardar copias en
carpetas locales y accederlas en ocasin de su uso. Esto hace que las estadsticas de uso sean muy representativas
de la realidad. Utilizando estos datos, Marcela va comprendiendo que hay perfiles de proyectos, aun que a veces
hay perfiles de sprints. Decidida a entender, arman con Ana un grupo de trabajo que incluye a Mariano y los
gemelos y empiezan una labor detectivesca, juntando datos de los atributos de los sprints y correlacionando estos
con el uso de ciertos elementos en la prctica. Analizando estos datos llegan a las siguientes conclusiones, que
publican en la BiPro para su difusin y uso.
Orientacin Sugerida por Perfil de Sprint
condicin
el tamao de la funcionalidad excede la
capacidad del sprint
la funcionalidad es nueva y tiene muchas aristas
inexploradas
la funcionalidad es totalmente central al
funcionamiento del producto (control)
el dueo del producto tiene dudas sobre la
funcionalidad que sugiere
el equipo no tiene miembros con experiencia

la arquitectura es crucial en el desempeo
futuro del producto
eleccin sugerida
Kanban con un mini-equipo dedicado
mini-espiral de Bohm dentro del sprint o partir el
sprint a partir del anlisis para hacer demos ms
frecuentes
usar TDD a full e inspecciones adems de
programacin de a dos
ampliar el juego de la planificacin hasta incluir un
bosquejo de modelo dinmico usando tcnicas de
UML y FDD
disminuir la duracin del sprint para hacer demos
ms frecuentes
usar inspecciones y programacin de a dos con el
scrum master en uno de los roles
usar un sprint para definir la arquitectura, a la
manera de FDD, y decidir despus sobre Kanban,
Scrum o Scrumban
Tabla 7.7: Orientacin Sugerida por Perfil de Sprint

2
Cuatro semanas despus de contar con la presencia del consultor en las oficinas de T , se vuelve a llamar a
Mximo para la revisin del proceso Definicin del Proceso Organizacional, con resultados perfectos.
Definicin del Proceso Organizacional (DFP)
DFP 1
Un conjunto definido de procesos estndar es establecido y mantenido, en conjunto con la

indicacin de la aplicabilidad de cada proceso;
DFP 2
Una biblioteca de activos de proceso organizacional es establecida y mantenida;
DFP 3
Tareas, actividades, roles y productos de trabajo asociados a los procesos estndar son
identificados y detallados, en conjunto con el desempeo esperado del proceso;
DFP 4
Las descripciones de los modelos de ciclo de vida a ser utilizados en los proyectos de la
organizacin son establecidas y mantenidas;
DFP 5
Una estrategia para la adaptacin del proceso estndar es desarrollada considerando las
necesidades de los proyectos;
DFP 6
El repositorio de medidas de la organizacin es establecido y mantenido;
DFP 7
Los entornos estndar de trabajo de la organizacin son establecidos y mantenidos;
DFP 8
Reglas y guas para la estructuracin, formacin y actuacin de equipos son establecidas y

mantenidas.
Tabla 7.8: Proceso DEFINICIN DEL PROCESO ORGANIZACIONAL
[SOFTEXT, 2012a]

43. Marcela incorpora una herramienta para compartir conocimiento entre los miembros de TahiniTahini.
44. Marcela define una arquitectura para organizar los activos de proceso.
92
Captulo 7
Boria et al.

45. Marcela define indicadores a partir de una base de datos de desempeo de los procesos que le
permiten mejorar el conocimiento de la capacidad individual y de los equipos.
46. Marcela define patrones de los ambientes de trabajo.
47. Marcela define un proceso y activos para la incorporacin de personal nuevo a los equipos.
48. Marcela conecta la herramienta de gestin del conocimiento a la biblioteca de activos de
proceso, utilizando un algoritmo que permite auto organizar los contenidos.
49. Un taller interno identifica correlaciones entre usos de activos de la biblioteca y atributos de los
proyectos y productos a construir y genera una gua de uso.
50. Mximo revisa los procesos y activos de Definicin del Proceso Organizacional y los aprueba.
7.3 Retrospectivas y procesos
As como el crecimiento del personal y la multiplicacin de los proyectos puede, como ya se dijo, recalar en
un mundo de procesos caticos, la aceleracin del cambio puede hacer que se pueda llegar a confundir cambios de
proceso como mejora de proceso, perdiendo tiempo y dinero. Marcela es un espritu prctico con formacin
contable y de sistemas, una combinacin que la hace muy astuta. Para evitar que se dispersen los esfuerzos en su
rea de procesos, ha adoptado una estrategia que le permite entender y documentar los objetivos estratgicos de
2
proceso de T , lo que se realiza durante las reuniones mensuales de revisin de cartera. La revisin permanente de
esos objetivos se hace a partir del sistema de mediciones de la capacidad de los procesos que Marcela pusiera en
prctica.
Con estos datos Marcela mantiene su plan de mejora basado en la medicin de la capacidad y los objetivos
estratgicos de negocio. El plan parte de actividades que realizan los proyectos, en particular las autoevaluaciones
73
que se hacen al final de cada sprint, llamadas retrospectivas , donde se discuten tanto nuevas necesidades como
mejoras ya realizadas, para seleccionar y adoptar mejoras que se difunden implantndolas en los otros proyectos.
El plan es uno ms de los planes de proyecto y se discute su avance en las reuniones mensuales. Como los planes
de proyecto, tiene los mismos atributos y la misma necesidad de monitoreo y control. La diferencia con los
proyectos de desarrollo es que para cada iniciativa se elije el grupo de expertos que ha de participar en la
confeccin de los activos, sean estos procesos, procedimientos o guas, o todos los anteriores, y se les asigna su
dedicacin, generalmente de tiempo parcial. Marcela conduce estos grupos, a lo sumo dos por mes, siguiendo su
propio tablero kanban y con reuniones semanales. Una buena prctica que se ha adoptado es la de hacer que
todos los expertos trabajen a la vez el mismo da de la semana, para obtener resultados ms rpidos y asegurar su
participacin. La asignacin es por mltiplos de 10% de dedicacin semanal, de modo que si se considera la
semana de cuarenta horas cada mltiplo es de medio da. De ese modo es posible controlar los compromisos con
el proyecto.
La inclinacin de Marcela por los nmeros la lleva a que sea sistemtica al medir los resultados obtenidos
contra los resultados esperados del plan de mejoras, que documenta en cada caso y presenta en las reuniones
mensuales de revisin de cartera. La planificacin estricta no le impide incorporar mejoras oportunistas cuando las
haya, como las ideas que Ana trae de sus ctedras. Marcela revisa por su cuenta los resultados del proceso
Evaluacin y Mejora de Procesos Organizacionales y, satisfecha con los resultados, enva un informe a Gerencia
General recomendando comenzar preparativos para una evaluacin de nivel E del MR-MPS SW.
Evaluacin y Mejora del Proceso Organizacional (AMP)
73
AMP 1
La descripcin de las necesidades y los objetivos de los procesos de la organizacin son

establecidos y mantenidos;
AMP 2
Las informaciones y los datos relacionados al uso de los procesos estndar para proyectos
especficos existen y son mantenidos;
AMP 3
Evaluaciones de los procesos estndar de la organizacin son realizadas para identificar sus
puntos fuertes, puntos dbiles y oportunidades de mejora;
AMP 4
Registros de las evaluaciones realizadas son mantenidos accesibles;
AMP 5
Los objetivos de mejora de los procesos son identificados y priorizados;
Ver Captulo 3
Captulo 7
93
Evaluacin y Mejora del Proceso Organizacional (AMP)

AMP 6
Un plan de implementacin de mejoras en los procesos es definido y ejecutado, y los efectos de

esta implementacin son supervisados y confirmados con base en los objetivos de mejora;
AMP 7
Activos de proceso organizacional son implantados en la organizacin;
AMP 8
Los procesos estndar de la organizacin son utilizados en proyectos a ser iniciados y, en caso de
que sea pertinente, en proyectos siendo llevados a cabo;
AMP 9
La implementacin de los procesos estndar de la organizacin y el uso de los activos de proceso

organizacional en los proyectos son supervisados;
AMP 10
Experiencias relacionadas a los procesos son incorporadas a los activos de proceso organizacional.
Tabla 7.9: Proceso EVALUACIN Y MEJORA DEL PROCESO ORGANIZACIONAL
[SOFTEXT, 2012a]

51. Marcela arma un plan de mejora continua de procesos basado en los objetivos organizacionales
de negocios y la capacidad real de los procesos.
52. Marcela revisa por su cuenta los resultados del proceso Evaluacin y Mejora de Procesos
Organizacionales.
7.4 Disminucin de costos por reuso de componentes
2
Pero antes de alcanzar el nivel E, T debe atender algunos otros procesos. A pesar de los esfuerzos de
contratacin de personal, creacin y difusin de conocimiento y los procesos que aceleran las actividades, los
equipos se quedan cortos en la productividad requerida. Ana, ya reincorporada parcialmente (participa de todas
las reuniones de direccin y cuando es invitada a revisar artefactos en conjunto con el equipo que lo genera)
seala que ya que se usa el algoritmo que aplicara uno de sus alumnos en el trabajo de graduacin para la autoorganizacin del conocimiento en las wikis, se podra usar el mismo algoritmo para encontrar las componentes
tiles en la biblioteca de los proyectos. Lo que sugiere es implementar una estrategia de reuso que contemple
criterios claros para la seleccin de las componentes, con mecanismos de almacenamiento y uso de los activos, y
procedimientos para que sean actualizados permanentemente con usuarios claramente identificados del sistema,
para advertirlos sobre cambios y mejoras. Los procedimientos tienen que cubrir tanto los aspectos tcnicos como
los administrativos. Se entiende como artefacto activo reutilizable a cualquier software que se prepara, es decir,
que es empaquetado expresamente para ser reutilizado por los procesos de la organizacin. Esto sugiere que haya
algunos criterios especiales para su construccin y prueba. La primera consideracin es el ajuste arquitectnico.
Las componentes se agrupan por tecnologa e interfaces, y su versin es actualizada constantemente. Las API se
publican en un reporte que se indexa para ser utilizado ms adelante. Esto evita que haya que hacer un proceso
manual de bsqueda, porque los filtros son automticos, lo que pone a disposicin del equipo un reservorio de
oportunidades a explorar justo cuando estn buceando por alternativas para integrar su plan del sprint.
Otros criterios fundamentales son el costo versus el beneficio de reusar, el ajuste al plan y el diseo del
producto, si es o no un producto heredado y otros que pueden ser dependientes del proyecto en s. Dado que los
proyectos son giles, es el equipo quin decide los criterios.
Lo resuelto es que los proyectos incorporen a su procedimiento de planificacin, en el momento de
establecer el Backlog del sprint, un anlisis de opciones que sigue los pasos del proceso de reuso. Brevemente, los
pasos son los siguientes:
94
1.
Enunciado de objetivos, es decir, para qu se busca reusar componentes. Algunos ejemplos son acortar
plazos sin prdida de calidad, permitir mantener la duracin del sprint desarrollando ms puntos de
usuario, bajar costos, etctera.
2.
Eleccin de atributos deseables, donde el equipo discute si vale la pena o no seguir el proceso de reuso, a
partir de los requisitos, el diseo a alodoptar o prexistente, la historia con reuso que tiene el equipo, el
volumen de trabajo en el sprint, y/o cualquier otro adecuado al proyecto.
3.
Identificacin de candidatos, que se realiza automticamente usando el algoritmo neural basado en los
atributos elegidos.
4.
Evaluacin de candidatos, lo que se realizan por pruebas ad-hoc, que son diseadas contra los atributos
elegidos, y la historia de la componente.
Captulo 7
Boria et al.
5.
Anlisis de opciones, esto se realiza siguiendo un mtodo prestablecido que utiliza una matriz de Pugh
como la que ya se vio en el Captulo 4. Una de las opciones es siempre no utilizar una componente para
reusar.
6.
Seleccin de alternativas, tambin siguiendo el mtodo anterior.
7.
Adopcin de componente, si aplica, se realiza el ajuste de la componente, de acuerdo a las necesidades del
equipo. Puede que llegado este punto el resultado de la evaluacin de alternativas con resultado negativo y
se decida no usar ninguna componente.
8.
Evaluacin del resultado, se compara con los objetivos enunciados en el primer paso para continuar
armando la historia de la componente y aadir los conocimientos adquiridos.
Figura 7.2: Anlisis de Opciones sobre Reuso
Asimismo para que una componente pueda integrar la biblioteca de activos de reuso hace falta que primero
sea propuesta como tal por los autores de la misma, aun antes de construirla, porque el desarrollo de una
componente para reuso es diferente del desarrollo normal de cdigo. Los criterios requieren que se aada una
documentacin especial para guiar en el reuso a quienes en el futuro seleccionen la componente, que la prueba
sea exhaustiva y el criterio de aceptacin sea cero defectos, que el diseo y la arquitectura, o arquitecturas con las
que interacta normalmente tambin formen parte de esa documentacin, que debe ser inspeccionada
formalmente. Adems hay un criterio especial para el anlisis esttico del cdigo, que requiere seguir normas
74
75
organizacionales , como la indentacin , los comentarios, los nombres de variable y la documentacin de
cambios en el mismo cdigo. La biblioteca de componentes para reuso tiene su propio mecanismo de gestin de
configuracin, y su propia rastreabilidad entre activos, que es simplemente un subconjunto con restricciones
mayores que las normales, del sistema de gestin de configuracin organizacional para lneas de base. Los usuarios
de este subsistema reciben los informes que se realizan sobre los activos as gestionados.
53. Ana sugiere introducir reuso de componentes como prctica para aumentar la capacidad de los
equipos.
54. Se define y despliega un proceso de creacin, adopcin y mantenimiento de componentes de
reuso con un procedimiento para decidir cuando se reusa una componente y se extiende la gua
de ajuste del proceso para que contenga este criterio.
Gestin de Reutilizacin (GRU)

GRU 1
Una estrategia de gestin de activos es documentada, contemplando la definicin de activo

reutilizable, adems de los criterios para aceptacin, certificacin, clasificacin, discontinuidad y
evaluacin de activos reutilizables
GRU 2
Un mecanismo de almacenamiento y recuperacin de activos reutilizables es implantado
GRU 3
Los datos de utilizacin de activos reutilizables son registrados
GRU 4
Los activos reutilizables son peridicamente mantenidos, segn los criterios definidos, y sus
modificaciones son controladas durante su ciclo de vida
GRU 5
Los usuarios de activos reutilizables son notificados sobre problemas detectados, cambios
realizados, nuevas versiones disponibles y discontinuidad de activos;
Tabla 7.10: Proceso GESTIN DE REUTILIZACIN [SOFTEX, 2012a]
7.5 Utilizando el conocimiento histrico en los proyectos

A partir del nivel E, algunos resultados esperados de los procesos evolucionan y otros nuevos se incorporan.
La gestin de administracin del proyecto se debe ahora realizar a partir de un proceso especialmente definido
para el proyecto, seleccionado en base a activos de la organizacin. Dicho proceso debe contemplar todos los
elementos constitutivos del proyecto desde la construccin de planes integrados a su cierre. Marcela es consciente
de las ventajas que estos cambios arrojan, pero su espritu prctico la obliga a ponerle un marco firme en las
2
necesidades de T .
74
75
En los mtodos giles los equipos escogen las normas que utilizarn, pero al promover una componente a la biblioteca de
componentes para reuso es necesario seguir normas de la organizacin.
Se consigue fcilmente con herramientas de Pretty Printing
Captulo 7
95
Algunas diferencias entre la manera de interpretar, y por lo tanto de ejecutar, ciertos procedimientos, hacen
que Marcela vuelva a la carga sobre su mensaje de uniformidad en la ejecucin. Su argumento es que sin
uniformidad no hay claridad en la interpretacin de los resultados y la capacidad real no puede conocerse.
Asimismo, sostiene que la calidad deviene de la previsibilidad. Su tesis se basa en que calidad no es ni subjetiva ni
76
objetiva, es un atributo de la relacin entre un objeto y el sujeto que evala la calidad . No existe la calidad
absoluta, siempre es calidad para y en un contexto. Por lo mismo, la calidad est ligada a las expectativas de
77
los clientes. En el modelo de Kano se puede ver que hay tres tipos de requisitos: los llamados Indispensables,
tambin llamados bsicos, porque si no se los satisface, el cliente estar sumamente insatisfecho, como por
ejemplo si compra una bicicleta y al entregarla le quitamos las ruedas porque se compran aparte. Hay una
expectativa de que las bicicletas se venden con sus ruedas. Pero, ya que el cliente los percibe indispensables,
cumplir con ellos no incrementa su satisfaccin. Por otra parte, los requisitos lineales son los ms visibles, los ms
usuales. La satisfaccin del cliente es proporcional al grado de satisfaccin de los mismos, mientras ms se cumple
con los objetivos, mayor la satisfaccin del cliente y viceversa. Por ejemplo la capacidad del bal de un automvil,
o la cantidad de kilmetros que se pueden hacer sin repostar en el mismo. A menudo los clientes exigen
explcitamente estos requisitos. Hay una tercera categora llamada por Kano Requisitos Atractivos, tambin
llamados deleites. Son aqullos que el cliente ni espera ni requiere explcitamente (sorpresas positivas). Cubrirlos
lleva a satisfacciones excepcionales pero si no se los cubre no hay sentimiento de insatisfaccin. Un ejemplo puede
constituir un canasto para transportar infantes o una rueda extra al comprar una bicicleta. Lo que se saca en
conclusin del modelo de Kano es que lo que se define por calidad es la percepcin que el cliente tiene, no los
atributos en s. Hay atributos esperados, por supuesto, que marcan el mnimo, pero por encima de esto el contexto
es el que define si hay o no suficiente calidad. La consistencia en las entregas es una calidad evidente del software
para el cliente. Tanto el tiempo como las interfaces como la densidad de defectos tienen que ser del nivel
esperado o el cliente estar insatisfecho. Ese es el argumento de Marcela a favor de la normalizacin y la
consistencia que deviene de ella.
Por lo tanto, en una reunin mensual de anlisis de cartera, levanta la solicitud de discutir varios temas
relacionados. Los gemelos aportan sealando que los equipos no aprenden de su experiencia y sigue habiendo
demasiada diferencia entre el tiempo ideal y el real, lo que trae inconsistencias en cada sprint que resultan
demasiadas para el cliente. Por otra parte, si bien hay una norma sobre los recursos a utilizar por empleado, no
siempre se la sigue. Marcela interviene para apuntar que va a contratar una persona que la ayude en el
aseguramiento de la calidad, de manera permanente, y que desde ahora el proceso del proyecto debe de
estipularse como parte del plan antes de proceder a darle comienzo. Ana pide que se expresen en el proceso con
toda claridad la estructura de decisiones, porque ha visto, en sus recorridas espontneas de los equipos de
proyecto, que las responsabilidades sobre las decisiones pueden demorar el proyecto si no se expresan
correctamente con antelacin. Los gemelos vuelven a intervenir, esta vez para criticar que las retrospectivas no se
guardan con fidelidad: las lecciones "aprendidas" son tan solo lecciones registradas que no se traducen en
experiencia para los proyectos porque no se usa la estructura de palabras clave que permite clasificarlas para su
uso posterior. Cuando la reunin concluye Marcela, que es la encargada de las minutas de la reunin, sale con la
lista de acciones pendientes:
a.
b.
c.
d.
e.
76
77
78
utilizar la historia de los sprints en el juego de planificacin para tener una mejor aproximacin
al esfuerzo real
78
fijar el uso del estndar de recursos necesarios en los planes de proyecto para poder comenzar
su provisin anticipadamente (escritorio, PC, SW, etc.)
establecer normas de comportamiento de los equipos y hacerlas respetar, con las variantes
necesarias
darle a las experiencias el lugar importante que merecen y almacenar juiciosamente los
resultados para aprovecharlos en futuros proyectos
establecer procesos estndar y mecanismos de eleccin entre ellos, con criterios para elegirlos y
adaptarlos.
[PIRSIG, 1974], Zen y el arte del Mantenimiento de la Motocicleta. Puede decirse que es uno de los ensayos ms importantes
y profundos que se hayan escrito sobre la naturaleza y el significado de "calidad" y, definitivamente, un calmante necesario
para las consecuencias de un mundo moderno, patolgicamente obsesionado con la cantidad.
http://kanomodel.com/
De poco vale tener una gua si no se la sigue!
96
Captulo 7
Boria et al.
Marcela sonre, ya muchas de las acciones ya han sido incorporadas en su biblioteca, pero ahora cuenta con
el mandato necesario para que se cumplan. Confa que pronto se materializar el progreso alcanzado en una
evaluacin formal del Nivel E.
Gestin de Proyectos (GPR) a partir del Nivel E
GPR 4
(A partir del nivel E) La planificacin y las estimativas de las tareas del proyecto se hacen con base
en el repositorio de estimativas y en el conjunto de activos de proceso organizacional;
GPR 8
(A partir del nivel E) Los recursos y el entorno de trabajo necesarios para ejecutar los proyectos
son planificados a partir de los entornos estndar de trabajo de la organizacin;
GPR 20
(A partir del nivel E) Equipos involucrados en el proyecto son establecidos y mantenidos a partir de
las reglas y directrices para estructuracin, formacin y actuacin;
GPR 21
(A partir del nivel E) Experiencias relacionadas a los procesos contribuyen para los activos de
proceso organizacional;
GPR 22
(A partir del nivel E) Un proceso definido para el proyecto es establecido de acuerdo con la
estrategia para adaptacin del proceso de la organizacin.
Tabla 7.11: Proceso GESTIN DE PROYECTOS (A partir del nivel E)
[SOFTEX, 2012a]

55. En la reunin mensual de anlisis de cartera se presentan los problemas de desempeo que
2
continan disminuyendo la capacidad de T , como personal sin suficiente idoneidad, equipos
que no aprovechan la historia o las experiencias anteriores, indefinicin en roles en los equipos,
etctera.
56. Marcela queda encargada de transformar la lista de acciones en realidades, parcialmente
implementadas en la BiPro pero todava no desplegada en los proyectos.
2
57. T se encamina a una evaluacin del Nivel E.
Captulo 7
97
CAPTULO 8 - ELIMINANDO LOS DEFECTOS (NIVEL D DE MPS-SW)

Aun antes de que se publique el resultado de la evaluacin de Nivel E, Marcela est tomando acciones para
hacer que los resultados sean lo ms firme posibles, segn su plan. Tras varias entrevistas de trabajo con
potenciales colaboradores, Marcela encuentra una persona que posee las condiciones que est buscando: Un
pasado con experiencia administrativa y contable, una licenciatura en Psicologa Aplicada a la Empresa y un
Diplomado en Diseo Instruccional. Jessica, tal es su nombre, estar a cargo de completar y mejorar el modelo de
2
competencias de T y de perfeccionar la base de conocimientos y su uso por los empleados de la misma. Jessica se
consigue integrar perfectamente con el equipo de conduccin, siendo, como ellos, joven, entusiasta y con mucha
formacin. No pasa mucho tiempo hasta que es invitada a formar parte de las reuniones mensuales de direccin.
8.1 Determinando el Problema
El primer orden del da en esas reuniones, desde que la BiPro y la base de datos estn funcionando en la
empresa, es revisar los nmeros. Mariano prepara un informe sobre los datos de satisfaccin de los clientes y la
correlacin con componentes del producto. Esto se plantea como un indicador de tendencia con dos datos que se
reflejan como series temporales en el grfico: Densidad de Defectos Hallados por el Cliente por Componente, que
es una cantidad que cambia mes a mes, al modificarse el tamao de la componente y los defectos encontrados; y
Porcentaje de Defectos Hallados por el Cliente relacionados con la componente. El primero indica qu tan grande
es la cantidad de defectos inyectados y no detectados antes de enviar el producto al cliente y el segundo cul de
los mdulos es el mayor responsable por ellos. La derivada de la primera serie es el indicador de mejoras o
empeoramiento, mientras que el histograma indica donde buscar los problemas y la serie temporal del mdulo
con peor desempeo indica la magnitud.
De ese modo se puede disear la estrategia para identificar aquellos defectos que vale la pena analizar en la
reunin. Si la variacin es muy grande desde el mes pasado, Marcela toma para s una accin de realizar un anlisis
ms profundo de causa raz con participacin de los expertos en el tema. Si el mdulo responsable acapara
demasiados defectos es posible prever que se lo rehaga.
A partir del anlisis de los defectos encontrados por el cliente y el grado de satisfaccin correspondiente se
79
itera sobre un proceso que Jessica introdujo al grupo, conocido como la hoja de resultados balanceados , de uso
comn en empresas de cierto tamao. Se lo utiliza para asegurar que la organizacin entiende su misin, alinea sus
objetivos con ella y canaliza adecuadamente los recursos y energas para cumplir con sus objetivos. El mtodo
consiste en identificar primero la visin de negocios, el hacia donde queremos ir, para poder encontrar significado
en las actividades. Luego de clarificar la visin, que en el caso de un ejercicio tan frecuente como el que se realiza
2
80
en T es simplemente revisada en cada oportunidad , se analizan los resultados, se fijan objetivos y se discuten las
2
inversiones en diferentes categoras. T ha adoptado como ejes de su anlisis las categoras clsicas: Resultados
Financieros, Satisfaccin del Cliente, Procesos Internos y Conocimiento y Crecimiento del Personal. La Figura
8.1 resume los pasos de su construccin.
79
[Kaplan y Norton, 1996], The Balanced Scorecard: Translating Strategy into Action.
80
98
La visin se expres como Tener un crecimiento sostenible de al menos 15% anual con aumento de los mrgenes
proporcional o mayor cada ao.
Captulo 8
Boria et al.
Figura 8.1: Estructura Tpica de una Hoja de Resultados Balanceados
Para cada una de las categoras listadas se eligen temas que estn alineados con la visin de negocios de la
empresa. Por ejemplo, para que los resultados financieros estn alineados con la visin de crecimiento hay por lo
menos cuatro cosas que pueden hacerse: aumentar las ventas con clientes actuales, (1) vendindoles nuevos
productos o (2) extendiendo las prestaciones, (3) aumentando la cartera de clientes, o (4) subiendo los precios. A
2
su vez, para analizar como estas metas financieras se traducen en metas con los clientes, en T se usan tres temas
para (1) expandir (que ellos compren ms licencias), (2) profundizar (que nos soliciten nuevas prestaciones) o (3)
redefinir relaciones (den mejores referencias de la empresa y se transformen en vas de ventas) con los clientes. En
todo caso se trata siempre de incrementar la satisfaccin de los clientes con los productos.
Est claro que si los objetivos de gestin con el cliente se cumplen tienen un impacto claro en las metas
financieras, pero el anlisis no termina ah: la pregunta que sigue es Qu tenemos que hacer para que estas
metas de buenas relaciones con los clientes se puedan alcanzar, desde el punto de vista de modificar lo que ya
estamos haciendo? Claramente, los procesos que utilizamos impactan en nuestra capacidad. Las dos variables que
ms impactan a los clientes son el plazo de entrega y el nmero de defectos que entregamos. Es necesario
disminuir ambos para aumentar significativamente la satisfaccin, la percepcin del cliente. Si al llevar a cabo
acciones tendientes a esos objetivos podemos alcanzarlos disminuyendo tambin los costos, mejor, porque an si
las ventas no suben mucho, al bajar los costos aumentan los mrgenes. El anlisis se completa con el diagnstico
de los aprendizajes necesarios para que los procesos permitan reducir plazos y defectos para que los clientes
tengan una mejor satisfaccin para que los resultados financieros mejoren. Como todo proceso, requiere que se
ajuste de manera constante el conjunto, porque el aprendizaje, por ejemplo, puede ser demasiado caro o
demasiado largo para que los resultados se puedan traducir en objetivos que tengan un plazo razonable.
Los datos recogidos permiten tambin realizar un anlisis objetivo de los resultados. Comparando la densidad
2
81
2
de defectos producida por los equipos de T con las medias histricas en la literatura la conduccin de T est
incmoda con los resultados: Quiere que los defectos bajen. Uno de los problemas detectados por las
retrospectivas es que pese a la BiPro hay poca preparacin tcnica. La BiPro ayuda mucho cuando la tarea es de
81
Capers Jones, [JONES, C., 1986], Programming Productivity
Captulo 8
99
gestin o de apoyo, pero las tcnicas de ingeniera de software, pese a que los ingenieros se han comenzado a
agrupar en disciplinas, todava son primitivas. La programacin no es el problema, puesto que el Politcnico (como
tantas buenas universidades) se encarga con creces de generar buenos programadores, pero las disciplinas
colindantes, como la definicin y anlisis de requisitos, el diseo a todo nivel y la ingeniera de pruebas dejan
mucho que desear. La falta de un taller de trabajo en esas capacidades es notoria.
82
58. Jessica se incorpora al equipo de Marcela e introduce BSC en las reuniones mensuales.
59. En un anlisis balanceado de los defectos se detectan demasiada densidad de defectos en el
producto, obstaculizando el logro de los objetivos financieros.
60. El uso del material generado en las retrospectivas de los equipos permite identificar una serie
de problemas relacionados.
8.2 Bsqueda de la Solucin
2
La solucin pudiera ser armar un mtodo propio y ajustado a las necesidades de negocios especficas de T ,
pero tanto Ana como Marcela son partidarias de una respuesta que les permita crecer en nmero de empleados
seleccionando personal ya pre-capacitado en la parte tcnica. Por lo tanto esa respuesta es descartada.
Consultados los gemelos, sin pensarlo siquiera sugieren la capacitacin integral en XP: Programacin entre dos,
desarrollo guiado por pruebas (Test driven development o TDD), Diseo incremental, integracin continua,
pertenencia colectiva del cdigo, conocimiento compartido, estndares de codificacin, paso sostenible y trabajo
energizado, adems de las prcticas comunes con Scrum, como los sprint y el juego de la planificacin. Ustedes
pueden imaginrselos hablando a la vez y terminando las frases uno del otro. En esas partes donde difieren Scrum
y XP, como la participacin del usuario en el equipo, obligada en esta ltima y desechada en Scrum, los gemelos
prefieren mantener las tcnicas del primero. Para Ana XP es una posibilidad, pero no la nica. Propone identificar
muchos mtodos y compararlos entre s, siguiendo el esquema de anlisis que se usa ya normalmente en la
empresa.
Aun cuando est de acuerdo en principio, a esta altura de su trayectoria a Marcela se le hace necesario
entender lo que anda mal y qu es lo que se quiere corregir antes de tan siquiera empezar a decidir. Para eso
cuenta con una fuente invalorable de experiencias: la base de conocimiento construida a partir de las reuniones de
retrospectiva. De ah surgen mltiples temas que se le aparecen a los equipos como problemas o riesgos de los
proyectos relacionados con su quehacer tcnico. Marcela convence a los cuatro a realizar un anlisis de los
mismos.
Entre ella, Ana y los gemelos van leyendo los problemas detectados y copindolos a una hoja autoadhesiva. Si
encuentran dos problemas con enunciados muy parecidos se los pega uno sobre el otro. Cuando todos los
problemas han sido reunidos en la pizarra los participantes intentan agruparlos en clases de semejanza. Por
ejemplo, al enunciado la falta de cobertura en la definicin de criterios nos ha llevado a tomar decisiones errneas
sobre la calidad del producto demostrada por la densidad de errores en pruebas es agrupado con no siempre la
densidad de defectos que calculamos est basada en datos crebles y al hacerlo se los coloca a ambos bajo el ttulo
Problemas en Pruebas. Al finalizar quedaron cinco clases. La primera se intitula Problemas de Requisitos y se
83
listan los problemas con la mitigacin o solucin a la derecha del mismo en la Tabla 8.1, de ese nombre .
82
83
riesgo o problema:
mitigacin:
los clientes nos dan informacin incompleta sobre las

necesidades y requerimientos del producto dando
lugar a mucho retrabajo
se sigue un proceso sistemtico para la

identificacin de lo que el cliente necesita para
que tenga lo que quiere segn lo que dice
la especificacin de un mdulo, componente o sistema

es a veces incompleta, resultando en un producto subptimo
se construye un documento que permite priorizar

los requisitos y especificarlos de modo que su
revisin y anlisis sea posible
Balance Score Card

Las otras cuatro se denominan Problemas de Diseo, Problemas de Integracin, Problemas de Verificacin y Problemas
de Validacin. En el contexto del modelo MPS SW la diferencia entre verificacin y validacin es clara: la verificacin es
relativa a los requerimientos, se verifica cuando se compara un producto, final o intermedio, contra los requerimientos de
los cules deriva, tomando en cuenta su completitud respecto de los mismos y su consistencia intrnseca.
100
Captulo 8
Boria et al.
riesgo o problema:
mitigacin:
suelen quedar funciones sin especificar y los requisitos

no funcionales son demasiado frecuentemente
aadidos hacia el final del proyecto resultando en
mucho retrabajo
hay mucho impacto en los compromisos por la
cantidad de requisitos derivados que surgen despus
del juego de planificacin
la especificacin de los requisitos debe permitir

identificar funciones as como los atributos de
calidad no funcionales del producto
la integracin continua fracasa ms de lo necesario

porque no hay una clara definicin de las interfaces
parte de la especificacin debe dirigirse

expresamente al entorno de funcionamiento del
producto, sean interfaces internas o externas
se malinterpretan las funciones pedidas porque no

hay un contexto donde situarlas, resultando en
demostraciones fallidas
hay cierto apresuramiento en pasar a la estimacin sin

hacer un anlisis ms profundo de la funcionalidad
que se implementa, resultando en oportunidades
perdidas e ineficiencias
aun en aquellos casos en los que se construyen
modelos del producto estos son pocas veces
discutidos con el dueo del producto
como parte del mecanismo de entendimiento de

los requerimientos es necesario construir historias
de usuario, narrativas y/o casos de uso que
expliquen el uso esperado del producto
la seleccin de procesos en un sprint se basa en el
anlisis de requisitos y necesidades del cliente
balanceadas contra las restricciones de capacidad
del equipo
durante el juego de planificacin los requisitos
menos comunes sern validados usando modelos y
los casos de uso o historias de usuario
antes de encarar un sprint se deben definir los

detalles de la porcin de funcionalidad que se va a
incluir
Tabla 8.1: Problemas de Requisitos
Este es el punto de partida de la futura tabla de decisiones. La columna de la derecha, mitigacin:, da la

definicin de atributos deseables de la solucin. Cuando se compara contra las prcticas de eXtreme Programming
queda claro que no hay una correspondencia, salvo con la presencia de tiempo completo del usuario en el medio
del equipo, que podra ayudar, pero que tambin podra hacer las cosas ms difciles: Un usuario que disponga de
8 horas diarias para trabajar en desarrollo de software posiblemente no tenga mucho poder de decisin en la
empresa que representa, haciendo ms compleja la elaboracin de los requisitos.
Los gemelos se quedan un poco frustrados, pero las reuniones de retrospectiva no mienten; tal es la densidad
de los problemas derivados de la mala elaboracin de requerimientos que finalmente los dos se resignan a
expandir el horizonte de las prcticas aplicables por los equipos de desarrollo (sobre todo) y mantenimiento. Sin
renunciar a XP es necesario adquirir tcnicas que enfoquen en la primera parte del proceso de elaboracin del
producto, la captura y elaboracin de las especificaciones tcnicas.
8.3 Corrigiendo los Procesos de Requerimientos
Como respuesta, Marcela y Ana sugieren volver a herramientas que resultan siempre tiles cuando se trata
de analizar requerimientos, herramientas que se conocen como mtodos de creacin de modelos. Los gemelos
no quieren creer lo que estn oyendo, pero prestan atencin de todas maneras: En su mundo, modelar no es
tarea de programadores! Marcela explica las bases de construccin de modelos, haciendo una breve resea de A
84
System Modeling Language, ASML , que luego se conoci como Yourdon Software Development Methodology
(YSDM). Lo que rescata Marcela es que se reconocen ms fcilmente las caractersticas a implementar de un
85
sistema si se construye un modelo del mismo, puesto que ese modelo obra como objeto de frontera entre el
cliente y el ingeniero de software. El modelo, entonces, es factible de anlisis tanto por los usuarios como por los
tcnicos. Una simple narrativa o caso de uso a secas puede ser malinterpretado sin que las diferencias se detecten
porque el lenguaje natural es demasiado ambiguo. Un Diagrama de Contexto (ver Figura 8.2), en cambio, no. Es
posible hacer un diagrama muy sencillo que describa los actores involucrados en el entorno del sistema y los
estmulos (flujos de entrada) a los que el sistema tiene que dar una respuesta automtica (flujos de salida). Esta
simple estructura tiene la excelente propiedad de poder ser ejecutada con usuarios para detectar diferencias de
opinin. Como ejemplo, Marcela realiza en pocos trazos el diagrama de la Figura 8.2 y lo narra, mostrando como
el sistema interacta con clientes, propietarios y administrador en un sistema de mediacin de propiedades para
84
85
[WARD, P., e MELLOR, S., 1986], Structured Development for Real-Time Systems, Volume I: Introduction and Tools
Un objeto de frontera se define como una entidad que tiene uso plstico, que vara de una comunidad a la otra. De ese
modo su interpretacin permite detectar discrepancias entre las comunidades.
Captulo 8
101
alquilar o vender. El Propietario se registra con sus datos catastrales y registra sus inmuebles. El sistema comunica
al administrador cada solicitud de registro (pide autorizacin para registrar un inmueble) al Administrador, quin
revisa y autoriza o no ese inmueble. Un Cliente se registra interactivamente y busca un inmueble en el sistema. El
sistema recibe sus ofertas y as sucesivamente. Los gemelos no estn convencidos, ya no hay en el mercado quin
maneje ASML o anlisis estructurado.
Las mujeres les recuerdan que ASML es el antecesor directo de UML, y que UML s se ensea en las
Universidades. Ana toma entonces el liderazgo de la reunin y comienza a explicar su experiencia en las ctedras
de Arquitectura y Diseo con lo que se conoce como FDD, pero haciendo nfasis en una de sus componentes, Java
86
87
Modeling in Color (JMC). En JMC se utiliza notacin de UML , una norma de expresin de modelos que
evolucion de los viejos lenguajes y que continua siendo soportada por herramientas y bibliografa, a la que en
JMC se le aplican profusamente patrones, que los autores han denominado arquetipos, que no se deben
confundir con los estereotipos de UML.
Figura 8.2: Diagrama de Contexto de un Sistema
En JMC las clases de UML se pintan de diferentes colores para expresar ms claramente su funcin. Las
rosas se llaman <<intervalo o evento>>; representan eventos o actividades para las que tenemos que realizar un
seguimiento por razones de negocios o jurdicas en el sistema a desarrollar. Si tomamos como un caso ilustrativo
una empresa de bienes races, ejemplos de clases de color rosa son Venta y Alquiler. Siempre las clases rosas son
las ms importantes, porque si no hubiera transiciones y eventos no habra necesidad de historia, luego no habra
necesidad de sistemas de informacin.
Figura 8.3: Diagrama de Clase de Acuerdo
Una clase se pinta de color verde si denota una <<entidad>> y se clasifican adems en <<grupo>>
(generalmente una persona u organizacin), <<lugar>> (el lugar donde el evento o actividad se produce), y
<<cosa>> (los objetos del mundo real que participan en el evento o actividad). Ejemplos para nuestro caso son
Persona (que pueden ser ms de uno), e Inmueble.
86
87
[COAD, P. et al, 1999], Java Modeling In Color With UML: Enterprise Components and Process. Actualmente se modific el
nombre a Visual Paradigm, abreviado VP UML.
[FOWLER, M., 2003], UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)
102
Captulo 8
Boria et al.
Las clases amarillas denotan <<roles>> y representan una forma de participar en un evento o actividad por
una clase de entidad verde. Ejemplos de clases amarillas son Comprador, Vendedor y AgenteDeVentas.
El cuarto arquetipo es el azul, denominado <<descripcin-como-entrada-de- catlogo>> (Descripcin para
abreviar), y representa la diferencia entre algo como un departamento en un edificio de varios pisos y la
descripcin del tipo de departamento en el catlogo de ventas. La descripcin es la clase azul, que contiene una
serie de valores e intervalos de valores que pueden tomar para todos los departamentos de ese tipo; cada
departamento individual fsico est representado por una clase verde <<entidad>>.
En estas clases no importa tanto la precisin con la que se pueden instanciar porque su papel es permitir
identificar clases faltantes y ayudar a realizar el anlisis dinmico del modelo. Las clases que pertenecen a una
clase arquetipo particular tienen ms o menos el mismo tipo de atributos y operaciones, pero no tienen que ser
iguales. Estas clases particulares de arquetipos tambin tienden a interactuar con las clases de otros arquetipos en
formas generalmente predecibles. Estos patrones de caractersticas y comportamiento nos pueden ayudar a
construir rpidamente modelos de objetos que resultan muy slidos y son fcilmente extensibles, al identificar
rpidamente atributos y operaciones que de otro modo podran perderse, y nos dar mayor confianza en la
estructura de nuestro cdigo.
Notablemente, un modelo dinmico, tal como un diagrama de transicin de estados, se puede deducir de la
estructura. Por ejemplo, dado un Acuerdo de Alquiler se comenzara con una bsqueda del identificador nico del
mismo para acceder al Cliente y a travs de l a datos de domicilio legal. Esta secuencia se repite si el objeto de la
bsqueda es un Libro prestado a un Lector en una biblioteca, para averiguar donde vive. Esta caracterstica de los
modelos UML en color hacen que la investigacin sea mucho ms sistemtica y hasta una persona sin
conocimiento del dominio sea capaz de conducir entrevistas productivas con usuarios. Los arquetipos se combinan
88
entre s de manera natural, que los autores de JMC llaman componentes independientes del dominio . La Figura
8.4 muestra una componente de este tipo. Como dijramos, la caracterstica de estas componentes
independientes es que tienen una dinmica implcita. Esta dinmica implcita se puede traducir de modo
semiautomtico en un diagrama de transicin de estados que muestra explcitamente las conexiones dinmicas
entre las clases para el caso en que, por ejemplo, quisieramos contabilizar transacciones de un cliente.
Figura 8.4: Diagrama de Clases de Acuerdo
La ventaja de contar con una arquitectura prefabricada es evidente para Ana y Marcela, sumando a esto el
hecho de que muchas herramientas soportan el diseo de diagramas UML, y que las universidades preparan
personal con este conocimiento, no necesitan ms pruebas.
Los gemelos solo estn convencidos a medias y piden tiempo para leer ms sobre el tema. Sugieren que
mientras tanto un mtodo sistemtico de diseo de las pruebas que incluya la redaccin de caos de uso sera
suficiente para muchos de los riesgos. Han estado siguiendo las ideas de Richard Denney desde su primera
88
Domain Neutral Components, traduccin de los autores.
Captulo 8
103
89
90
publicacin en StickyMinds , y encuentran su ltimo libro sumamente til. Presentan entonces una propuesta
alternativa: Usar historias de usuario para mantenerse dentro de eXtreme Programming, elaborar con ellas un
91
diagrama de casos de uso, identificar casos faltantes usando una matriz CRUD , y desenvolver un perfil de
92
operaciones siguiendo las tcnicas del libro de Denney y para aquellos casos que lo ameriten , desarrollar casos
93
de uso completos siguiendo los parmetros del libro de Allistair Cockburn . Se puede as certificar que todas las
entidades necesarias estn siendo consideradas en los requisitos. Para asegurar que la transicin desde los
requerimientos al cdigo se realiza fluidamente, se utiliza el Desarrollo Basado en Pruebas (Test Driven
94
Development o TDD ). De ese modo, opinan, solucionarn la mayora de los problemas sin modificar demasiado el
tratamiento actual de los requerimientos.
2
Como T es una organizacin que ha madurado mucho, las opiniones no se discuten sino que son sometidas a
anlisis y comparaciones. Los cuatro arman una matriz de Pugh que cruza los problemas con las soluciones. En la
interseccin de cada fila (problemas) y cada columna (soluciones) se coloca una letra que indica la contribucin de
la columna para esa solucin. Por ahora basta con categorizarlas como A (alto), M (medio) o B (bajo). Si no hay
ningn impacto de la solucin en el problema, se deja la celda en blanco.
Las dos soluciones se colocan en las filas: Modelado en Color con UML y XP ampliado con mejor diseo de
pruebas. La Tabla 8.2, Comparacin entre Mtodos de Desarrollo por su beneficio, muestra los resultados segn
los entiende el equipo de anlisis. De la matriz queda claro que ambos enfoques son bastante poderosos pero
ninguno es completo. Hay elementos de proceso que aadir en todos los casos y es poca la ventaja que tiene un
mtodo sobre el otro. Dada la paridad, el equipo decide incorporar un anlisis ms, esta vez basndose en la curva
de aprendizaje y el riesgo de la adopcin.
riesgo:
los clientes nos dan informacin
incompleta sobre las necesidades y
requerimientos del producto dando
lugar a mucho retrabajo
informacin incompleta sobre
necesidades y requerimientos
especificaciones incompletas
mitigacin:
identificacin de lo que el cliente necesita
para que tenga lo que quiere segn lo que
dice
proceso sistemtico de identificacin
JMC
XP + TST
documento donde priorizar requisitos y

especificarlos
identificar funciones as como atributos
de calidad
definir detalles de la porcin de
funcionalidad en el sprint
especificar interfaces internas y externas
construir historias de usuario, narrativas
y/o casos de uso
balancear requisitos y necesidades del
cliente contra restricciones del equipo
funciones y requisitos no funcionales

B
sin especificar
demasiados requisitos derivados
M
despus del juego de planificacin
no hay clara definicin de las interfaces
A
no hay contexto donde situar las
A
especificaciones
se pasa a la estimacin sin hacer un
M
anlisis ms profundo de la
funcionalidad
los modelos no son discutidos con el
validar requisitos menos comunes
A
dueo del producto
temprano
Tabla 8.2: Comparacin entre Mtodos de Desarrollo por su Beneficio
89
90
91
92
93
94
M
M
A
A
A
http://www.stickyminds.com/
[DENNEY, R., 2012], Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test
Design.
CRUD es la secuencia de iniciales de las palabras inglesas CREATE, READ, UPDATE, DELETE. Estas actividades surgen del uso
tpico de un sistema de informacin y la falta de una de esas funciones sugiere una especificacin incompleta, siendo la ms
frecuente falta la de las eliminaciones de registros que ya no se necesitan.
Siguiendo a Denney, los casos que tengan mayor frecuencia de uso se desarrollan primero.
[COCKBURN, A., 2000], Writing Effective Use Cases.
Fundamental en XP, el TDD se basa en un ciclo corto de repeticiones: primero el desarrollador escribe un caso de prueba
automatizado que define una mejora deseada o nuevas funcionalidades. El cdigo sin modificar tiene que hacer que esa
prueba falle, sino se la rehace. El nuevo cdigo que se produce puede entonces ser validado por verificacin a travs de la
nueva prueba. Si hiciera falta reacomodar el cdigo para que cumpla con normas de legibilidad o semejantes, se lo redisea
usando Refactoreo y Smells.
104
Captulo 8
Boria et al.
JMC
XP + TST
curva de aprendizaje
riesgo de adopcin
Tabla 8.3: Comparacin entre Mtodos de Desarrollo por el Riesgo
Pese a que es un poco mejor usar UML con las extensiones de modelado en color, es mucho ms sencillo
continuar como hasta ahora con el agregado de los casos de uso y las tcnicas propuestas por Denney.
Rendidas ante la evidencia, Ana y Marcela se ponen a trabajar con los gemelos en la mejora, resumiendo las
tcnicas en un proceso (ver Figura 8.5).
Figura 8.5: Proceso de Captura de Requerimientos
Algunos procedimientos del proceso anterior son expandidos para que puedan ser ejecutados de manera
similar en todos los casos. Por ejemplo, para definir historias de usuario se agregan pasos que profundizan en la
funcionalidad en el juego de planificacin, en particular durante la discusin con el Dueo del Producto. El Dueo
del Producto participa activamente en la creacin de estas historias.
Una historia de usuario es una o ms frases en el lenguaje cotidiano del usuario final, que capta lo que hace o
precisa hacer como parte de su funcin. Captura 'quin', 'qu' y 'porqu' de un requisito, de una forma simple y
concisa, muchas veces limitada en detalles que pueden ser manuscritas en una servilleta de papel. Por ejemplo,
Un cliente se registra en el sistema para buscar inmuebles para alquilar o comprar. Las historias de usuario son la
principal forma de influenciar la funcionalidad del sistema a ser desarrollado. Pueden ser tambin escritas por los
mismos ingenieros de desarrollo para expresar requisitos no funcionales (seguridad, calidad, desempeo, etc.) o
requisitos derivados, por ejemplo aquellos que se omitieron en la definicin del Backlog del sprint porque se
dieron por sentados como obvios (una verificacin de saldos en una cuenta, la existencia del cliente en un
repositorio, etc.). Las historias de usuario se traducen en casos de uso a nivel del diagrama de casos de uso.
Figura 8.6: Resultado de los Pasos 1 y 2
Captulo 8
105
Segn el nuevo proceso, el prximo paso es generar el diagrama de casos de uso con los actores como ilustra
la Figura 8.7.
Figura 8.7: Diagrama de Arquitectura
Segn Denney uno se asegura ahora que no haya ms casos de uso que estn faltando. Se listan primero los
casos de uso: Registrarse; Buscar inmueble; Ofertar Alquilar; Ofertar Comprar; Cerrar Acuerdo; Ingresar Inmueble;
Rechazar oferta; Realizar contraoferta; Aceptar oferta; Autenticar propietario; Eliminar propietario.
Propietario
Aceptar oferta
Realizar contraoferta
Rechazar oferta
Ingresar Inmueble
Cerrar Acuerdo
Ofertar Comprar
U
R
Inmueble
Acuerdo de Alquiler
Acuerdo de Compra
Oferta
Eliminar propietario
Autenticar propietario
Cliente
Ofertar Alquilar
CLASES................................
Buscar inmueble
CASOS DE USO
Registrarse
Luego se listan las clases que surgen de los casos de uso y se analizan para constatar si las cuatro funciones
CRUD estn definidas para cada una de ellas. Para continuar con el ejemplo propuesto, tomando el primero de los
casos de uso, Registrarse, siendo que tanto el actor Cliente y el Propietario utilizan ese caso de uso es razonable
suponer que tendremos clases para cada uno. Se ingresan en la lista de Clases. En el orden de los casos de uso,
sigue Buscar Inmueble; Inmueble va a la lista. As siguiendo las clases que tiene la lista son: A: Cliente; B:
Propietario; C: Inmueble; D: Acuerdo de Alquiler; E: Acuerdo de Compra; F: Oferta. Nuestra matriz ahora tiene
Actores en la primera columna y casos de uso en cada una de las siguientes. El resultado es la Tabla 8.4.
Tabla 8.4: Matriz CRUD sin Completar
La matriz se completa colocando en la interseccin de cada fila y columna una C, R, U o D segn el caso de
uso de la columna cree, lea, actualice o elimine un objeto de la clase de la fila. La matriz as completada se ve en la
Tabla 8.5.
106
Captulo 8
Propietario
Aceptar oferta
Rechazar oferta
Ingresar Inmueble
Cerrar Acuerdo
Ofertar Comprar
Cliente
Ofertar Alquilar
CLASES................................
Registrarse
CASOS DE USO
Buscar inmueble
Boria et al.
U
R
Inmueble
Acuerdo de Alquiler
Acuerdo de Compra
Oferta
Tabla 8.5: Matriz CRUD ya Completada
Todas las clases tienen al menos un caso de uso que crea objetos de su clase. Los casos de uso Aceptar Oferta
y Cerrar Acuerdo se ven sospechosamente idnticos. Quizs se trata de un requerimiento redundante, habr que
desglosarlo en detalle con el Dueo del Producto. La gran cantidad de espacios en blanco sugiere que debemos
analizar con el Dueo del Producto las reglas del negocio ms profundamente. Por ejemplo, si la creacin de un
acuerdo actualiza los objetos que se relacionan con l, el cliente y el propietario adems del inmueble. Parece
lgico que as sea y deberamos confirmarlo. Esto nos lleva a pensar que el objeto Oferta crea similares relaciones,
aun no marcadas en la matriz. Por otra parte, no hay casos de uso que actualicen o eliminen objetos de la clase
Cliente, de modo que una vez creado el objeto es persistente y totalmente inerte. Objetos con esas caractersticas
son poco tiles en general. Luego, en un caso real, preguntaramos si existen reglas de negocio que nos dicen que
hacer con un Cliente, como se actualiza su informacin y como, si acaso, se lo da de baja del sistema.
Anlogamente, nos falta informacin sobre inmuebles y acuerdos, que parecen ser modificados una nica
vez. Seguramente los acuerdos se renuevan o vencen, los inmuebles pueden salir del sistema. Incluso nos
preguntamos si al dar de baja a un Propietario no corresponde dar de baja a los objetos relacionados con l o ella.
Nuestro conocimiento del sistema, tan completo como pareca cuando mirbamos la Figura 8.7, ahora nos parece
demasiado sumario. Con un mtodo simple pero exhaustivo podemos asegurar que identificamos casos de uso
faltantes o redundantes y reglas de negocio incompletas.
8.4 Perfil Operativo
Describiremos ahora el paso siguiente, construir el primer nivel del perfil operativo, que refinaremos luego
para cada caso de uso en su momento. El propsito de esta actividad es evitar detallar casos de uso que son poco
95
frecuentes y que por lo tanto conllevan poco riesgo. En las palabras de Denney , es mejor tener una estrategia
para utilizar el tiempo sabiamente, y saber cuales tcnicas funcionan mejor (o no) en diferentes problemas.
Para simplificar, supongamos que hemos consultado con el cliente las reglas de negocio y este nos ha dicho
que por ahora solo quiere incluir dos casos de uso ms, Limpiar Datos, que tendr en cuenta eliminaciones de
objetos que caducaron, y Actualizar Datos, que usarn Cliente y Propietario para renovar sus identificaciones. Para
construir nuestro perfil de uso debemos entender la frecuencia de uso de cada caso de uso por cada uno de los
actores. Obviamente, si se trata de un producto existente investigaremos el comportamiento actual y lo
ajustaremos a los deseos o necesidades futuras del cliente. Si el sistema es nuevo deberemos utilizar la visin del
Dueo del Producto para conseguir los datos.
Nuestra matriz tiene ahora Actores en la primera columna y casos de uso en cada una de las siguientes, pero
se ha agregado una columna que identifica la cantidad de actores esperadas de cada uno de los tipos. Por ejemplo,
hay un solo Administrador, pero si el sistema es nuevo la cantidad de usuarios de los otros dos tipos es
96
desconocida. Segn Denney , la precisin es despreciable en este momento, basta con conocer un orden de
95
96
Use Case Level of Test, op.cit., pgina 6.

Use Case Level of Test, op.cit., pginas 40 y 41.
Captulo 8
107
magnitud relativo. Es importante reconocer que los rdenes de magnitud son suficientes para identificar perfiles
de uso. En nuestro caso diremos que hay mil Propietarios por cada administrador y diez Clientes por cada
Propietario en el sistema.
Ahora hay que cuantificar el uso de los casos de uso por los actores. Primero elegimos (nfasis en elegir) un
intervalo de tiempo conveniente. Puede ser un segundo, un minuto, o un ao. Lo importante es que sirva para
estimar nmeros razonables. En nuestro caso digamos que se cuenta con estimados mensuales para cada actor, de
97
modo que el intervalo elegido es el mes. En la matriz que estamos generando (llamada QFD por Denney, dada la
similitud existente entre su matriz de cuantificacin de perfil con la usada por el mtodo de ese nombre) se ingresa
en cada celda el estimado de frecuencia de uso mensual del caso de uso (columna) por el Actor (fila). Este nmero
es un nmero real positivo que se omite cuando la frecuencia es exactamente 0. Por ejemplo, se ha estimado de
un estudio de mercado realizado por la empresa cliente, que ingresarn 59 Propietarios por mes que en total
(nuevos y ya registrados) darn de alta un promedio de 0.27 propiedades cada uno por mes, tomando datos de
publicaciones de avisos de alquiler en la red y otros medios (avisos clasificados de los diarios). Siguiendo con las
estimaciones de modo parecido al modelo de tomar como referencia rdenes de magnitud el resultado es el de la
Tabla 8.6, Estimaciones de Actividad.
por mes
600
59
clientes nuevos
propietarios nuevos
63.13
inmuebles nuevos
4000
bsquedas compra
8500
bsquedas alquiler
1000
oferta compra
3000
oferta alquiler
80
contraoferta compra
12
contraoferta alquiler
2
3830
59
0.01
rechazos
acuerdos cerrados
autenticaciones de propietario
eliminar propietario
Tabla 8.6: Estimaciones de Actividad
ranking
porcentaje de
esfuerzo
659
18%
20%
0.125
1250
34%
38%
0.03
300
8%
9%
Propietario
peso relativo
Registrarse
0.06
0.059
Buscar inmueble
Ofertar Alquilar
ACTORES
CASOS DE USO................................
97
1000
ejecuciones por mes
10000
Cliente
Cantidad
Administrador
Con esas estimaciones, la matriz de QFD queda con los datos siguientes:
Despliegue de la funcin calidad (QFD) es un mtodo de gestin de calidad basado en transformar las demandas del usuario
en la calidad del diseo, implementar las funciones que aporten ms calidad, e implementar mtodos para lograr calidad
del diseo en subsistemas y componentes, y en ltima instancia a los elementos especficos del proceso de fabricacin.
http://es.wikipedia.org/wiki/QFD (N.A.: la redaccin de esta pgina indica su origen en alguna traduccin automtica, lo
que la hace de bajo valor esttico, pero es todava legible).
108
Captulo 8
766
21%
0.06313
63.13
2%
Rechazar oferta
0.002
0%
0.02
Ofertar Comprar
0.01
Cerrar Acuerdo
0.0383
Ingresar Inmueble
20
1%
59
59
2%
0%
Limpiar Datos
110
110
3%
Actualizar Datos
330
330
9%
porcentaje de
esfuerzo
3%
CASOS DE USO................................
Cliente
100
0.383
ACTORES
ranking
peso relativo
1000
ejecuciones por mes
10000
Administrador
Cantidad
Propietario
Boria et al.
23%
10%
Tabla 8.7: Perfil Operativo de los Casos de Uso
Los valores en cada celda surgen de dividir los datos correspondientes a cada caso de uso por la multiplicidad
correspondiente del actor que lo ejecuta. Por ejemplo, si hay cien ofertas de compra al mes y son diez mil los
actores, cada uno de ellos ejecuta 0.01 veces el caso de uso correspondiente. Las ejecuciones por mes resultan de
sumar los productos de ese nmero por dicha multiplicidad. Por ejemplo, si hay 0.06 ejecuciones de Registrarse de
parte de Clientes y 0.059 ejecuciones del mismo caso por parte de Propietarios, el producto de 0.06 x 10000
sumado al producto de 0.059 por 1000 da 659. Sumando todas las ejecuciones el resultado es 3660, que usado
como divisor de los nmeros anteriores da el porcentaje que corresponde a cada uno. As 1250 dividido 3660 da
aproximadamente 34%, que es el caso de uso de ms alto ranking. Descartando los casos de uso de baja
frecuencia, se recalcula el peso relativo entre los restantes. Ese nuevo peso sirve para usar de proporcin para
multiplicarlo por el esfuerzo esperado y obtener como calcular la dedicacin a cada caso de uso.
Dados los nmeros as calculados, tiene sentido invertir en los casos de uso que ocupan los primeros 4
lugares porque en conjunto representan el 82% del uso del sistema. Los 5 primeros suman 90%, mientras que los 3
primeros suman 73%. Cualquiera sea la eleccin, el mtodo es claro: se elijen para ser detallados los casos de uso
que ms peso tienen en trminos de utilizacin por los usuarios. La excepcin o excepciones pueden provenir del
riesgo que plantean algunos casos de uso en particular, por ejemplo puede que el caso de uso Autenticar
Propietario sea muy importante en trminos del negocio, de modo que pese a su relativo bajo peso se lo considere
para detallar de todos modos.
8.5 Detallando Un Caso
Cada caso de uso debe describir cmo se utiliza el sistema en un aspecto nico del negocio, es decir describe
desde un punto de vista del usuario el comportamiento del sistema cuando este ayuda a un usuario a alcanzar un
objetivo de negocios con l. Para la mayora de proyectos de software, esto significa que quizs a veces es
necesario especificar centenares de casos de uso para definir completamente el nuevo sistema. Los proyectos
giles, con su definicin de sashimi para cada sprint no necesitan tantos. Si adems se seleccionan, como vimos
en la seccin anterior, aquellos que son ms representativos, el resultado es manejable por el equipo en pocas
horas.
Un caso de uso contiene una descripcin textual de todas las maneras que los actores que se espera lo
ejecuten interactan con el sistema. Los casos de uso no describen funcionalidad interna del sistema, ni exponen
cmo se implementar, en cambio muestran los pasos de la interaccin del sistema con el actor. Para ser til, un
caso de uso debe describir una nica tarea del negocio que sirva a un objetivo de negocio, porque si tiene muchos
objetivos el resultado es un producto muy complejo; tener un nivel apropiado del detalle, ni demasiado detallado
ni demasiado simple; y ser bastante sencillo como que un desarrollador lo elabore en un perodo corto. Para evitar
escribir largos casos de uso, hay objetivos y sub-objetivos, de modo que un caso de uso extiende otro caso de uso,
o un caso de uso puede invocar a otro caso de uso. El detallado de cada caso seleccionado implica seguir ciertas
convenciones para evitar tener un conjunto de casos de uso dispares en tamao y extensin y por ende
Captulo 8
109
98
incomparables. En este caso Marcela se inclina por el formato propuesto por Allistair Cockburn en su libro . A
menudo se propone la siguiente estructura en el diseo de casos de uso:
Componentes de un Caso de Uso
Definicin
ID
Segn nomenclador de configuracin
NOMBRE
Descriptivo del caso de uso (CU)
REFERENCIAS CRUZADAS
Otros materiales que se utilizan para entender el CU
CREADO POR
Nombre del Autor
ULTIMA ACTUALIZACION POR
Nombre del Revisor o Actualizador
FECHA DE CREACION
Obvia
FECHA DE ULTIMA ACTUALIZACION
Obvia
ACTORES
Todos los que intervienen, robots incluso
DESCRIPCION
Texto explicativo de alto nivel (opcional)
DETONADOR
Evento que detona el CU
PRE-CONDICION
Estado del sistema que permite ejecutar el CU
POST-CONDICION
Estado del sistema que surge de ejecutar el CU
FLUJO NORMAL
Serie de pasos que se consideran normales
FLUJOS ALTERNATIVOS
Serie de pasos que se consideran especiales
INCLUSIONES
Otros CU que son referenciados por este
FRECUENCIA DE USO
De acuerdo con el perfil operativo
REGLAS DE NEGOCIO
Aquellas que aplican en el CU
REQUERIMIENTOS ESPECIALES
Hardware o ambiente de ejecucin o performance
NOTAS Y ASUNTOS
Comentarios para revisores o futuros usuarios

Tabla 8.8: Componentes Sugeridas de los Casos de Uso
La plantilla anterior es una de muchas variantes. Para ver un ejemplo de los campos de Flujo ver la Tabla 8.15
ms abajo. Posiblemente un caso de uso complejo pueda requerir todos esos campos y algunos ms, por ejemplo a
veces se separan los flujos alternativos en dos categoras, una de ellas dedicadas al tratamiento de excepciones,
como cuando una condicin intermedia no se cumple. Es el caso del flujo que atiende al usuario que se olvid su
clave de acceso en el CU de Ingreso. Otras veces estos casos se derivan a Casos de Uso especialmente diseados e
incluidos. La decisin de que plantilla usar depende exclusivamente de las necesidades de cada situacin, basta
que se utilicen uniformemente los campos para que se puedan revisar.
61. Marcela, Ana, y los gemelos analizan los problemas y los agrupan para buscar soluciones.
62. Haciendo un anlisis de causas profundas se decide incorporar mtodos y tcnicas para el
desarrollo de los requerimientos en el Sprint.
63. Comparando mtodos por su impacto y costo de implementacin se decide utilizar una mezcla
de XP -TDD con tcnicas de desarrollo de casos de prueba propuestas por Denney.
En este punto el proceso de captura de requerimientos ya tiene todas sus componentes descriptas. Los
gemelos los ponen en prctica en los cuatro equipos que dirigen, y al cabo de cuatro sprints, controlando contra
los riesgos detectados se aprecia que se han tomado todos ellos en cuenta.
98
riesgo:
XP + TST

necesidades y requerimientos del producto dando lugar a
mucho retrabajo

identificacin de lo que el cliente necesita para que
tenga lo que quiere segn lo que dice
[COCKBURN, A., 2000], Writing Effective Use Cases.
110
Captulo 8
Boria et al.
riesgo:
XP + TST

necesidades y requerimientos del producto dando lugar a
mucho retrabajo
Se utilizan diagramas de CU y matriz CRUD
la especificacin de un mdulo, componente o sistema es

incompleta resultando en un producto subptimo
Las prioridades se fijan con el DP y se analizan

mediante CU
suelen quedar funciones sin especificar y los requisitos no

funcionales son demasiado frecuentemente aadidos
hacia el final del proyecto resultando en mucho retrabajo
Las planillas de CU identifican funciones y permiten

aadir requisitos no funcionales
hay mucho impacto en los compromisos por la cantidad de

requisitos derivados que surgen despus del juego de
planificacin
El juego de la planificacin pasa a incluir el detalle

de los requisitos
la integracin continua fracasa ms de lo necesario porque

no hay una clara definicin de las interfaces
La plantilla de CU ataca ese punto
se malinterpretan las funciones pedidas porque no hay un

contexto donde situarlas, resultando en demostraciones
fallidas
Los CU cubren este riesgo
hay cierto apresuramiento en pasar a la estimacin sin

hacer un anlisis ms profundo de la funcionalidad que se
implementa, resultando en oportunidades perdidas e
ineficiencias
aun en aquellos casos en los que se construyen modelos
del producto estos son pocas veces discutidos con el
dueo del producto
Los perfiles operativos se ocupan de establecer ese

equilibrio cuando hay presiones de recursos
El juego de la planificacin pasa a incluir el detalle

de los requisitos y su revisin
Tabla 8.9: Lista de Control de Mitigacin de Riesgos en Requisitos
Marcela ha incorporado a los pasos de aprobacin de un procedimiento la creacin de un mapa de los

resultados esperados del MPS que el cambio trae. Esto se realiza sin nimo de completar necesariamente todos los
resultados, sino para entender mejor la brecha entre lo ya implementado y lo que resta para cumplir con los
requisitos de una evaluacin. El resultado se detalla en la Tabla 8.10.
Resultados Esperados de DRE en el MPS
Evidencia de implementacin en Tahini-Tahini
DRE 1 Las necesidades, expectativas y limitaciones del

cliente, tanto del producto como de sus
interfaces, son identificadas
DRE 2 Un conjunto definido de requisitos del cliente es
especificado y priorizado a partir de necesidades,
expectativas y limitaciones identificadas
DRE 3 Un conjunto de requisitos funcionales y nofuncionales, del producto y de las componentes
del producto que describen la solucin del
problema a ser resuelto, es definido y mantenido
a partir de los requisitos del cliente
DRE 4 Los requisitos funcionales y no-funcionales de
cada componente del producto son refinados,
elaborados y asignados
DRE 5 Interfaces internas y externas del producto y de
cada componente del producto son definidas
se sigue un proceso sistemtico para la identificacin

de lo que el cliente necesita para que tenga lo que
quiere segn lo que dice
se construye un documento que permite priorizar los
requisitos y especificarlos de modo que su revisin y
anlisis sea posible
la especificacin de los requisitos debe permitir
identificar funciones as como los atributos de
calidad no funcionales del producto
DRE 6 Conceptos operacionales y escenarios son

desarrollados
Captulo 8
antes de encarar un sprint se deben definir los

detalles de la porcin de funcionalidad que se va a
incluir
parte de la especificacin debe dirigirse
expresamente al entorno de funcionamiento del
producto, sean interfaces internas o externas
como parte del mecanismo de entendimiento de los
requerimientos es necesario construir historias de
usuario, narrativas y/o casos de uso que expliquen el
uso esperado del producto
111
Resultados Esperados de DRE en el MPS
Evidencia de implementacin en Tahini-Tahini
DRE 7 Los requisitos son analizados, usando criterios

definidos, para balancear las necesidades de los
interesados con las restricciones existentes
la seleccin de procesos en un sprint se basa en el

anlisis de requisitos y necesidades del cliente
balanceadas contra las restricciones de capacidad del
equipo
DRE 8 Los requisitos son validados
durante el juego de planificacin los requisitos
menos comunes sern validados usando modelos y
los casos de uso o historias de usuario
Tabla 8.10: Implementacin de DRE en T2

64. Piloteando los procedimientos en cuatro sprints se aprecia que se han controlando todos los
riesgos detectados
65. Marcela constata que los resultados esperados para DRE se han cubierto con la implementacin
de los nuevos procedimientos
8.6 Detectando Defectos en los Productos
Los riesgos controlados por los cambios realizados en el proceso de requerimientos han debido hacer
disminuir la densidad de defectos. En la reunin posterior a los cuatro meses de pilotaje, los nmeros son mixtos.
Si bien se han eliminado los problemas que se inyectan en un sprint que llegan al usuario, los problemas legados
de sprints anteriores a la reforma han comenzado a surgir con fuerza y son el foco de la atencin ahora.
Este fenmeno es frecuente y una de las causas ms habitual de frustracin con la mejora de procesos:
Arreglar un problema hace evidente la existencia de otro que antes, la existencia del primer problema
enmascaraba. El fenmeno, conocido por los diseadores de sistemas operativos, se denomina problema del
embotellamiento, porque se lo ilustra con esta conocida molestia del trnsito. La historia es as: Supongamos que
un punto de un camino produce embotellamientos diarios a un costo anual al pblico de cien mil horas de espera,
sumadas todas las partes involucradas. Digamos que el erario pblico calcula que una hora de espera tiene un
costo social asimilable a cincuenta dlares. Luego el punto en cuestin cuesta a la sociedad cinco millones de
dlares anuales. El estado inicia planes para eliminar el problema que cuestan diez millones de dlares, que una
vez concluidos se espera que lo gastado se repague en dos aos. Una vez entregadas las obras el embotellamiento
no se produce ms en ese punto, pero en un tramo un poco ms abajo en la misma ruta surge uno nuevo, que
antes no se detectaba porque el trnsito no llegaba a ese segundo punto en la densidad suficiente para crear un
embotellamiento. Las horas perdidas son ahora casi las mismas, pero en otro punto.
Este enmascaramiento ocurre en la mejora de procesos tambin. Podemos considerar a un proyecto como
una serie de estaciones unidas por trazados predefinidos (los procesos) que llevan los productos de una a otra. En
cada estacin el producto es transformado (de necesidad del cliente en caso de uso, de caso de uso en cdigo, de
caso de uso en caso de prueba, de cdigo no probado en cdigo probado, y as siguiendo). Si el que brinda el
servicio est ocupado, el producto espera a que se libere. Esto produce colas. Acelerar el servicio en una estacin,
en este caso la deteccin de errores, hace que otra estacin ms hacia la salida tenga ahora una cola de espera.
Vimos el tratamiento que ocurre en Kanban sobre este tema en el Captulo 3, enfocado a liberar el servicio de la
mejor manera posible y cuanto antes. En esta seccin nos limitaremos a mostrar las actividades que hacen falta
para mejorar el servicio que sigue.
En este caso el problema es que se ha eliminado la inyeccin de problemas derivados de requisitos
incompletos, ambiguos o inconsistentes, pero el usuario sigue encontrando defectos porque el producto sigue
mostrando defectos que no fueron detectados en su momento e inyectados en muchos sprint anteriores, puede
2
que hasta aos antes. T se enfrenta al problema de detectarlos antes que el cliente. Revisando las planillas
analizadas en su momento junto con los Problemas de Requisitos, que se conglomeraron en otras cuatro, a saber,
Problemas de Diseo, Problemas de Integracin, Problemas de Verificacin y Problemas de Validacin, los
2
cuatro protagonistas de nuestra historia en T concluyen que hay motivos para seguir modificando lo que hacen.
Primero consideran los problemas de Validacin, porque en el sentido ms estricto afectan al cliente. De las notas
que se tomaron en el anlisis rescatan la Tabla 8.11.
112
Captulo 8
Boria et al.
riesgo o problema:
en ocasiones hemos preparado validaciones con el
cliente que no cumplan las expectativas de lo que
ellos queran ver, por ejemplo omitimos
documentacin, perdiendo credibilidad y tiempo
en ocasiones hemos preparado validaciones que
seguan un orden incorrecto y confundan al cliente,
haciendo que tuvieramos que remontar la
presentacin
a menudo los clientes no comparten nuestros
criterios de calidad, sobre todo cuando los
requisitos han sido disputados varias veces
en ocasiones el producto corre en nuestro
ambiente pero no en el ambiente del cliente
por arreglar con el cliente hemos hecho
correcciones sobre la marcha que no quedan
registradas y sacan de sincronizacin a la lnea de
base
hemos arreglado de ms y de menos en muchas
ocasiones, desperdiciando esfuerzo o perdiendo
calidad
en ocasiones hemos liberado cdigo sin el
suficiente respaldo
mitigacin:
acordar con el cliente y el equipo la estrategia
de validacin, los productos a evaluar, el
cronograma de esta, los criterios de entrada y
aceptacin y los ambientes de aplicacin
reforzar el seguimiento del proceso de

aceptacin del usuario aumentando la
frecuencia de las auditoras y ayudando a
prevenir disconformidades, asegurando que los
criterios de aceptacin se cumplen, basados en
documentacin fehaciente
Tabla 8.11: Problemas de Validacin
Comparando las acciones de mitigacin de esta tabla con las de la Tabla 8.12, Problemas de Verificacin,
Marcela encuentra similitudes que sugieren que la mejora del proceso de ingeniera de pruebas puede atender
tanto Validacin como Verificacin.
riesgo o problema:
si bien el plan de pruebas es comprehensivo, la
inspeccin es selectiva y no hemos siempre elegido
bien los productos o partes de los mismos que se
deben inspeccionar, o sino hemos elegido mtodos
ms dbiles de los que debiramos
no siempre planificamos con la anticipacin
suficiente las actividades de prueba o verificacin y
perdemos participantes importantes
la falta de cobertura en la definicin de criterios
nos ha llevado a tomar decisiones errneas sobre la
calidad del producto demostrada por la densidad
de errores
cuando el sprint se est por acabar se ha cortado
camino saltendose pruebas importantes, como la
de estrs
no siempre la densidad que calculamos est basada
en datos crebles
debiramos poder justificar ante el equipo el
retorno de la inversin que supone verificar usando
inspecciones
mitigacin:
acordar con el equipo la estrategia de
verificacin, los productos a evaluar y con qu
mtodos, el cronograma de las diferentes
evaluaciones, los criterios de entrada,
discontinuacin y aceptacin (garantizando que
la cobertura mnima es uno de ellos) y los
ambientes de prueba cuando aplican
aplicar a rajatabla auditoras de proceso y

producto hasta que se fije la conducta de
prueba sistemtica
automatizar todas las pruebas
los datos obtenidos de las pruebas y las
inspecciones, recorridas y revisiones tcnicas,
deben ser analizados y discutidos en la reunin
mensual de cartera
Tabla 8.12: Problemas de Verificacin
Desde el comienzo Marcela ha dejado claras las diferencias entre Validacin y Verificacin. A pesar de que
hay escuelas opuestas en lo que hace al significado de estos dos trminos, Marcela, siguiendo los consejos de
Captulo 8
113
99
Mximo, utiliza las interpretaciones que de ellos hace Barry Bohm en su obra . Para ellos entonces, verificar es
comparar si lo que se realiza cumple con lo especificado, mientras que validar es garantizar que el producto
satisface las necesidades del cliente.
2
100
Para verificar sus productos, T utiliza mltiples herramientas. Las revisiones , ya sean inspecciones por
101
102
pares, recorridas , revisiones estructuradas o revisiones continuas ; se usan para constatar que el producto
bajo revisin tiene la calidad esperada y es consistente no solo en s mismo sino con los productos que lo
anteceden, fundamentalmente con los requisitos del sistema. Las pruebas de programa se utilizan para provocar
103
cadas o fallas del sistema con el propsito de detectar errores en el producto , pero tambin como herramienta
104
de diseo y gua para la construccin del programa, como ya viramos en el Captulo 3. Desarrollaremos tanto
las revisiones en general como mtodos y tcnicas de prueba de programas.
105
Para validar sus productos T2 hace uso de actividades en las que participa el DP . Al planificar el Sprint el
equipo crea el modelo que representa la funcionalidad deseada y lo ejecuta frente al DP. Esto permite validar la
visin del equipo, en que ha traducido lo que entendi a un objeto de frontera que el DP ha podido interpretar a
su vez, hallando entonces diferencias o hasta clarificando su propia visin. Al finalizar el Sprint el equipo presenta
una demostracin del producto al DP, para constatar que se materializ correctamente la visin compartida. Estas
dos actividades son efectivamente actividades de validacin, apuntan a evaluar la efectividad del producto para el
cliente.
8.7 Procedimientos de Verificacin
Ya hemos cubierto en el Captulo 3 la revisin continua, como programacin por pares o de a dos. Ac
desarrollaremos en detalle los procedimientos de revisin clsicos: la recorrida, la revisin formal estructurada, y
la inspeccin.
Las revisiones son una parte fundamental de toda actividad de creacin de un producto. En particular en la
ingeniera de software son indispensables porque si se posterga la prueba del producto hasta ltimo momento se
pone en peligro la totalidad del proyecto. Vamos a argumentar esto ltimo empezando por una definicin que fue
evolucionando en la dcada del 60 del siglo pasado, por la que el proceso de construccin de un artefacto de
software puede verse como la traduccin de un contenido semntico de una sintaxis a otra, con preservacin de la
semntica y el posible agregado de detalles en cada paso. Por ejemplo, el documento de especificacin mediante
casos de uso se puede ver como un refinamiento del documento de historias de usuario, con una nueva sintaxis (la
del caso de uso) pero preservando el significado (la semntica) del documento anterior. Asimismo el caso de
prueba puede verse como un refinamiento del caso de uso con otras reglas sintcticas, y el cdigo generado como
una nueva iteracin de ese proceso de traducir y refinar con otra sintaxis. Esto se visualiza en la parte izquierda de
la Figura 8.8, bajo el ttulo Actividades de Traduccin.
99
De manera muy general, se puede decir que la verificacin se ocupa de constatar si el producto est siendo desarrollado
correctamente, mientras que la validacin busca asegurar que se est desarrollando el producto correcto, es decir, aqul
producto que el cliente necesita [BOEHM, B., 1981].
100
101
102
103
104
105
Vase para mayor detalle [FREEDMAN e WEINBERG, 1990].

N. del A. Hemos traducido walkthroughs como recorridas, manteniendo la consistencia histrica con [BORIA, J., 1987].
Siguiendo a [BECK, K., 2000] consideramos a la programacin de a dos una forma extrema de revisin continua.
Probar el programa para asegurarse que funciona es un error de enfoque que disminuye la efectividad de la prueba.
Test Driven Design en [BECK, K., 2000]
Dueo del Producto, Captulo 3.
114
Captulo 8
Boria et al.
Figura 8.8: Modelo V de Desarrollo de Software
La rama derecha del modelo en V define la correspondencia entre las actividades de traduccin y las
actividades de deteccin de defectos introducidos por las mismas. La hiptesis es que cada traduccin introduce
ruido en el sentido que ese trmino tiene en teora de informacin, es decir, un elemento que dificulta la
recepcin del mensaje. Cada actividad, entonces, inyecta defectos. Si se espera hasta que el cdigo ha sido escrito
para remover defectos el resultado es catico. Es seguro que el proyecto tiene pocas reservas de tiempo y
esfuerzo al llegar a ese punto, como es bien sabido por los ingenieros de prueba que consistentemente ven su
calendario deslizarse hacia el futuro porque el desarrollo todava no alcanza el punto donde les pueden hacer
llegar el producto. En esas circunstancias la deteccin de errores no es diferente en primera instancia, pero la falta
de tiempo conspira contra el arreglo: las modificaciones se hacen rpido y sin pensar demasiado. El resultado es
106
que la reparacin introduce nuevos errores con mayor probabilidad de la que tendra repararlo con tiempo . Si la
deteccin de todos los defectos introducidos se posterga se puede esperar que el resultado sea una zona de alta
friccin hacia el final del esfuerzo, como muestra la Figura 8.9.
Figura 8.9: Zona de Caos por Postergacin de Actividades de Remocin
Si en contraste con este enfoque se hace un esfuerzo por detectar y eliminar defectos ni bien se pueden
haber introducido, como muestra la Figura 8.10, donde se agregaron actividades de deteccin temprana
(revisiones indicadas por la letra R en un crculo, donde la flecha CRUCIAL seala las dos ms importantes), el
resultado es un menor esfuerzo de retrabajo, realizado en el momento justo.
106
[MYERS, G., 1979],
Captulo 8
115
Figura 8.10: Modelo en V con Revisiones entre Actividades de Traduccin
8.8 Revisiones
Los tres mtodos de revisiones que se aconsejan, adems de la programacin en pareja, son la inspeccin,
que detallaremos a continuacin, la revisin formal estructurada y la recorrida del producto. Los productos que se
aconsejan revisar son los que se asocian a requisitos, como casos de uso o documentos de especificacin, y el
cdigo mismo. Siempre es conveniente identificar las componentes ms riesgosas para cubrirlas antes de
quedarnos sin tiempo.
Comencemos entonces por las inspecciones, para luego, por diferencia, definir los otros dos mtodos. Qu
se gana al hacer inspecciones? Calidad, porque al inspeccionar productos se detectan y eliminan defectos, pero
tambin comunicacin, ya que eligiendo convenientemente a los participantes se consigue comunicar contenidos
con precisin, as como mejorar el conocimiento de los ms nuevos. Al inspeccionar materiales generados por
expertos aprenden de ellos mejores prcticas. Una inspeccin es un proceso muy formal que identifica un
producto, escoge un equipo de inspectores, escoge las herramientas de inspeccin, detecta los defectos en el
producto, y garantiza la calidad resultante. Un equipo de inspeccin se forma con roles bien definidos. Debe haber
un Moderador que conduzca el proceso y capacite, de ser necesario, a los inspectores. El autor de los materiales a
inspeccionar participa sin voz, escuchando lo que opinan los Revisores, tambin llamados inspectores. Uno entre
ellos, o el Moderador, acta de Escribiente tomando nota de lo actuado. El Moderador es alguien que tiene
habilidades de facilitador y recibi entrenamiento para dirigir inspecciones. El equipo es pequeo, no ms de siete
personas en total, contando al Moderador, el Autor, y dos a cinco Inspectores. Los inspectores se eligen de modo
de conseguir el mximo beneficio de la inspeccin, por ejemplo conocen o son los autores del producto anterior o
sern los autores del producto que sigue. Individualmente son representantes de categoras importantes dentro
de la organizacin, como arquitectos o testers. Lo que es seguro es que comprenden el producto y el proceso y son
expertos o estn para ser educados. Posiblemente alguien de aseguramiento de la calidad participe con funciones
especiales, pero tambin es til que aseguramiento de la calidad haya hecho antes de la inspeccin una auditora
del producto.
8.9 Actividades del Proceso de Inspeccin
El proceso de inspeccin se activa cuando el autor del producto avisa que este est completo. El encargado
que recibe este aviso consigue la participacin de un Moderador del cuadro de Moderadores entrenados de la
empresa. Este se comunica con el Autor y comienzan la primera actividad de preparacin, que consiste en la
Seleccin del Material. En ella el Autor con el Moderador deciden juntos qu partes del producto se van a
inspeccionar. Como criterio de seleccin, las partes a inspeccionar tienen que estar completas, no tienen que ser
tan extensas que incurran en grandes esfuerzos de los inspectores, por lo tanto tienen que ser crticas para que
valga la pena evaluarlos. Entonces Autor y Moderador eligen y preparan materiales acerca del producto
(mrgenes, presentacin, etc.) y las listas de chequeo y guas que apliquen, o patrones que ayuden a entender el
material, as como productos referenciados que sirven para esto.
La logstica se prepara tambin entre el Moderador y el Autor. Entre ambos eligen el equipo, asignan distintos
roles (por lo menos el escribiente) y el moderador fija las duraciones para revisin del material, que es a lo sumo
unas 2 horas de esfuerzo, puede que en 2 das de duracin; para la junta de instruccin (unos 30 minutos); para la
junta de unificacin de defectos (no ms de 2 horas) y comunica las decisiones al equipo. Se consideran las
116
Captulo 8
Boria et al.
respuestas al pedido de participacin, y una vez estabilizado el equipo y el calendario de actividades se procede a
la Junta de Instruccin.
Junta de Instruccin
En la junta de instruccin el Moderador instruye al equipo de inspectores en qu buscar y porqu es
importante, qu pasa si se les pasa un error (impacto en el proyecto, impacto en el cliente). El Moderador instruye
a los participantes en los procesos a seguir, si son nuevos con respecto al proceso se los forma aparte. La Junta
tambin sirve para repartir los materiales a revisar y las referencias, discutir los roles cada inspector va a tener si es
que se elige hacer que cada uno juegue un papel (por ej., cliente, usuario final, diseador, ingeniero de pruebas,
aseguramiento de calidad). En ese caso cada rol puede tener su propia lista de tems de chequeo. El autor provee
de informacin acerca del producto, como resumen del material a inspeccionar y responde preguntas, clarifica
significados y relaciona entre s a los productos. Todo esto se realiza en a lo sumo en 30 minutos.
Los materiales distribuidos se preparan cuidadosamente. El producto tendr las lneas numeradas o
identificadas de forma clara, y si no es todo el producto, se destaca lo que hay que revisar. Se entrega tambin la
plantilla usada para preparar el producto, as como los estndares y referencias, los materiales relacionados y las
listas de tems de inspeccin que servirn para identificar los defectos. Para juntarlos, se entrega una plantilla de
ingreso de defectos.
Inspeccin Individual del Producto
Cada inspector revisa los materiales por su cuenta, e intenta encontrar TODOS los defectos, para lo cul usa
las guas, plantillas y las listas de tems y se coloca en la perspectiva de su rol. Ingresa uno a uno las observaciones
encontradas en la plantilla de ingreso de defectos, donde marca la ubicacin del problema, el tipo de tem
(pregunta, defecto, ambigedad, positivo), y si es un defecto su severidad. Cuando ha completado todos los tems
que ha encontrado ingresa tiempo y esfuerzo en la planilla y realiza un sumario de los problemas. Si en el plazo de
dos horas no ha alcanzado el final del producto a revisar puede extender el tiempo de inspeccin personal pero no
ms de media hora. En cualquier caso, cuando se acaba el plazo sin terminar marca hasta donde inspeccion y da
por concluida la inspeccin personal. Si el producto no est listo para ser revisado por la baja calidad del mismo, o
de existir algn otro motivo para que no se haga la junta de unificacin, como que el producto es redundante o
est desactualizado, informa al Moderador. Si se sigue el proceso normal, cada Inspector enva la planilla
completada al Moderador para que este la unifique en la que presentar en la Junta de Unificacin.
Junta de Unificacin
Las diferentes cuestiones encontradas individualmente son unificadas en una junta especial, cuyo objetivo es
incrementar la calidad del producto. La sinergia obtenida de la discusin incrementa en un 20% el nmero de
cuestiones documentadas en la sesin.
Es el Moderador quin conduce dicha junta. El Moderador la prepara verificando que todos han enviado sus
planillas completadas. Si alguien no lo hizo se posterga la reunin, lo que es un grave problema porque demora el
proyecto. Se podra hacer sin el Inspector holgazn, pero el precedente as sentado hara que la inspeccin pierda
la prioridad que debe tener.
En la reunin, el Moderador recuerda a todos el objetivo de la junta, que consiste en tomar responsabilidad
conjunta por los defectos del producto, no la caza de brujas de autores. El equipo de inspeccin ha empleado
valiosos recursos en analizar el producto para que este salga como un resultado colectivo con la mejor calidad
posible. Para reforzar la conciencia del trabajo en comn, el Moderador presenta las estadsticas de los
inspectores, tiempo, esfuerzo y cantidad de cuestiones levantadas. Luego, ayudado por un proyector, va
recorriendo uno a uno los defectos unificados en su planilla unificada. Los ha ordenado por ubicacin, de modo de
ir de lo general a lo particular y del principio al fin. De cada cuestin da la descripcin, tipo y severidad. Una vez
leda una cuestin hace una pausa para permitir comentarios de los participantes. Los inspectores pueden hacerse
preguntas entre s, por ejemplo si tal o cul cuestin est relacionada con otra, o si es de la severidad planteada.
Pueden hacer preguntas al autor sobre sus decisiones, pero no las ponen en tela de juicio. Si surgen nuevos
problemas se los ingresa en el momento, con todo el equipo, salvo el Autor, acordando en la redaccin de la
cuestin levantada. Estas pueden ser problemas en otros productos (mejoras de la plantilla, por ejemplo, o
cuestiones no detectadas previamente en otros documentos que se ofrecieron como soporte) incluso otras
cuestiones levantadas en la sesin. Se aceptan del equipo que se hagan comentarios, se ofrezcan sugerencias y
alternativas, que se hagan preguntas que sirvan para clarificar y propuestas de soluciones, pero no se discuten,
Captulo 8
117
solo se registran. El Autor contesta preguntas si le son dirigidas, pero puede tambin preguntar sobre cuestiones
levantadas, sin defender su posicin, para que se le aclaren.
La discusin se limita para que la sesin dure no ms de una hora. Generalmente el Moderador intenta
llevarla a su conclusin en noventa minutos para que sea muy probable que termine antes de las dos horas. Si las
dos horas se cumplen la inspeccin se cancela, lo que da un aliciente muy grande para que el equipo intente darle
cierre. En la Junta de Unificacin no se discuten o resuelven las cuestiones; se las anota. Quizs se aclara el tipo o
la severidad que puede cambiar si el que levant la cuestin acepta hacerlo. Como dijramos, se puede pedir
aclaracin sobre porqu eso se considera una cuestin o un defecto.
Disposicin del Producto
Cuando ya no hay ms cuestiones el equipo dispone del producto. Esto significa que escoge entre opciones
de: aceptarlo completamente, no hay retrabajo indicado; o hay retrabajo, pero alcanza con que lo verifique el
moderador; o hay retrabajo, pero es necesaria otra inspeccin por este equipo u otro; o no hay retrabajo, se
rechaza el producto, hay que rehacerlo entero. En los casos en que la decisin no sea completa (aprobar o
desaprobar) el equipo tiene que fijar criterios de aprobacin para el Autor que el Moderador garantizar. El
Moderador facilita esta discusin de cierre y la ordena. Se enva el resultado completo, con la resolucin y las
cuestiones levantadas a todos los participantes, sobre todo al Autor.
Retrabajo y Conclusin
Para cada cuestin levantada, el Autor se rene con el Moderador para definir si la corrige, caso sea un
defecto, o la documenta y archiva, si es una mejora pedida para ese u otro producto y no est dispuesto a llevarla
a cabo todava. En todos los casos apunta su decisin en la planilla de la inspeccin que recibi del Moderador. Si
el Moderador lo autoriza, puede cambiar la severidad. Esto es para que si hay personas que se comportan con
107
fanatismo en la reunin se pueda dejar de discutir en un punto y avanzar. Se completa entonces el trabajo
segn sea necesario y el moderador verifica la completitud del trabajo realizado, es decir que se hayan corregido
los defectos severos, que el criterio de aprobacin fijado por los inspectores se alcance o supere. Pueden entonces
ocurrir alguna de las siguientes alternativas: Que el Moderador revise y apruebe el retrabajo, porque la disposicin
elegida por el equipo lo permite, o que sea el equipo quien revisa porciones selectas del producto, guiados por
sugerencias del Moderador, ya sea que trabajen individualmente (que es la opcin preferida) o en una nueva
junta. Tambin puede ocurrir que todo el producto se re-inspeccione cuando los problemas eran de fondo y el
producto crtico para el proyecto.
Informe Final
La inspeccin se completa con un Informe de Cierre o Informe Final de Inspeccin. El autor actualiza los tems
de la plantilla de inspecciones, dejando claro el status de cada tem, puesto que algunas cuestiones pueden haber
quedado sin resolver; la clasificacin final de severidad y tipo para cada tem, puesto que pueden haber cambiado
con anuencia del Moderador, y enva la planilla actualizada al Moderador. El Moderador o el Autor se ponen de
acuerdo para ver quien es que enva pedidos de cambio a los autores de los documentos de soporte relacionados
con tems levantados en la plantilla. Es el moderador quien es responsable por emitir el informe final, que describe
la disposicin final del producto de trabajo e incluye las estadsticas finales: severidad por tipo, esfuerzo, etc. Estos
nmeros se consolidan y son analizados especialmente para medir la efectividad y eficacia de las inspecciones.
8.10 Factores Crticos de xito
El hecho de que una revisin se denomine una Inspeccin no la transforma en una actividad efectiva. Es
necesario planificarla bien y tener en cuenta los factores de xito. Al planificar su inspeccin elija los participantes
con cuidado, siguiendo las pautas anotadas (al final de la seccin Revisiones, pgina 116). Siempre es til contar
con un ingeniero de pruebas porque se los entrena para encontrar problemas. Incluir personal novato permite
mostrarles buenas prcticas. Asegrese que se limita la cantidad de material a inspeccionar para que se pueda
revisar todo. El Moderador debe exigir que los proyectos otorguen suficiente tiempo de preparacin a los
Inspectores para la revisin inicial. La duracin de la junta de unificacin debe restringirse a dos horas; en una
organizacin con problemas de disciplina las inspecciones comenzaron a ser usadas para otro tipo de reuniones
porque eran las nicas Juntas que los ingenieros respetaban, convirtindolas en maratones de decisiones hasta
que dejaron de asistir a todas. Por ltimo, monitoree y controle el proceso. Lo que no se controla se dispersa.
107
Un fantico es una persona que no est dispuesta a cambiar de opinin ni a cambiar de tema. Winston Churchill.
118
Captulo 8
Boria et al.
8.11 Factores de Fracaso

Las pautas para que una inspeccin sea exitosa no acaban ac. Hay ciertas decisiones que matan la
inspeccin. Si se incluye a la alta gerencia en la junta es muy probable que no se levanten cuestiones para no daar
la reputacin del Autor.
Si se revisan toneladas de material las cuestiones levantadas no resultarn significativas y las inspecciones
perdern fuerza rpidamente. Si la junta de unificacin se transforma en una junta de solucin degenerar muy
pronto en un concurso de opiniones, deje que el Autor sea el responsable de elegir los arreglos. La inspeccin no
es una propuesta de diseo por comit, sino de calidad por apoyo del equipo. Si la junta de unificacin dura para
siempre las personas comenzarn a poner objeciones y excusas para no participar en ellas. Si durante la junta el
Moderado acepta comentarios personalizados o cargados de emocin (Esto es una porquera de producto o
Quienquiera que escribe as no puede trabajar conmigo) las peleas sern moneda corriente y el propsito de la
inspeccin, que es que un grupo ayude a una persona a mejorar su producto para bien de todos, se pierde
irremisiblemente.
8.12 Diferencias Entre Inspecciones, Recorridas y Revisiones Estructuradas
Utilizando a las inspecciones como gnero, revisaremos los otros dos tipos mostrando tan solo las
diferencias. Seguimos ac el material de tres libros que coinciden en lo esencial respecto de estos tres tipos:
[FREEDMAN, 1990], [GILB, 1994] y [EBENAU, 1994]. Primero comenzaremos con la ms dbil de las tres, medida en
108
capacidad de encontrar defectos, la recorrida. Hay un libro de Yourdon que describe con detalle el proceso de
recorrida, pero que en nuestra opinin describe una revisin estructurada, de modo que si se est interesado en
esta ltima esa es una buena referencia.
A diferencia de la inspeccin, la recorrida no exige un moderador. El propio Autor la organiza y facilita. El
equipo no est limitado a un nmero mximo y no necesita ser convocada con anticipacin alguna. El autor puede
reunir un grupo que dispone del tiempo y pedirles que se presenten en un saln en minutos u horas. La duracin
de la reunin tambin es flexible, y los roles se asignan, si acaso, en el momento de comenzar la junta. Si la
inspeccin es una tarea premeditada, la recorrida es una actividad apenas formal. El propsito es obtener
retroalimenta-cin rpida de un grupo de personas para mejorar la calidad de un producto en el momento. La
toma de notas, captura de datos y resolucin quedan a cargo del autor. Es posible que no queden rastros de esta
actividad y que se considere que la falta de historia no es un problema. Entre los dos tipos se encuentra la revisin
estructurada, que como ya dijimos est bien documentada en la literatura. Nuestra descripcin coincide con la
realizada en el libro de Gilb ya citado y en muchas partes con el libro de Yourdon, tambin citado.
En la revisin estructurada quin convoca es el encargado del proyecto, sea lder tcnico, gerente de
proyecto, o lder de proyecto. El propsito es conocer el estado de un producto. El encargado designa al facilitador
y este puede elegir si el autor participa en la logstica. Es decir, puede no tenerlo en cuenta para las decisiones de
composicin de equipo y dems. El facilitador cumple un papel ms directo que el Moderador en la inspeccin
puesto que pese a su nombre toma ms decisiones que el Moderador. En general se sigue el procedimiento
descripto para la inspeccin, salvo que la junta de instruccin es opcional, siendo remplazada a menudo por una
comunicacin electrnica para los participantes. Las listas de chequeo son semejantes, aunque es menos frecuente
que sean diferentes para los distintos participantes segn sus roles, que tampoco son asignados con la misma
frecuencia que en las inspecciones. Cambia tambin la capacidad del equipo de disponer del producto. En vez de
elegir la disposicin, el equipo recomienda al encargado del proyecto un camino a seguir, que este no est
obligado a considerar.
Una de las aplicaciones ms interesantes es su uso combinado en proyectos de cierto riesgo. Para ms
informacin ver [BORIA, 2010].
Resumiendo las diferencias en una tabla, son las siguientes:
Objetivos
108
Recorridas
Obtener
retroalimentacin
temprana sobre la
manera de avanzar con el
Revisiones Estructuradas
Mostrar que el producto
tiene la calidad esperada
Inspecciones
Ubicar todos los errores
posibles y corregirlos hasta
alcanzar un nivel de calidad
prefijado
YOURDON, Edward, 1989, Structured Walkthroughs. Prentice-Hall.
Captulo 8
119
Recorridas
producto y corregir
errores si hubiera
Revisiones Estructuradas
Inspecciones
Criterio de
Entrada
Se identifica la necesidad
en el calendario del
proyecto o el autor u
otro lo deciden
El autor solicita la inspecin

y confirma que el producto
cumple con los criterios
para ser inspeccionado
Decisiones
Las decisiones las toma el

autor
Cierre de las
Cuestiones
Fuera del alcance del

procedimiento
La gerencia estima que el

producto est listo, se han
publicado los criterios de
calidad, el autor confirma
que se puede empezar
El equipo de inspeccin
informa y recomienda, la
gerencia decide
La gerencia controla como
parte del proyecto
Tamao
Dos o ms personas, sin

lmites
Quin est disponible
Composicin
del Equipo
Liderazgo
Autor
Preparacin
Opcionalmente se
distribuye el material con
horas de anticipacin
Presentador
Mediciones
Recogidas
Usualmente el autor
Opcional, raramente se
hace
Informes
Lo emite el autor a su
discrecin
Captura de
Datos
No es requerida
Al menos tres, no ms de
los
Lderes tcnicos y colegas
del autor
Generalmente un lder
tcnico del proyecto
Hay una revisin individual
previa siguiendo criterios
establecidos en lista de
chequeo
Autor o lector designado
Generalmente se hacen
como en inspeciones pero
no son requeridas,
depende de la empresa
Informe con la lista de
defectos, cuestiones y
acciones realizadas
No es requerida
El equipo define la
disposicin del producto y
acciones futuras
El moderador controla de
acuerdo a los criterios del
equipo
Tres por lo menos, no ms
de siete
Colegas del autor elegidos
bajo criterios
Moderador capacitado
Hay una revisin individual
previa siguiendo criterios
establecidos en lista de
chequeo y con materiales
de soporte
Lector designado o nadie
Requeridas formalmente,
esfuerzo, tiempo, tipo y
nmero de cuestiones
Informe con detalle de lo
detectado, invertido y
actuado
Colecta con fines
estadsticos de todos los
datos catastrales y esfuerzo,
tiempo, costo, etc.
Tabla 8.13: Comparacin entre Revisiones
8.13 Usos giles

Las revisiones, as descriptas, tienen demasiado sabor a proyecto largo para ser tiles en un ambiente gil. Sin
2
embargo, veamos como las adaptaron Marcela y los gemelos en T . En primer lugar, la revisin elegida por los
gemelos es revisin continua, llamada en la literatura programacin por pares, a la que para que se puedan juntar
los datos han hecho cambios en el proceso: cuando el mdulo es crtico el programador con ms experiencia acta
de coach y captura datos en una planilla adaptada de la que se usa habitualmente en inspecciones (ver Tabla 8.14)
Con esos datos se puede iniciar un anlisis estadstico de los defectos detectados. Asimismo Marcela y Jessica han
2
adaptado el mtodo de revisiones estructuradas para su uso en sprints. Recordando los inicios de T , cuando se
realizaba el remate de tareas, cuando un equipo de trabajo termina un producto que amerita ser revisado, lo
2
que se define en el juego de planificacin del Sprint, invoca mediante la Intranet de T (llamada festivamente ITT) a
los otros equipos para una revisin. Cada equipo tiene la obligacin moral de prestar un miembro en las dos horas
que siguen al llamado que pueda revisar el material. Al cierre del da los revisores se renen con los autores para
presentarles sus cuestiones. El Scrum Master del equipo que solicit la revisin es el Moderador y tiene las mismas
responsabilidades respecto del informe que en una inspeccin. De ese modo las revisiones son giles y producen
resultados. Los datos de las revisiones se almacenan en un repositorio central para ser analizados en la reunin
mensual.
120
Captulo 8
Boria et al.

66. Los problemas inyectados dentro de un sprint se han eliminado pero los problemas legados han
escalado.
67. Marcela verifica que una mejora del proceso de ingeniera de pruebas puede atender tanto
Validacin como Verificacin.
68. Marcela, Jessica y los gemelos adaptaron el proceso de revisiones estructuradas a sus sprint y
modificaron el procedimiento de programacin por pares para que produzca evidencia de
revisin continua.
Cuestiones Levantadas Por la Inspeccin

Proyecto
Autor
Producto
Moderador
Logging Date
Revisores
Hora de Comienzo
Hora de Fin
Duracin
Ubicacin (Pgina,
Lnea)
Descripcin de la Cuestin)
(Si el tem se levant en la reunin selelo con *)
Tipo
Severidad
Comentarios del Arreglo
Tabla 8.14: Plantilla de Registro de Cuestiones
8.14 Pruebas de Producto

Para continuar con la mejora de la percepcin de calidad del producto por el cliente, los gemelos lideran un
equipo de expertos en pruebas. Jessica ha incorporado entre las mejoras al sistema de compensaciones la
evaluacin continua, que consiste en descartar la evaluacin anual de desempeo y en cambio realizar
evaluaciones del resultado de cada tarea, inspirada por el material de [CULBERT 2010]. Como parte del sistema de
recompensas los ms destacados por su desempeo reciben un ttulo honorario de Campeones y un curso de su
2
eleccin de entrenamiento anual pago por T . En consecuencia, Evelina Kahn ha resultado la Campeona de Pruebas
y como su recompensa escogi un taller de ingeniera de procesos y tcnicas de pruebas y viene del mismo
dispuesta a aplicar lo recientemente aprendido. Como el taller est inspirado en el libro de Denney p. cit. la
compatibilidad entre lo que buscan los gemelos y lo que quiere aplicar Evelina es total.
Revisando las acciones para las cuestiones de validacin y verificacin, Marcela ya se ha ocupado de reforzar
el seguimiento del proceso de pruebas, tanto para la aceptacin del usuario como para las pruebas que lo
preceden, aumentando la frecuencia de las auditoras y ayudando a prevenir disconformidades, de modo que este
punto se considera cerrado. Pasa entonces a mayor prioridad la necesidad de acordar con el cliente y el equipo las
estrategias de prueba, los productos a evaluar, el cronograma de las pruebas, los criterios de entrada y aceptacin
y los ambientes de aplicacin.
8.15 Criterios Relacionados con Pruebas
Se entiende por criterio, segn la Real Academia Espaola, a una norma que se sigue para conocer la verdad.
En segunda acepcin un criterio es un juicio o discernimiento. En ambos casos el significado enfoca sobre el
criterio como un elemento de juicio que permite conocer la verdad. Cuando trabajamos en un ambiente de
software, es importante responder a la pregunta Cmo sabremos que el producto est listo para pasar a la
prxima fase o ser liberado al usuario? Llamamos a criterios de ese tipo Criterios de Aceptacin.
Para cada tipo de prueba, se define:
1.
2.
3.
4.
Captulo 8
El conjunto de casos de prueba que se tiene que usar

Los datos que tienen ser utilizados cada vez que se corran los casos
Los ambientes en los que tienen que correr las pruebas
Las pruebas de regresin incluidas en las pruebas de dicho tipo
121
5.
6.
7.
8.
9.
10.
El nmero de defectos tolerados por categora de severidad

El mnimo de funcionalidad cubierta por las pruebas (cobertura)
Objetivos de desempeo de las pruebas a ser alcanzados (performance)
Objetivos especficos de volumen (si aplican)
Objetivos de confiabilidad (si aplican)
Objetivos de usabilidad (si aplican)
Otros dos criterios tiles sirven para responder a la pregunta: Cmo sabemos que el producto est listo para
ser probado? Saber esto es importante porque si comenzamos la prueba sobre un producto inmaduro los defectos
se acumularn sin beneficio, al tener que realizar muchas modificaciones. Luego es importante definir y confirmar
que se cumple el criterio de entrada a la fase de pruebas correspondiente.
Para cada tipo de prueba, se define:
Cul es el estado que tiene que tener el producto para ingresar a la fase (generalmente el
criterio de aceptacin del producto en la fase anterior, es decir tiene que haber sido probado en
tal ambiente con tales casos que dieron tal cobertura y con los resultados de no ms de tantos
defectos segn la severidad). Garantizar que el criterio de entrada se cumple implica una buena
inversin de los recursos. Esto es especialmente importante en las primeras etapas de prueba,
porque es ah donde se producen los atrasos mayores, cuando los desarrolladores entregan
apresuradamente productos todava sin terminar.
El siguiente criterio a incluir es el que responde a la pregunta: Cundo hay que dejar de
probar un producto porque ya tiene demasiados errores? Se deja de probar el producto y se lo
devuelve a la fase de desarrollo para arreglarlo cuando no tiene sentido seguir invirtiendo
recursos para probar cdigo que fatalmente va a cambiar significativamente. Es bastante usual
conectar este criterio con el de aceptacin en lo que hace a la cantidad de errores por severidad.
Claramente se sigue probando el producto mientras que el criterio de aceptacin relacionado con
la densidad de defectos (el 5 en nuestra lista) se sigue cumpliendo y el criterio de cobertura no
todava (el 6 en nuestra lista).
8.16 Cobertura
La cobertura que proveen las pruebas es un aspecto sumamente importante en la definicin de criterios.
Podemos ser ms especficos que simplemente hablar de la funcionalidad cubierta. En ese caso lo que se expresa
como cobertura es el porcentaje de los casos de uso que los casos de prueba cubren. Pero si recordamos la
redaccin de un caso de uso (Tabla 8.8) es posible que haya flujos alternativos. Por ejemplo, veamos el primero de
todos los CU, Registrarse como Usuario del Sistema.
FLUJO NORMAL
1. El sistema espera un usuario nuevo mostrando la pantalla de ingreso

2
Un usuario escoge ingresar al sistema
El sistema presenta la pantalla de opciones para usuarios registrados o nuevos
El usuario escoge la opcin para usuarios nuevos
El sistema presenta la pantalla de registro de datos
El usuario ingresa sus datos personales y los confirma haciendo "ENTER"
7
FLUJOS
ALTERNATIVOS
El sistema almacena los datos del nuevo usuario en su base de datos y pasa al CU de
Ingresar
7a El sistema encuentra un usuario con la misma identidad (nombre, tipo y nmero de
documento) pero otros datos de catastro (direccin y bancos)
7b El sistema consulta al usuario sobre los datos existentes solicitando permiso para
actualizar con los datos recin ingresados
7c El usuario autoriza al sistema a realizar la actualizacin
7d El sistema actualiza los datos en su base de datos y pasa al CU de Ingresar
Tabla 8.15: Ejemplo de Secuencia Principal y Alternativa de un CU
Es claro que un caso de prueba que siga la secuencia feliz (el usuario es totalmente nuevo) no cubre toda la
funcionalidad del caso de uso, puesto que hay por lo menos un flujo alternativo cuando el usuario se ha registrado
anteriormente y en consecuencia una regla de negocio (actualizar los datos de catastro) que no se prueba. Por lo
122
Captulo 8
Boria et al.
tanto es importante definir que se quiere decir con la cobertura de los casos de prueba. Obviamente, al nivel ms
alto, se espera que haya por lo menos un caso de prueba para cada caso de uso. Se puede reclamar que la
cobertura de casos de uso sea el 100% en la mayora de los casos, pero no siempre es as, si el perfil operativo nos
dice que algunos de los CU son de muy baja importancia. Si algunos casos de uso son importantes debemos saber
que cobertura de las diferentes alternativas y excepciones de cada uno estamos cubriendo con nuestros casos de
prueba.
En realidad, la literatura clsica de diseo de casos de prueba asocia cobertura de los casos de prueba con los
mtodos de caja de cristal, o caja blanca como se los llamaba en un principio. Los mtodos de diseo de pruebas se
clasifican en dos grandes tipos: el diseo de casos haciendo caso omiso del cdigo que fue o ser construido,
llamados caja negra por su similitud con mtodos de diseo de pruebas que ignoran el diseo de las
componentes a probar, y caja de cristal, o caja blanca originalmente (hasta que alguien tomo en consideracin
que el problema es distinguir entre opacidad y transparencia, y no entre colores de cajas igualmente opacas). Los
mtodos de caja de cristal se asocian fcilmente a cobertura, puesto que las categoras de cobertura son:
sentencias (porcentaje de lneas de cdigo ejercitadas durante la ejecucin del conjunto de datos de prueba),
condiciones (porcentaje de las condiciones probadas en ambos sentidos, es decir Falso / Verdadero, ejercitadas
durante la ejecucin del conjunto de datos de prueba), y caminos (porcentaje de todos los caminos posibles
ejercitados durante la ejecucin del conjunto de datos de prueba). Las categoras son crecientes, en que la
cobertura de caminos implica la cobertura de condiciones, que a su vez implica la cobertura de sentencias. No
puedo cubrir todas las condiciones sin cubrir todas las sentencias A NO SER QUE HAYA CDIGO INALCANZABLE, es
decir cdigo que no puede ser ejecutado en condiciones normales de uso. Es el caso de porciones de cdigo que se
han separado del conjunto colocando un salto (GOTO) a la primera sentencia que le sigue a la porcin en la
sentencia anterior a la que le da comienzo o que estn condicionados por una condicin inalcanzable.
Volvemos ahora a Denney y su libro Use Case Levels of Test. Lo habamos dejado con la construccin del Perfil
Operativo del sistema y la construccin de aquellos casos de uso que se justificaban. Ahora ya podemos elaborar
sobre estos casos de uso que valen la pena para analizar cules pasos hay que cubrir. Del perfil operativo ya no
podemos sacar ms nada, a no ser que refinemos los pasos que se recorren dentro de cada caso de uso y
analicemos su frecuencia relativa. Precisamente es eso lo que nos propone Denney, convirtiendo primero el caso
de uso en un diagrama de flujo de control. El intento de construccin del diagrama permite ver que hay caminos
sin definir en el caso de uso. Por ejemplo, Qu pasa si el usuario no da permiso para actualizar sus datos? En el
diagrama hemos tomado la decisin de finalizar sin actualizar.
Figura 8.11: Diagrama de Flujo del Caso de Uso de la Tabla 8.15
Un diagrama de flujo de control requiere tener un nico punto de entrada y un nico punto de salida. Estos
nodos permiten cerrar regiones en el diagrama, marcadas como 1, 2, y 3, de abajo hacia arriba. Esto es importante
porque nos permite conocer el nmero de casos de prueba que necesitaremos generar.
Comencemos por hacer abstraccin de lo que pasa en un nodo para poder mostrar el mtodo de
construccin de casos de prueba progresivamente ms la cobertura a medida que agregamos casos al conjunto.
Tomando nuevamente prestado de Denney usaremos su ejemplo de la Figura 8.12.
Captulo 8
123
Figura 8.12: Diagrama de Flujo de Control con Funcionalidad Abstrada
Dependiendo de si este es un caso de uso de muy alta frecuencia los caminos que vale la pena cubrir con
casos de prueba sern diferentes. Imaginemos el peor caso, en el que la cobertura de todos los casos de uso es
parte de los criterios de aceptacin de una fase de pruebas pero el caso de uso as representado tiene muy baja
frecuencia de utilizacin. Entonces intentaremos hacer lo menos posible para cumplir con el criterio, pero sin usar
recursos dems. Cuando hay que elegir un nico caso de prueba para un caso de uso generalmente se disea
sobre la base de que el empleo ms frecuente ha de ser en el caso en que todas las condiciones se dan bien. Es por
eso que a este caso se le denomina el camino feliz, porque no ocurren excepciones. Aun para el camino feliz
podramos tener una misma secuencia de prueba con diferentes datos, pero hablaremos de esto ms adelante. Un
caso de prueba que recorra los nodos 1, 2, 3, 4, 5 y 6 de la Figura 8.12 ejercita el camino feliz. Si dentro de cada
nodo no hay caminos alternativos, la ejecucin de un nodo implica la ejecucin de todas las sentencias que forman
parte de ese nodo en el cdigo, por lo que cobertura de nodos en el diagrama de flujo de control es equivalente
a cobertura de sentencias en el cdigo. Para conseguir cobertura de sentencias necesitamos dos casos de
prueba. Uno puede aprovecharse de la existencia de dos ciclos (entre 5 y 4 y entre 5a y 4) para que el caso de
prueba que recorre 1, 2, 2a, 3, 3a, 4, 5, 4, 5a, y 6 de cubrimiento a la rama de la derecha del diagrama, y luego con
1, 1a y 1b cubrir la rama izquierda.
Pero la cobertura de sentencias no garantiza que las pruebas sean definitivas. Para tener la mayor cobertura
posible, la de caminos, podemos partir del diagrama de flujo de control y sistemticamente producir todos los
caminos. Empecemos con el primer camino, el Camino Feliz, que como ya vimos es 1, 2, 3, 4, 5 y 6 (Figura 8.13a) y
yendo del ltimo nodo hacia arriba elijamos un paso que no hayamos explorado. Como ya pasamos por el 5 la
nica opcin es el 5a con sus dos pasos, desde 4 hacia l y desde l hacia el 6. Esto delimita la primera zona del
diagrama, la zona 1 (Figura 8.13b). Repitiendo el algoritmo llegamos al nodo 4, y ahora elegimos cualquier arco de
entrada. Damos preferencia a los que son numricamente posteriores, luego elegimos el nodo 5 y el arco que va
del 5 al 4 (Figura 8.13c). Queda delimitada la segunda zona, la 2. Repitiendo el proceso aparecen sucesivamente
todas las zonas hasta la 7. Se necesitan 8 casos de prueba para cubrir todos los caminos.
Solo queda por definir como se seleccionan los caminos que vale la pena detallar con casos de prueba. El
mtodo de Denney sugiere Adivinar! Pero no sin fundamentos. Basndose en la conocida distribucin de los
bienes del matemtico italiano Pareto, Denney propone asignar probabilidad 80% al paso ms probable y 20% al
otro, si son dos. Por ejemplo, en la Figura 8.13, el paso de salida (1, 2) tendra 80% de probabilidad y el (1, 1a)
tendra 20%. Cada paso del camino feliz tiene 80% y las alternativas 20%. Cuando hay solo un camino de salida este
tiene un peso probabilstico del 100%, obviamente. De esta manera se asignan las probabilidades a cada paso. Se
desprende entonces que la frecuencia de uso de un camino es el producto de todos los pasos en ese camino. El
camino feliz tiene frecuencia (0,8 x 0,8 x 0,8 x 0,8 x 0,8) = 0, 32768. El camino 1 -> 1a -> 1b tiene frecuencia 0,16.
(Figura 8.14).
124
Captulo 8
Boria et al.
Figura 8.13: Secuencia de Seleccin de Caminos para Cubrirlos Todos
Marcela y los equipos tcnicos investigan la posibilidad de utilizar criterios de cobertura fuertes para
garantizar que las pruebas dan una alta seguridad de que los defectos remanentes son muy pocos y dentro del
objetivo de proceso establecido por el comit de gestin. Finalmente se decide que los criterios sern establecidos
por el dueo del producto en conjunto con el equipo durante el juego de planificacin, como parte de establecer
los requisitos no funcionales del sprint. Pero cuando un camino dentro de un caso de uso de alta frecuencia de
empleo tenga riesgo alto, el caso de prueba correspondiente debe ser incluido entre los casos a disear e
implementado para la prueba de integracin continua del sprint. Como parte del diseo se acuerda seguir los
pasos descriptos por Denney. Para el sprint de estabilizacin se fijarn criterios especiales ligados a los objetivos de
negocio de la empresa respecto del producto en cuestin.
Captulo 8
125
Figura 8.14: Probabilidad de Cada Transicin del Grafo

69. Jessica incorpor entre las mejoras al sistema de compensaciones la evaluacin continua
70. Los gemelos encabezan un grupo de expertos para modificar y mejorar las tcnicas de pruebas
de producto.
71. Evelina ha resultado Campeona de pruebas y viene de un taller de ingeniera de pruebas
dispuesta a aplicar lo recientemente aprendido.
72. Se adoptan las tcnicas de diseo de casos de prueba guiadas por riesgos y frecuencia de
empleo.
73. 73. Los criterios de cobertura, con diferente nfasis, se emplean en la fijacin de objetivos para
cada sprint.
74. 74. El Sprint final de estabilizacin recibir sus propios criterios de cobertura.
Como ltimo paso en la mejora de procesos de la ingeniera de pruebas Marcela y Jessica exploran la brecha
2
existente entre los procedimientos en uso por T y los resultados esperados del MPS para los procesos de
Verificacin y Validacin.
Resultados Esperados de VER en el MPS
Atividades Internas en Tahini-Tahini
VER 1 Los productos de trabajo a ser verificados son

acordar con el equipo la estrategia de verificacin,
identificados
los productos a evaluar y con qu mtodos, el
cronograma de las diferentes evaluaciones, los
VER 2 Una estrategia de verificacin es desarrollada e
criterios de entrada, discontinuacin y aceptacin
implementada, estableciendo el cronograma,
(garantizando que la cobertura mnima es uno de
revisores involucrados, mtodos para verificacin
ellos) y los ambientes de prueba cuando aplican
y cualquier material a ser utilizado en la
verificacin
VER 3 Criterios y procedimientos para verificacin de los
productos de trabajo a ser verificados son
identificados y un ambiente para verificacin es
establecido
VER 4 Actividades de verificacin, incluyendo pruebas y
aplicar a rajatabla auditoras de proceso y producto
revisiones por pares, son ejecutadas
hasta que se fije la conducta de prueba sistemtica
VER 5 Los defectos son identificados y registrados
automatizar todas las pruebas
VER 6 Los resultados de actividades de verificacin son
los datos obtenidos de las pruebas y las inspecciones,
analizados y puestos a disposicin de las partes
recorridas y revisiones tcnicas, deben ser analizados
interesadas
y discutidos en la reunin mensual de cartera
2
Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T
126
Captulo 8
Boria et al.
Resultados Esperados de VAL en el MPS
Atividades Internas en Tahini-Tahini
VAL 1 Los productos de trabajo a ser validados son

identificados
acordar con el cliente y el equipo la estrategia de

validacin, los productos a evaluar, el cronograma de
esta, los criterios de entrada y aceptacin y los
ambientes de aplicacin
VAL 2 Una estrategia de validacin es desarrollada e

implementada, estableciendo um cronograma,
participantes involucrados,
mtodos para
validacin y cualquier material a ser utilizado en la
validacin
VAL 3 Criterios y procedimientos para la validacin de
los productos de trabajo a ser validados son
identificados y un ambiente para validacin es
establecido
VAL 4 Las actividades de validacin son ejecutadas para
garantizar que el producto est listo para su uso
en el ambiente operativo previsto
VAL 5 Los problemas son identificados y registrados
reforzar el seguimiento del proceso de aceptacin

del usuario aumentando la frecuencia de las
auditoras y ayudando a prevenir disconformidades,
asegurando que los criterios de aceptacin se
cumplen, basados en documentacin fehaciente
VAL 6 Los resultados de las actividades de validacin son

analizados y puestos a disposicin de las partes
interesadas
VAL 7 Las evidencias de que los productos de software
desarrollados estn listos para su uso previsto son
provistas
2
Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T
Los resultados son muy buenos, lo que la conduccin de T2 recibe con mucha alegra. La pregunta que se
hacen es si vale la pena hacer una evaluacin para el Nivel D o esperar hasta tener el C implementado. Marcela les
recuerda que todava no revisaron todos los procesos del nivel D, falta que se ocupen de Integracin del Producto
ITP y de Diseo y Construccin del Producto PCP.
8.17 Diseo y Construccin
Siguiendo el hilo que surgi de los requisitos, la construccin de casos de prueba, se puede ir hacia ITP
considerando que la integracin tiene una fuerte componente de pruebas, o hacia PCP, porque el equipo ha
elegido Test Driven Design como tcnica de diseo. Esto ltimo los gua hacia revisar la brecha con PCP. Estos son
los procesos de PCP:
Diseno y Construccin del Producto (PCP)
PCP 1
Las alternativas de solucin y los criterios de seleccin son desarrollados para atender los
requisitos definidos del producto y componentes de producto
PCP 2
Las soluciones son seleccionadas para el producto o componentes de producto, con base en
escenarios definidos y en criterios identificados
PCP 3
El producto y/o componente del producto es diseado y documentado
PCP 4
Las interfaces entre las componentes del producto son diseadas tomando como base criterios
predefinidos
PCP 5
Un anlisis de las componentes del producto es conducida para decidir sobre su construccin,
compra o reuso
PCP 6
Las componentes del producto son implementadas y verificadas de acuerdo con lo que fue
diseado
PCP 7
La documentacin es identificada, desarrollada y puesta a disposicin de acuerdo con los patrones

establecidos
PCP 8
La documentacin es mantenida de acuerdo con criterios definidos

Tabla 8.18: Proceso DISENO Y CONSTRUCCIN DEL PRODUCTO
[SOFTEX, 2012a]
Revisando los materiales derivados de las reuniones de retrospectiva se analizan los problemas que se
vinculan al diseo y construccin de los productos. Se refleja este anlisis en la Tabla 8.19.
Captulo 8
127
Diseo y Construccin del Producto PCP

riesgo o problema:
nos dedicamos a explorar la primera opcin de diseo y
si no hay razn para descartarla la implementamos sin
considerar los objetivos del diseo y buscar alternativas
mejores, arriesgando sub-optimizar el mismo
el sprint de estabilizacin est teniendo problemas
porque el equipo no reconoce algunas decisiones de
diseo tomadas que impactan en las pruebas
la integracin a menudo fracasa en el primer intento,
haciendo perder un da de pruebas cada vez
hemos intentado reinventar la rueda en varias ocasiones
en ocasiones el equipo se ha desviado significativamente
de las decisiones de diseo, en aras de mejoras
hipotticas, incrementando la probabilidad de tener que
rehacer los casos de prueba a ltimo momento
en casos particulares se ha entregado la documentacin
incompleta o en formato diferente del acordado
mitigacin:
desarrollar criterios universales para iniciar un anlisis
de alternativas de diseo basados en los objetivos de
2
negocios de T y el proyecto
documentar el diseo, sobre todo el porqu de la
seleccin de componentes, apoyado en los requisitos,
sobre todo los no funcionales
realizar un anlisis de causa para identificar acciones
aplicar el anlisis de reuso amplindolo con
componentes del mercado
109
reforzar el sentimiento de YAGNI
utilizando solo
pruebas que han sido aprobadas por el equipo en el
momento de aprobar el plan del sprint
aadir una plantilla de revisin de documentacin

para ser utilizada por afirmacin de calidad antes del
cierre del sprint
rehacer la revisin de la documentacin en el sprint
de estabilizacin
Tabla 8.19: Problemas de Diseo
Comparando las soluciones contra los resultados esperados del proceso Marcela y Ana ven grandes
oportunidades de resolver el problema detectado en cada caso y a la vez hacerlo con una implementacin que
alcanza esos resultados esperados. Algunas acciones son muy fciles de implementar, por ejemplo ampliar el
110
anlisis de reuso que ya viramos para incluir entre las opciones componentes que se pueden adquirir fuera de
2
T . Esto de inmediato da frutos porque Mariano mantiene un cuaderno de tecnologa en la misma wiki que se
guarda la informacin de componentes reusables. El motivo por el cul hace esto es porque quiere tener muy claro
2
cules son los productos que compiten con las lneas de producto de T y orientarlas hacia las necesidades del
mercado. De ese modo, los equipos no tienen que cambiar ni un pice sus procesos, un pequeo cambio en el
mtodo de bsqueda en la wiki da el resultado esperado. Pero la investigacin sobre reuso trajo un regalo
inesperado: Se puede adaptar el mtodo de anlisis de decisiones para reuso para que sea un mtodo de anlisis
para diseo en general, de modo que al comenzar el diseo ya se est pensando en alternativas. De ese modo se
ataca la raz del problema de diseo, el primero de los puntos. Modificado el anlisis que debe regir en el juego de
planificacin queda as:
109
110
1.
Enunciado de objetivos, es decir, para qu se realiza el diseo del producto del sprint. Algunos ejemplos son
acortar plazos sin prdida de calidad, permitir mantener la duracin del sprint desarrollando ms puntos de
usuario, bajar costos, etctera.
2.
Eleccin de atributos deseables, donde el equipo discute a partir de los requisitos qu atributos debe tener el
diseo, por ejemplo debe ser integrable fcilmente, compatible con el diseo actual, fcil de probar, ejecutar
muy rpido, etc.
3.
Identificacin de soluciones candidatas, que se realiza automticamente usando el algoritmo neural basado
en los atributos elegidos para componentes existentes o en el mercado. En el caso de no existir, o de
considerarlo necesario el equipo, se describen al menos tres soluciones alternativas enfatizando el impacto
del riesgo en la identificacin.
4.
Evaluacin de candidatos, lo que se realizan por pruebas ad-hoc, que son diseadas contra los atributos
elegidos, y la historia de la componente cuando existe, o por mtodos menos formales cuando se trata de
soluciones originales.
5.
Anlisis de opciones, esto se realiza siguiendo un mtodo prestablecido que utiliza una matriz de Pugh como
la que ya se vio en el Captulo 4. Una de las opciones es siempre no utilizar una componente para reusar.
6.
Seleccin de alternativas, tambin siguiendo el mtodo anterior.
7.
Adopcin o Diseo de componente, si aplica, se realiza el ajuste de la componente, de acuerdo a las
You Ain't Gonna Need It (No vas a necesitarlo)

Captulo 7, Figura 7.2: Anlisis de Opciones sobre Reuso, pgina 22.
128
Captulo 8
Boria et al.
necesidades del equipo. Puede que llegado este punto el resultado de la evaluacin de alternativas sea
totalmente negativo y se deba volver a revisar el diseo.
8.
Evaluacin del resultado, se compara con los objetivos enunciados en el primer paso para continuar armando
la historia de la componente y aadir los conocimientos adquiridos cuando se trata de reuso, y si es un diseo
nuevo capturar lo aprendido en la wiki. Si aplica, registrar la componente como til para reuso.
Tabla 8.20: Anlisis de Opciones sobre Diseo
De este modo se extiende la aplicacin de reuso a componentes an no construidas o ya existentes en el

mercado.
Realizado un anlisis de causa sobre los problemas del fracaso de la integracin continua en el primer intento
se determina que el problema es que ha habido cambios en las API sin que se los comunicara a todos los
interesados. La solucin es que las API queden bajo control del Scrum Master una vez aprobadas y que todos los
cambios deban ser comunicados. El uso de herramientas de control de configuracin hace que este pequeo
cambio sea fcil de implementar. Pese a todo, los primeros Sprints utilizando el cambio todava muestran trazas de
ese problema, por lo que el grupo de Calidad, que ahora depende de Jessica, se aboca a realizar auditoras
tempranas para garantizar que las API y las interfaces de usuario estn bajo control de cambio y asignadas al
Scrum Master. Si bien esto viola en cierto modo los principios giles la propuesta es bien recibida por los equipos:
Pocas cosas se sienten peor que llegar por la maana a una oficina vaca y encontrar que los resultados de la noche
son nulos.
Ya en el tema de auditoras de calidad, se incorpora la sugerencia de las retrospectivas de agregar un tem de
control que permita conocer el estado de la documentacin pactada con el usuario en cada caso. Todas las
auditoras pre-demo las incluyen, as como las de ingreso y salida al Sprint de estabilizacin.
Volviendo al tema de diseo de pruebas, dado que las pruebas se desarrollan de modo sistemtico ahora, se
hace ms deseable utilizarlas como elemento de diseo. Los equipos ratifican su poltica de usar las pruebas
diseadas por los ingenieros de prueba para desarrollar el producto. En este punto Marcela considera que se ha
dado cobertura a los tems principales surgidos de las retrospectivas que se relacionan con Diseo. Para verificarlo
construye la siguiente Tabla 8.21.
Resultados Esperados de PCP en el MPS
Cobertura en Tahini-Tahini
PCP 1 Las alternativas de solucin y los criterios de

seleccin son desarrollados para atender los
requisitos definidos del producto y componentes
de producto
desarrollar criterios universales para iniciar un

anlisis de alternativas de diseo basados en los
2
objetivos de negocios de T y el proyecto
PCP 2 Las soluciones son seleccionadas para el producto

o componentes de producto, con base en
escenarios definidos y en criterios identificados
PCP 3 El producto y/o componente del producto es
diseado y documentado
documentar el diseo, sobre todo el porqu de la

seleccin de componentes, apoyado en los
requisitos, sobre todo los no funcionales
PCP 4 Las interfaces entre las componentes del producto

son diseadas tomando como base criterios
predefinidos
controlar las interfaces de todo tipo para que sus

modificaciones se propaguen a los interesados
PCP 5 Un anlisis de las componentes del producto es

conducida para decidir sobre su construccin,
compra o reuso
aplicar el anlisis de reuso amplindolo con

componentes del mercado
PCP 6 Las componentes del producto son

implementadas y verificadas de acuerdo con lo
que fue diseado
reforzar el sentimiento de YAGNI utilizando solo

pruebas que han sido aprobadas por el equipo en el
momento de aprobar el plan del sprint
PCP 7 La documentacin es identificada, desarrollada y

puesta a disposicin de acuerdo con los patrones
establecidos
aadir una plantilla de revisin de documentacin

para ser utilizada por afirmacin de calidad antes del
cierre del sprint
PCP 8 La documentacin es mantenida de acuerdo con rehacer la revisin de la documentacin en el sprint

criterios definidos
de estabilizacin
Tabla 8.21: Cobertura de Resultados Esperados de PCP
Captulo 8
129
8.18 Integracin
Las retrospectivas tambin dejaron enseanzas sobre los procedimientos de integracin. En ellas se haban
detectado varios problemas relacionados, y se haban propuesto asimismo soluciones. Algunas de estas soluciones
propuestas estn vinculadas a procedimientos ya implementados para ingeniera de pruebas, por lo que resultan
muy fciles de implementar.
riesgo o problema:
la integracin continua se est usando muy
limitadamente, sin considerar las componentes ya
desarrolladas, lo que puede traer consecuencias en el
sprint de estabilizacin (y ya las ha traido en alguno
casos)
cuando el producto comienza a estabilizarse y crecer el
ambiente de desarrollo es muy lento y la integracin
obstaculiza el desarrollo, resultando en horas perdidas
la integracin puede fracasar porque las interfaces no
son compatibles, lo que puede llevar a prdidas de
eficacia en el uso de los recursos
los cambios a las interfaces tienen efectos negativos en
las pruebas de regresin que no siempre se consideran
en el anlisis de impacto
cediendo a presiones propias los programadores suelen
subir cdigo defectuoso al ambiente de integracin
mitigacin:
ampliar el uso de la integracin continua para
conseguir que las pruebas de regresin se corran con
cierta frecuencia para minimizar el esfuerzo de
estabilizacin en el sprint final
contar con ambientes de integracin definidos para
los proyectos que sean acordes a sus necesidades, a
partir de una definicin bsica estndar y criterios de
ajuste
asegurar la compatibilidad de las interfaces mediante
una mini-inspeccin antes de subir un mdulo a
integrar
dedicar parte del procedimiento de anlisis de
impacto al anlisis de interfaces
utilizar inspecciones breves para analizar los

productos y auditar que se han corrido las pruebas
unitarias y se cubrieron los criterios
la integracin se realiza espontneamente sin seguir
orientar a los equipos para que generen sus propias
demasiadas pautas, salvo lo que est en scripts de la
reglas siempre que incluyan a las normas
herramienta
organizacionales o reciban dispensa para no hacerlo
en el pasado hemos credo haber aprobado una
los datos de la integracin deben ser cuidadosamente
integracin cuando en realidad no se haba corrido
ingresados en la herramienta y los resultados deben
todava
ser analizados como parte del scrum diario
algunos casos de la base de pruebas de regresin han
aadir a la descripcin del rol de ingeniero de pruebas
dejado de ser tiles y nuevos casos que debieran haber
el procedimiento de mantenimiento de la base de
sido includos no lo han sido
regresin
no en todos los casos se ha desarrollado la
orientar a los scrum master para que revisen el
documentacin prevista por contrato a la par del
backlog y cuestionen la falta de tareas relacionadas
producto en s, lo que a menudo provoca sofocones
con documentacin contractualmente obligatoria
sobre el final
cuando sea pertinente
Tabla 8.22: Acciones Relacionadas con Integracin Derivadas de Retrospectivas
Como parte del procedimiento habitual de integracin continua se aadi el correr pruebas de regresin
todos los viernes al salir para el fin de semana, para minimizar el esfuerzo de estabilizacin en el sprint final.
Al contar con ambientes de prueba bien definidos para los proyectos acordes a sus necesidades, se incorpor
naturalmente el ambiente de integracin, a partir de una definicin bsica estndar y criterios de ajuste que
integran la BiPro.
Cuando se sube un programa a la lnea base para su integracin continua, el colega que realiz las pruebas
correspondientes debe asegurar la compatibilidad de las interfaces mediante una mini-auditora antes de subirlo.
En el juego de planificacin se dedica ahora parte al anlisis de interfaces.
Se realizan mini-auditoras de configuracin y procesos para asegurar que se han corrido las pruebas unitarias
y se cubrieron los criterios de aprobacin de los mdulos antes de que puedan ser integrados.
Los equipos adaptan las normas organizacionales para realizar procedimientos de integracin, o reciben
dispensa para no hacerlo bajo justificacin bien documentada.
Los datos de la integracin surgen de la herramienta y los resultados son analizados a primera hora, como
parte del scrum diario.
El rol de ingeniero de pruebas tiene ahora documentada su responsabilidad por el procedimiento de
mantenimiento de la base de pruebas de regresin.
130
Captulo 8
Boria et al.
Es tarea de los Scrum master revisar diariamente el backlog y cuestionar la posible falta de tareas
relacionadas con documentacin obligatoria cuando sea pertinente por el acuerdo con el cliente.
Con todas estas mejoras el Comit de Gestin espera obtener buenos beneficios, manifestados en los
objetivos de negocio.
75. Los cambios introducidos permiten suponer que se cubren los resultados esperados de VER y
VAL.
76. La conduccin duda si esperar a llegar a implementar el Nivel C o hacer una evaluacin del D.
77. Se revisan los resultados esperados de PCP e ITP junto con las acciones resultantes de
retrospectivas y se implementan aprovechando cambios anteriores.
Captulo 8
131
CAPTULO 9 - AMPLIANDO LA CAPACIDAD DE DECISIN (NIVEL C de MPS-SW)

9.1 Una Gestin Ambiciosa
2
Hasta ac la gestin de T ha sido, en los dos aos y un mes que la hemos estado siguiendo, un proceso
slido, basado en decisiones estructuradas y con un profundo sentido de las opciones posibles y los riesgos que
entraaban. El xito obtenido con la implementacin de los ajustes a la ingeniera, realizados con nfasis en los
resultados esperados de los procesos de Nivel D del modelo MPS, han convencido a Marcela que la fuente donde
abrevan es slida, y ese es el mensaje que transmite a la conduccin. En la reunin mensual de Diciembre, la ms
importante del ao porque coincide con el cierre del ejercicio anual, Marcela hace su anuncio oficial: la ya no tan
pequea Tahini-Tahini va a realizar una evaluacin conjunta del Nivel C del MPS y del Nivel 3 (Definido) del CMMI
en el ao que abre. Ana, que ya saba del proyecto, lo apoya a viva voz. Alfredo mira alternativamente a una y a
otra sin saber qu decir. Los gemelos preguntan si los tres nuevos proyectos que estn encarando, as como las
extensiones a los sistemas de farmacia y hospital que se producen cada cuatrimestre, podrn recibir el apoyo de
recursos que requieren o si la demanda por las evaluaciones va a dificultar su xito. Marcela se dirige a Mariano,
interrogndolo con la mirada.
-
No hay duda, dice Mariano, las ventajas de entrar en el mercado internacional con productos
innovadores como los nuestros es incomparable. Podemos demorar proyectos y pagar las consecuencias
con creces si ser evaluados en el Nivel 3 nos trae un solo cliente del Hemisferio Norte.
Pero eso no tiene por qu ser as, dice Jessica, porque podemos alcanzar ese codiciado galardn sin
detener a los proyectos ni un segundo. Hasta que no venga el momento mismo de la evaluacin lo nico
que necesitamos es fondos para dos recursos, uno empleado tiempo completo y el otro, Mximo, para
que nos conduzca en las decisiones ms importantes.
9.2 Lder en Accin

"Managers are people who do things right and leaders are people
111
who do the right thing"
Marcela presenta un cuadro comparativo de las ganancias haciendo uso de una herramienta nueva (otra ms)
que introdujo Jessica, el rbol de decisin. Uno de los caminos del rbol representa el statu quo, con las
inversiones normales y las ganancias esperadas. Otra de las ramas muestra las inversiones a realizar para alcanzar
el nivel C y los beneficios esperados. Estos se derivan de un ejercicio que realizaron Ana, Mariano y Claudio,
analizando la expansin de mercado posible en base a las mejoras de calidad, as como los beneficios internos
inmediatos de bajar costos. Una tercera rama muestra los costos y beneficios de alcanzar tanto el nivel C como el
nivel Definido del CMMI. En esa rama se aade la expansin al mercado del hemisferio norte.
Figura 9.1: rbol de Decisin
111
[BENNIS, 1997], Learning to Lead
132
Captulo 9
Boria et al.
Status Quo
Nivel C
SCAMPI
112
Ingresos
Gastos
Ingresos
Gastos
Ingresos
Gastos
32.1
25.3
0.8
0.032
1.6
0.069
Probabilidad
0.98
0.9
0.85
Esperanza
31.458
25.3
0.72
0.032
1.36
0.069
Pago
6.158
0.688
1.291
Tabla 9.1: Tabla de Pagos del rbol de Decisin
Mariano interviene para sealar que ya han iniciado contacto con una importante farmacutica que quiere
2
hacer ingresar el producto de T en el mercado de Canad. Obtener el Nivel de Madurez 3, segn Mariano,
terminara de convencerlos y cerrara el negocio. La votacin es unnime a favor de la evaluacin conjunta. La
Tabla 9.1 muestra los clculos realizados para el rbol de la Figura 9.1.
Marcela elabora sobre los tres aspectos que son muy importantes para el nivel C de la MR-MPS: Formalizar la
gestin de riesgos, la gestin de las decisiones y desarrollar mtodos para que el reuso sea sistemtico.
-
Los tres puntos, seala Marcela, ya estn en nuestros procesos. Solo es cuestin de detallarlos aun
ms, ponerlos en papel y documentar su uso de manera ms estricta.
Los gemelos objetan el giro empleado por Marcela: Alberto la acusa de ser ecolgicamente incorrecta por
hablar de papel, Armando explica que en un mundo sin rboles el oxgeno pasa a ser un bien de los muy ricos. El
ambiente se distiende y la reunin termina con un brindis: Los Galarraga cumplen aos y han trado a la mesa de
trabajo Champagne Mumm Cordon Rouge del que se da buena cuenta en minutos.
9.3 Visin Estratgica de los Riesgos
2
T hace ms de un ao que ha comenzado a aprovechar los conocimientos adquiridos por el personal creando
activos en sus archivos. La biblioteca de proceso es continuamente actualizada y mejorada. Los ingenieros, que ya
pasan de ciento veinte, ya forman naturalmente grupos de inters en cada una de las disciplinas. Las anomalas en
la entrega de los productos y los retrasos en los proyectos estn empezando a verse como excepciones y no como
la regla. Cuando aparecen problemas son rpidamente identificados y resueltos. Los ingenieros estn alerta,
detectando los patrones que permiten anticiparse a los problemas, y ha introducido un mtodo sencillo para
capturar estos patrones en una tabla. Sobre esa base Marcela elabora un procedimiento de riesgos que es
compatible con lo actual y cubre los resultados esperados del proceso Gestin de Riesgos del MPS.
Consciente de los desvos y excesos en el uso de la palabra riesgo, como ilustra su abuso en varias tablas
113
que vimos ya en el Captulo 8 , Marcela procede a definir con precisin el significado y el uso del trmino dentro
2
2
de T . Siguiendo el uso de IEEE, el MPS y el CMMI, Riesgo en T es un problema potencial, es decir algo que no ha
114
ocurrido aun. Existe riesgo en todas las actividades, porque el futuro es incierto. Se le atribuye a Niels Bohr la
frase Nada es ms difcil de prever que el futuro e ironas aparte, nada es ms cierto desde nuestro conocimiento
2
cientfico. Marcela elige la forma ms amplia de definir un riesgo. Su uso en T parte de la definicin de problema.
Habitualmente reconocemos un problema como una situacin incmoda, molesta, un obstculo en nuestra vida o
proceso de negocios. Es, en definitiva, algo malo. Si miramos al problema como un problema intelectual, algo que
nos desafa a encontrar una mejora aun cuando la situacin no es mala, tenemos una mejor definicin de
problema. Por clasificarlos de algn modo para aclarar, podemos hablar de problemas de desempeo cuando la
situacin actual es peor que la esperada, problemas de mejora cuando la situacin actual no es tan buena como
deseamos, y problemas de mantenimiento cuando la situacin actual debe ser mantenida. En ese caso hay riesgos
de los tres tipos, el primero de los tipos coincide con la definicin habitual: Algo malo que pueda pasar. La
pregunta que se hace el que intenta identificarlos es Qu puede ocurrir que impida obtener el resultado
esperado? El segundo tipo es el riesgo de perder una oportunidad. Est relacionado con la innovacin y lo
112
113
114
SCAMPI son las siglas de Standard CMMI Appraisal Method for Process Improvement, el mtodo estndar y oficial de
evaluar la madurez de procesos contra el modelo CMMI
En las tablas derivadas de las retrospectivas la primera columna se intitula riesgos, pese a que eran problemas ya
detectados o incidentes. La segunda se intitula mitigacin aunque en realidad era un plan de accin para resolver el
problema.
http://www.aps.org/policy/reports/popa-reports/energy/modeling.cfm
Captulo 9
133
llamaremos riesgo de oportunidad. La pregunta que se hace el que intenta identificarlo es Qu estamos dejando
de considerar que puede darnos una ventaja competitiva?. Est claro que esta segunda pregunta va a ser mucho
menos frecuente que la primera, pero de todos modos Marcela propone extender el alcance a todos los aspectos
del negocio, por ejemplo las contrataciones, los proveedores, los salarios, la tecnologa, la ubicacin de las oficinas
115
2
y hasta los mtodos de evaluacin . Una modificacin a la poltica de calidad de T define el alcance de la
aplicacin de la gestin de riesgo con precisin.
2
Lo que Marcela se propone es que todos los que trabajan en T , desde Alfredo al ingeniero ms
recientemente incorporado, vean su trabajo como una serie infinita de toma de decisiones, cada una de ellas con
sus consecuencias. Al plantearse opciones para esas decisiones la persona tiene que preguntarse, o preguntar en el
caso de quines tienen capacidades directivas, Cul es el riesgo? Marcela piensa en una organizacin consciente
de sus riesgos, no en una que los evita en todos los casos. Ser consciente de un riesgo es comprender el impacto
que tiene si se materializa, es decir si deja de ser un riesgo para convertirse en un problema. La probabilidad de
que un riesgo se materialice es importante para hacer una evaluacin de como actuar al respecto. Por ejemplo, no
se puede descartar que antes de finalizar el ao un meteorito destruya la ciudad en que vivimos y trabajamos, con
las obvias nefastas consecuencias para los individuos que vivimos en ella y nuestros clientes, aun aquellos que
viven en otros pases. Pero el evento tiene muy baja probabilidad de ocurrir, por lo que preferimos ignorarlo. Esta
es una de las posibles respuestas ante un riesgo: Asumirlo y continuar con el plan. Hay dos motivos por los cuales
se asume un riesgo: O bien la probabilidad es tan baja que cualquier inversin en mitigarlo o planificar
contingencias es demasiado gasto, o bien estos gastos son tan altos que no justifican ser realizados, porque es
peor el remedio que la enfermedad. Si un riesgo es demasiado grande es posible que no haya mitigacin posible,
pero eso pone en cuestin si vale la pena continuar con el proyecto.
Marcela define el proceso de gestin del riesgo desde el primer contacto de ventas. Parte del proceso de
Mariano ha de ser analizar los riesgos antes de presentar una propuesta. Claudio colaborar en el anlisis
financiero, valor presente, perodo de repago y otras maneras de analizar el riesgo monetario. A cada momento se
116
siguen los pasos definidos por Boehm : Hay dos etapas, la de evaluacin del riesgo y la de control de los riesgos.
En la etapa de evaluacin se distinguen las siguientes actividades: Identificacin, Anlisis y Priorizacin. En la de
control las actividades son: Planificacin, Resolucin y Monitoreo. En los detalles de cada actividad Marcela se ha
tomado libertades para adaptarlos a las necesidades de la empresa.
Fase
preventa
Fuente de riesgos a
evaluar
cliente
dominio
tecnologa
competencia
reuso
115
116
117
alto
nuevo, procesos
dbiles, teora X de
117
gestin
desconocido, baja
tecnologa, alto
impacto en clientes
del cliente
novedosa, nuevas
API, nuevas
herramientas
existen buenos
proveedores con
mucha experiencia
escassima
probabilidad de
reuso
Categorias
medio
bajo
nuevo, procesos OK,

gestin moderna
conocido, procesos
OK, gestin moderna
conocido en parte,
tecnologa
moderna, impacto
medio en clientes
del cliente
conocida, algunas
nuevas
herramientas
existen buenos
proveedores con
nuestra misma
experiencia
algo de reuso pero
no en ciertos
mdulos crticos
conocido, tecnologa
de avanzada, impacto
manejable en el
cliente
conocida y compatible
100%
dominamos el
mercado
fundamentalmente
adaptaciones a
productos nuestros
Ya vimos en el Captulo 8 que se ha eliminado la evaluacin anual, remplazada por la evaluacin continua.
BOEHM, B., 1989, Software Risk Management.
http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y
134
Captulo 9
Boria et al.
Fase
kickoff
Fuente de riesgos a
evaluar
tradeoff de sprints
con requisitos
bajo
se puede modular la
funcionalidad para
reducir la duracin
se prefiere calidad en
lo entregado a muchas
funciones
entiende el
problema pero est
limitado en su
capadidad de
decisin
un poco ms alto
que lo habitual por
su duracin
operativo, resolutivo,
independiente, capaz
desarrollo nuevo vs
arreglos
nunca hay tiempo

para arreglar
porque lo nuevo
siempre tienen
mayor prioridad
hay que estirarse un

poco para poder
arreglar lo del sprint
anterior, pero es
manejable
el dueo del producto

entiende los
problemas y apoya
que se solucionen
antes de llegar a la
estabilizacin
mucha
funcionalidad
hay presin por

incluir siempre 'un
poco ms'
se puede descartar
alguna historia si no se
llega con la fecha
requisitos dbiles
el dueo del
producto no sabe
definir con claridad
lo que necesita
no hubo mucho
tiempo para
arreglar y el sprint
de estabilizacin es
corto
hay presin por

incluir siempre 'un
poco ms' pero hay
posibilidad de bajar
el ritmo cada dos
sprints
el dueo del
producto duda
sobre lo que
necesita
quedan cosas para
arreglar pero entran
en el sprint si no
surgen algunos
defectos
enmascarados
costos del proyecto
estabilizacin
Categorias
medio
demasiada
funcionalidad para
el release
planificado
no entiende el
problema y est
totalmente
impedido de tomar
decisiones
muy altos,
relacionados con la
tecnologa a
incorporar y la curva
de aprendizaje
dueo del producto
sprints
alto
costos de
mantenimiento
habituales

sabe lo que necesita y
sabe explicarlo
llegamos con muy
poco para arreglar, se
puede usar tiempo par
refactorear
entrega tarda
el dueo del
el dueo del
producto es
producto negocia
prefiere un producto
terminante respecto calidad por fecha de estable a que se
de la fecha de
entrega
entregue a tiempo
entrega y no hay
negociacin
Tabla 9.2: Estrategia de Riesgos de Alto Nivel, Fuentes y Categoras
La estrategia se refina despus de la preventa. La captura de conocimiento acerca de riesgos abarca las
fuentes, categoras y las medidas asociadas a su eliminacin, mitigacin, transferencia, disminucin, o tratamiento
de la contingencia. Hay ya ciertas mitigaciones que se han detectado y forman parte del conocimiento
2
almacenado. Por ejemplo, la primera decisin de un proyecto es el mtodo organizativo que se va a dar. En T los
ciclos de vida autorizados estn asociados al tipo de proyecto, para mitigar los riesgos: Kanban para proyectos muy
simples con tareas tcnicas difciles de separar en sashimi y que duran algo ms de lo habitual, Scrum para la
mayor parte de los proyectos, y FDD para aquellos proyectos donde el volumen de trabajo es tan grande que una
pirmide de Scrums hara que de hecho se estuviera trabajando como en una cascada simple. De hecho FDD no ha
sido ensayado todava, la organizacin no quiere tomar el riesgo de introducirlo cuando el cliente no es
suficientemente comprensivo.
Captulo 9
135
9.4 Definicin de un Riesgo

Detectar el riesgo no es equivalente a definirlo correctamente. Para poder hacer la gestin del riesgo ms
efectiva y eficiente es importante dedicarle tiempo a la redaccin de la definicin del riesgo. Se debe indicar
claramente la situacin actual, presente o potencial que dispara el riesgo. Esta formulacin diferencia entre
Puesto que y Puede que. Por ejemplo, Puesto que nuestra nica experta en sistemas de bases de datos
persistentes ha quedado embarazada es del primer tipo, la situacin ya est presente. El segundo caso es en s
mismo probable, por ejemplo, Puede que las componentes A y B, por ser ambas compradas de fabricantes
distintos, no sean compatibles entre s. En este caso no se sabe a ciencia cierta si eso es real, pero existe la
sospecha de que puede serlo. La segunda pare del enunciado del riesgo debe apuntar a las consecuencias. En los
casos en los que nuestro enunciado del riesgo comienza con puesto que el resto de la definicin tiene que dejar
claro que hay una probabilidad de que la consecuencia se materialice que no sea la certeza. Por ejemplo, el
enunciado Puesto que nuestra nica experta en sistemas de bases de datos persistentes ha quedado embarazada
es seguro que no podremos terminar a tiempo no es un riesgo, es un problema manifiesto. Para ms, est
descripto de tal manera que las condiciones resultantes en la prdida (no terminar a tiempo) no se puede analizar.
En cambio Puesto que nuestra nica experta en sistemas de bases de datos persistentes ha quedado embarazada
es probable que deba de dejar de asistir a la empresa durante los meses finales, por lo que es posible que se
resienta nuestro sprint de estabilizacin al no poder contar con ella 24 x 7 est redactado en trminos de riesgo y
nos da claras indicaciones de por donde atacarlo. Se puede montar un ambiente de tal manera que ella pueda
participar en el sprint desde su hogar, o entrenar ms personas para que ella pueda dirigirlos remotamente con
poca interaccin, o conseguir alguien para ese sprint que la suplante. Como se ve, es importante redactar el
enunciado del riesgo de manera que sea clara cul es la fuente del problema, no el embarazo ni la ausencia, sino la
falta de experiencia en el momento del sprint de estabilizacin.
La definicin en trminos de puede que es semejante, siguiendo el ejemplo, Puede que las componentes A
y B, por ser ambas compradas de fabricantes distintos, no sean compatibles entre s, y debamos invertir mucho
esfuerzo en hacer envoltorios que armen API compatibles entre ellas. Tome nota de que el enunciado Dado que
las componentes A y B, por ser ambas compradas de fabricantes distintos, no son compatibles entre s, debemos
invertir mucho esfuerzo en hacer envoltorios que armen API compatibles entre ellas no hace mencin a
probabilidad, es un problema que ya existe y hasta enuncia el plan de accin a seguir.
9.5 Captura de los Riesgos
Marcela ha adaptado una planilla para que sirva en la captura y gestin del riesgo.
Al explicar la planilla quedar claro el procedimiento de definicin, anlisis, priorizacin, monitoreo y control
2
de riesgos en T . La planilla comienza con una lista de datos correspondientes al proyecto en cuestin. Las
columnas de izquierda a derecha contienen: el ndice del riesgo, un nmero natural; el enunciado del riesgo,
dividido en Condicin y Consecuencia; la probabilidad de que el riesgo se materialice, es decir que se transforme
en un problema, calculada arbitrariamente como un nmero real entre cero y uno (ni cero, porque entonces no
hara falta controlar ese riesgo por ser imposible de afectar al proyecto, ni uno, porque entonces ya es un
problema); la prdida estimada para el proyecto en caso que el riesgo se materialice, medida en una escala de uno
a cien; la exposicin que trae el riesgo, definida como el producto entre probabilidad y prdida, y que es el valor
usado para priorizar el riesgo entre los dems, a mayor exposicin, mayor prioridad; el orden de prioridad que
ocupa ese riesgo en este anlisis, donde 1 es el de ms prioridad y 10 el de menor; la misma informacin respecto
a la ltima vez que se realiz el ejercicio de control de riesgos; el nmero de veces que el riesgo lleva en la lista, lo
que es indicativo de su maduracin o no; la accin, sea eliminacin, mitigacin, transferencia, disminucin, o
tratamiento de la contingencia que se va a tomar, incluyendo, cuando es un plan de contingencia, un disparador
para largarlo; y quin va a llevar adelante las acciones y cuando va a reportar su resultado.
136
Captulo 9
Boria et al.
Planilla de Definicin y Control de Riesgos

ID - identificador del riesgo
Descripcin del Riesgo - problema potencial ( condicin y consecuencia)
Prob - probabilidad de que el riesgo se transforme en un problema
Prioridad en este anlisis - ranking pro exposicin
Accin - acciones a llevar a cabo para lidiar con el riesgo
Descripcin del Riesgo
Aada las columnas que sean necesarias para monitorear la evolucin de los riesgos.
Perd - Prdida - potencial relativo de la prdida (monetaria) o un nmero entre 1 y 100) Exp - Exposicin - producto entre prob y perd
Prioridad la ltima vez - muestra el cambio ocurrido
# Veces en la lista - resistencia a las acciones
Quin - persona responsable por las acciones
Cuando - fecha en la que se revisarn las acciones
Prob Perd Exp
ID
Condicin
Nombre del Proyecto:

Fecha:
Preparado por:
Prioridad Prioridad # Veces

en este la ltima
en la
anlisis
vez
lista
Accin:
eliminacin, mitigacin, transferencia, disminucin, o
tratamiento de la contingencia
Quin
Cuando
Consecuencia
10
Figura 9.2: Planilla de Definicin, Monitoreo y Control de Riesgos
9.6 Estrategias de Control de Riesgos

En toda estrategia lo que cuenta es la secuenciacin de los esfuerzos. La primera parte de un anlisis
estratgico consiste en identificar los riesgos y priorizarlos. Una vez conocido el enemigo ahora hay que estimar
los esfuerzos que vamos a dedicar a combatirlo. Cada actividad tiene su costo y este costo no puede ser tal que el
2 2
proyecto se resienta por ellos. En primer lugar las estrategias de T (T tiene en sus guas de control de riesgos dos
estrategias para ser aplicadas por los proyectos) comienzan por analizar si es posible o deseable la eliminacin del
riesgo. Dado el ejemplo de la seccin anterior, Puede que las componentes A y B, por ser ambas compradas de
fabricantes distintos, no sean compatibles entre s, y debamos invertir mucho esfuerzo en hacer envoltorios que
armen API compatibles entre ellas debiramos ver si podemos eliminar ese riesgo. Una alternativa sugerida es
que construyamos las componentes internamente. Eso modifica el proyecto, los costos y la estructura del equipo,
trayendo sus propios riesgos. Otra es que desistamos del proyecto. Una tercera es que compremos informacin. Si
hiciramos un pequeo ensayo en un ambiente especialmente diseado para ello y viramos si A y B son
realmente incompatibles podramos tomar mejores decisiones y eliminar el riesgo de nuestra lista.
Si es imposible eliminarlo el prximo paso es intentar transferirlo. Si ha sido el cliente el que exige el uso de
las componentes, o si es el que tiene parmetros rgidos sobre la fecha de entrega o el costo, debiramos ser
capaces de ir con ellos y explicar el riesgo, pidindoles una clusula de riesgo que cubre el trabajo extra de
construir los envoltorios para generar la compatibilidad entre ellos, clusula que entra en efecto si el riesgo se
118
materializa. Si hemos sido nosotros mismos los que hemos tomado la decisin apresuradamente , entonces es
abusivo que intentemos hacer esto. Sin embargo, es posible que las ventajas de usar A y B sean tan grandes que
podamos negociar algn compromiso. Por ejemplo, puede que si en vez de B usamos C el resultado sea una
prdida menor de desempeo pero una ganancia muy grande en compatibilidad. De este modo se transfiere el
riesgo de incompatibilidad a un riesgo de desempeo.
Cuando no se puede eliminar o transferir el riesgo, el procedimiento pide que se intente mitigarlo. La
mitigacin es exitosa si se reduce la exposicin que el riesgo causa al proyecto. Esto se puede realizar de dos
maneras: O se reduce la probabilidad de que el riesgo se materialice o se reduce la prdida que el riesgo provoca.
119
Siguiendo con nuestro ejemplo, dada que la situacin de incompatibilidad es nuestro gato de Schrdinger ,
puesto que la incompatibilidad existe o no, solo que no lo sabemos, es imposible mitigar la probabilidad de que
sean incompatibles. Nuestra nica esperanza es mitigar el impacto, la prdida. La prdida la hemos expresado
118
119
Tarea para Marcela: modificar el mtodo de decisin de adquisiciones para incluir en la lista de chequeo la compatibilidad
entre componentes cuando se compran ms de una.
Gato de Schrdinger: es un experimento imaginario concebido en 1935 por el fsico Erwin Schrdinger para exponer una de
las consecuencias menos intuitivas de la mecnica cuntica. Un gato, junto con un matraz que contiene un veneno y una
fuente radiactiva, se coloca en una caja sellada. Si un contador Geiger detecta la radiacin, el frasco se rompe, liberando el
veneno que mata al gato. La interpretacin de la mecnica cuntica de la Escuela de Copenhague, implica que despus de
un tiempo, el gato est al mismo tiempo vivo y muerto
Captulo 9
137
como el esfuerzo invertido para construir artificialmente esa compatibilidad. Se le puede disminuir? Dejamos este
ejercicio de la imaginacin a cargo del lector, porque no se nos ocurre como.
Por ltimo, si todo lo dems falla o si sospechamos que las acciones pueden no ser efectivas, el
2
procedimiento de T llama al tratamiento de la contingencia. Se entiende por esto que se planifica tomar acciones
que actan contra el riesgo como problema. En el caso del ejemplo anterior, la contingencia es que sean
efectivamente incompatibles. En ese caso habr que construir los envoltorios para que se comuniquen a travs de
ellos. Cunto es que podemos esperar antes de incurrir en esos gastos extra? Puesto que nuestro enunciado es
puede que, eso indica que no estamos seguros de la incompatibilidad, solo temerosos de que ocurra. Empezar a
trabajar en los envoltorios antes de estar seguros es una prdida de esfuerzos. Se elige un evento o una fecha
como disparador de esos esfuerzos y posiblemente se rearme el plan de sprints para contemplarlo.
Figura 9.3: Matriz de Riesgos
9.7 Estrategia Conjunta

La gua de control de riesgos contempla el procedimiento de ataque a cada riesgo, pero la vida no es tan
simple. Cmo organizar los esfuerzos si son mltiples los riesgos que hay que atender? Marcela ha recogido dos
mtodos, uno simple y fcil de aplicar, la matriz de riesgos (Figura 9.3), y otro ms sofisticado que llama el espectro
de riesgos. Veamos ahora el ms sencillo primero.
Se ubican los riesgos en la matriz de la Figura 9.3, construida como se ve sobre dos ejes, la prdida en el
vertical y la probabilidad de ocurrencia en el horizontal. Se han elegido cinco intervalos en cada eje, aunque
podran haber sido otro nmero. La estrategia conjunta consiste en adaptar las actividades al grado de riesgo que
tiene cada uno. De ese modo no se invierte tiempo en intentar eliminar defectos que tienen poco impacto. Las
actividades relacionadas con los intervalos de diferente color se listan a la derecha del dibujo.
El otro mtodo es el del espectro de riesgos. La gua lo propone para proyectos que tengan muchos riesgos
pero cuya importancia estratgica hacen que valga la pena el llevarlos delante de todos modos. En ese caso se
asigna presupuestariamente una cantidad de dinero o esfuerzo para el tratamiento de los riesgos, y se analiza
como invertirlo mejor. Suele ocurrir que la distribucin de la exposicin siga un patrn parecido con el espectro
luminoso, no se distribuye uniformemente sino que hay franjas con un mayor nmero de ellos que otras de igual
tamao. Simplemente dividir el presupuesto de modo que al primer riesgo le toca ms, menos al segundo y as
sucesivamente no cumple con el objetivo de usar el esfuerzo de la mejor manera posible. Veamos un ejemplo:
ID
1
2
3
4
5
6
7
8
138
Probabilidad
0.8
0.8
0.8
0.8
0.6
0.5
0.5
0.5
Prdida
90
84
69
66
64
71
40
32
Exposicin
72
67.2
55.2
52.8
38.4
35.5
20
16
Captulo 9
Boria et al.
ID
Probabilidad
Prdida
Exposicin
9
0.3
37
11.1
10
0.3
33
9.9
Tabla 9.3: Ejemplo de Tabla (Parcial) de Riesgos
Los dos primeros riesgos estn muy prximos entre s. Como los nmeros han sido estimados para la prdida
y la probabilidad en cada caso sin contar con un razonamiento demasiado slido por detrs es difcil asegurar que
el riesgo 1 es mayor en exposicin que el 2. Una tcnica que se puede aplicar es el anlisis de sensibilidad, que
veremos luego, para entender mejor las variables en juego. La mejor estrategia es considerarlos de la misma
categora y tratarlos como iguales. Lo mismo pasa con los dos siguientes. Esto sugiere que se puede dividir el
presupuesto para tratamiento de riesgos entre las dos primeras categoras y simplemente monitorear los
restantes. En qu proporcin se reparten los recursos queda librado a la discrecin de cada equipo.
Marcela introduce a los gemelos en los vericuetos del MPS y recluta su ayuda para establecer la brecha con la
Gestin de Riesgos. Los gemelos concuerdan con ella en que el alcance de la gerencia de riesgos est bien
2
establecido en la poltica de calidad, y que se aplica universalmente en T . Colocan GRI 1 del lado de los resultados
alcanzados. La Gua de riesgos describe las fuentes y categoras de los riesgos, as como los parmetros para
analizarlos, priorizarlos y controlar el esfuerzo que se realiza (GRI 2). Las estrategias completan algunas de estas
cosas con aun mayor detalle (GRI 3). Cada proyecto ha hecho uso de este mtodo y la documentacin acorde se
discute en las reuniones mensuales del comit de gestin estratgica. (GRI 4, GRI 5, GRI 6). Se los revisa cada
semana, cada quincena o cada mes, segn dictamine la estrategia fijada, utilizando la plantilla a ese efecto. (GRI 7
y GRI 8). Las acciones correspondientes, sean de eliminacin, mitigacin, transferencia o contingencia, se
documentan y monitorean para asegurar su efectividad. Marcela est satisfecha, la Gua de Gestin de Riesgos
est de acuerdo con el MPS.
78. Tras un perodo de seis meses de estabilidad, Marcela anuncia los planes para pasar al Nivel C
en una evaluacin conjunta.
79. Jessica introduce una nueva herramienta de decisiones, el rbol de decisin.
80. Basndose en las presentaciones de Marcela y los resultados del rbol de decisin, el Comit de
Gestin aprueba de manera unnime la inversin para alcanzar el Nivel C del MPS en una
evaluacin conjunta con un SCAMPI de Nivel Definido (3).
81. La primera implementacin del Nivel C es la del proceso de gestin de riesgos, que se construye
e implanta en tiempo rcord.
82. Una vez difundido el uso de la Gua de Gestin de Riesgos, Marcela y los gemelos constatan que
cubre todos los resultados esperados de GRI en el MPS
9.8 Nota de Cautela
El economista y financista experto en riesgo Nassim Nicholas Taleb ha dedicado su vida a analizar cuestiones
relacionadas con el azar y la probabilidad. Sus ltimos dos libros, [TALEB, 2010] y [TALEB, 2012] exploran lo
imprevisto. Su tesis es que la normalidad de las cosas no es importante, que lo que realmente modela el mundo es
el azar, los grandes acontecimientos imprevisibles, que l llama cisnes negros. Sus libros estn llenos de ejemplos,
incluyendo la peste negra y la ocupacin de Amrica por los europeos en el Siglo XVI, de sucesos que parecan
imposibles a la generacin que los viva y que cambiaron las vidas de las personas y las trayectorias de las
120
naciones. Esta visin del azar, compartida en otras ciencias , fuerza a las organizaciones a repensar su estructura
y el manejo de riesgo. Puesto que un cisne negro no se puede prever, es imprescindible organizarse para que la
llegada del mismo no sea destructiva en el corto, mediano y largo plazo. En el corto plazo las empresas y
organizaciones deberan crear planes de contingencia alineados con su supervivencia ante desastres, al estilo de
[TOIGO, 2002]. En el mediano plazo las empresas y organizaciones tienen que tener la flexibilidad y la
adaptabilidad para no solo tolerar las nuevas circunstancias, sino aprovecharlas. En el largo plazo las empresas y
las organizaciones deben saber que si se anquilosan el prximo cisne negro las destruir y deben segmentarse,
dividirse y multiplicarse sin endurecer sus canales de informacin.
120
Es la tesis dominante en el neo-Darwinismo, ver por ejemplo, Dinosaur in a Haystack: Reflections in Natural History, [GOULD
S., 1996].
Captulo 9
139
9.9 Decisiones Formales

Del mismo modo en que los riesgos son analizados siguiendo procedimientos bien definidos para agregar
valor, recogiendo nuevos riesgos y las soluciones correspondientes que se deben considerar, hay decisiones
121
especiales que se hacen, cuando corresponde, sobre la base de mtodos formales . El propsito de usar mtodos
formales al tomar decisiones, es que siguiendo un estndar formal se pueden almacenar, comparar, analizar y
2
reutilizarse las decisiones basndose en los resultados que arrojan. Al principio, T tena slo mtodos muy
bsicos, basados en matrices de Pugh con pesos entre alternativas, pero la importancia de las decisiones ha hecho
clara la necesidad de herramientas ms potentes, incluyendo rboles de decisin, simulaciones, modelos y
2
correlaciones simples. T se ha iniciado correctamente en el camino de la alta madurez en sus procesos
estratgicos.
Veamos como lo ha hecho. Nuevamente Marcela con su bagaje de la Maestra en Administracin ha acudido
122
a un profesor suyo, el Dr. Zito, quien le ha recomendado varias lecturas , de las cules extrajo Marcela poderosas
ideas que transform en una Gua de Aplicacin de Decisiones.
La Gua es parte del material que se usa en la induccin de ingreso de nuevo personal. La justificacin reside
en que en todo proyecto de software a menudo se enfrenta el equipo con la necesidad de tomar una decisin. En
casi todas esas ocasiones las alternativas estn claras y las variables que las diferencian son claramente
observables y fciles de comparar. Seleccionar entre las alternativas resulta sencillo y justificar la decisin tampoco
implica un costo extra para el equipo: Las caractersticas de la solucin son obvias, la generacin de alternativas
sencilla y la decisin es una consecuencia lgica de aplicar bien los pasos anteriores. En esos casos, la aplicacin
documentada de un proceso formal es innecesaria. Pero en ocasiones la decisin importa un riesgo muy alto para
el proyecto y resulta poco aconsejable tomarla de manera informal. Las decisiones difciles no dejarn de serlo
por ser tomadas formalmente, pero si se ejecuta el procedimiento formal paso a paso, la organizacin en su
conjunto consigue aprender de sus errores cuando los comete. De otra manera, las mismas decisiones se pueden
tomar repetidas veces en distintos proyectos sin que haya necesariamente ocurrido un aprendizaje de uno a otro.
La Gua formaliza el proceso de toma de decisiones para garantizar que se genera y captura toda la informacin
necesaria de modo de que si la decisin es acertada se pueda repetir y si no lo es, que se pueda analizar lo que se
decidi para mejorar esa decisin en futuros proyectos.
El Procedimiento de Anlisis de Alternativas y Toma de Decisiones (PAyTDD) permite a la organizacin tomar
decisiones de manera consistente. En particular, el PAyTDD ayuda a los participantes en una decisin a tomar
decisiones difciles, aquellas que entraan riesgo a bienes o personas. El PAyTDD es un procedimiento sistemtico
que describe paso a paso las actividades a realizar para poder formalizar la generacin, documentacin, evaluacin
y seleccin de alternativas entre el espacio de soluciones de un problema. Consiste en identificar claramente el
problema a resolver, plantear objetivos de la solucin (sus atributos), generar (identificar) alternativas,
descomponer el problema y modelarlo, medir las alternativas contra el mtodo de evaluacin y seleccionar la
mejor entre ellas. El Procedimiento de Anlisis de Alternativas y Toma de Decisiones (PAyTDD) no fue construido
con el propsito de ser aplicado a todas las decisiones que se toman en un equipo. La lista que sigue pretende ser
una gua de la aplicacin del procedimiento, no necesariamente exhaustiva. El PAyTDD puede ser utilizado en
mltiples ocasiones, segn sea til a criterio del equipo o de la gerencia de la organizacin.
Para la aplicacin del PAyTDD la Gua establece claros parmetros: El PAyTDD debe ser utilizado cuando el
equipo se enfrente a decisiones que tienen una o ms de las siguientes caractersticas: (a) La decisin est
relacionada con un tpico que se considera de alto riesgo que est siendo monitoreado formalmente, o (b) La
decisin afecta el plan de trabajo de modo que se impacta en ms de un 5% la lnea base, o (c) La decisin afecta el
plan de trabajo de modo que se impacta en ms de un 5% el presupuesto, o (d) La decisin afecta el plan de
trabajo de modo que se impacta en ms de un 5% la fecha de entrega del producto, o (e) La decisin afecta el plan
de trabajo de modo que se impacta en ms de un 5% la calidad final del producto, o (f) El cliente requiere que la
toma de decisiones quede integralmente documentada para la decisin en cuestin, o (g) El impacto estimado de
la decisin supera en ms de un 100% el costo esperado de aplicar el procedimiento PAyTDD. El PAyTDD contiene
los siguientes pasos:
121
122
De hecho en la literatura hay muchas publicaciones que hablan a la vez de riegos y decisiones formales.
En particular el Dr. Zito recomend el libro de CLEMEN, 1997, pero Marcela tambin encontr til un libro mucho ms
sencillo, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, de [Schuyler 1996].
140
Captulo 9
Boria et al.
1.
2.
3.
4.
5.
6.
7.
8.
Definir correctamente al problema a resolver.

Establecer atributos deseables de la solucin.
Definir mtodos de medicin de los atributos seleccionados.
Disear mtodos de evaluacin de las soluciones.
Generar o descubrir selecciones alternativas.
Aplicar a cada solucin generada la medicin de los atributos deseables.
Evaluar mediante los mtodos seleccionados las soluciones generadas.
Seleccionar la mejor alternativa.
Tabla 9.4: Definicin de los Pasos del PAyTDD
Desarrollaremos cada uno de los pasos con un poco ms de detalle. Comenzamos por el paso 1, Definicin del
Problema. El propsito de este paso es establecer el enfoque del problema y asegurar que se pretende resolver el
problema correcto. Se busca alinear el enfoque con los objetivos de negocio de la organizacin e identificar las
causas principales del problema, para usarlas como entrada al paso de seleccin de soluciones alternativas. Las
tareas Involucradas son Fijar los objetivos de Resolucin del Problema; Identificar y listar diferentes puntos de vista
sobre que constituye el problema; Reducir por agrupamiento el nmero de temas a una cantidad manejable;
Rankear los temas en orden de importancia para el objetivo del proyecto; Realizar un anlisis de las causas
profundas de los posibles problemas; Listar cada una de las causas profundas consideradas y reducirlas por
agrupamiento; Dividir las causas en tres grandes categoras: inmediatas, mediatas, a considerar alguna vez. Los
pasos requieren que los participantes estn capacitados para realizar tormenta de ideas, agrupamiento de temas y
el uso de herramientas como el diagrama de causa-efecto, jerarqua de objetivos, diagrama de Ishikawa o
diagrama de espina de pescado. Tambin deben ser suficientemente responsables para poder realizar un triage de
los problemas.
El paso 2, Atributos de la Solucin tiene como propsito establecer los objetivos que tienen que ser
cumplidos por una solucin, es decir, definir los atributos de una solucin aceptable en trminos de los objetivos.
La nica tarea es identificar los atributos de una buena solucin.
El paso 3, Mtodos de Medicin tiene como propsito fijar mediciones objetivas de los atributos que deben
pertenecer a la solucin elegida. Las tareas involucradas son las que siguen: Definir el indicador adecuado para el
atributo en cuestin, Describir los criterios de anlisis involucrados en el modelo de medicin, Listar las mediciones
derivadas de las mediciones bsicas y las funciones de composicin requeridas, Listar las mediciones bsicas y su
mtodo de medicin, y Definir claramente las unidades de cada medicin en cada nivel.
El paso 4, Mtodos de Evaluacin tiene como propsito describir el o los mtodos que permitan discriminar
entre soluciones alternativas. Las tareas involucradas son las que siguen: Jerarquizar y dar pesos relativos a los
diferentes atributos de las soluciones, Ponderar posibles relaciones entre atributos considerados independientes, y
Definir funciones que ponderen los resultados obtenidos a travs de los indicadores para poder comparar entre
soluciones. En principio los atributos elegidos para representar una buena solucin son independientes unos de los
otros. Las diferentes soluciones exigen que se realice un anlisis de los pesos relativos entre los atributos para
poder ponderarlos, puesto que si no fuera as los resultados, al encontrarse en un espacio multi-dimensional,
resultan incomparables. Este mecanismo se conoce como trade-off analysis.
El paso 5, Soluciones Alternativas tiene como propsito definir un conjunto de soluciones que puedan
resolver el problema. Las tareas involucradas son las que siguen: Revisar la lista de causas profundas de realizacin
inmediata, Generar un ranking por prioridad de causa, y Sugerir soluciones alternativas a cada causa de problemas
detectada. Si bien esta actividad puede realizarse de manera inmediata a la identificacin del problema, es
aconsejable postergar su realizacin hasta que haya un conocimiento ms profundo de la naturaleza de la
solucin, cosa que las actividades listadas antes que esta pueden proveer. Por otra parte, es posible que durante la
realizacin de la actividad 1. Definicin del Problema sea natural la identificacin de posibles soluciones como
colofn de la tarea Identificar causas profundas. Cada equipo y cada circunstancia deben indicar cul de las dos
opciones es la correcta para la ocasin.
El paso 6, Mediciones de las Alternativas tiene como propsito obtener indicadores para cada solucin
alternativa definida a partir de la medicin de los atributos pre-definidos para poder evaluarlas. Hay una sola tarea
involucrada: Aplicar las mediciones definidas en 3 (Mtodos de Medicin) a las alternativas identificadas en 5.
(Soluciones Alternativas).
El paso 7, Evaluacin de las Alternativas tiene como propsito generar la tabla final de resultados para poder
seleccionar la solucin a adoptar. Las tareas involucradas son: Calcular el valor de cada una de las alternativas
Captulo 9
141
utilizando los valores obtenidos en la medicin de los atributos y la funcin de evaluacin antes definida, Ordenar
las soluciones en orden descendente y presentarlas en forma de tabla, Revisar los resultados y corregir las
herramientas cuando el orden obtenido contradiga el sentido comn. Llegado este punto es bueno revisar lo
actuado a lo largo de todo el proceso, juzgndolo a partir de la tabla generada. Si los resultados contradicen el
sentido comn es bueno preguntarse si es ste quien debe ser modificado, o si se han introducido errores de
concepto en las funciones definidas para medir y combinar mediciones en la construccin del valor de la solucin
individual.
El paso 8, Seleccin de la Mejor Alternativa tiene como propsito el que dice el ttulo, obviamente. Las tareas
involucradas son: Revisar y explicar los resultados de la tabla final, Identificar y exponer pros y contras de la mejor
alternativa, Definir con precisin el impacto de la alternativa en trminos de planes y tareas, y Obtener consenso
en adoptar la solucin de mejor valor para la organizacin. Un rasgo de madurez organizacional es la
implementacin inteligente de soluciones elegidas a travs de mtodos objetivos. En este punto la solucin debe
ser desplegada con detalle para que la conduccin tome la decisin de manera consciente y responsable.
2
Marcela se propone agregar adems los mtodos al repertorio de toma de decisiones de T . Primero redacta
instrucciones para construir una jerarqua de objetivos. Dado el problema que se trata de identificar se busca el
efecto que se trata de conseguir. Por ejemplo, tenemos que decidir entre dos proveedores de un producto. Cul
es el objetivo? Habr quizs muchos, de modo que entender cul es el ms importante es crucial para la decisin.
Digamos que el equipo se divide entre los que creen que entregar a tiempo es el objetivo y aquellos que creen
que entregar con calidad es el objetivo, y que la eleccin surge clara de cul es el que se elija. Eso puede paralizar
la decisin completamente, de modo que es necesario encontrar un objetivo de orden mayor que los contenga. En
este caso podra ser entregar a tiempo y con calidad, que no ayuda mucho, o mejor entregar siempre a tiempo.
Este ltimo objetivo es mejor porque nos lleva a analizar el impacto que tiene entregar con baja calidad este
producto en los proyectos futuros (Figura 9.4). Cuntos recursos sern distrados para realizar enmiendas en el
producto que entregamos con defectos conocidos? Esto lleva rpidamente a otra herramienta de pensamiento, el
rbol de decisin. Cundo las decisiones se encadenan, la matriz de Pugh no captura eso de manera directa. Es
necesaria una nueva herramienta, que ya vimos en el principio de este captulo, en la Figura 9.1, introducida por
Jessica para analizar la decisin de ir o no a la evaluacin de Nivel C y de hacerla o no conjunta.
Figura 9.4: rbol de Objetivos
Cuando aparece la probabilidad en el anlisis, y a menudo ese es el caso en la toma de decisiones, puesto que
2
se est planteando el problema en un ambiente de relativa incertidumbre, la herramienta que se considera en T
es el rbol de decisin. El rbol nace de un nodo raz del que salen las primeras decisiones, puesto que el rbol
puede usarse para tomar decisiones combinadas, sean estas independientes o no unas de otras. Por ejemplo se
puede usar para decidir entre proveedores de un producto semejante y a la vez decidir si se les contrata el
mantenimiento o no (las decisiones son independientes) o se puede usar para decidir entre dos productos, uno
con adaptaciones y otro sin ellas, y decidir conjuntamente si se subcontrata la adaptacin (las decisiones no son
independientes, una de las ramas quedar vaca porque la decisin de adaptacin solo aplica en un caso). Esta
versatilidad para adaptarse a decisiones complejas es el rasgo ms destacado del rbol de decisin. Tampoco hay
restricciones demasiado grandes sobre su sintaxis, lo importante es que las ideas se expresen claramente. La tabla
de pagos (Tabla 9.1) que acompaa al rbol de decisin ejemplifica ms claramente la obtencin de resultados.
142
Captulo 9
Boria et al.
Para completar el ejemplo, veamos como se puede refinar el rbol para un anlisis de distintas posibilidades
en el caso de optarse por el Nivel C del MR-MPS-SW (Figura 9.5)
Figura 9.5: rbol de Decisin Refinado
La tabla de pagos correspondiente, con comentarios, se muestra en la Figura 9.6.
Figura 9.6: Tabla de Pagos Correspondiente al rbol de Decisin Refinado
Marcela aade otra tcnica al repertorio, el diagrama de dependencias o diagrama de influencias. Un

diagrama de influencia es una representacin visual simple en forma de grafo de un problema de decisin. Ofrece
una manera intuitiva de identificar y representar elementos esenciales de un problema de este tipo, incluyendo
objetivos, decisiones, elementos de incertidumbre ligados a probabilidad y las relaciones entre ellos.
En el grafo podemos diferenciar entre nodos y arcos. Los arcos son dirigidos y representan relaciones entre
los nodos. Los nodos representan decisiones (nodos cuadrangulares, llamados nodos de decisin), variables
aleatorias (nodos ovalados, llamados nodos estocsticos) cuyo valor es conocido solo en probabilidad, o bien
utilidades (nodos en forma de rombo, llamados nodos de valor).
Por ejemplo, ampliando el diagrama de jerarqua de objetivos con decisiones de inversin en marketing
podemos obtener un diagrama de dominio como el que se muestra en la Figura 9.7.
Captulo 9
143
Figura 9.7: Diagrama de Influencias con Inclusin de Otras Inversiones
En el diagrama de la Figura 9.7 se asume que el tamao del mercado es una variable aleatoria que no puede
ser influenciada por las decisiones que se tomen. Esto podra ser revisado, si la inversin en marketing pudiera
alterar esto, por ejemplo, incluyendo clientes de otros pases. Tambin pudiera ser que haya otras decisiones que
influyan en esa variable. De todos modos, en aquellas variables donde opera el azar mantendremos nodos
estocsticos en el diagrama aunque sean dependientes, como es el caso de costos. Tambin se puede notar que la
calidad del producto influye en la cuota de mercado y en los costos. El nodo nmero de licencias vendidas es
redundante, puesto que se desprende su valor de cuota de mercado y tamao de mercado, pero el propsito de
un diagrama de influencias es mostrar las relaciones, por lo que su inclusin no vulnera los objetivos. El diagrama
de influencias es una herramienta para la discusin de ideas, no un objetivo en s mismo. Una vez que se entienden
las relaciones entre las variables se utilizan otras tcnicas como apoyo a la decisin.
Uno de los problemas de la estimacin es la inseguridad sobre los valores estimados. La variacin de los
mismos es importante en funcin de comprender el impacto de una decisin. Supongamos que el tamao del
mercado es de varios millones de licencias posibles. Por fijar un nmero, digamos que se trata de 10.000.000 de
licencias. Ahora bien, si cada licencia representa un ingreso de 1.000 dlares anuales, estamos hablando de un
mercado de 10.000.000.000 de dlares. Una variacin de un punto en la cuota de mercado representa entonces
100.000.000 de dlares. Parece razonable entonces que se utilicen los medios ms potentes en estimar si se trata
de una cuota de 1% o de 0,002%, sobre todo si la calidad del producto influye de manera decisiva en esta cifra.
Este tipo de anlisis, el de entender para entender hasta qu punto la incertidumbre asociada a sus parmetros
numricos podra hacer variar la utilidad esperada afectando las decisiones, o en otras palabras, donde hay que
invertir en conocimiento para disminuir la incertidumbre, se denomina anlisis de sensibilidad y la herramienta
ms comn para realizarla es el diagrama de tornado.
Estos diagramas muestran grficamente los cambios que se producen en la utilidad esperada cuando vara
una cantidad o valor especfico. Si vamos cambiando una a una las variables manteniendo las dems en su valor
original obtendremos un rango de utilidades esperadas por cada una de ellas. Estos rangos se representan como
barras en un grfico. Estas barras se ordenan de arriba a abajo y de ms larga a menos larga, de modo que el
grfico se parece a un tornado. Las ms largas indican que el cambio de los valores de la variable que representan
implica un mayor cambio en la utilidad esperada, lo que es lo mismo que decir que la importancia de una variable
en alcanzar un resultado es ms grande cuanto ms grande sea la barra correspondiente en el diagrama de
tornado. Generalmente se hacen variar los valores entre dos extremos, el mnimo probable y el mximo probable,
de modo que la incertidumbre reflejada puede reflejarse en el impacto sobre el objetivo. Para las variables que no
muestran sensibilidad, invertir en mejorar el conocimiento de su incertidumbre no es til, as como mejorar su
valor en funcin de ello tampoco lo es.
El diagrama de la Figura 9.8 ha sido construido sin ninguna base de frmulas al solo efecto de ilustrar la forma
que tienen los diagramas de tornado. Si las frmulas que produjeron ese diagrama existieran, del diagrama se lee
que el tamao del mercado es la variable que ms influye en el objetivo de mrgenes. Invertir para tener mejor
conocimiento de ese tamao es sensato. Por lo contrario, nuestro objetivo de aumentar los mrgenes parece ser
inelstico relativamente al presupuesto de Marketing. Sera mejor transferir ese presupuesto a mejorar la calidad
del producto, que est bajo nuestro control, para aumentar as los mrgenes.
144
Captulo 9
Boria et al.
Figura 9.8: Diagrama de Tornado
Para construir el diagrama de tornado una herramienta til es conocer la dependencia estadstica entre las
variables. Este conocimiento se expresa en una ecuacin llamada de regresin que modela la relacin entre una
variable llamada dependiente, en nuestro caso Mrgenes, y un conjunto de variables independientes que
influyen en el comportamiento de la variable dependiente. Este modelo asume la forma de una ecuacin Y = c 0 + c1
X1 + c2 X2 + + cn Xn + . Los coeficientes cj son los que determinan la variabilidad correspondiente en el diagrama
de tornado. Un coeficiente muy grande en comparacin a los dems permite suponer que el impacto de la
variacin de la variable independiente correspondiente es mayor que el de las dems. Esto, por supuesto, est
limitado a que dicha variacin sea posible. El coeficiente c0 es el que establece la ordenada al origen, es decir el
valor de Y cuando todos los valores independientes son nulos. El coeficiente es un artificio, se le llama trmino
aleatorio y solo existe para que se cumpla la igualdad. Si se conoce ese valor entonces se puede conocer el
ajuste de la ecuacin.
El problema de la regresin consiste en elegir unos valores determinados para los parmetros desconocidos
cj, de modo que la ecuacin quede completamente especificada. Para ello se necesita un conjunto de
observaciones. En una observacin cualquiera i-sima (i=1,... n) se registra el comportamiento simultneo de la
variable dependiente y las variables explicativas (las perturbaciones aleatorias se suponen no observables).
Mediante el uso de tcnicas estadsticas se obtienen dichos coeficientes. Dada la existencia de mltiples
herramientas de clculo de dichos coeficientes (empezando por Excel) y la naturaleza de este libro dispensaremos
123
al lector de los detalles matemticos y remitimos a los interesados a la literatura clsica . El uso que se le da a la
2
ecuacin de regresin en T es el de poder calcular los valores dependientes para un rbol de decisin, pero
veremos que de este modesto inicio surge una aplicacin muy madura, en el Captulo siguiente.
83. Marcela sigue consejos de su profesor e implementa una Gua de decisiones que cumple
claramente con los preceptos del MPS para el proceso GDE.
84. El proceso para toma de decisiones es piloteado y aprobado para su difusin.
85. Marcela agrega una Gua de Mtodos para que las decisiones no se limiten tan solo a matrices
de Pugh.
9.10 La Fbrica de Componentes
2
Mariano llega muy excitado a las oficinas de T un martes por la maana. Acaba de bajar del avin que lo
trajo de Toronto y llama a una reunin urgente del comit de gestin. Sentado en la sala de reuniones espera a
que lleguen los dems. Uno a uno van saludando, se sirven su primer cafecito del da y preguntan el motivo de
tanta urgencia a Mariano, que sonre enigmticamente y desva la conversacin hacia otros tpicos, como la
turbulencia que siempre se hace presente sobre el ecuador en los vuelos, o la baja temperatura que se ha hecho
costumbre en el interior de los aviones. ltimos llegan Ana y Alfredo, que tuvieron que pasar antes por la
guardera. Mariano se para, respira hondo y comienza sin ahorra detalles:
123
[SPIEGEL, M., 2011] es nuestro libro de cabecera para Estadstica Elemental.
Captulo 9
145
Colegas de T , bienvenidos a la gran empresa. Ayer firmamos con TransKND un acuerdo de

entendimiento para que financien la reingeniera de nuestro producto central para hospitales y farmacias.
Su financiacin cubre la creacin de una arquitectura de lnea de producto orientada a los servicios, SOA.
La inversin les da derechos de comercializacin exclusivos en mercados internacionales, pero no les da
2
ningn privilegio tcnico ni participacin alguna en decisiones financieras internas a T . En este momento
est reunido el Board de TransKND en Toronto para ratificar o rechazar el acuerdo, del mismo modo que
nosotros lo estamos haciendo ac. Revisemos el acuerdo.
Acto seguido distribuye copias a cada uno, previamente marcadas con resaltador las partes importantes. El
Comit discute varias horas, pero al finalizar la discusin se aprueba el acuerdo y se encomienda a Mariano y
Claudio la firma del contrato. Ana tambin va a participar por la parte tcnica. Alcanzado el resultado Mariano
disca el nmero de su contraparte en TransKND y los empresarios se saludan, se lleg al mismo resultado positivo
en el hemisferio norte, hay alianza. La reunin se disuelve antes que los gemelos tengan tiempo de ir a buscar ms
Mumm.
Ni bien salen al pasillo, Ana se pega a Marcela y solicita su ayuda. Entre las dos y con apoyo de los dems
deben dar forma al proceso que se utilizar para la reingeniera y en lo sucesivo, para que todos los proyectos se
aprovechen de SOA.
9.11 Service Oriented Architecture (SOA) para Principiantes
124
SOA es un concepto que aplica en la construccin de sistemas distribuidos de gran porte. Para comprender
SOA es fundamental entender las propiedades de este tipo de sistemas. En la actualidad esto significa que hay que
poder integrar cdigo legado, porque nadie puede parar las mquinas y volver atrs la historia cuando los sistemas
pasan los millones de lneas de cdigo. De entrada un proyecto de SOA es entonces ms parecido a un proyecto de
reingeniera que a un proyecto de desarrollo. Involucra cambiar la estructura de un sistema pero sin rescribirlo.
Hay que desacoplar y envolver los servicios que ya se estn brindando para volcarlos en un formato que permite
construir fcilmente a partir de las partes resultantes.
Los servicios son unidades de funcionalidad no asociadas, dbilmente acopladas que no tienen llamadas entre
ellas. Cada servicio se refiere a una accin, como llenar una solicitud en lnea para una cuenta, o ver un extracto de
cuenta en lnea, o la colocacin de una reserva online o comprar billetes de avin.
Los desarrolladores que utilizan SOA asocian objetos individuales (servicios) de SOA mediante el uso de la
orquestacin. En el proceso de orquestacin de la funcionalidad el desarrollador de software asocia (servicios) en
una disposicin no jerrquica con una herramienta de software que contiene una lista completa de todos los
servicios disponibles, sus caractersticas, as como los medios para construir una aplicacin que utiliza estas
fuentes. Tiene entonces que existir un sistema de comunicacin heterogneo para que se puedan compatibilizar
2
arquitecturas de dcadas anteriores con los ltimos avances tecnolgicos. Veamos el producto estrella de T , el
sistema que vincula el estado de cada paciente con su historia clnica, la medicacin y la farmacia del hospital, as
como las farmacias proveedoras de los mismos. Ya tiene tres aos de desarrollo y ha crecido a ms de un milln y
medio de lneas de cdigo. Hay muchas reglas de negocio embutidas que no se pueden arrojar por la ventana o
intentar recodificar en nuevos lenguajes y probarlas en nuevos ambientes. Es imprescindible preservarlas. Esto
sugiere que hagamos los menores cambios posibles.
2
Pero ahora imaginemos el nuevo gran producto de T , el sistema hospitalario, hoy colgado de la nube, pero
conectando a los enfermeros, mdicos, pacientes, familiares de los pacientes, mdicos de cabecera, sistemas de
ambulancia y todos los otros integrantes de la gran familia de la industria de la salud. Hay que desacoplar el cdigo
de las interfaces y generar un protocolo para que los telfonos, las Blackberry, las tabletas, las laptop, y toda otra
futura invencin que aproveche corrientes de bits se puedan aprovechar de esas reglas de negocio y aumentar la
capacidad y velocidad de la decisin de los interesados. En lugar de llamarse los servicios entre s por mtodos o
rutinas de su cdigo fuente, utilizan protocolos definidos que describen cmo los servicios se pasan y analizan
mensajes mediante metadatos de descripcin.
Detrs de esto y para permitir que funcione se requieren que estos metadatos tengan el suficiente detalle
para describir no slo las caractersticas de estos servicios, sino tambin los datos que los propulsan a funcionar.
Los programadores han hecho un uso extensivo de XML en SOA para estructurar los datos descriptos en un
124
[JOSUTTIS, N.,2009]
146
Captulo 9
Boria et al.
envoltorio casi exhaustivo de la descripcin del contenido. Anlogamente, el lenguaje de descripcin de servicios
Web (WSDL) por lo general describe los servicios en s, mientras que en el protocolo SOAP se describen los
protocolos de comunicacin. Si estos lenguajes de descripcin son las mejores posibles para el trabajo, y si se
convertir en o seguirn siendo los favoritos en el futuro, son preguntas abiertas. A partir de 2008 SOA depende de
los datos y servicios que son descritos por metadatos que deben cumplir con los siguientes dos criterios:
1.
2.
Los metadatos deben venir en forma tal que los sistemas de software los pueden utilizar para
configurarse dinmicamente mediante el descubrimiento y la incorporacin de servicios definidos,
manteniendo coherencia y integridad. Por ejemplo, los metadatos pueden ser utilizados por otras
aplicaciones, como un catlogo, para realizar la deteccin automtica de los servicios sin necesidad de
modificar el contrato funcional de un servicio.
Los metadatos deben venir en una forma que los diseadores de sistemas pueden comprender y
manejar con un gasto razonable de costo y esfuerzo.
SOA tiene como objetivo permitir a los usuarios encadenar piezas bastante grandes de funcionalidad para
formar aplicaciones ad hoc que se construyen casi por completo a partir de los servicios de software existentes.
Cunto ms grande es el bloque, menor la cantidad de puntos de interface necesarios para implementar cualquier
conjunto dado de funcionalidad; sin embargo, si los trozos de funcionalidad son muy grandes puede no resultar
suficientemente granular cada uno de ellos como para ser reutilizado fcilmente. Cada interface lleva consigo una
cierta cantidad de gravamen de proceso, por lo que la granularidad de los servicios es una consideracin de
rendimiento, tanto para el servicio como para futuros usos del mismo. Demasiado pequeo sobrecarga las
interfaces, demasiado grande reduce el reuso. Esta caracterstica hace que sea muy rentable el uso de SOA en
dominios especficos, en vez de dominios muy generales.
Los servicios SOA estn ms dbilmente acoplados que las funciones de biblioteca conectadas para formar un
ejecutable. Los servicios SOA tambin se ejecutan en wrappers "seguros" (como Java o .NET) y en otros lenguajes
de programacin que gestionan la asignacin de memoria y recuperacin, permiten enlace ad hoc y tardo, y
proporcionan un cierto grado indeterminado de tipo de datos (data typing).
SOA como arquitectura se basa en la orientacin a servicios como principio fundamental de diseo. Si un
servicio presenta una interfaz simple que abstrae la complejidad subyacente, los usuarios pueden acceder a
servicios independientes sin saber como se lo implement, el Santo Grial del reuso. La gran promesa de SOA es
que el costo marginal de la creacin de la ensima aplicacin es bajo, puesto que todo el software necesario ya
existe porque ha sido creado para satisfacer los requisitos de otras aplicaciones anteriores. Idealmente, uno slo
necesita orquestacin para producir una nueva aplicacin.
Con el fin de utilizar eficientemente un SOA, la arquitectura debe cumplir los siguientes requisitos:
Debe haber interoperabilidad entre los diferentes sistemas y lenguajes de programacin que
proporcionan la base para la integracin entre aplicaciones en diferentes plataformas a travs de un
protocolo de comunicacin. Un ejemplo de dicha comunicacin es el concepto de mensajes. El uso de
mensajes a travs de canales definidos disminuye la complejidad de la aplicacin final, permitiendo de
este modo al programador de la aplicacin concentrarse en la funcionalidad en lugar de las
complejidades de un protocolo de comunicacin.
El deseo de crear una federacin de recursos. Establecer y mantener el flujo de datos a un sistema de
base de datos distribuda. Esto permite nuevas funcionalidades desarrolladas para hacer referencia a
un modelo de negocio comn para cada elemento de datos.
2
Estos requisitos son centrales para T en cunto son esenciales a la visin de interoperabilidad e
independencia de la configuracin hardware y software del cliente. El primer paso es construir la arquitectura de
referencia SOA, que provee un plan del diseo de servicios de una implementacin a lo largo de una organizacin.
Uno de los aspectos relevantes en SOA es definir la Arquitectura de Referencia para la Empresa, porque permite
tener un marco de referencia en donde ubicar los futuros desarrollos o aun aquellas componentes de servicios
2
convenientemente empaquetadas. En el caso de T esta arquitectura de referencia debe ser documentada,
ampliada y refinada, pero el conocimiento del dominio permite avizorar que ese proceso no va a ser doloroso ni
largo.
La Arquitectura de Referencia SOA plasma los distintos componentes de una solucin SOA, principalmente
Procesos de Negocio y Servicios, adems muestra como interactan estos componentes con los usuarios de
negocio, y con los sistemas existentes en la Empresa (sistemas legados). Generalmente orientada a capas por la
Captulo 9
147
independencia que este modelo arquitectnico provee y el poqusimo acoplamiento que produce, hay grandes
125
126
parecidos con el diseo de Sistemas Operativos moderno . Hay definiciones bien documentadas de todo lo
127
que es necesario describir y como crear un registro de metadatos .
SOA es menos una arquitectura que lo que es un paradigma para la construccin y mantenimiento de
128
procesos de negocios que abarcan sistemas distribuidos de gran porte . Una componente esencial de una
arquitectura SOA es el bus. El bus es el gran unificador, permite eliminar la necesidad de conocer detalles de
interfaces entre servicios. A cambio exige la existencia de un registro de los metadatos que cada uno espera recibir
y la capacidad de cada uno de interpretar metadatos. Esto puede llevar a un gran caos, por lo que todos los
autores recomiendan incorporar un nivel de supervisin y gua para gobernar el registro y la orquestacin.
Figura 9.9: Ilustracin de la Arquitectura SOA
9.12 Armando la Fbrica

2
Para el proceso de reingeniera dentro de T Ana propone contratar un ayudante que trabaja ya con ella en la
ctedra y que cumple con las condiciones y tiene las competencias necesarias. Pasadas las entrevistas y los
129
chequeos de antecedentes, el nuevo ingeniero pasa a ser arquitecto del proyecto . Junto con Ana y los gemelos
130
elaboran la arquitectura de alto nivel, aplicando JMC . Despus de ese ejercicio comienza a funcionar la fbrica
de Software: Dependiendo del dominio en particular de la componente a convertir en servicio, los gemelos
131
recomiendan un experto que asume el papel de programador jefe del equipo . Ser l quin se encargue de los
132
detalles de la envoltura y la definicin de metadatos para el registro. Para la escritura de la envoltura armar su
equipo y lo conducir. En suma, una aplicacin clsica de FDD a SOA.
2
86. Una empresa canadiense establece una alianza con T para rehacer la arquitectura del producto
de salud llevndola a SOA.
87. Marcela y Ana arman un proceso para fabricar los servicios a partir del cdigo existente,
aplicando FDD.
125
126
127
128
129
130
131
132
[BORIA, J. 1989]
http://www.soa.com/solutions/metadata_federation/
Una bsqueda en Google devuelve ms de un milln de sitios
[JOSUTTIS, N. 2009]. SOA in Practice: The Art of Distributed System Design.
Una de esas cosas que ocurren solo en software!
Ver captulo 8, Java Modeling in Color.
Ver captulo 3, Feature Driven Development.
En la tecnologa de la informacin, una envoltura (wrapping) son los datos que preceden o enmarcan los principales datos
de un programa, o un programa que pone en marcha otro programa para que se pueda ejecutar correctamente. En
particular, en programacin, una envoltura es un programa o script que establece las bases y hace posible el
funcionamiento de otro programa ms importante.
148
Captulo 9
Boria et al.
9.13 El nivel C del MPS

Revisando lo actuado con Mximo, una vez ms invocado para realizar un anlisis de brecha, el nfasis recae
en dos cosas: El proceso de Desarrollo para el Reuso, y los resultados de atributos de proceso, que marcan el grado
de institucionalizacin de los procesos.
Dado el nuevo convenio con la empresa de Canad, el resultado DRU 1: Los dominios de aplicacin en los que
sern investigadas las oportunidades de reuso de activos o en los cules se pretende practicar reuso se identifican,
detectando los potenciales de reuso respectivos, est claramente cubierto. El segundo resultado, DRU 2: La
capacidad de reuso sistemtica de la organizacin es evaluada y las acciones correctivas son tomadas, en el caso
de que sean necesarias, es evidenciado en la incorporacin de un arquitecto para SOA y la instalacin del proyecto
basada en FDD. El tercer resultado, DRU 3: Un programa de reuso, cubriendo propsitos, alcance, metas y
objetivos, es planificado con el fin de atender a las necesidades de reuso de dominios, tambin es evidenciada por
este proyecto. El cuarto resultado, DRU 4, que pide que el programa de reuso sea implantado, monitoreado y
2
evaluado decanta de los mismos preceptos de gobierno que se usa en todos los proyectos de T . DRU 5 dice: Las
propuestas de reuso son evaluadas de forma de garantizar que el resultado del reuso sea apropiado para la
aplicacin objetivo, y se aplica en el mecanismo de evaluacin de cada sprint del proyecto SOA, mientras que DRU
6, Las formas de representacin para los modelos de dominio y las arquitecturas de dominio son seleccionadas, es
evidenciado por el registro y la arquitectura de negocios que constituyen el nivel ms alto de especificacin del
proyecto, realizado por Ana y los gemelos. DRU 7, Un modelo de dominio es desarrollado y sus lmites y relaciones
con otros dominios son establecidos y mantenidos, est captado en el registro de metadatos, ya que el resultado
se elabora de este modo: Este modelo debe ser capaz de capturar caractersticas, capacidades, conceptos y
funciones comunes, variantes, opcionales y obligatorias. Tambin la eleccin de SOA permite fcilmente evidenciar
el DRU 8: Una arquitectura de dominio describiendo una familia de aplicaciones para el dominio es desarrollada y
mantenida por todo su ciclo de vida. Por ltimo, DRU 9, que pide que los activos de dominio sean especificados;
adquiridos o desarrollados, y mantenidos por todo su ciclo de vida, es parte del contrato mismo con TransKND y el
corazn del nuevo proyecto. El proceso DRU no constituye un problema.
Respecto de los resultados de los atributos de proceso, o RAP, la revisin alcanza hasta aquellos que aplican
hasta el Nivel C y no han sido remplazados por otros en el proceso de maduracin. Estos son: RAP 1, el ms bsico,
que hace referencia a el grado en que el proceso alcanza sus resultados definidos. Esto es el motivo de que se
realice la revisin de los resultados de los procesos, de modo que no es una preocupacin para Marcela y su
equipo. Tampoco surgen muchas dudas de los siguientes resultados esperados: RAP 2. Existe una poltica
organizacional establecida y mantenida para el proceso; RAP 3. La ejecucin del proceso es planificada; RAP 4. Las
mediciones son planificadas y recolectadas para monitorear la ejecucin del proceso y los ajustes son realizados;
RAP 5. Las informaciones y los recursos necesarios para la ejecucin del proceso son identificados y puestos a
disposicin de los interesados; RAP 6. Los roles requeridos, las responsabilidades y la autoridad para la ejecucin
del proceso definido son asignados y comunicados; RAP 7. Las personas que ejecutan el proceso son competentes
en trminos de formacin, entrenamiento y experiencia; RAP 8. La comunicacin entre las partes interesadas em el
proceso es planificada y ejecutada de forma de garantizar su involucramiento; RAP 9. Los mtodos adecuados para
monitorear la eficacia y adecuacin del proceso son determinados y los resultados del proceso son revistos con la
gerencia de alto nivel para darles visibilidad sobre su situacin en la organizacin. Todas estas forman parte de la
planificacin normal de proyectos, programas, y sprints, o de la estructura de control de calidad y el mecanismo de
2
gobierno encarnado en las reuniones mensuales del comit de gestin de T . Lo mismo acontece con RAP 10, la
adherencia de los procesos ejecutados a sus descripciones de proceso, padrones y procedimientos es evaluada
objetivamente y son tratadas las no-conformidades.
La implementacin de la buena gerencia de configuracin en la que han insistido todos, en particular los
gemelos, produce las evidencias necesarias para RAP 11, Los requisitos de los productos de trabajo del proceso son
identificados; RAP 12, los requisitos para documentacin y control de los productos de trabajo son establecidos;
RAP 13, los productos de trabajo son colocados en niveles apropiados de control; y RAP 14, los productos de
trabajo son evaluados objetivamente en relacin a los estndares, procedimientos y requisitos aplicables y son
tratadas las no conformidades.
Ms trabajo le ha dado a Mximo encontrar la evidencia de RAP 10, el proceso planificado para el proyecto es
ejecutado. Ha tenido que comparar planes y procesos para poder encontrar que, efectivamente, lo que se dice es
lo que se planifica, y lo que se planifica es lo que se hace. Pero esto le ha servido para ver asimismo la evidencia de
RAP 15, un proceso estndar es descripto, incluyendo directrices para su adaptacin; RAP 16, la secuencia e
interaccin del proceso estndar con otros procesos son determinadas; RAP 17, los roles y competencias
Captulo 9
149
requeridos para ejecutar el proceso son identificados como parte del proceso estndar; y finalmente de RAP 18, la
infra-estructura y el ambiente de trabajo requeridos para ejecutar el proceso son identificados como parte del
proceso estndar. Todo esto lo encuentra Mximo en la BiPro cuando compara los planes de los proyectos con los
procesos que les dan origen.
En ese anlisis, Mximo se apoya en el proceso definido que cada proyecto elige, siguiendo las guas de
adaptacin, lo que le permite observar evidencia de RAP 19, un proceso definido es implementado basado en las
guas para seleccin y/o adaptacin del proceso estndar; RAP 20, la infra-estructura y el ambiente de trabajo
requeridos para ejecutar el proceso definido son puestos a disposicin, gestionados y mantenidos; y finalmente
RAP 21, los datos apropiados son recolectados y analizados, constituyendo una base para la comprensin del
comportamiento del proceso, para demostrar la adecuacin y la eficacia del proceso, y evaluar donde pueden ser
realizadas mejoras continuas del proceso.
2
Mximo concluye que T est preparada para la evaluacin de Nivel C, y en consecuencia, dada la fuerza del
modelo MPS, para hacerla conjuntamente con un SCAMPI de Nivel 3, Definido, del CMMI.
2
88. Mximo concluye que T est preparada para la evaluacin de Nivel C, y en consecuencia, dada
la fuerza del modelo MPS, para hacerla conjuntamente con un SCAMPI de Nivel 3.
150
Captulo 9
Boria et al.
Parte IV Apogeo
CAPTULO 10 - ESTABILIZAR PARA LA MEJORA CONTINUA
(NIVELES B Y A DE MPS-SW)
No es la especie ms fuerte la que sobrevive, ni la ms inteligente, sino aquella que mejor se adapta a los
cambios
Charles M. Darwin
2
Han pasado veinte meses desde que visitramos a nuestros amigos de T y ha corrido bastante agua bajo el
puente. Cuando los dejamos estaban preparando su evaluacin conjunta de nivel C del MPS con el nivel Definido
del CMMI, evaluacin que se produjo sin sobresaltos y con xito a los pocos meses. El desarrollo de la fbrica de
software basada en arquitectura SOA era incipiente, y el despegue estaba acentundose en el convenio con la
2
empresa de Canad. Casi dos aos ms tarde todos los aspectos de T se han acentuado positivamente. La
empresa tiene tres lneas de productos, es conocida por el primer ERP seguro en la nube, cotiza en bolsa y sus
marcas se reconocen. Llegar a la ciudad desde el aeropuerto es recorrer cartel tras cartel recordando al viajero que
2
est en la ciudad de T . Los fundadores son caras conocidas en los programas de televisin locales e invitados
frecuentes a seminarios y charlas. Son todava jvenes, algunos han cambiado de estado civil, Adolfo y Ana ya
tienen tres nias, los gemelos siguen siendo ms conocidos en los antros que en su casa paterna, Mariano se ha
casado, Claudio vive con su pareja. Marcela ha adoptado un enorme perro, cruza de mastn con San Bernardo, que
ocupa sus das ms que su novio. La vida es buena.
10.1 Estabilidad
En todos los aspectos de nuestras vidas la estabilidad nos ofrece una sensacin de tranquilidad. Cuando los
sucesos son estables y las sorpresas son mnimas sentimos que se est seguro. Hasta en deportes extremos los
seres humanos queremos control sobre lo que ocurre. Las cintas de aventuras nos sacan de la zona de confort y
aceleran nuestra circulacin porque nos presentan un panorama donde el provenir es incierto, no se puede hacer
predicciones y en consecuencia, los mejores planes salen mal.
2
Nuestros amigos de T dedujeron lo mismo de una experiencia particular en los primeros intentos de
2
planificar sus sprints para el proyecto SOA. La estimacin del esfuerzo y duracin de las tareas se realiza en T ,
desde el nivel E, tomando un primer valor asociado al tamao. En los Scrum este valor fue el punto-historia
primero, y a partir del nivel D, puntos casos de uso, dada la introduccin de los mismos como parte de la definicin
de alcance. En Kanban se usan diferentes medidas de volumen, pero dado que su uso (el de Kanban) es poco
frecuente, volcado en principio a ciertas tareas tcnicas de duracin media, no hay un mtodo tan preciso. A partir
de esta estimacin del tamao se toma como punto inicial del esfuerzo el valor resultante de aplicar la ecuacin de
regresin para tareas de ese tipo, tomando los valores histricos de la base de datos de procesos.
Conscientes de que se trataba de procesos y procedimientos nuevos, los gemelos comenzaron por generar
los datos para que la ecuacin pueda ser usada con el mismo efecto. Durante tres meses las estimaciones se
hacan a ojo y se fueron ajustando los parmetros de estimacin hasta obtener los coeficientes derivados de la
historia. Aun as, los gemelos se asombraron de la gran disparidad que comenzaron a observar entre sprints de la
fbrica. Las predicciones erraban por varios das, hasta por semanas en una ocasin. Armados con las herramientas
de anlisis se pusieron a trabajar. Porqu un proceso, el de estimacin, que haba sido suficientemente bueno
hasta entonces, ya no serva con la misma capacidad? Obviamente que lo primero que se cuestionaron fue la
novedad del dominio y la consecuencia inmediata fue comparar los datos de ambas modalidades. Tomaron los
datos histricos para tareas semejantes (anlisis, construccin, prueba) y los cargaron en la herramienta de
133
software de anlisis estadstico en uso y con su ayuda produjeron las curvas normales para ambas poblaciones.
Esperaban que los valores medios fueran distintos, pero no crean que en lo dems las distribuciones fueran muy
distintas.
133
Hay muchas herramientas de software para anlisis estadstico, incluyendo open source y extensiones a Excel. De mucha
difusin es Mini Tab y para las simulaciones de Monte Carlo, Crystal Ball. Para una lista ver
http://alternativeto.net/software/minitab/
Captulo 10
151
Figura 10.1: Distribuciones de Esfuerzo de Tareas Semejantes en Dos Poblaciones
Las dos distribuciones resultaron de formas muy diferentes. El valor medio era, como esperado, bastante
mayor para la nueva poblacin (a la derecha en los grficos de la Figura 10.1) pero la mayor diferencia la
134
constituye la dispersin . Los gemelos acudieron a Claudio, para abrevar en sus recientemente adquiridos
135
profundos conocimientos de estadstica . Claudio se muestra casi sorprendido de la pregunta de los gemelos,
que quieren saber por qu las estimaciones son tan errticas en el nuevo proyecto cuando eran tan precisas en los
viejos. Les da una respuesta muy sucinta, que a los gemelos les parece tan buena que lo invitan a realizar una
breve exposicin para los lderes tcnicos que dirigen las estimaciones.
2
Claudio se dirige por primera vez a un auditorio dentro de T , pero no es la primera vez que expone en
2
pblico. l tambin es vctima del xito de T y es a menudo invitado a exponer sobre el anlisis financiero
2
aplicado al anlisis de cartera, como lo viene haciendo en T desde hace aos. Por lo tanto, est preparado, aunque
presentar sobre el tema de estadstica es nuevo para l. Su exposicin, basada en transparencias, se intitula
Estimacin y Dispersin. Su argumento central es que la precisin de la estimacin no es un problema del
mtodo de estimacin, sino del comportamiento del proceso estimado. Para ilustrar esto elige el siguiente
ejemplo:
-
134
135
Supongamos que estamos intentando estimar el error de un reloj, para lo cul observamos la hora que
marca y la comparamos con la hora real, medida por un instrumento fiable, como una computadora,
cada veinte minutos. Al cabo de un da, veinticuatro horas, tendremos 72 observaciones. Ahora bien,
imaginemos que observamos un cronmetro. En ese caso las desviaciones estarn, posiblemente, debajo
del lmite de tolerancia de nuestras mediciones, es decir, si comparamos las mediciones en segundos, es
posible que la diferencia entre la computadora y el cronmetro sea menor de un segundo. Aun si fuera de
alrededor de un segundo, la dispersin de los datos es mnima. Por contraste, observamos un reloj de
pared que se ha quedado sin bateras, por lo tanto, siempre marca la misma hora. Dado que el reloj solo
marca doce horas, cada medicin que hacemos del error aumenta en veinte minutos hasta alcanzar o
pasar las seis horas, entonces disminuye de veinte en veinte minutos. Si tomamos los errores con su signo,
se compensan entre s, de manera que el valor medio de ambos relojes es cero, quizs si alguno no es cero
es el del cronmetro. Por supuesto que tomamos las desviaciones en su valor absoluto, pero de todos
modos, esto es indicativo que el valor medio no es el mejor modo de pensar sobre estimaciones, porque
hay una gran parte de la informacin que radica en la dispersin y que el valor medio no captura. Si
usamos la media del error para ajustar nuestra estimacin el reloj de pared nos dar sorpresas: Cada
observacin dista mucho de la realidad, sin embargo el promedio se compensa. El mtodo es el mismo, el
error totalmente diferente. Luego el error no proviene del mtodo, sino de la distribucin subyacente de la
variable que mide el comportamiento del proceso. Si no nos gustan nuestras estimaciones es intil
castigar a los estimadores, hay que mejorar la estabilidad del suceso que se intenta estimar.
Las medidas de dispersin, tambin llamadas medidas de variabilidad, muestran la variabilidad de una distribucin,
indicando por medio de un nmero, si las diferentes puntuaciones de una variable estn muy alejadas de la mediana media.
Cuanto mayor sea ese valor, mayor ser la variabilidad, cuanto menor sea, ms homognea ser a la mediana media. As se
sabe
si
todos
los
casos
son
parecidos
o
varan
mucho
entre
ellos.
http://es.wikipedia.org/wiki/Medidas_de_dispersi%C3%B3n
Claudio ha iniciado cursos de doctorado en anlisis financiero para empresas. De paso, se ha recibido de Actuario.
152
Captulo 10
Boria et al.
Figura 10.2: Distribucin del Error en Dos Relojes
10.2 Eliminando Aleatoriedad

La resultante es que los procesos de SOA no son estables. Buscando la causa raz se encuentran varias
candidatas: Los procedimientos no estn definidos con suficiente precisin, se tienen diferentes interpretaciones
de como se deben ejecutar; dentro de este mismo tema, diferentes ejecuciones tienen diferente grado de
adherencia al proceso (fidelidad); los ajustes que permite la gua han sido mal hechos y esto ha pasado
desapercibido por calidad; al ser un proceso nuevo las mediciones estn mal automatizadas y la granularidad es
mayor que en los casos de Scrum, donde las tareas estn claramente separadas y la captura de datos es limpia.
El primer paso para controlar el problema es clarificar el proceso inicial de definicin del sprint, que antes era
bien descripto por el juego de planificacin, pero como este no aplica en SOA, se lo remplaza por un procedimiento
centrado en la estimacin individual del volumen, realizada por el programador jefe. Esta estimacin no es
revisada y es parte de la fuente de error. Marcela se encarga de precisar el procedimiento de conteo,
construyendo un mtodo semejante a los puntos caso de uso que ya utilizan, pero basado en la densidad y
extensin de los metadatos que requiere el servicio o la componente en cuestin. Puesto en prctica, los
resultados son prometedores, la dispersin baja significativamente en pocas aplicaciones, pero deciden continuar
136
con el experimento hasta que las herramientas estadsticas sealen que el resultado es significativo al 10% . Esto
no los detiene en la mejora continua, puesto que Marcela aade auditoras y revisiones que en el apuro por
comenzar el proyecto SOA fueron dejadas de lado. Sea esto una leccin: Hasta las mejores intenciones suelen dar
paso al optimismo y el resultado puede ser peor que el esperado. Nada remplaza a la vigilancia continua. De paso,
los anlisis estadsticos slo conducen a ideas y nuevas preguntas - no a soluciones. Para solucionar problemas
detectados hay que analizar las causas y posiblemente crear nuevas mediciones para investigarlas claramente.
10.3 El Cielo se Desploma
Los resultados permiten que nuevamente la gerencia confe en las estimaciones y la estabilidad resultante
induce una feliz sensacin de estar en control. Hasta que un acontecimiento inusual sacude a todos. Jessica
137
recuerda sus lecturas de Taleb y los cisnes negros. Un proyecto nuevo de SOA marchaba normalmente, es
decir de acuerdo con las expectativas, hasta que en el Sprint de estabilizacin se desplom el cielo: Los errores no
solo estaban fuera de toda prediccin sino que cada correccin agregaba nuevos. La cuenta de errores abiertos
138
conocidos suba de ciclo de prueba en ciclo de prueba. Un tpico escenario de proyecto fuera de control . En vez
de disminuir, los defectos aumentan a cada intento de eliminar uno de ellos. El comit de gestin tira de la perilla
de emergencia y detiene la lnea de produccin. En una reunin de los programadores jefe se realiza un anlisis
2
de causas profundas que no llega a ninguna conclusin. Por primera vez en su historia, T est perpleja y sin
respuesta. Marcela acude, como siempre, a la literatura existente y sus buenos contactos acadmicos. El Dr. Zito,
que ha consultado para empresas internacionales de software en encarnaciones anteriores de su profesin, sonre
beatficamente al escuchar su narracin, como corresponde a los profesores titulares que ya saben lo que tiene
que contestar.
136
En las pruebas estadsticas, se considera un resultado estadsticamente significativo si es tan extremo que tal resultado
se espera que surja por casualidad slo en raras circunstancias. El porcentaje expresa qu tan raro es: 10% significa
que una de cada nueve veces el resultado es fruto de la eleccin hecha de la muestra, un 1% indica que una de cada
cien veces es ese el caso. Ver [SPIEGEL 2011].
137
[TALEB, 2010] y [TALEB, 2011], op. cit., ver Captulo 9.
138
[GLASS R., 1997]: Un proyecto de software se clasifica como fuera de control cuando excede en ms del 30% sus
estimaciones presupuestarias. En el caso que citamos el indicador de gestin que apunta a esto es el crecimiento
permanente de los defectos conocidos y abiertos en cada ciclo de prueba.
Captulo 10
153
Marcela, le dice, estamos hablando del problema de complejidad de las interfaces. Es tpico que el
acoplamiento bajo produzca, en un sistema lo suficientemente grande, un caos de interpretacin. La
parte del software de ustedes que interpreta los metadatos se ha vuelto ms voltil y compleja que las
ganancias que obtienen del bajo acoplamiento. Ya era conocido el problema en la poca del anlisis
139
estructurado, Constantine hablaba de esto, en 1979 . La pregunta clave es: Cunto un mdulo debe
conocer de otro para entenderlo y comunicarse con l? Cuanto ms debemos saber del mdulo B para
entender del mdulo A, ms acoplados estn A y B. Puesto que tenemos que saber algo acerca de otro
mdulo es una prueba a priori de un cierto grado de interconexin, incluso si la forma de la interconexin
no se conoce. Esto es llevado al extremo en el intento de SOA. Lamentablemente, llega un punto donde el
no tener que saber nada de nada implica poder aprender de todo en el momento de conectarse. Esa es la
complejidad con que se estn enfrentando.
Pero, dice Marcela, Porqu funcion antes y ahora no?.
Qu es diferente de este proyecto con los anteriores?, pregunta el Doctor.
Es un proyecto desde cero de un dominio que no conocemos tan bien, contesta Marcela.
Y ah lo tienes, dice el Doctor, la respuesta es esa. SOA no es la herramienta para eso, estn abusando
del modelo.
Marcela agradece y se va pensando en lo que acaba de aprender. Su perplejidad ha disminuido, pero no

desaparecido. Porqu una herramienta tan til en algunos casos es tan contraproducente en otros? Y sobre todo,
Cmo se arregla esto ahora? Claro que por otro lado tambin su costado de mejora continua le acucia: Se podra
haber prevenido?
El comit de gestin est reunido en junta de emergencia. Marcela expone el caso como lo vio junto al Doctor
140
Zito. En el viaje de la Facultad a las oficinas ha tenido un Eureka y lo transmite al comit. Utiliza un mtodo de
141
Ford que se conoce como las ocho disciplinas , por el cul se define correctamente el problema igual que en el
caso del anlisis de causas races, pero se le agrega un elemento importante, la contencin del problema antes de
preocuparse de solucionar las causas races.
Con esto en mente, Marcela hace su presentacin: El problema es la necesidad de cubrir todos los metadatos
posibles en un dominio nuevo, donde no hay experiencia necesaria para entender qu es lo crtico y que es lo
accesorio. De ese modo los envoltorios (wrappers) terminan siendo extremadamente complejos, casi programas
de inteligencia artificial. Esto ocurre porque no hay un cdigo heredado que se pueda abstraer, sino que se lo
desarrolla a medida que se define el servicio.
Marcela ahora llama a un grupo de programadores jefe que ya haba seleccionado y comunicado su
necesidad de estar preparados para esta reunin, a la que llama una retrospectiva acelerada. Ingresan en la sala y
Ana, quin ya fue puesta en antecedentes por Marcela sobre el sesgo que quiere darle a la reunin, toma la posta
y conduce la discusin sobre los arreglos arquitectnicos que habr que efectuar para contar con un producto
dentro de plazos razonables. Los programadores se sienten muy incmodos, puesto que las reuniones de comit
2
de gestin se han vuelto legendarias en T , material de muchas leyendas nacidas al abrigo de la decisiones
2
tomadas en ella por aquellos que los ms jvenes consideran los popes de T .
139
140
141
[YOURDON, E., CONSTANTINE, L. 1979]. Muchos atribuyen gran parte del material a Constantine, de ah la cita a medias del
Doctor.
Eureka! o Heureka en griego Lo he encontrado!, es una famosa exclamacin atribuida al matemtico griego Arqumedes,
quin segn la leyenda pronunci esta palabra tras descubrir que el peso de un cuerpo, dividido su peso aparente al ser
sumergido en agua, es una propiedad que hoy conocemos con el nombre de densidad. Esto le permiti saber si la corona
del Rey estaba hecha de oro puro. Este descubrimiento lo habra realizado mientras se encontraba sumergido en la baera.
Tal fue su alegra que sali a las calles de Siracusa desnudo y gritando Eureka! Marcela tuvo su Eureka en el automvil y
vestida, por suerte.
http://es.wikipedia.org/wiki/Ocho_disciplinas_para_la_resoluci%C3%B3n_de_problemas
154
Captulo 10
Boria et al.
Figura 10.3: El Mtodo de las Ocho Disciplinas
Tmidamente exponen sus quejas, casi todas justificadas: La conduccin sobrestim la capacidad de adquirir
conocimientos por parte de los equipos, as como la capacidad de expresarse con precisin y completitud de los
clientes. Los mtodos de Denney no sirvieron porque las definiciones iniciales no contenan reglas de negocio
suficientemente claras ni completas. Los metadatos no fueron definidos con una plantilla nica a la vista, sino que
cada uno adapt la suya a las necesidades que iban surgiendo. El atraso en el sprint de arquitectura fue tomado
como un buen sntoma, como que el tiempo invertido en al anlisis iba a pagarse solo en lo sucesivo, cuando en
realidad se cort abruptamente porque se sinti que continuar era mejor que esperar a entender bien el problema
del usuario.
El ambiente es cada vez ms sombro dentro de la sala. Solo los programadores jefe hablan, en realidad
musitan, sus sensaciones. En un punto Alberto Galarraga intenta objetar a algunos comentarios, pero Ana lo
interrumpe.
-
Armando, le dice, confundindolo con su hermano, No hay nada que objetar, la percepcin es la
realidad en este caso. No importa si pensamos que fue de otra manera, para poder arreglar este desastre
necesitamos ponernos en la visin de los que lo tienen que sacar adelante.
La trampa de Deming: Estuvimos tan pendientes de los recursos que nos olvidamos de los objetivos,
agrega Alfredo, quin se qued pensando en el problema.
Los programadores jefe se sienten respaldados, pero el miedo no desaparece. Marcela pide, casi ruega, que
se propongan soluciones al problema actual. Uno de los ms jvenes, que ha sido alumno de Ana, sugiere empezar
de nuevo pero con diferentes mtodos y achicar el tiempo reusando el cdigo ya escrito. En parte tratar al cdigo
como un legado pero empezar con un modelo ms preciso del negocio del cliente. Otro suma su voz, diciendo que
est de acuerdo pero que necesitan dejar SOA de lado, acabar con los metadatos por ahora. Las otras voces se
suman para pedir que se hagan los requerimientos. Alfredo objeta:
-
No hay tiempo para rehacerlos, lo mximo que disponemos es de seis semanas, dos meses a lo sumo y
haciendo concesiones al cliente.
No es necesariamente cierto que no haya tiempo, recoge el guante Mariano, habitualmente callado en
las reuniones tcnicas, Podemos aplicar JAD y salvar esto en ese plazo.
Captulo 10
155
10.4 Contencin
Ahora es el turno de Mariano para exponer su idea. Sucintamente describe JAD para los no iniciados. Al
escucharlo Marcela recuerda que Mariano era un entusiasta del mtodo all por los aos en que ambos
compartan las aulas del Poli.
142
JAD es la abreviatura que se usa para Joint Application Development , un mtodo integral de construccin
de software basado fuertemente en la participacin de todos los interesados en la construccin del modelo del
sistema previamente a escribir el cdigo. En cierto modo es uno de los precursores de gil, porque el equipo es
autnomo y elige sus procesos hasta cierto punto y los perodos estn prefijados. El mtodo se basa en una
investigacin inicial, en esencia la recoleccin de los requisitos, para construir un modelo del sistema en cuestin.
Esta etapa, segn opina Mariano, puede ser realizada sin intervencin del cliente porque los equipos ya tienen el
conocimiento necesario. La segunda fase constituye la identificacin de un equipo y su convocatoria para revisar y
actualizar el modelo. En esta etapa hay dos resultados crticos: La eleccin de los participantes y el respaldo de la
143
alta gerencia. Los participantes deben ser usuarios CRACK es decir, ser personas reconocidas en el ambiente del
cliente, contar con capacidad de decisin, contar con conocimiento de dominio y ponerse a disposicin del equipo.
El auspicio de la alta gerencia es necesario por dos cosas: La convocatoria a la reunin debe surgir de la alta
gerencia, de otro modo es poco posible que atiendan los usuarios CRACK, y la otra razn es que al hacer la
convocatoria el auspiciante debe comprometer a todos con el resultado. Nadie puede decir esto no es lo que yo
quera, pero para terminar la discusin prefer aceptarlo. El compromiso con el resultado obliga a todos tanto a
participar como a negociar, puesto que el proyecto tiene duracin fija. La tercera fase es la junta de anlisis en s,
donde se propone el modelo, se lo analiza y mejora. Las objeciones que se levantan en la reunin son incorporadas
al modelo durante la noche y presentadas de nuevo al da siguiente. Esto y la presencia de personas con
conocimiento y poder de decisin genera una dinmica muy rpida y en tres a cinco das se puede cubrir lo que
habitualmente lleva dos o tres meses. Quedarn algunos puntos sin cerrar pero los responsables por cerrarlos
tendrn un plazo perentorio para hacerlo. En cuanto se cierran las ltimas acciones se escribe el cdigo, se lo
prueba y se lo demuestra.
Los programadores jefe aprueban la estrategia y Mariano se compromete a convencer al cliente si el comit
los respalda. Los gemelos siguen con dudas, pero no tienen una mejor opcin. Mariano queda encargado de hablar
con el cliente y facilitar las actividades de JAD futuras.
10.5 Causas Races
Hasta cierto punto la reunin ha atacado las causas races, pero no todava de forma sistemtica. Marcela
utiliza datos del fracaso para mostrar los resultados e iniciar una discusin de anlisis. Jessica, que est oficiando
de escriba y ha recogido los comentarios de los programadores jefe, propone hacer el anlisis a partir de ellos.
riesgo o problema:
causa(s) raz (ces):
mitigacin:
Se sobrestim la capacidad de
adquirir conocimientos por parte de
los equipos
No se sigui el proceso de
riesgos en la parte de preventa
Agregar una auditora de proceso

a la actual auditora de producto y
hacer una revisin por colegas del
producto
Se sobrestim la capacidad de los

clientes de expresarse con precisin y
completitud
Las definiciones iniciales no contenan
reglas de negocio suficientemente
claras ni completas.
142
143
Los metadatos no fueron definidos

con una plantilla nica a la vista, sino
que cada uno adapt la suya a las
necesidades que iban surgiendo
Los procesos de negocio

estaban sufriendo reingeniera
al mismo tiempo que se los
intentaba describir para
construir el sistema
No hay una plantilla nica, no
hay guas de ajuste ni de uso
Aadir a los riesgos en preventa el

conocimiento del negocio del
punto de contacto
Colocar una clasula en el
contrato que hace responsable al
cliente de las demoras
relacionadas con requisitos
incompletos
Contruir la plantilla estndar para
metadatos y los artefactos
necesarios para su uso productivo
en BiPro
[WOOD, S. e SILVER, D., 1995]

Ver Captulo 3.
156
Captulo 10
Boria et al.
riesgo o problema:
El atraso en el sprint de arquitectura

fue tomado como un buen sntoma,
como que el tiempo invertido en al
anlisis iba a pagarse solo en lo
sucesivo, cuando en realidad se cort
abruptamente porque se sinti que
continuar era mejor que esperar a
entender bien el problema del
usuario
causa(s) raz (ces):
mitigacin:
El sistema de gobierno de los

metadatos qued sin
implementar y no hay
revisiones de las definiciones
porque ya no aplican los
procesos de Scrum
Implementar el sistema de
gobierno de los metadatos, incluir
las definiciones de metadatos
entre los artefactos y documentos
sujetos a revisin por inspeccin y
crear la lista de tems de control
para poder realizarlas
objetivamente
Tabla 10.1: Los Problemas del Proyecto Fuera de Control
La reunin avanza rauda mientras se tratan los primeros cuatro puntos, pero llega a un impasse cuando se
confronta el quinto. Hay silencios largos que son llenados por toses y sugerencias inconclusas, un A ver, si
hacemos que se diluye sin terminar, o un Y si pusiramos en cambio que tampoco prospera.
Jessica finalmente decide intervenir.
-
Esto nos pasa porque somos buenos haciendo autopsias pero no sabemos hacer diagnsticos
tempranos, dice, decidida.
Cmo, cmo, cmo?, pregunta con sincera curiosidad Alfredo.
Si, somos forenses pero no somos clnicos. No sabemos medir la glucosa en sangre, los triglicridos, la
cantidad de glbulos rojos, de leucocitos, de calcio. No lo sabemos, y lo que es peor, si tuviramos los
nmeros no sabramos interpretarlos, insiste Jessica, a quin le gusta hablar con parbolas e hiprboles.
Ana comienza a entender:

-
No somos clnicos, no hacemos prevencin, no hacemos anlisis, no medimos Es eso?, pregunta Ana.
Pero s medimos, dice Alberto.
Y s hacemos anlisis, dice Armando.
Pero todo lo hacemos cuando ya ocurri el hecho, lo nuestro es post mortem, es autopsia, es rigor mortis
y ya no hay nada que hacer, exagera una vez ms Jessica, que tiene cierta afinidad por el drama de los
pases blticos.
La discusin se anima, todos parecen querer hablar a la vez, en parte fascinados por lo que intuyen es cierto,
en parte rechazando las ideas porque no son descriptivas de la realidad.
10.6 La Prediccin Como Herramienta
Lo que Jessica ha querido expresar en su forma tan peculiar es que si bien se hacen predicciones, estas
carecen de rango. Es decir, se elige un punto central y se lo proyecta para saber cuntos defectos vamos a
encontrar, qu nmero de veces hemos de ejecutar cada caso de prueba o cuando vamos a entregar con la calidad
prevista, pero todas estas estimaciones estn imbuidas de error y no se ingresa ese error en el clculo. Recordando
la ecuacin de regresin debemos considerar el , porque si este valor es muy grande no podemos poner mucha
confianza en la estimacin. En cierto modo, es la misma discusin acerca de la estabilidad trasladada a las
ecuaciones de regresin. Si los procesos son estables debiera ser posible establecer la correlacin entre los valores
de las variables independientes y los valores dependientes con ajuste a la aleatoriedad que tienen, es decir,
predecir el valor medio dentro de un intervalo de confianza. De esa manera podramos afirmar cosas como que
el proyecto est dentro de los lmites esperados, en vez de poner valores arbitrarios de 15% por encima y por
debajo del valor medio.
Captulo 10
157
En trminos de las teoras de calidad, lo que no estamos haciendo es escuchar la voz del proceso. Los
procesos tienen comportamientos derivados del grado de estabilidad que tienen en la empresa. Menor es la
dispersin, mayor es la estabilidad.
10.7 Prediccin y Anlisis
Nuestra especie basa su conocimiento en una ley: Como el ayer es el hoy. La repetitividad de un fenmeno es
el parmetro por el cul medimos su calidad cientfica. Las leyes cientficas establecen las relaciones entre eventos
y objetos, miden los resultados y se las enuncia como ecuaciones matemticas. Kepler y las rbitas planetarias, o
Galileo y el plano inclinado, primero observaron los fenmenos y luego postularon relaciones matemticas que los
explican.
Del mismo modo y basados en los mismos principios pensamos que si nuestra fbrica se comport de una
manera ayer, y no ha habido cambios, se deber de comportar de forma semejante hoy. Lo que aprendimos ayer
sirve hoy porque la realidad es bastante parecida como para aprovechar ese conocimiento. En trminos de los
procesos, los datos que se han venido juntando sobre las caractersticas de los mismos (adems de los datos
catastrales de las tareas que implementan un procedimiento se lleva la cuenta de la duracin de la tarea, el costo,
el esfuerzo que demanda, el tamao del producto que se produce y las correcciones que se le realizaron, esto
ltimo para estimar su calidad) se pueden utilizar para comparar lo pasado contra el presente. Mientras que no
aparezcan cisnes negros esperamos que los valores obtenidos en el pasado sean representativos de lo que est
por ocurrir. En vez de tener presente el rango y los valores medios (mediana o media) es ms instructivo conocer la
distribucin de los valores histricos. El punto de Jessica es que si invertimos en conocer la distribucin de una
144
variable aleatoria relacionada con nuestros proyectos podemos aplicar control estadstico de procesos ,
abreviado SPC por sus iniciales en ingls.
Tomemos una de las variables asociadas con una cierta tarea y observemos su comportamiento. Para fijar
ideas, digamos que tomamos el esfuerzo que representa la construccin de casos de prueba por unidad de tamao
del caso de uso en los que se basan. Derivando el histograma vemos que afecta una forma parecida a una
distribucin normal, quizs un poco ms volcada a la derecha que a la izquierda. Revisando en la literatura de
2
estadstica la forma ms parecida es la , una distribucin derivada de la curva normal de Gauss. Siguiendo
nuestra bsqueda vemos que hay una familia completa de curvas semejantes, la familia Weibull (ver Fig. 10.4), y
145
que Putnam las ha utilizado en sus investigaciones sobre los procesos de software.
Figura 10.4: Curvas de la Familia Weibull
Aplicar SPC hubiera resultado til en el proyecto fuera de control, porque nos hubiera dicho que la duracin
de ciertas actividades estaba fuera de sus lmites normales. Esto implica que conocemos cules son esos lmites.
Digamos que uno entra en un club de bridge y se acerca a una mesa donde hay dos parejas jugando. Observando
las cartas vemos que cada uno tiene en la mano trece cartas del mismo palo, lo que obviamente despierta nuestras
suspicacias. De nuestro conocimiento de la distribucin que se produce al mezclar y dar cartas de un mazo, la
probabilidad de que ocurra esa exacta distribucin es exactamente igual a la de todas las otras manos, pero es tan
particular que nos sorprende verla. Puesto que esto tiene un impacto muy alto en el resultado del juego,
sospechamos que este hecho no es normal. Es decir, normal y anormal lo juzgamos en trminos estadsticos. Si
sobre la campana de Gauss, que es la representacin de la curva normal, dibujamos zonas correspondientes a la
144
145
[SHEWHART, 1939]
[PUTNAM, L. H. e MYERS, W., 2003]
158
Captulo 10
Boria et al.
146
distancia de la media a una, dos, y tres desvos estndares , y llamamos a esas zonas A, B, y C, como en la Figura
10.5, encontraremos que las dos colas sealadas con flechas tienen muy baja probabilidad de ser parte de una
muestra pequea de la variable, una vez de cada cien que observemos la variable podemos encontrar un valor en
esas zonas (de hecho la probabilidad de que ocurra naturalmente es inferior al 0,3%). Por lo tanto, si las cosas son
normales, no esperaramos que eso ocurra. A la inversa, si vemos un valor fuera de las zonas A, B, o C,
sospechamos que algo anormal est ocurriendo, que el proceso nos est diciendo algo. Es por esto que el adagio
es hay que escuchar la voz del proceso.
Figura 10.5: Zonas de SPC Bajo la Distribucin Normal
Si se lo hubiera hecho en las primeras etapas del proyecto fuera de control se hubieran detectado las
anomalas y se podran haber tomado medidas paliativas o correctivas.
Las zonas A, B y C sirven adems para otros usos. Dada la caracterstica aleatoria de las variables los valores
obtenidos del mismo proceso no son siempre idnticos. La variacin que consideramos aceptable la rotulamos
normal e ignoramos el ruido que produce. Shewhart se dio cuenta que el proceso a veces grita (cuando se
exceden los 3 desvos estndares) y a veces musita. Las reglas complementarias a la del punto ms all de la zona
de control son mltiples y han sido modificadas desde que Shewhart las generara para Western Electric. Son las
siguientes:
2 de 3 puntos consecutivos en la zona A, que es similar al caso anterior, ya que la probabilidad de que
esto suceda es inferior al 0,0625%.
6 puntos consecutivos en lnea ascendente o descendente, puesto que esto tambin tiene muy baja
probabilidad (probabilidad de las rachas) se considera que el sistema sigue una tendencia no aleatoria.
9 puntos consecutivos a un lado de la lnea central (ya sea por encima de ella o por debajo). Este caso
suele indicar un desplazamiento de la media, generalmente debido a un cambio significativo en el
sistema. Puede ser una buena noticia, por ejemplo que aument la productividad, pero de todos
modos hay que explicarlo.
14 puntos consecutivos alternando arriba o abajo, lo que puede indicar un fenmeno cclico o series
temporales, o que estamos en presencia de dos poblaciones.
15 puntos consecutivos en la zona B o C: esto implica una mejora de la precisin y una menor
desviacin estndar asociada. Otra vez, en general es una buena noticia.
4 de 5 puntos consecutivos en la zona B o ms all.
8 puntos consecutivos por encima y por debajo de la zona C indica que tenemos dos poblaciones
diferentes.
En definitiva, prestar atencin al comportamiento del proceso permite tomar decisiones anticipadas, al poder
separar el ruido del mensaje. La tabla de riesgos se completa con la ltima fila como muestra la Tabla 10.2.
5
146
El atraso en el sprint de arquitectura fue tomado

No hay un conocimiento
como un buen sntoma, como que el tiempo
profundo del comportamiento
invertido en al anlisis iba a pagarse solo en lo
de los procesos y en
sucesivo, cuando en realidad se cort
consecuencia la supersticin se
abruptamente porque se sinti que continuar era impone a la realidad
mejor que esperar a entender bien el problema
del usuario
Tabla 10.2: La ltima Fila del Anlisis una Vez Completo
Aplicar SPC a los

procesos crticos.
Medida de la dispersin de una variable alrededor de la media de su distribucin.
Captulo 10
159
10.8 Correlacin y Regresin

2
Si T hubiera utilizado SPC podra haber detectado las anomalas muy temprano en el proyecto. Ese uso ya
justifica el anlisis, pero una vez que poseemos ese conocimiento es tentador poder usarlo ms extensamente.
2
Considerando que en los aos en que se llevan datos en T la masa de ellos es sumamente interesante Jessica
propone que se identifiquen tendencias y se las analice. Claudio se ha familiarizado con las tcnicas de inteligencia
147
de negocios y propone contratar a un doctorando con quin comparte cursos y sabe un experto en el tema. As
2
es como, temporariamente, Damin se incorpora al equipo de T .
Damin segmenta los datos en poblaciones diferentes y produce un anlisis detallado de cada una. Arma lo
que se llama hipercubos de datos que va a someter a mtodos estadsticos. La idea es que una base de datos
relacional en 5 forma normal es muy lenta para realizar las miles de operaciones SELECT que demanda el anlisis,
por lo que hay un proceso de extraccin que separa los datos y arma una super-tabla, el cubo en cuestin. Sobre
ese cubo hace diversas operaciones: limpia los datos, analiza correlaciones y factores mediante anlisis de la
varianza y anlisis factorial; y construye ecuaciones de regresin que vinculan los valores de sus cubos. El resultado
de esos esfuerzos es un conjunto de modelos que predicen el comportamiento de variables del proyecto a partir
de ciertos datos que son obtenidos en etapas tempranas del mismo, justo lo que el mdico recomienda.
10.9 Identificacin de procesos crticos
2
Dada la gran masa de datos que posee T es posible sacar conclusiones de los mismos usando minera de
datos, como hizo Damin, pero en los casos en que esos datos no existen o son insuficientes, el construir
trabajosamente decenas de mediciones es poco operativo. Aun cuando los datos existan, es posible que haya un
148
exceso de informacin, que puede ser tan paralizante como su falta . Como dijera Stephen Covey, lo principal es
149
asegurarse que lo principal es lo principal . Pero como?
Si recordamos el modelo de Kano (Figura 10.6) que vimos en el Captulo 7 la satisfaccin del cliente es el
principal objetivo de la empresa. En primer lugar debiramos asegurarnos que no hay requisitos obligatorios que
no han sido cubiertos. Esto significa que debemos hacer un esfuerzo grande por conocer las necesidades de
nuestro cliente, ms all de las que son verbalizadas en los requisitos, como ya vimos en el Captulo 8 al discutir los
resultados de DRE. Es necesario saber que lo que pide, lo que quiere y lo que necesita no son lo mismo. Liste
entonces las necesidades de su cliente, identifique cuando satisface sus expectativas y donde todava no lo hizo,
pero no intente medir xitos y fracasos, mantenga su foco en las expectativas y use el modelo de Kano para
clasificar los requisitos. Este conocimiento debiera permitirnos identificar los eventos crticos. Un evento
crtico es un instante en el que el usuario de un producto o servicio se forma una opinin sobre la calidad o el
valor del mismo. Por ejemplo, un restaurant de comida rpida en una ruta es elegido para parar a comer por un
viajero atrado por la publicidad en el camino, pero al acercarse al el cliente tiene varios eventos crticos, para
empezar si el restaurante est del mismo lado de su marcha o si tiene que dejar la autopista y cruzar para ingresar
al establecimiento; de inmediato la accesibilidad del estacionamiento; su limpieza, dado que es un indicador de lo
que puede encontrar dentro del restaurant; su percepcin de la seguridad en el estacionamiento, puesto que va a
dejar su automvil con valores dentro, no va a bajar su equipaje; la disponibilidad de lugares de estacionamiento,
puesto que en la ruta esperar no es agradable. Todo esto lo considera el cliente sin hacer un anlisis de decisiones
formal.
147
Se denomina inteligencia empresarial, inteligencia de negocios o BI (del ingls business intelligence) al conjunto de
estrategias y herramientas enfocadas a la administracin y creacin de conocimiento mediante el anlisis de datos
existentes en una organizacin o empresa. http://es.wikipedia.org/wiki/Inteligencia_empresarial
148
149
http://www.thedailybeast.com/newsweek/2011/02/27/i-can-t-think.html en Newsweek y su traduccin en Tiempo,

http://www.tiempodehoy.com/cultura/exceso-de-informacion hacen referencia a investigaciones al respecto conducidas
por Angelika Dimoka, directora del Centre for Neuronal Decision Making de la Universidad de Temple (Pensilvania)
[COVEY, S., 1996], First Things First.
160
Captulo 10
Boria et al.
Figura 10.6: Diagrama del Modelo de Kano
En productos y servicios de software el equivalente a estos eventos crticos pueden ser diferentes de cliente
en cliente, pero hay que considerar los defectos, como las diferencias con los requisitos, en su severidad y nmero;
la adecuacin y conveniencia de uso del sistema a las necesidades, su facilidad de uso, lo complicado o no del
aprendizaje; el tiempo que se demora en la entrega, hecha efectiva con calidad, quizs no solo el tiempo
acumulado de las demoras sino tambin la cantidad de veces que se prometi entregar y no se cumpli; la
facilidad de instalacin (transicin de la vieja versin o el producto anterior); el volumen de cambio en los
procesos; la migracin de datos; los costos de una vez, ya sea por licencia (COTS) o los costos de desarrollo en
contratos de tiempo y materiales, o de ajustes en MOTS, tambin con consideraciones sobre el soporte, como el
personal dedicado y la curva de aprendizaje de su propia gente si se transfiere este al cliente; todos estos
momentos de verdad pueden afectar la percepcin de calidad del cliente. Esto constituye lo que se denominan
CTCs (Critical to Customer).
El prximo paso es identificar caractersticas medibles de un producto, servicio o proceso que son clave, de
modo que los lmites de especificacin o estndares de performance deben cumplirse para obtener la satisfaccin
del cliente, que en la literatura se denominan CTQs (Critical to Quality). Para transformar las necesidades y deseos
del cliente en requerimientos mensurables que se puedan implementar y controlar en la empresa necesitamos una
herramienta, y esa es el rbol CTQ. Para construir el rbol seguimos los siguientes pasos: Escuchar la voz del
cliente (VOC); Identificar Defectos en Productos y Servicios; Definir las Unidades de Productos y Servicios; y
Detallar las Oportunidades para Productos y Servicios. Por ejemplo, tomemos un incidente registrado en nuestra
base de datos: Cada vez que pido un cambio en el producto tengo que esperar seis semanas para que me
contesten'. El incidente pasa a ser un evento crtico y queremos resolverlo. Debemos primero identificar la variable
CTQ, en este caso el tiempo de respuesta a pedidos de cambio. La medicin que debemos usar o crear es el tiempo
de respuesta a un pedido de cambio, medido en das desde que aparece en nuestra base de pedidos de cambios
hasta que el usuario recibe la respuesta, no antes. Hablando con los clientes descubrimos que les parece razonable
un tiempo de respuesta que no exceda tres das hbiles. Ahora dispondremos de una seal para medir cuando un
pedido de cambio tiene un tiempo de respuesta que excede los tres das. En este punto debemos identificar que
lleva a los procesos a demorar ms de tres das. La Figura 10.7 muestra una grfica que ejemplifica nuestro anlisis.
Figura 10.7: Barreras a la Calidad
Captulo 10
161
Desde una necesidad genrica expresada por el cliente identificamos los procesos que estn haciendo de
barrera para la satisfaccin del cliente y los procesos relacionados CTQs que especficamente hay que mejorar para
eliminar los obstculos. Un ejemplo, de nuevo con una cadena de restaurantes, pudiera ser que esta viene
recibiendo quejas de la mala actitud de sus empleados en varias concesiones. Un anlisis de los incidentes indica
que los clientes (VOC) se quejan de tener que esperar hasta que los saludan al ingresar al establecimiento, se los
ignora por mucho tiempo; tambin el tener que esperar mucho tiempo hasta que les limpian una mesa cuando no
hay mesas libres al llegar; y que los que atienden las mesas no son amables, profesionales pero demasiado
distantes. El anlisis podra dar el siguiente resultado (Figura 10.8).
Figura 10.8: Anlisis de Factores CTQ
Los rectngulos representan procesos, los valos objetivos de negocio traducidos a objetivos de proceso, y las
flechas cambios sugeridos. Ntese que Trato Amable Segn Proceso ha sido traducido en una serie de objetivos
que no cubren las necesidades del cliente. Esto es tpico de una inhabilidad para traducir en objetivos medibles
ciertos comportamientos. Ya hemos recomendado el libro de Mager en Captulos anteriores y lo volvemos a hacer
ac. Estn faltando dos objetivos observables: Mira a los ojos del cliente cuando se dirige a ella, y Sonre al hablar.
Estos dos objetivos son medibles puesto que son observables y una lista evaluativa lo consigue evaluar.
Este proceso es equivalente al que introdujera Jessica al comit de gestin en una de sus primeras
intervenciones, el BSC u hoja de resultados balanceados. Los pasos son semejantes, se identifican objetivos de
negocio y se los traduce a objetivos derivados hasta que se obtiene una clara asociacin con procesos. Por
ejemplo, partiendo de retener a los clientes de nuestra cartera, es posible traducir este objetivo en varios objetivos
derivados de mejorar la interface con el usuario, disminuir el nmero de defectos entregados, acelerar el
procesamiento de ciertos datos, mejorar el tiempo de descarga e instalacin, etc. etc.
Estos objetivos se pueden asociar fcilmente con procesos, posiblemente ms de uno, y para cada uno de
ellos podemos a su vez identificar objetivos. Por ejemplo, podramos asociar la cantidad de defectos entregados
150
con el proceso de inspecciones, y colocar un objetivo de eliminar, o disminuir significativamente la porosidad de
las inspecciones. Esto llevara a la exploracin de varias alternativas para detectar ms defectos en cada
inspeccin, ya sea mejorar las listas de chequeo, entrenar mejor al personal o involucrar personal con ms
experiencia. Conocida la distribucin de los valores asociados al proceso, como la densidad de defectos
encontrados, se pueden fijar objetivos que expresen las mejoras como modificaciones a los parmetros de la
distribucin, como disminuir el valor medio, o disminuir el valor de la desviacin estndar, lo que significa un
aumento en la precisin de la estimacin.
150
La porosidad de un proceso de software es el porcentaje de defectos que deja escapar sobre el total que debiera haber
encontrado. Obviamente la porosidad no se puede calcular in processu, es necesario contar con datos de los defectos
escapados que son encontrados en procesos posteriores. Los defectos latentes son los que nunca son encontrados.
162
Captulo 10
Boria et al.
Figura 10.9: BSC Aplicado a Identificar Procesos Crticos
Por ltimo, una tcnica para identificar procesos crticos es construir modelos de regresin con las variables
conocidas y analizar la sensibilidad del modelo usando diagramas de tornado. Aqullos que demuestren mayor
sensibilidad son crticos y deben ser mejor controlados.
10.10 Procesos Capaces
Una vez establecido el objetivo a alcanzar es til preguntarse si podemos modificar el proceso para que este
se alcance. Dado nuestro conocimiento de la variacin ya no podemos enunciar objetivos en trminos de un solo
nmero, debemos especificar los lmites que consideramos definen la zona deseable para los valores de la variable.
Por ejemplo podemos definir un objetivo como la densidad de defectos detectada por las pruebas de sistema
debe ser de 0,1 defecto por punto funcin (PPF), ms o menos 0,001 defecto PPF. Por supuesto, los nmeros
elegidos son arbitrarios y sumamente ambiciosos, pero de nada vale fijar objetivos que no lo sean. Por ejemplo un
objetivo de 10 defectos PPF ms o menos 7 defectos PPF es tan poco ambicioso que el efecto puede ser que los
equipos desciendan en su capacidad.
Hemos definido un proceso como estable si la variacin es aceptable para los propsitos del negocio. Por
supuesto, somos conscientes que esta no es una definicin operativa y que es demasiado subjetiva para aparecer
til. Sin embargo, dado que todos los procesos muestran variacin, cualquier definicin que fije valores es
arbitraria y el nico juicio que podemos proponer es el de la adecuacin. Visto desde la perspectiva de SPC un
proceso estable es uno que se observa dentro de los lmites de control. Un concepto afn, el de proceso capaz, est
vinculado a las necesidades del negocio impuestas por el cliente. Dados los objetivos fijados a partir de las
necesidades del cliente establecemos otros lmites al proceso, no de control sino de especificacin. Ya hemos
hablado de la voz del proceso, estos lmites ahora se asocian a la voz del cliente. En realidad hay una gran cantidad
de vas para identificar los procesos crticos. La Figura 10.10 ilustra muchos de ellos.
Figura 10.10: Factores En la Eleccin de Procesos Crticos
No solo son importantes las necesidades de los clientes, hay otras variables, como costos y ocupacin de
recursos que pueden determinar procesos crticos. As y todo es recomendable no ignorar la calidad so pena de
desaparecer del mercado. El proceso que mejor se adapta a las necesidades del negocio y del cliente es aqul que
es capaz y estable. De hecho podemos poner en duda que un proceso no estable sea capaz porque sera imposible
de demostrar. La Figura 10.11 muestra la relacin entre ambas caractersticas. En la figura UCL significa Lmite de
Control Superior, del ingls Upper Control Limit. LCL es el Lmite de Control Inferior, por Lower Control Limit, USL el
Captulo 10
163
Lmite de Especificacin Superior y LSL el Lmite de Especificacin Inferior. En la mitad derecha se muestra un
proceso capaz y estable, porque los lmites de control estn comprendidos por los lmites de especificacin,
mientras que la mitad derecha muestra un proceso estable pero no capaz. Si no se pueden modificar los requisitos
del cliente no queda alternativa que modificar el proceso para que sus lmites de control se reduzcan.
Figura 10.11: Procesos Capaces y Procesos Estables
10.11 Lneas Base

Los procesos crticos tienen que ser controlados ms de cerca que los otros. Si en los primeros niveles del
MPS alcanza con verificar el progreso de manera global y en puntos prepautados del proyecto, como los hitos de
cambio de fase, y en los niveles G y superiores es indispensable verificar el avance por tarea, en los niveles B y A el
control recae en SPC. Para ello es necesario contar con los datos necesarios para entender los lmites de control
naturales de los procesos, en particular los crticos. A esa caracterizacin se la llama lnea base de desempeo y
es la piedra basal de la alta madurez. Cada punto que se ingresa en el diagrama de control de SPC permite sacar
conclusiones sobre el comportamiento del proceso. Por eso, Damin ha segmentado los datos en poblaciones
diferentes, los ha estratificado cuando diferentes rangos mostraban diferentes comportamientos, depurado para
eliminar los datos mal tomados o que responden a situaciones excepcionales y construido la lnea base de
desempeo de todo lo que sirve para la gestin cuantitativa de los procesos crticos.
10.12 Indicadores Lderes
Dada la relacin entre los procesos tempranos que se exploran con diferentes medios, Damin ha encontrado
que varios procesos sirven de alerta temprana para saber si un proyecto est orientado a alcanzar sus objetivos. La
nocin de un indicador que permite anticipar resultados de un proceso posterior es fundamental para la gestin
cuantitativa de un proyecto. Digamos que hemos decidido que para aumentar nuestra participacin en el mercado
debemos reducir los defectos que llegan al cliente y que para esto hay que aumentar el esfuerzo en inspecciones y
conseguir mejores y ms inspectores. Con eso pensamos que podemos disminuir el porcentaje de errores filtrados
y de ese modo bajar los defectos de campo.
Figura 10.12: Indicadores Lderes
Los modelos de regresin que ha construido Damin a partir de los datos son los que nos permiten establecer
151
estas hiptesis. Un indicador es siempre un indicador de resultado : mide lo que pas, ninguno puede medir lo
152
que va a pasar. Pero algunos indicadores pueden ser indicadores de causa
porque sus valores sirven para
predecir el resultado de las acciones que se encuentran ms adelante en el flujo del proceso. Justamente esos
151
152
Tambin se les llama indicadores de efecto, y en ingls, lag indicators u outcome measures.
Tambin se llaman indicadores inductores, y en ingls, lead indicators o performance drivers.
164
Captulo 10
Boria et al.
modelos de regresin permiten establecer intervalos dentro de los cules se encontrar una variable futura a
partir del conocimiento del valor actual de un indicador de desempeo. Esto nos permite corregir el rumbo si es
necesario. Por ejemplo, Damin ha encontrado en sus datos una relacin que modela la duracin de la
construccin de un requerimiento como predictor de la duracin del perodo de pruebas. Con ese modelo hubiera
sido posible prever en los primeros momentos que el proyecto fuera de control lo iba a estar.
10.13 Composicin del Proceso Definido del Proyecto
2
Mientras que T usaba sus herramientas del BiPro cualitativamente, las guas de ajuste cumplan con creces el
propsito de adaptar el proceso estndar a las necesidades del proyecto en particular. Pero la introduccin de las
herramientas cuantitativas, las lneas base y los modelos, hacen necesario que se revise el proceso de seleccin de
las componentes. Lo que antes era cualitativo ahora debe ser seleccionado con atencin a los objetivos de la
empresa. Los objetivos fijados en la reunin mensual se traducen uno a uno para cada sprint, y Damin a partir de
sus modelos y las lneas base de desempeo que se les aplica corre simulaciones que le permiten ofrecer a los
equipos las alternativas posibles, una o ms, para alcanzar los objetivos. Esto implica que no hay una estrategia
dominante, es decir que no hay una nica forma de hacer las cosas.
Figura 10.13: Distintas Posibilidades de Composicin del Proceso
Imaginemos que hay tres diferentes mtodos para capturar requisitos, las Entrevistas Individuales, JAD y RAD,
y que cada uno tiene su lnea base de desempeo a nivel del requisito individual, con su distribucin para costo,
duracin y calidad. Lo mismo ocurre para los dos mtodos de Diseo, los cuatro de Codificacin y los tres de
Testing. Dependiendo de lo que se est buscando optimizar el camino que se siga ser distinto, por ejemplo RAD
es el que mejor calidad tiene pero es ms costoso que RAD o las Entrevistas. Damin tiene entonces de donde
sacar datos para correr sus simulaciones de Montecarlo y generar resultados alternativos que le permitan al
equipo interesado hacer la eleccin que mejor se aviene a sus necesidades.
Si no hubiera ninguna alternativa que permita alcanzar los objetivos cmodamente el comit es convocado
para revisarlos o para dar una dispensa al equipo, o para intentar, de todos modos, alcanzarlos con un proceso que
no tiene una alta probabilidad de hacerlo. En este ltimo caso se aaden a los riesgos los procesos que tienen ms
impacto en el resultado y se buscan alternativas que permitan mitigar esos riesgos.
10.14 Gestin Cuantitativa
Armados con un proceso que debe funcionar en la mayora de los casos los equipos simplemente tienen que
hacer las tareas, medir los resultados y controlarlos mediante SPC para que la gestin se lleve adelante. No hay
ms necesidad de nada y el proyecto se controla solo mientras los datos no muestren anomalas. Si hay decisiones
a tomar ante cambios de cualquier porte, el Scrum Master o el programador jefe pueden reusar el modelo, con o
sin la ayuda de Damin, para estimar el efecto de sus decisiones. Esto es as porque los modelos poseen variables
que estn bajo control de los que toman las decisiones, como ser la experiencia promedio de los participantes en
ciertas tareas, la cantidad de inspecciones que se introducen en el proceso, las estrategias de prueba y otras que,
al poder modificarse, permiten hacer ajustes al proyecto durante su ejecucin a travs de modificaciones al
proceso.
10.15 La Mejora Continua Como Estrategia de Negocio
2
Para T el objetivo es ser mejor. No solo ser la mejor de todas las empresas en su rubro, sino mejor que ella
misma, ayer. Desde su humilde inicio la empresa no h hecho mas que mejorar. La calidad que muestran sus
productos y su afn de superacin resulta en un diferencial competitivo que es usado para ganar y retener clientes.
Cada paso en su camino a la excelencia es difundido por los canales tradicionales y los premios obtenidos ayudan a
la conquista de mercado, continuamente.
Captulo 10
165
El conocimiento profundo que ha adquirido de su funcionamiento no solo le permite predecir con mayor
precisin que sus competidores los resultados, sino que le permite tambin elegir los clientes. Aquellos que no le
ofrecen seguridad en los mrgenes se los pasa graciosamente a los perseguidores de cuota de mercado, como
los llama Claudio. Este conocimiento y su versatilidad con los mtodos giles son el fruto directo de decisiones
estratgicas que permiten disear nuevas lneas de producto con alta probabilidad de xito. Los riesgos de
territorios desconocidos y dominios sin dueo le son conocidos y ha aprendido a navegarlos. Sus anlisis de cartera
han pasado a ser verdaderos anlisis financieros con profusin de datos de mercado, probabilidades y
simulaciones.
10.16 Costo de Competir
2
Todava ms importante para T es que sus competidores tienen serios problemas para poder entrar en los
2
mercados de T . Sus mtodos giles y su perfecta posicin en el mercado hacen que constantemente arriesguen
2
mrgenes, con las consiguientes prdidas ocasionales y los dolores de cabeza consiguientes. La calidad de T ha
subido el costo de entrada para sus competidores.
2
Adems de eso, T puede conseguir los mejores recursos humanos en el mercado porque su mito tiene
2
mucho arraigo. Trabajar para T es un orgullo para los profesionales y es considerada una excelente escuela de
2
negocios. Si alguien recibe una oferta de T es poco probable que la rechace.
10.17 Innovacin tecnolgica
2
Sin embargo T tiene claro que no se puede dormir en los laureles. Como parte de su programa de induccin a
la empresa los ingresantes reciben instruccin en el proyecto de Escucha Tecnolgica. Ese proyecto, hijo de
153
Mariano y Alfredo, quines lo comparan al SETI , consiste en la bsqueda constante de nuevas ideas y
2
tecnologas de aplicacin. Cada ingeniero de T elige una publicacin acadmica, cientfica o de divulgacin, como
Scientific American, CACM, IEEE Computer, IEEE Software, o Discover, y la empresa le paga la suscripcin y las
cuotas sociales si aplican. A cambio el ingeniero tiene que contribuir al menos una nota al mes sobre lo que ha
2
154
ledo en la revista de T , llamada SPI Glass. Al principio del programa cuando los ingenieros se contaban por
unidades todo lo que se enviaba se publicaba. Hoy, con los nmeros acercndose a los mil en las tres plantas, hay
un comit de seleccin de materiales que es una tarea de tiempo completo.
Varias ideas germinaron a partir de lecturas en los medios. Una manera novedosa de captar requerimientos
mediante prototipos en papel pas de inquietud a propuesta de mejora a ser pilotada en un proyecto y complet
su ciclo cuando fue adoptada como una tcnica en BiPro. La incorporacin de estos cambios a los procesos ha
sufrido cambios en s misma tambin. Antes los pedidos y sugerencias de cambio se trataban en reuniones para
priorizarlos y aprobarlos, postergarlos, rechazarlos o darles un tratamiento piloto. Hoy los datos y modelos
estadsticos gobiernan las decisiones. El comit de gestin ya no pregunta Cmo va el proyecto? o Cmo
podemos aprovechar eso? sino que es mucho ms preciso: Cul es la probabilidad de cumplir sus compromisos
que tiene este proyecto? y espera una respuesta numrica con un grafico que lo acompae. Para el caso de
procesos, lo que pregunta es Cmo se modifican nuestros mrgenes en el futuro, adoptando ese cambio? y
Cul es el valor presente de esa inversin?. Marcela no lleva nada ante el comit que no vaya acompaado del
plan piloto, los datos financieros que prepar con Claudio sobre las simulaciones que corri Damin. En casos en
que as se justifique presenta un rbol de decisiones.
153
154
http://www.seti.org/, SETI es un proyecto de bsqueda de vida extraterrestre.

Software Process Improvement, Spy Glass es el nombre del catalejo en ingls.
166
Captulo 10
Boria et al.
Figura 10.14: Definicin de Adyacencias y Espacio en Blanco Segn Johnson
De ese modo se han incorporado cambios a muchos procesos, inclusive algunos que provienen de la noche
de los tiempos, como llaman los gemelos a los das en que los fundadores se reunan alrededor de una mesa de
enchapado vinlico para ordenar sus ideas de diseo y rematar las tareas. La automacin gobierna los procesos,
2
pero las ideas gobiernan la automacin. T ha aprendido a reconocer su ncleo pero tambin a explorar el espacio
155
en blanco , aquellas oportunidades que no encajan con sus modelos de negocios o con sus clientes habituales.
Johnson define al espacio en blanco como: la gama de posibles actividades que no estn definidas o dirigidas
por el modelo de negocios de la empresa actual, es decir, las oportunidades fuera de su ncleo y ms all de sus
adyacencias que requieren un modelo de negocio diferente de explotar.
Figura 10.15: Construir-Medir-Aprender
Algunas de las propuestas que se escuchan en el comit son atendidas de una manera muy particular: Se crea
un grupo de estudios que recibe presupuesto del mismo modo que un proyecto, pero que no tiene las mismas
obligaciones. Por ejemplo, no sigue un ciclo de vida normal, utilizando en cambio uno que Jessica adapt del libro
155
[JOHNSON, M., 2010], Seizing the White Space: Business Model Innovation for Growth and Renewal
Captulo 10
167
156
de Eric Ries, The Lean Startup . Ries llama a su ciclo de retroalimentacin Construir-Medir-Aprender. (Ver Figura
10.15). El objetivo es acelerar el aprendizaje pasando tan rpido como sea posible por todos los pasos del ciclo. En
vez de construir un prototipo completo, lo que se conoce como una prueba de concepto, se construye una
maqueta incompleta que se somete de inmediato a la prueba de uso por el cliente. Esto debe ser medido contra
criterios que se han fijado de antemano, como es el caso en el diseo de nuevas funciones en software. Las
reacciones de los usuarios sugieren cambios, ajustes, continuar por el camino y ampliarlo o simplemente
2
suspender el proyecto. Sea cul fuera el resultado, T cree justificado el experimento porque la organizacin
aprendi.
A veces los usuarios hacen comentarios que identifican errores gruesos pero no exactamente como
resolverlos. Para ello se aplican las mismas tcnicas de anlisis de causa que usan los proyectos de software y el
grupo de calidad de Marcela para identificar problemas, oportunidades y soluciones, pero sin contar, como los
anteriores, con la ventaja de los datos estadsticos. Ya vimos varias tcnicas de uso comn, empezando en la
noche de los tiempos con el diagrama de espina de pescado, y el mtodo de las ocho disciplinas. En dos
157
oportunidades hemos mencionado la Ley de Pareto , pero no hemos mostrado una aplicacin particular que se
hace en el anlisis de causas profundas. Cuando un acontecimiento lo merece, por ejemplo un cisne negro, el
anlisis de causa sigue el mtodo habitual de analizar las causas profundas con los expertos, identificar soluciones,
estimar su impacto, venderlas a la direccin, implementarlas y medir el resultado. Pero en dos ocasiones al ao el
grupo de Marcela analiza las mejoras a implementar para el semestre. Las fuentes de iniciativas son los grupos de
estudio, las sugerencias a travs del SPI Glass y los cambios a los objetivos de negocio. Estos ltimos sugieren
mejoras en trminos de mrgenes a alcanzar, para lo cul una de los puntos de partida son los defectos
registrados.
Marcela y su grupo clasifican los defectos y analizan su impacto en el retrabajo. Los que ms esfuerzo
demandan son candidatos a seguir el proceso de anlisis de causa. La Figura 10.16 muestra un diagrama usado en
este anlisis.
Figura 10.16: Diagrama de Pareto de Defectos de Cdigo
Los defectos de cada categora se contabilizan sumando el esfuerzo de correccin individual en das de
trabajo. Salida Incorrecta acumula 53 das, que representa un 52,5% del total del esfuerzo invertido en
correcciones. Entre esta categora y la que le sigue en importancia acumulan 81,2% del total, un ejemplo de la ley
del 80-20. Es fcil sacar conclusiones a partir del diagrama. Por ejemplo, si consiguiramos disminuir a la mitad el
nmero de defectos de la primera categora reduciramos en promedio 26,5 das de esfuerzo de correccin. Esto es
traducible a dinero contante y sonante de modo inmediato, por lo que se puede rpidamente tener una idea del
volumen que se puede invertir en eliminar los defectos de ese tipo. Los errores de direccionamiento no tienen ese
mismo peso, y por lo tanto salen del anlisis.
156
157
[RIES, E., 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful
Businesses
Captulos 2, en la discusin de Lean, y 8, aplicndolo al anlisis de perfil operativo.
168
Captulo 10
Boria et al.
Este mtodo de experimentar nuevas ideas ha dado frutos muy interesantes. T ha generado dos spin-offs:
Una lnea de producto nuevo es ya una empresa propia, fabricando ambientes de desarrollo para aplicaciones para
telefona inteligente, la segunda fabrica una serie de servicios en la nube para aplicaciones de seguros con banda
ancha para hacer uso profuso de la imagen en siniestros, ahorrando miles de horas de inspeccin por mes. Una de
las aplicaciones desarrolladas por la fbrica de apps es una visin 3-D de un objeto a partir de una filmacin de
360. Las empresas tienen sinergia
Pero ms interesante es el uso que han dado a proyectos que se aventuraron en el espacio en blanco. En
algunos casos vendieron las patentes, en otros iniciaron nuevas sociedades o financiaron a los que hicieron el
2
estudio, a cambio de una participacin en la nueva empresa. T est preocupada por la enfermedad del
crecimiento: El anquilosamiento, y lo combate de todas las maneras posibles.
2
89. Los valores tpicos del proyecto de SOA no corresponden a la historia de los proyectos de T .
90. Un proyecto SOA nuevo entra en crisis y se sale de control.
2
91. Jessica introduce SPC a T .

92. Damin ingresa al equipo para realizar anlisis de datos con herramientas de inteligencia de
negocios.
93. Damin segmenta los datos en poblaciones diferentes y produce la lnea base de desempeo de
cada una.
2
94. Con la ayuda de diversas tcnicas se identifican los procesos crticos para T .
2
95. Definidos los procesos crticos T se asegura de que sean estables y tengan ya su lnea base.
96. Para los procesos crticos Damin genera modelos estadsticos de prediccin para utilizarlos en
el anlisis de objetivos.
97. El sistema de medicin se extiende para incluir indicadores lderes e intervalos de confianza.
98. La composicin del proceso definido del proyecto pasa a ser cuantitativa, basada en
simulaciones Monte Carlo de su desempeo.
2
99. La persecucin constante de la excelencia sube el costo de entrada para la competencia de T .

100.La innovacin sistemtica da frutos dulces.
Captulo 10
169
CAPTULO 11 - CONCLUSIONES
La no-ya-tan-pequea Tahini Tahini

Nuestra historia termina aqu. Nuestra amable T2 est considerando una oferta de compra astronmica de
dos de sus lneas de negocio, hecha por una empresa gigante de los EE.UU. Los gerentes, an muy jvenes, evalan
ideas acerca de su retiro en las islas del Pacfico Sur o Fernando de Noronha. Teniendo en cuenta su trayectoria se
lo merecen. Pero, por ahora, es necesario resumir su historia para que otros la puedan aprovechar.
Lean como mtodo de identificacin de mejoras de proceso

El uso de una metodologa para la identificacin de oportunidades basadas en la reduccin del fracaso y de
los tiempos de entrega, hizo que la compaa se centrase en los negocios antes que en los procesos. Si bien
2
mientras mejoraban los procesos, el objetivo siempre ha sido mejorar la competitividad de T . El precio nunca fue
tan alto de manera que los resultados siempre justifican la inversin. En resumen, el resultado es una compaa de
clase mundial que justifica su importancia en los hechos.
Mtodos giles como una herramienta para mejorar

2
Uno de los factores que aceleraron la maduracin de T como empresa, fue la eleccin de mtodos giles al
comienzo de su vida. La iteracin continua aument el conocimiento de los procesos y su aplicacin. Con muchos
datos en la mano, las decisiones fueron ms simples y ms exitosas. Aun cuando la creciente complejidad de los
sistemas que se desarrollaron eliminaron el uso de Scrum y Kanban, la compaa contina con su adhesin a los
mtodos giles, eligiendo FDD para atacarlos nuevos retos.
El MR-MPS-SW como marco de crecimiento organizacional

Uno de los aspectos ms fascinantes del MR-MPS es su funcionalidad como herramienta para el desarrollo
organizacional. En etapas muy accesibles genera un camino de crecimiento que va desde el desorden inicial a la
excelencia global. Desde los primeros pasos, donde la reaccin es frecuente y los errores son muchos, hasta los
reinados de calidad donde los clientes estn plenamente satisfechos, el MR-MPS acompaa a las organizaciones
2
que lo adoptan. El resultado no siempre es tan exitoso como el de T , pero aquellos que no tratan de llegar a la
cima no disfrutarn del paisaje!
170
Captulo 11
Boria et al.
REFERENCIAS BIBLIOGRFICAS
ABNT, 2012, ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 29110-4-1: Engenharia de Software
Perfis de ciclo de vida para microorganizaes (VSEs) Parte 4-1: Especificaes de perfil: Grupo
Perfil Genrico, Rio de Janeiro: 2012.
AMBLER, S. W., 2002, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, John
Wiley and Sons.
ANDERSON, D. J., 2011, Kanban. Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
ANDRIOLE, S., 1993, Rapid Application Prototyping: The Storyboard Approach to User Requirements Analysis, QED
Technical Publishing Group.
ARTHUR, J., 2004, The Small Business Guerrilla Guide to Six Sigma, LifeStar Publishing.
ARTHUR, J., 2006, Lean Simplified. The Power Laws of Speed, LifeStar Publishing.
ATWOOD J., 2006, The Multitasking Myth, Coding Horror. Se encuentra en:
http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html.
BECK, K., 2000, Extreme Programming Explained, Addison-Wesley.
BOEHM, B., 1981, Software Engineering Economics, Prentice Hall.
BOEHM, B., 1989, Software Risk Management, IEEE Computer Society Press.
BOEHM, B. & TURNER, R., 2003, Balancing Agility and Discipline: A Guide for the perplexed, Addison-Wesley.
BENNIS, W., 1997, Learning to Lead: A Workbook on Becoming a Leader, Addison Wesley.
BORIA, J., 1987, Ingeniera de Software, Kapelusz (II EBAI).
BORIA, J., 1989 Construccin de Sistemas Operativos, Kapeluz (IV EBAI).
BORIA, J., 2010, Dont Be On Time. Se encuentra en: http://www.slideshare.net/jorgeboria/dont-be-on-time.
BROOKS, F. P., 1995, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition),
Addison-Wesley.
BROWN, A., 2010. Se encuentra en: http://www.aaronmbrown.net/blog/2010/07/programmers-flow-andproductivity/
CAMERON, K., QUINN, R., 2011, Diagnosing and Changing Organizational Culture: Based on the Competing Values
Framework, Jossey-Bass.
CARL III, W. J., Unpublished paper, Flow
A Theory of Optimal Experience: History and Critical Evaluation.
CARLZON, J., 1989, Moments Of Truth, Harper Business.

rd
CHRISSIS, M. B.; KONRAD M. & SHRUM S., 2011 (3 Edition), CMMI for Development: Guidelines for Process
Integration and Product Improvement, Addison-Wesley.
CLEMEN, R., 1997, Making Hard Decisions: An Introduction to Decision Analysis, Duxbury.
COAD, P., DE LUCA, J., LEFEVRE E., 1999, Java Modeling In Color With UML: Enterprise Components and Process,
Prentice-Hall.
COCKBURN, A., 2000, Writing Effective Use Cases, Addison-Wesley Professional.
COCKBURN, A., 2005, Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley.
COHN, M., 2006, Agile Estimation and Planning, Prentice-Hall.
COVEY, S., 1996, First Things First, Free Press.
CONNER, D., PATTERSON, R., 1982, Building Commitment to Organizational Change, Training and Development
Journal, v36 n4 p18-26,28-30 Apr 1982.
CULBERT, S., 2010, Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing-and Focus on What Really Matters, Business Plus.
Referencias Bibliogrficas
171
CRISPIN, L. & GREGORY, J., 2009, Agile Testing. A Practical Guide for Testers and Agile Teams, Addison-Wesley.
CSIKSZENTMIHALYIS M., 1991, Flow: The psychology of optimal experience, Harper & Row.
DECKER, B., RAS, E., RECH, E., KLEIN, B., HOECHT, C., 2005, Self-organized Reuse of Software Engineering
Knowledge Supported by Semantic Wikis, Proceedings of the Workshop on Semantic Web Enabled
Software Engineering.
DE BONO, E., 1985, Six Thinking Hats, Little Brown and Company.
DE MARCO, T. & LISTER, T., 1987, Peopleware: Productive Projects and Teams, Dorset House.
DEMING, E. D., 2010, Out of the Crisis, The MIT Press.
DENNEY, R., 2007, Succeeding with Use Cases. Working Smart to Deliver Quality, Addison-Wesley.
DENNEY, R., 2012, Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software
Test Design, CreateSpace Independent Publishing Platform.
DIAZ, M., & KING, J., 2002, How CMM Impacts Quality, Productivity, Rework, and the Bottom Line, Crosstalk, March
2002. Se encuentra en: http://www.crosstalkonline.org/storage/issue- archives/2002/200203/200203Diaz.pdf
EBENAU, R. & STRAUSS S., 1994, Software Inspection Process, McGraw-Hill.
FLORAC, W. A. & CARLETON, A. D., 1999, Measuring the Software Process, Addison-Wesley.
FOWLER, M., 2003, UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), AddisonWesley.
FREEDMAN, D. P. & WEINBERG G., 1990, Handbook of Walkthroughs, Inspections, and Technical Reviews. Dorset
House,
FRIED, J., 2005, An Analysis of the Correlation between System Engineering Defect Phase Containment and System
Engineering Hours at General Dynamics C4 Systems. Se encuentra en:
http://www.acims.arizona.edu/PUBLICATIONS/PDF/JenniferFriedMCSproject%205-21-05.pdf.
GAUSE, D. & WEINBERG G., 1989, Exploring Requirements: Quality Before Design. Dorset House.
GILB T. & GRAHAM D., 1994, Software Inspection, Addison-Wesley Professional.
GLASS R., 1997, Software Runaways: Monumental Software Disasters, Prentice Hall.
GOULD S., 1996, Dinosaur in a Haystack: Reflections in Natural History, Three River Press.
GRIES, D., 1987, The Science of Programming, Springer.
HALL, E., 1998, Managing Risk: Methods for Software Systems Development, Addison-Wesley Professional.
HIGHSMITH, J., 1999, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems,
Dorset House.
HIGHSMITH, J., 2001, Agile Alliances Agile Manifesto, History and Contents. Se encuentra en:
http://agilemanifesto.org/
HIGHSMITH, J., 2004, Agile Project Management. Creating Innovative Products, Addison-Wesley.
HOFMEISTER, C., NORD, R., & SONI, D., 2000, Applied Software Architecture, Addison Wesley.
HUMPHREY, W., 1989, Managing the Software Process, Addison Wesley.
HUNT, A. & THOMAS, D., 1999, The Pragmatic Programmer: From Journeyman to Master, Addison Wesley
Professional.
ISO/IEC, 2003, ISO/IEC 15504 Software Engineering Process Assessment, The International Organization for
Standardization and The International Electrotechnical Commision.
ISO/IEC, 2008, ISO/IEC 12207 System and Software Engineering Software Life Cycle Process, The International
Organization for Standardization and The International Electrotechnical Commision.
172
Boria et al.
JOHNSON, M., 2010, Seizing the White Space: Business Model Innovation for Growth and Renewal, Perseus Books
Group.
JONES, C., 1996 Applied Software Measurement, McGraw-Hill.
JONES, C., 1994, Assessment and Control of Software Risks, Prentice-Hall.
JONES, C., 1986, Programming Productivity, McGraw-Hill.
JOSUTTIS, N.,2009, SOA in Practice: The Art of Distributed System Design, OReilly Media.
KAPLAN, R., & NORTON, D., 1996, The Balanced Scorecard: Translating Strategy into Action, Harvard Business
Review Press.
KAN. S., 2002, Metrics and Models in Software Quality Engineering, 2nd Edition, Addison-Wesley Professional.
KERNIGHAN B. W., & PLAUGER P. J., 1974, The Elements of Programming Style, McGraw-Hill.
KNIBERG, H., 2007, Scrum and XP from the Trenches. How we do Scrum, C4Media, Publisher of InfoQ.com.
KNIBERG, H. & SKARIN, M., 2010, Kanban and Scrummaking the most of both, C4Media, Publisher of InfoQ.com.
KUBLER-ROSS, E., 1997, On Death and Dying. Scribner.
KUZNETS, S., 1966, Economic Growth and Structure. Selected Essays, Heinemann.
LADAS, C., 2008, Scrumban and Other Essays on Kanban Systems for Lean Software Development, Modus
Cooperandi Press.
LEFFINGWELL, D., 2007, Scaling Software Agility. Best Practices for Large Enterprises, Addison-Wesley.
LUCIA, A.D., LEPSINGER, R., 2007, The Art and Science of Competency Models. Pinpointing Critical Success Factors in
Organizations, Jossey-Bass Pfeiffer.
SM
McFEELEY, B., 1996, IDEAL : A Users Guide for Software Process Improvement. Software Engineering Institute
Handbook CMU/SEI-96-HB-001.
McMAHON, P., 2011, Integrating CMMI and Agile Development, Addison-Wesley.

McGARRY,J.; CARD, D.; JONES, C.; LAYMAN, B.; CLARK, E.; DEAN, J. & HALL, F, 2002, Practical Software
Measurement: Objective Information for Decision Makers, Addison Wesley.
MEADOWS, D., 2008, Thinking in Systems, A Primer, Chelsea Green Publishing.
MIRANDA, E., 2003, Running the Successful Hi-Tech Project Office, Artech House Publishers.
MONDEN, Y., 2011, Toyota Production System: An Integrated Approach to Just-In-Time, 4th Edition, Productivity
Press.
MOREIRA, M., 2010, Adapting Configuration Management for Agile Teams. Balancing Sustainability and Speed,
Wiley.
MYERS, G., 1979, The Art of Software Testing, Wiley.
NOLAN, R., 1973, Managing the Computer Resource: A Stage Hypothesis. CACM, Vol 16, No 7, July 1973,
republished in Managing The Data Resource Function, same author, West.
OKTABA, H. et al., 2005, Modelo de Procesos para la Industria del Software MoProSoft, versin 1.3.
PALMER, S. R. & FELSING, J. M., 2002, A Practical Guide to Feature-Driven Development, Prentice Hall.
PAULK, M., WEBER, C., E CURTIS, B., 1994, The Capability Maturity Model: Guidelines for Improving the Software
Process, Addison Wesley.
PIRSIG, R.M., 1974, Zen and the Art of Motorcycle Maintenance, An inquiry into Values, William Morrow and Co.
PMI, 2008, Project Management Institute. The Standard for Portfolio Management. Syba: PMI Publishing Division.
POPPENDIECK, M. & POPPENDIECK, T., 2010, Leading Lean Software Development. Results Are Not the Point, The
Addison Wesley Signature Series.
PUGH, S., 1991, Total Design: Integrated Methods for Successful Product Engineering. Addison-Wesley.
173
PUGH, S. 1981, Concept selection: a method that works. In: Hubka, V. (ed.), Review of design methodology.
Proceedings international conference on engineering design, March 1981, Rome. Zrich: Heurista.
PUTNAM, L. H. & MYERS, W., 2003, Five Core Metrics: The Intelligence Behind Successful Software Management,
Dorset House Publishing Company.
RODIN, R. & HARTMAN, C., 2000, Free, Perfect and Now: Connecting to the Three Insatiable Customer Demands, A
CEOs true Story, Free Press.
RIES, E., 2011, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically
Successful Businesses, Random House.
ROYCE, W., 1970, Managing the Development of Large Software Systems, Proceedings of IEEE WESCON 26
(August): 19
SCHWABER, K. & BEEDLE, M., 2002, Agile Software Development with Scrum, Prentice Hall.
SCHWABER, K., 2004, Agile Project Management with Scrum, Microsoft Press.
SCHUYLER, J., 1996, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, Project
Management Institute.
SEI, 2010, Capability Maturity Model Integration (CMMI) for Development, version 1.3, Carnegie Mellon University,
Software Engineering Institute, Technical Report CMU/SEI-2010-TR-033.
SENGE P. M., 2006, The Fifth Discipline: The Art & Practice of The Learning Organization, Crown Business.
SHEWHART, W., 1939, Statistical Method from the Viewpoint of Quality Control, Dover Books on Mathematics.
SOFTEX, 2011a, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX, MPS.BR
Guia de Aquisio:2011, junho 2011. Se encuentra en: http://www.softex.br.
SOFTEX, 2011b, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS:2011,
junho 2011. Se encuentra en: http://www.softex.br.
SOFTEX, 2011c, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:2011,
SOFTEX, 2011d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS:2011,
SOFTEX, 2011e, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS:2011,
SOFTEX, 2011f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS:2011,
SOFTEX, 2011g, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS:2011,
SOFTEX, 2011h, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS:2011,
SOFTEX, 2011i, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 8: Implementao do MR-MPS:2011 em organizaes que adquirem
software, junho 2011. Se encuentra en: http://www.softex.br.
SOFTEX, 2011j, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 9: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de
Software, junho 2011. Se encuentra en: http://www.softex.br.
174
Boria et al.
SOFTEX, 2011k, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 10: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de
Teste, junho 2011. Se encuentra en: http://www.softex.br.
SOFTEX, 2011l, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Curso de Introduo ao MPS-Software (C1-MPS-SW), setembro 2011.
SOFTEX, 2012a, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia Geral MPS de Software:2012, agosto 2012. Se encuentra en: http://www.softex.br.
SOFTEX, 2012b, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia Geral MPS de Servios:2012, agosto 2012. Se encuentra en: http://www.softex.br.
SOFTEX, 2012c, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Avaliao:2012, maio 2012. Se encuentra en: http://www.softex.br.
SOFTEX, 2012d, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS-SW:2012 em Conjunto com o
CMMI-DEV v1.3, agosto 2012. Se encuentra en: http://www.softex.br.
SOFTEX, 2012e, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 12: Anlise da Aderncia do MRMPS-SW:2012 em relao NBR ISO/IEC
29110-4-1:2012 -Engenharia de Software Perfis de ciclo de vida para microorganizaes (VSEs)
Parte 4-1: Especificaes de perfil: Grupo Perfil Genrico, setembro 2012. Se encuentra en:
http://www.softex.br.
SOFTEX, 2012f, ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX., MPS.BR
Guia de Implementao Parte 13: Mapeamento e Sistemas de Equivalncias entre o MR-MPS-SW:2012 e
o MoProSoft:2005, outubro 2012. Se encuentra en: http://www.softex.br.
SOLINGEN, R.; BERGHOUT, E., 1999, The Goal/Question/Metric Method: a Practical Guide for Quality Improvement
of Software Development, McGraw-Hill.
SPIEGEL, M. & STEPHENS, L., 2011, Schaums Outline of Statistics, Fourth Edition (Schaum's Outline Series) Mc Graw
Hill.
STAPLETON, J. & CONSTABLE, P., 1997, DSDM: Dynamic Systems Development Method: The Method in Practice,
Addison-Wesley Professional.
TALEB, N., 2012, Antifragile: Things That Gain from Disorder, Random House.
TALEB, N., 2010, The Black Swan: Second Edition: The Impact of the Highly Improbable: With a new section: On
Robustness and Fragility, Random House Trade Paperbacks.
TENNANT, G., 2001, Six Sigma: SPC and TQM in Manufacturing and Services, Gower.
TOIGO, J., 2002, Disaster Recovery Planning: Preparing for the Unthinkable (3rd Edition), Prentice Hall.
UNKNOWN AUTHOR. Se encuentra en: http://c2.com/cgi/wiki?CodeSmell.
WARD, P., & MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume I: Introduction and Tools,
Prentice-Hall.
WARD, P., & MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume II: Essential Modeling
Techniques, Prentice-Hall.
WARD, P., & MELLOR, S., 1986, Structured Development for Real-Time Systems, Volume III: Implementation
Modeling Techniques, Prentice-Hall.
WHEELER, D., 2000, Understanding Variation. The Key to Managing Chaos, SPC Press.
WEINBERG, G., 1992, Quality Software Management, vol. 1 Systems Thinking. Dorset.
WEINBERG, G., 1993, Quality Software Management, vol. 2 First-Order Measurement. Dorset.
WEINBERG, G., 1994, Quality Software Management, vol. 3 Congruent Action. Dorset.
WEINBERG, G., 1997, Quality Software Management, vol. 4 Anticipating Change. Dorset.
175
WOOD, S. & SILVER, D., 1995, Joint Application Development, Wiley.

YOURDON, E., 1989, Structured Walkthroughs, Prentice-Hall.
YOURDON, E., e CONSTANTINE, L. 1979, Structured Design: Fundamentals of a Discipline of Computer Program and
System Design, Prentice-Hall.
ZAHNISER, R., 1995, System Storyboarding Techniques, American Programmer, Sep 1993. Se encuentra en:
http://www.belizenorth.com/articles/SST.htm
176
Boria et al.
Sumrio
Prefacio ............................................................................................................................................................ iii
Prlogo - Consultora en Mejora de Procesos ................................................................................................... iv
El Origen del Libro ................................................................................................................................................ iv
El Propsito del Libro ........................................................................................................................................... iv
Las Vertientes del Libro. ....................................................................................................................................... iv
Nota de Cautela .................................................................................................................................................... v
Nota Sobre los Autores ......................................................................................................................................... v
Autores ................................................................................................................................................................. vi
PARTE I Introduccin
Captulo 1 - Introduccin ................................................................................................................................... 7
1.1 El propsito del libro .......................................................................................................................................7
1.2 Definicin de mtodo gil para este libro .......................................................................................................7
1.3 Si la mejora de procesos de software es la respuesta, Cul es la pregunta? ................................................7
1.4 El caso de estudio: La empresa Tahini-Tahini .................................................................................................8
Captulo 2 - El Mtodo de Mejora Continua ..................................................................................................... 12
2.1 Mejora de procesos.......................................................................................................................................12
2.2 Plan-Do-Check-Act ........................................................................................................................................14
2.3 El Mtodo IDEAL............................................................................................................................................15
2.4 Focus-Improve-Sustain-Honor ......................................................................................................................17
2.5 Lean Simplified ..............................................................................................................................................18
Captulo 3 - Los Mtodos giles: Kanban, Scrum, XP y FDD.............................................................................. 22
3.1 Qu son los mtodos giles? .......................................................................................................................22
3.2 Kanban: Midiendo el flujo .............................................................................................................................23
3.3 Scrum: Organizando el sistema para un estado de equilibrio orgnico ........................................................26
Momentos de Verdad en Un Scrum ..............................................................................................................27
3.4 XP: Inspecciones, Diseo, Cooperacin, y Muchas Pruebas .........................................................................28
El Juego de la Planificacin. ...........................................................................................................................29
Entregas Rpidas ...........................................................................................................................................29
Metfora ........................................................................................................................................................29
Diseo Simple ................................................................................................................................................29
Prueba Dirigiendo el Desarrollo.....................................................................................................................30
Refactoreo .....................................................................................................................................................30
Programacin en Parejas (o de a Pares) ........................................................................................................30
Propiedad Colectiva (de los productos por el equipo) ..................................................................................31
Integracin Continua .....................................................................................................................................31
Semana de 40 Horas (hoy llamada Paso Sostenible) .....................................................................................31
Cliente Presente ............................................................................................................................................31
Estndares de Cdigo ....................................................................................................................................31
Escalamiento .................................................................................................................................................32
3.5 Feature Driven Development ........................................................................................................................32
3.6 Resumen........................................................................................................................................................36
Captulo 4 - El Modelo de Mejora de Procesos de Software MPS-SW .............................................................. 37
4.1 Competir con la excelencia ...........................................................................................................................37
4.2 Un camino para la excelencia organizacional ...............................................................................................38
4.3 Arquitectura del MPS ....................................................................................................................................39
4.4 Los Niveles de Madurez del MPS ..................................................................................................................40
4.5 Para que el Cambio Tenga Lugar ...................................................................................................................42
4.6 Cuando el Cambio es Cultural .......................................................................................................................45
4.7 Evaluacin del Estado de Madurez ...............................................................................................................47
Sumario
177
PARTE II Primeros Pasos

Captulo 5 - Una Organizacin con Problemas (Nivel G de MPS-SW) ................................................................ 48
5.1 La Pequea Historia de Tahini-Tahini ............................................................................................................48
5.2 Quin Est A Cargo? ....................................................................................................................................49
5.3 Mostrando la Carga de Trabajo y el Estado de las Tareas .............................................................................51
5.4 Planificacin, Monitoreo y Control del Proyecto en Dosis Homeoptica .....................................................54
5.5 El Cliente quiere Cambios .............................................................................................................................55
5.6 Avances en la Implementacin del MPS .......................................................................................................58
5.7 Preparando la Evaluacin ..............................................................................................................................60
Captulo 6 - Una Organizacin en Crecimiento (Nivel F de MPS-SW) ................................................................ 64
6.1 Crecen los pedidos ........................................................................................................................................64
6.2 Buscando Ayuda Fuera de Tahini-Tahini .......................................................................................................64
6.3 Qu deberamos fabricar? ...........................................................................................................................67
6.4 Midiendo resultados .....................................................................................................................................70
6.5 Protegiendo los Activos .................................................................................................................................75
6.6 Garantizando la Calidad de los Procesos y Productos ...................................................................................77
6.7 La pequea fbrica de software con Scrum ..................................................................................................79
Parte III Evolucin
Captulo 7 - Organizando la Organizacin (Nivel E de MPS-SW) ....................................................................... 83
7.1 Una Empresa en Crecimiento Franco ............................................................................................................83
7.2 La Necesidad de Activos de Proceso .............................................................................................................90
7.3 Retrospectivas y procesos .............................................................................................................................93
7.4 Disminucin de costos por reuso de componentes ......................................................................................94
7.5 Utilizando el conocimiento histrico en los proyectos .................................................................................95
Captulo 8 - Eliminando los Defectos (Nivel D de MPS-SW) .............................................................................. 98
8.1 Determinando el Problema ...........................................................................................................................98
8.2 Bsqueda de la Solucin .............................................................................................................................100
8.3 Corrigiendo los Procesos de Requerimientos .............................................................................................101
8.4 Perfil Operativo ...........................................................................................................................................107
8.5 Detallando Un Caso .....................................................................................................................................109
8.6 Detectando Defectos en los Productos .......................................................................................................112
8.7 Procedimientos de Verificacin ..................................................................................................................114
8.8 Revisiones....................................................................................................................................................116
8.9 Actividades del Proceso de Inspeccin .......................................................................................................116
Junta de Instruccin.....................................................................................................................................117
Inspeccin Individual del Producto..............................................................................................................117
Junta de Unificacin ....................................................................................................................................117
Disposicin del Producto .............................................................................................................................118
Retrabajo y Conclusin ................................................................................................................................118
Informe Final ...............................................................................................................................................118
8.10 Factores Crticos de xito ..........................................................................................................................118
8.11 Factores de Fracaso ...................................................................................................................................119
8.12 Diferencias Entre Inspecciones, Recorridas y Revisiones Estructuradas ...................................................119
8.13 Usos giles ................................................................................................................................................120
8.14 Pruebas de Producto .................................................................................................................................121
8.15 Criterios Relacionados con Pruebas ..........................................................................................................121
8.16 Cobertura ..................................................................................................................................................122
8.17 Diseo y Construccin ...............................................................................................................................127
8.18 Integracin ................................................................................................................................................130
Captulo 9 - Ampliando la Capacidad de Decisin (Nivel C de MPS-sw) .......................................................... 132
9.1 Una Gestin Ambiciosa ...............................................................................................................................132
9.2 Lder en Accin ............................................................................................................................................132
178
Sumario
Boria et al.
9.3 Visin Estratgica de los Riesgos .................................................................................................................133

9.4 Definicin de un Riesgo ...............................................................................................................................136
9.5 Captura de los Riesgos ................................................................................................................................136
9.6 Estrategias de Control de Riesgos ...............................................................................................................137
9.7 Estrategia Conjunta .....................................................................................................................................138
9.8 Nota de Cautela...........................................................................................................................................139
9.9 Decisiones Formales ....................................................................................................................................140
9.10 La Fbrica de Componentes ......................................................................................................................145
9.11 Service Oriented Architecture (SOA) para Principiantes ...........................................................................146
9.12 Armando la Fbrica ...................................................................................................................................148
9.13 El nivel C del MPS ......................................................................................................................................149
Parte IV Apogeo
Captulo 10 - Estabilizar para la Mejora Continua (Niveles B y A de MPS-SW) ................................................ 151
10.1 Estabilidad .................................................................................................................................................151
10.2 Eliminando Aleatoriedad ...........................................................................................................................153
10.3 El Cielo se Desploma .................................................................................................................................153
10.4 Contencin ................................................................................................................................................156
10.5 Causas Races ............................................................................................................................................156
10.6 La Prediccin Como Herramienta .............................................................................................................157
10.7 Prediccin y Anlisis ..................................................................................................................................158
10.8 Correlacin y Regresin ............................................................................................................................160
10.9 Identificacin de procesos crticos ............................................................................................................160
10.10 Procesos Capaces ....................................................................................................................................163
10.11 Lneas Base ..............................................................................................................................................164
10.12 Indicadores Lderes .................................................................................................................................164
10.13 Composicin del Proceso Definido del Proyecto ....................................................................................165
10.14 Gestin Cuantitativa................................................................................................................................165
10.15 La Mejora Continua Como Estrategia de Negocio ..................................................................................165
10.16 Costo de Competir ..................................................................................................................................166
10.17 Innovacin tecnolgica ...........................................................................................................................166
Captulo 11 - Conclusiones ............................................................................................................................. 170
Referencias Bibliogrficas .............................................................................................................................. 171
Sumario
179
Lista de Figuras
Figura 1.1: Relacin entre herramientas y competencia de personas..................................................................... 8
Figura 2.1: El Mtodo IDEAL [McFEELEY, 1996] .................................................................................................... 15
Figura 2.2: Visin de Mejora de Procesos de IDEAL [McFEELEY, 1996] ................................................................. 17
Figura 3.1: Tablero kanban .................................................................................................................................. 24
Figura 3.2: Nota psit del Tablero kanban ........................................................................................................... 24
Figura 3.3: Proceso Scrum .................................................................................................................................... 27
Figura 3.4: Ciclo de Desarrollo de XP .................................................................................................................... 30
Figura 3.5: Ciclo de Desarrollo de FDD ................................................................................................................. 33
Figura 3.6: rbol de Funciones derivada de la Arquitetura................................................................................... 35
Figura 4.1: Relacin del Retrabajoo vs. Nivel de CMM [DIAZ & KING, 2002] ........................................................ 37
Figura 4.2: Organizacin del MPS.BR [SOFTEX, 2011l] .......................................................................................... 38
Figura 4.3: Componentes del Modelo MPS [SOFTEX, 2012a] ................................................................................ 39
Figura 4.4: Niveles de Madurez del MR-MPS-SW [SOFTEX, 2012a] ....................................................................... 40
Figura 4.5: Estructura del MPS [SOFTEX, 2011l] ................................................................................................... 40
Figura 4.6: Secuencia de Resistencia al Cambio [KUBLER-ROSS, 1997] ................................................................. 43
Figura 4.7: Modelo de Transicin Ilusoria (1) ....................................................................................................... 43
Figura 4.8: Modelo de Transicin Ilusoria (2) ....................................................................................................... 44
Figura 4.9: Modelo de Transicin Administrada ................................................................................................... 44
Figura 4.10: Modelo de Transicin Sin Administrar .............................................................................................. 44
Figura 4.11: Pasos del Compromiso (adaptado de [CONNER 1982]) ..................................................................... 45
Figura 4.12: Valores en Competencia (adaptado de [CAMERON & QUINN, 2011]) ............................................... 46
Figura 5.1: Causas de la Falta de Conocimiento del Estado del Proyecto .............................................................. 50
Figura 5.2: Tablero kanban elemental.................................................................................................................. 52
Figura 5.3: Tablero kanban con ciclo de vida de las historias -1- .......................................................................... 52
Figura 5.4: Historia en el Tablero kanban ............................................................................................................. 53
Figura 5.5: Tablero kanban con ciclo de vida de las histrias -2- .......................................................................... 55
Figura 5.6: Plantilla para Definicin de Historias .................................................................................................. 56
Figura 5.7: Plantilla para Definicin y Anlisis de Riesgos .................................................................................... 56
Figura 5.8: Plantilla de Propuesta de Proyecto ..................................................................................................... 57
Figura 5.9: Diagrama de Andariveles .................................................................................................................... 59
Figura 5.10: Planilla de Detalle de un Procedimiento ........................................................................................... 62
Figura 5.11: Evidencias para GPR en el Nivel G ..................................................................................................... 63
Figura 6.1: Diagrama Ishikawa sobre Crecimiento 1 ............................................................................................. 65
Figura 6.2: Diagrama Ishikawa sobre Crecimiento 2 ............................................................................................. 65
Figura 6.3: Organigrama Tahini-Tahini ................................................................................................................. 71
Figura 6.4: Datos vs. Informacin ......................................................................................................................... 72
Figura 6.5: Grfico sobre Precios Futuros del Petrleo ......................................................................................... 72
Figura 6.6: Proceso de Auditora de Calidad ......................................................................................................... 79
Figura 6.7: La Muerte del Scrum .......................................................................................................................... 80
Figura 6.8: Cobertura de los Resultados Esperados con Scrum y Kanban ............................................................. 80
Figura 7.1: Formulario Misin y Funcin .............................................................................................................. 85
Figura 7.2: Anlisis de Opciones sobre Reuso....................................................................................................... 95
Figura 8.1: Estructura Tpica de una Hoja de Resultados Balanceados ................................................................. 99
Figura 8.2: Diagrama de Contexto de un Sistema ............................................................................................... 102
Figura 8.3: Diagrama de Clase de Acuerdo ......................................................................................................... 102
Figura 8.4: Diagrama de Clases de Acuerdo........................................................................................................ 103
Figura 8.5: Proceso de Captura de Requerimientos ............................................................................................ 105
Figura 8.6: Resultado de los Pasos 1 y 2 ............................................................................................................. 105
Figura 8.7: Diagrama de Arquitectura ................................................................................................................ 106
Figura 8.8: Modelo V de Desarrollo de Software ................................................................................................ 115
Figura 8.9: Zona de Caos por Postergacin de Actividades de Remocin ........................................................... 115
Figura 8.10: Modelo en V con Revisiones entre Actividades de Traduccin ....................................................... 116
Figura 8.11: Diagrama de Flujo del Caso de Uso de la Tabla 8.15 ....................................................................... 123
Figura 8.12: Diagrama de Flujo de Control con Funcionalidad Abstrada ............................................................ 124
Figura 8.13: Secuencia de Seleccin de Caminos para Cubrirlos Todos ............................................................... 125
180
Lista de Figuras
Boria et al.
Figura 8.14: Probabilidad de Cada Transicin del Grafo ..................................................................................... 126

Figura 9.1: rbol de Decisin ............................................................................................................................. 132
Figura 9.2: Planilla de Definicin, Monitoreo y Control de Riesgos .................................................................... 137
Figura 9.3: Matriz de Riesgos ............................................................................................................................. 138
Figura 9.4: rbol de Objetivos ............................................................................................................................ 142
Figura 9.5: rbol de Decisin Refinado .............................................................................................................. 143
Figura 9.6: Tabla de Pagos Correspondiente al rbol de Decisin Refinado ....................................................... 143
Figura 9.7: Diagrama de Influencias con Inclusin de Otras Inversiones............................................................. 144
Figura 9.8: Diagrama de Tornado ....................................................................................................................... 145
Figura 9.9: Ilustracin de la Arquitectura SOA .................................................................................................... 148
Figura 10.1: Distribuciones de Esfuerzo de Tareas Semejantes en Dos Poblaciones ........................................... 152
Figura 10.2: Distribucin del Error en Dos Relojes .............................................................................................. 153
Figura 10.3: El Mtodo de las Ocho Disciplinas .................................................................................................. 155
Figura 10.4: Curvas de la Familia Weibull ........................................................................................................... 158
Figura 10.5: Zonas de SPC Bajo la Distribucin Normal ...................................................................................... 159
Figura 10.6: Diagrama del Modelo de Kano ....................................................................................................... 161
Figura 10.7: Barreras a la Calidad ....................................................................................................................... 161
Figura 10.8: Anlisis de Factores CTQ ................................................................................................................. 162
Figura 10.9: BSC Aplicado a Identificar Procesos Crticos.................................................................................... 163
Figura 10.10: Factores En la Eleccin de Procesos Crticos .................................................................................. 163
Figura 10.11: Procesos Capaces y Procesos Estables .......................................................................................... 164
Figura 10.12: Indicadores Lderes ....................................................................................................................... 164
Figura 10.13: Distintas Posibilidades de Composicin del Proceso ..................................................................... 165
Figura 10.14: Definicin de Adyacencias y Espacio en Blanco Segn Johnson .................................................... 167
Figura 10.15: Construir-Medir-Aprender ............................................................................................................ 167
Figura 10.16: Diagrama de Pareto de Defectos de Cdigo .................................................................................. 168
Lista de Figuras
181
Lista de Tablas
Tabla 2.1: Seleccin del Mtodo de Mejora de Procesos...................................................................................... 13
Tabla 2.2: Seleccin del Mtodo de Mejora de Procesos...................................................................................... 20
Tabla 5.1: Tamaos de Tareas .............................................................................................................................. 53
Tabla 5.2 Proceso GESTIN DE PROYECTOS en el Nivel G [SOFTEX, 2012a] .......................................................... 59
Tabla 5.3 Proceso GESTIN DE REQUISITOS [SOFTEX, 2012a] .............................................................................. 60
Tabla 6.1: Pensamientos Negativos sobre el Cambio ........................................................................................... 65
Tabla 6.2: Preparndonos para Crecer ................................................................................................................. 66
Tabla 6.3: Proceso ADQUISICIN [SOFTEX, 2012a] ............................................................................................... 67
Tabla 6.4: Matriz de Pugh sobre Propuestas ........................................................................................................ 68
Tabla 6.5: Riesgos del Crecimiento ....................................................................................................................... 70
Tabla 6.6: Proceso GESTIN DE PORTFOLIO DE PROYETOS [SOFTEX, 2012a] ........................................................ 70
Tabla 6.7: Misin y Funciones .............................................................................................................................. 71
Tabla 6.8: Riesgos Asociados ................................................................................................................................ 73
Tabla 6.9: Proceso MEDICIN [SOFTEX, 2012a] .................................................................................................... 74
Tabla 6.10: Definicin de Mediciones .................................................................................................................. 74
Tabla 6.11: Definicin de Indicadores .................................................................................................................. 75
Tabla 6.12: Riesgos Derivados de la Falta de Control de Activos .......................................................................... 76
Tabla 6.13: Propiedades de Cada Tipo de tem de Configuracin ......................................................................... 76
Tabla 6.14: Proceso GESTIN DE CONFIGURACIN [SOFTEX, 2012a] ................................................................... 77
Tabla 6.15: Riesgos de no Auditar ........................................................................................................................ 78
Tabla 6.16: Severidad de Inconsistencias en Auditoras ....................................................................................... 78
Tabla 6.17: Proceso ASEGURAMIENT DE LA CALIDAD [SOFTEX, 2012a] ................................................................ 79
Tabla 7.1: Actividades de Reclutamiento e Incorporacin de Personal ................................................................ 86
Tabla 7.2: Porcentaje de xito en Actividades Seleccionadas por Tipo de Cargo .................................................. 87
2
Tabla 7.3: Riesgos a T Derivados de Polticas Pobres en Recursos Humanos ....................................................... 87
Tabla 7.4: Primera Parte de un Modelo de Competencias .................................................................................... 88
Tabla 7.5: Lista evaluativa Correspondiente a la Primera Tarea ........................................................................... 89
Tabla 7.6: Proceso GESTIN DE RECURSOS HUMANOS [SOFTEX, 2012a] ............................................................. 89
Tabla 7.7: Orientacin Sugerida por Perfil de Sprint ............................................................................................ 92
Tabla 7.8: Proceso DEFINICIN DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a]............................................ 92
Tabla 7.9: Proceso EVALUACIN Y MEJORA DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a] ........................ 94
Tabla 7.10: Proceso GESTIN DE REUTILIZACIN [SOFTEX, 2012a] ...................................................................... 95
Tabla 7.11: Proceso GESTIN DE PROYECTOS (A partir del nivel E) [SOFTEX, 2012a]............................................ 97
Tabla 8.1: Problemas de Requisitos ................................................................................................................... 101
Tabla 8.2: Comparacin entre Mtodos de Desarrollo por su Beneficio ............................................................. 104
Tabla 8.3: Comparacin entre Mtodos de Desarrollo por el Riesgo .................................................................. 105
Tabla 8.4: Matriz CRUD sin Completar ............................................................................................................... 106
Tabla 8.5: Matriz CRUD ya Completada.............................................................................................................. 107
Tabla 8.6: Estimaciones de Actividad ................................................................................................................. 108
Tabla 8.7: Perfil Operativo de los Casos de Uso .................................................................................................. 109
Tabla 8.8: Componentes Sugeridas de los Casos de Uso ..................................................................................... 110
Tabla 8.9: Lista de Control de Mitigacin de Riesgos en Requisitos .................................................................... 111
Tabla 8.10: Implementacin de DRE en T2 ......................................................................................................... 112
Tabla 8.11: Problemas de Validacin ................................................................................................................. 113
Tabla 8.12: Problemas de Verificacin ............................................................................................................... 113
Tabla 8.13: Comparacin entre Revisiones ........................................................................................................ 120
Tabla 8.14: Plantilla de Registro de Cuestiones .................................................................................................. 121
Tabla 8.15: Ejemplo de Secuencia Principal y Alternativa de un CU ................................................................... 122
2
Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T .............................................................. 126
2
Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T .............................................................. 127
Tabla 8.18: Proceso DISENO Y CONSTRUCCIN DEL PRODUCTO [SOFTEX, 2012a] .............................................. 127
Tabla 8.19: Problemas de Diseo ....................................................................................................................... 128
Tabla 8.20: Anlisis de Opciones sobre Diseo ................................................................................................... 129
Tabla 8.21: Cobertura de Resultados Esperados de PCP ..................................................................................... 129
Tabla 8.22: Acciones Relacionadas con Integracin Derivadas de Retrospectivas .............................................. 130
182
Lista de Tablas
Boria et al.
Tabla 9.1: Tabla de Pagos del rbol de Decisin ................................................................................................ 133

Tabla 9.2: Estrategia de Riesgos de Alto Nivel, Fuentes y Categoras ................................................................. 135
Tabla 9.3: Ejemplo de Tabla (Parcial) de Riesgos ................................................................................................ 139
Tabla 9.4: Definicin de los Pasos del PAyTDD ................................................................................................... 141
Tabla 10.1: Los Problemas del Proyecto Fuera de Control .................................................................................. 157
Tabla 10.2: La ltima Fila del Anlisis una Vez Completo ................................................................................... 159
Lista de Tablas
183

Tahini Tahinispfinalcover A4 131115081722 Phpapp01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tahini Tahinispfinalcover A4 131115081722 Phpapp01

Uploaded by

Copyright:

Available Formats

Jorge Luis Boria

Viviana Leonor Rubinstein

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

PRLOGO - CONSULTORA EN MEJORA DE PROCESOS

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Jorge Luis Boria

Viviana Leonor Rubinstein

Andrs Oscar Rubinstein

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 1.1: Relacin entre herramientas y competencia de personas

La comunidad gil se reconoce en el sitio web: http://www.agilemanifesto.org/

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

CAPTULO 2 - EL MTODO DE MEJORA CONTINUA

No esperaba otra cosa, dijo Pedro.

Qu suerte que lo tomes as, me da gusto, contest Pablo.

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 2.1: El Mtodo IDEAL [McFEELEY, 1996]

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 2.2: Visin de Mejora de Procesos de IDEAL [McFEELEY, 1996]

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

En el corazn de LS est el tema de la velocidad de produccin . La velocidad no es apuro, es hacerlo mejor y

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Tabla 2.2: Seleccin del Mtodo de Mejora de Procesos

El proceso exacto producir los resultados exactos.

Lo nico que agrega valor en un proceso es la transformacin fsica o informacional de la materia-prima

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

CAPTULO 3 - LOS MTODOS GILES: KANBAN, SCRUM, XP Y FDD

KNIBERG, H. e SKARIN, M., 2010

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 3.1: Tablero kanban

Figura 3.2: Nota psit del Tablero kanban

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

En ingls, hand-off entre un rol y el otro.

Figura 3.3: Proceso Scrum

[CARLZON, 1989] Moments of Truth.

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Prueba Dirigiendo el Desarrollo

Figura 3.4: Ciclo de Desarrollo de XP

Vase code smells, http://c2.com/cgi/wiki?CodeSmell

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

[BORIA, J., 1987, Ingeniera de Software, Kapelusz]

Figura 3.5: Ciclo de Desarrollo de FDD

Entremos en un poco de detalle en los cinco procesos.

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Estamos usando funciones, o caractersticas, para traducir el original en ingls features.

Figura 3.6: rbol de Funciones derivada de la Arquitetura

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

CAPTULO 4 - EL MODELO DE MEJORA DE PROCESOS DE SOFTWARE MPS-SW

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

4.2 Un camino para la excelencia organizacional

Figura 4.2: Organizacin del MPS.BR [SOFTEX, 2011l]

[SOFTEX, 2012a], pgina 6

Figura 4.3: Componentes del Modelo MPS [SOFTEX, 2012a]

4.3 Arquitectura del MPS

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 4.4: Niveles de Madurez del MR-MPS-SW [SOFTEX, 2012a]

Figura 4.5: Estructura del MPS [SOFTEX, 2011l]

Mejora de Procesos de Software con Mtodos giles y el Modelo de Madurez MPS

Figura 4.6: Secuencia de Resistencia al Cambio [KUBLER-ROSS, 1997]

Figura 4.7: Modelo de Transicin Ilusoria (1)

Movimiento por el cual las cosas se transforman.