Jorge Luis Boria

Viviana Leonor Rubinstein

Andrés Rubinstein

La Historia de Tahini-Tahini:

Mejora de Procesos de Software con

Métodos Ágiles

y el Modelo de Madurez MPS

Boria et al.

Prefacio iii

PREFACIO

La discusión sobre la posibilidad o no de utilización de métodos ágiles en conjunto con modelos de madurez de procesos de software es frecuente y actual.

Algunos consideran que las exigencias de los modelos de madurez no pueden ser implementadas en organizaciones con desarrollo ágil. Otros consideran que la implantación de estos modelos va a lastimar la agilidad de desarrollo. Esta incompatibilidad es discutida, por lo tanto, por defensores del uso de métodos ágiles y por defensores de los modelos de madurez.

En este contexto se sitúa el libro “La Historia de Tahini-Tahini: Mejora de Procesos de Software con Métodos Ágiles y Modelo MPS” de Jorge Boria, Viviana Rubinstein y Andrés Rubinstein.

El libro tuvo origen en una llamada realizada en diciembre de 2011 por la Secretaria de Política de Informática – SEPIN, del Ministério de Ciência, Tecnologia e Inovação – MCTI, responsable por la conducción del Programa Brasileiro de Qualidade e Produtividade em Software – PBQP Software, para el Ciclo 2012 del Programa “Série de Livros do PBQP Software”. Entre varios competidores resultó el texto seleccionado para publicación.

Y fue, sin duda, una excelente elección. En él, los autores, a partir de su riquísima experiencia como consultores, evaluadores MPS y lead appraisers CMMI, nos muestran que no existen contradicciones entre modelos de madurez, mejora de procesos y métodos ágiles. Existe, por el contrario, un excelente camino que puede ser recorrido con éxito por las organizaciones hasta que sean alcanzados niveles muy altos de calidad y madurez en los procesos de software.

De acuerdo con los autores, el libro tiene como objetivo mostrar cómo se inter-relacionan las técnicas de consultoría, con los métodos ágiles para alcanzar los resultados esperados del MR-MPS-SW. Para esto utilizan cuatro métodos ágiles, Kanban, Scrum, XP y FDD (Feature Driven Development), y la historia de Tahini-Tahini, una empresa ficticia que ciertamente a todos nos gustaría que existiese.

Es un libro técnico, más fascinante y de lectura muy agradable. A veces nos hace reír, tal el buen humor de los autores al tratar el tema. Ciertamente será un caso de éxito, en esta excelente iniciativa del MCTI.

Agradezco a los autores la invitación a escribir el prefacio de un libro tan interesante y con contribuciones tan importantes para la calidad y la Ingeniería de Software.

Abril, 2013

Ana Regina Cavalcanti da Rocha Universidade Federal do Rio de Janeiro

COPPE/UFRJ

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

iv Prólogo

PRÓLOGO - CONSULTORÍA EN MEJORA DE PROCESOS

El Origen del Libro

Este libro se originó en un llamado realizado en Diciembre de 2011 de la Secretaria de Política de Informática – SEPIN, del Ministerio de Ciencia, Tecnología e Innovación - MCTI, responsable por la conducción del Programa Brasilero de la Calidad y Productividad en Software - PBQP Software, para su Ciclo 2012 del Programa "Serie de Libros de PBQP Software". Entre los temas para los cuáles había que presentar propuestas uno nos parecía sumamente útil a la población de ingeniería de software, la Mejora de Procesos de Software con Métodos Ágiles y el Modelo MPS. Sobre los otros temas, igualmente de importancia, hay literatura básica y avanzada. Tampoco es un valor agregado, en un mundo globalizado, escribir un libro en Castellano o Portugués; el Inglés es la nueva Lingua Franca y los principales cultores de esto son los informáticos. Nos atrajo el desafío de conciliar tres vertientes, tal la complejidad del tema. Estamos agradecidos a todos los que intervinieron en el proceso que llevó a la selección, edición y publicación de este libro.

El Propósito del Libro

Este libro se plantea como un libro de cuentos para profesionales. La empresa que se usa como caso de éxito no existe ni existió, ojalá exista alguna vez. Los personajes surgieron de amigos, conocidos y situaciones que alguna vez nos tocó vivir, como empleados, consultores o patronal de empresas de software. Su propósito es ilustrar como se interrelacionan las técnicas de consultoría, siempre una buena facilitación cuando está bien hecha, a veces enseñanza-aprendizaje, nunca dictadura; con los métodos ágiles, que son muchos más que Scrum; para cumplir con los resultados esperados del MPS.

Este libro no es un recetario, no hay en él un algoritmo, ni siquiera una heurística que permita a otros recorrer el mismo camino que el de los protagonistas de nuestra historia. Sin embargo, abrevar en él para identificar problemas y avizorar soluciones es lo que nos propusimos que fuera su utilización. Esperamos que los lectores aprecien la historia, porque está ahí para hacerlos pensar en las situaciones que ocurren a diario en la industria de software.

Por último, este libro no es auto contenido. Requiere que el lector utilice las pautas bibliográficas que les dejamos, ocho páginas en total de materiales superlativos. Si algo destacamos de este libro es que la bibliografía de por sí vale la pena.

Las Vertientes del Libro.

El título de este libro mezcla tres ideas poderosas. Habla de mejora de procesos con métodos ágiles y el modelo de mejora MPS. Cualquiera de las tres ideas merece un libro de por sí, de manera que escribir uno solo, y en el corto plazo con que contamos los autores, implica una elección de contenidos. Este es un libro sobre las actividades que se llevan a cabo en consultorías de mejora de procesos. Aunque el principal personaje es una mujer, Marcela, que trabaja en relación de dependencia con la empresa que nos permite crear el hilo conductor de la historia, sus actividades son las de un consultor de primer nivel.

Marcela encarna la heroína de la novela romántica Inglesa del siglo XVIII en que es inteligente, sabe lo que quiere y sabe cómo conseguirlo. Es el ejemplo de liderazgo de este libro, aun cuando los demás socios y compañeros de ruta son buenos gerentes y excelentes profesionales, cada uno con su vena técnica, es Marcela la que guía con el ejemplo, la que cuestiona el statu quo, la que, en definitiva, lleva la empresa Tahini-Tahini a la cima de la calidad. Cuando escribíamos el libro era con Marcela que preferíamos identificarnos, al fin y al cabo es el personaje más exitoso. Las lecciones que debieran recogerse de este libro se deben a Marcela.

No es un libro de consultoría, los hay, y muy buenos, escritos por consultores mejores que nosotros. Sin embargo, hay muchos consejos sobre cómo realizar las cosas que importan, las que llevan a los cambios serios, que están contenidos en las acciones de los personajes. También hay muchísimas técnicas que solemos introducir, de un modo u otro, en nuestras consultorías. El Capítulo 2 inicia el camino mostrando variantes de métodos de mejora continua, culminando con el método Lean. Recomendamos lecturas extras para poder entenderlo y aprovecharlo.

No es un libro sobre el MPS, preferimos que el lector aprenda acerca de este robusto modelo en las guías del mismo y en los cursos autorizados que se dictan. Sin embargo no hay nada en el libro que no haya sido escrito con el MPS en mente. Toda la historia de Tahini-Tahini, los vaivenes con las técnicas, a menudo presentadas para su discusión antes de que puedan ser aprovechadas, ilustra nuestro punto de vista sobre los modelos de madurez,

Boria et al.

Prólogo v

centrado en el MPS: Hay que tener la visión global del destino para que el camino se pueda transitar con comodidad.

Tampoco es un curso de métodos ágiles. El lector avisado debe entender que para introducir un método ágil en una organización hace falta un entrenador o un mentor que guíe la implementación día a día. Producir una organización ágil a partir de una que no lo es requiere experiencia y adaptación a las necesidades de la organización.

Y aunque no es un libro sobre cambio organizacional, de esta disciplina sí que toma muchos conceptos prestados. De todos modos, la literatura de cambio organizacional es muy vasta y muy rica, y le haríamos muy poca justicia si intentáramos resumirla en estas pocas páginas.

El libro intenta describir las actividades de consultoría que tienen lugar en muchas organizaciones. Los autores hemos elegido un mecanismo de presentación de los materiales que está a mitad de camino del libro de texto y la narración de una historia que nos permite divertirnos con los personajes. Esperamos que se entretengan con su lectura.

Nota de Cautela

Ningún libro de calidad puede dejar de citar a Deming. Este superhombre de la calidad nos dejó decenas de pensamientos e ideas para andar con mayor comodidad tras sus huellas. En este Prólogo queremos rendirle un pequeño homenaje a la vez que usar sus palabras para advertir al lector del error que muchas veces se comete en aras de contener los gastos: “El Obstáculo de Deming, La esperanza de postre instantáneo --- la suposición de que una o dos consultas con un estadístico competente pondrá a la empresa en el camino a la calidad y la productividad – postre instantáneo. No es tan simple, siempre será necesario estudiar y ponerse a trabajar.”

No somos estadísticos expertos, pero hemos visto el mismo síntoma en muchas empresas traducido a una invitación a almorzar a cambio de un consejo gratuito que después se intenta llevar a la práctica sin los conocimientos necesarios. Los consultores no son irremplazables, pero el conocimiento que traen a las organizaciones si lo es.

Nota Sobre los Autores

Siempre un libro es una creación colectiva. Tolkien hablaba del ‘humus’ que el autor junta para plantar sus ideas, humus que le debe a sus lecturas y experiencias. Las musas inspiradoras solo trabajan en mentes abiertas que han pasado por las experiencias que enriquecen la vida, tantas veces dolorosas. Pero además de la herencia, los autores siempre están obligados con muchas personas que hicieron lo imposible posible.

Queremos agradecer muy especialmente a Ana Regina Cavalcanti da Rocha por su confianza y amistad, a Kival Chaves Weber, Nelson Henrique Franco de Oliveira y José Antonio Antonioni por el apoyo y las oportunidades brindadas y a Richard Denney por prestarnos el material de su autoría usado en algunas partes de este libro.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

vi Prólogo

Autores

Jorge Luis Boria

Master of Engineering in Computer Science por Cornell University, Estados Unidos. Senior Advisor del Modelo MPS. Evaluador Líder Experimentado MPS. SCAMPI Lead Appraiser para alta madurez. Instructor certificado de los cursos del modelo CMMI. Fue Visiting Scientist del Software Engineer Institute de Carnegie-Mellon University. Fue Professor Titular de las Universidades UBA, UNICEN, UNSL, USal, UB y otras en Argentina. Es autor de otros dos libros relacionados con la industria del software.

Jorge quiere agradecerle particularmente a Joyce Statz por la formación que recibió trabajando para ella en TeraQuest Metrics. Joyce fue a la vez amiga, formadora, orientadora y entrenadora.

Viviana Leonor Rubinstein

Licenciada en Computación Científica por la UBA. Certified Project Manager, UT-SQI. Evaluadora Líder Experimentada MPS. SCAMPI Lead Appraiser DEV y SVC para alta madurez. Instructora certificada de los cursos del modelo CMMI. Fue Profesora Titular en las Universidades UNS en Ushuaia, UBA, UNICEN y otras en Argentina. Es autora de tres volúmenes para la enseñanza de computación en colegios secundarios.

Viviana quiere agradecerle a Regina, su mamá, con la que compartió la escritura de su primer libro.

Andrés Oscar Rubinstein

Programador y Analista de Sistemas de la Pontifícia Universidade Católica do Rio de Janeiro. Evaluador Líder Intermedio MPS. SCAMPI Lead Appraiser DEV y SVC. Sócio de TecnoVoz S.A. Argentina. Fue profesor y auxiliar docente en la PUC-Rio y en la Universidad de Belgrano y el Colegio Nacional de Buenos Aires en Argentina.

Andrés quiere agradecerle a Viviana y a Jorge por la confianza, a Adri y a los amigos de siempre por el aguante, y a Male y a Nico por estar.

Finalmente, Jorge y Viviana quieren agradecer a Alma, Beto y Franca por darle un nuevo sentido a sus vidas. Y Viviana y Andrés agradecen a Jorge por su liderazgo en la confección de este libro, sin el que tendría sido imposible su realización.

Boria et al.

Capítulo 1 7

PARTE I – Introducción

CAPÍTULO 1 - INTRODUCCIÓN

1.1 El propósito del libro

Este libro está dirigido a (en orden de interés creciente):

• implementadores de mejora de procesos de software que quieran conocer mejor los métodos ágiles para implantarlos en organizaciones de software;

• gerentes de proyecto interesados en conocer mejor los métodos ágiles para desarrollo de software, sea para adoptarlos o para evaluar su adopción;

• ingenieros de software que intentan trabajar em un proyecto ágil; • profesores de grado en Computación; • estudiantes de grado en Computación; • profesores de postgrado en Ingeniería de Software; • estudiantes de postgrado en Ingeniería de Software.

En la medida en que los métodos ágiles y los modelos de madurez han sido considerados términos opuestos en las disciplinas de desarrollo y mantenimiento de software, es difícil concebir un texto que busque alzar un puente entre los dos mundos. Ya fue hecho, sin embargo, con gran suceso, en el moderno clásico [BOEHM & TURNER, 2003]. El modelo de referencia para ellos es el CMMI, siendo fácil de imaginar la conversión para el MR-MPS-SW, dada la intencional compatibilidad entre los dos.

1.2 Definición de método ágil para este libro

Este libro está principalmente enfocado en cuatro métodos ágiles1: Kanban, Scrum, XP y FDD (Feature Driven

Development). Esta elección no es por azar. Esos cuatro métodos cubren la mayoría de las implementaciones ágiles realizadas en el mundo. Además, cubren casi todas, sino todas, las necesidades de uso de métodos ágiles.

Cada uno de estos métodos será debidamente explicado en el capítulo 3, donde se los introduce al lector. Obviamente, esto ocurrirá en orden creciente de complejidad: Primero el más sencillo y el que tiene el mayor retorno de la inversión, Kanban. Kanban tiene alto retorno porque al organizar las tareas y detectar los problemas rápidamente permite al equipo que lo utiliza aumentar el tiempo disponible para mejorar sus procesos e intentar nuevas mejoras. Scrum, que frecuentemente es el método que se elige desde un principio, acá se ve sólo cuando la empresa ha conseguido estabilizarse lo suficiente como para tener el tiempo de conseguir que las actividades de Scrum puedan ser seguidas con la correspondiente disciplina. Las otras dos técnicas se suman a las ya vistas a medida que la empresa gana en definición de sus procesos y en el número de su personal.

1.3 Si la mejora de procesos de software es la respuesta, ¿Cuál es la pregunta?

El principal enemigo de una empresa desarrolladora de software es la baja calidad. Hasta ahora, nadie tiene una propuesta válida para mejorar la calidad, salvo la mejora de procesos, que pasa a ser entonces la cuestión principal. Se puede argumentar que las personas y las herramientas (de software, como CASE) son importantes en su impulso a la mejora de la productividad. Esto es cierto, pero solo cuando los procesos están en su lugar para conseguir que se aprovechen las condiciones de los individuos y las herramientas de software. Es común el caso de empresas y organizaciones

2 que desaprovechan sus recursos humanos y tienen licencias que no se usan, por lo que

se deduce que si bien las herramientas y las capacidades de las personas son importantes, son los procesos los que habilitan realmente el aumento de productividad.

En la Figura 1.1 simbolizamos esto con íconos. En la primera “ecuación” el personal capacitado sumado a herramientas de software, sumado a procesos bien definidos culmina (después del signo de igualdad) en éxito y

1 Las principales referencias de cada uno de los métodos están indicados cuando se describe cada uno en los capítulos

siguientes. 2 En este libro utilizaremos en lo que sigue el término “organización” para referirnos a todo tipo de grupo humano organizado

para la realización de tareas con un propósito común, sea con o sin fines de lucro.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

8 Capítulo 1

felicidad. En la segunda ecuación la falta de procesos bien definidos incrementa los riesgos y produce frecuentes problemas en los productos resultantes.

Figura 1.1: Relación entre herramientas y competencia de personas

La disciplina que inducen los procesos es la que permite aprovechar los conocimientos y las herramientas. Sin esta disciplina no es posible reproducir los éxitos que puedan haber alcanzado los proyectos, porque la memoria organizacional se pierde.

1.4 El caso de estudio: La empresa Tahini-Tahini

En este libro seguimos el desarrollo de una organización que nace de una idea de estudiantes universitarios. La empresa que crean es pequeña y por hacerse a sí mismos una broma, la han llamado Tahíni-Tahíni. El nombre surgió cuando una de las fundadoras llegó a la reunión de creación un poco retrasada y al mirar el número de personas alrededor de la mesa dijo, “Somos una empresa tiny-tiny”. Sus futuros socios encontraron eso gracioso y le pusieron de nombre Tahíni-Tahíni, haciendo un doble juego de palabras. En el libro a menudo nos referiremos a la misma con las siglas que sus socios usan para referirse a ella: T

2, T2 o la Doble T.

Como toda empresa recién nacida, creada por jóvenes emprendedores, no ha seguido un plan de crecimiento ideal, más bien ha crecido a saltos, y los mares embravecidos que ha tenido que capear la han hecho más fuerte. Los problemas de la empresa no son poco comunes, son los más frecuentes para una organización de ese tamaño y con esa historia en cada etapa de su crecimiento. En cada paso los socios han debido tomar decisiones que afectan los resultados, y en cada oportunidad lo han hecho alterando los procesos que gobiernan el desarrollo del producto. En cada caso apuntaron a mejorar la calidad y el control de los procesos para mejorar la calidad y el control sobre el producto.

Durante el desarrollo del caso de estudio utilizaremos la descripción de Kanban para el principio de un proyecto de mejora de procesos; Scrum en relación a las actividades de gerencia de proyectos más comunes; XP (Extreme Programming) para lo que constituye la categoría de las áreas de ingeniería de software tratadas en el nivel D (Ampliamente Definido) del MR MPS SW. Cuando una empresa crece, los métodos anteriores comienzan a mostrar limitaciones. La coordinación de muchos equipos en Scrum de Scrums presenta mayores limitaciones que los métodos tradicionales. XP ya es difícil de controlar en proyectos medianos. Acompañando el crecimiento de T

2,

la propuesta es una metodología conocida como Feature Driven Development (FDD). En torno de la cuestión del cambio organizacional, seguiremos el camino de la metodología Lean, que se concentra principalmente en la resolución de problemas a través de la mejora de procesos.

También en este capítulo describimos cada uno de los capítulos restantes. Cada capítulo que hace referencia a un nivel del MR MPS SW explica los resultados requeridos de los procesos siguiendo las exigencias del modelo. El libro se divide en cuatro partes, cada una atendiendo una necesidad diferente. En la primera parte (Capítulos 1 a 4) se sientan las bases para que el lector pueda comprender los métodos y filosofía de trabajo que los autores proponen. La segunda parte (Capítulos 5 y 6) atiende los temas de baja madurez (Niveles G y F del MPS) e introduce en detalle los primeros dolores de crecimiento de T

2 y la resolución encarada por los socios basada en el

uso de Kanban y Scrum. La tercera parte (Capítulos 7 a 9) desenvuelve la temática de Madurez Media, los niveles E, D, y C del Modelo MPS, donde aparecen XP y más adelante FDD. Finalmente, la cuarta parte (Capítulos 10 y 11) expone como la madurez definida de T

2 le permite alcanzar un conocimiento profundo del funcionamiento de sus

procesos, caracterizándolos cuantitativamente. El libro se cierra con un resumen del viaje de T2 desde su creación

hasta su venta billonaria.

En el Capítulo 2 explicaremos nuestra filosofía de mejora de procesos. Para ello utilizaremos el método Lean, palabra inglesa que significa delgado, porque es el que mejor se adapta a nuestras ideas. Adoptando mensajes de diversas fuentes, explicaremos como es mejor hacer lo menos posible para resolver un problema que hacer grandes cambios sin efecto aparente. También aprovecharemos el Capítulo 2 para hablar de una visión sistémica

Boria et al.

Capítulo 1 9

de las organizaciones y de la relación multicausal de los eventos. De este modo preparamos al lector para que entienda porque una sola acción puede resolver muchos problemas y como a veces es necesario aplicar múltiples acciones (y esperar) para obtener resultados. El libro de [POPPENDIECK et al., 2010], Leading Lean Software Development, es nuestra guía por este territorio. También, donde es útil, citamos material del clásico de [MEADOWS, 2008] Thinking in Systems, A Primer. Los dos libros revolucionan el pensamiento clásico, lineal, de los gerentes tradicionales, y abren la puerta a una gerencia más ágil, más integrada y con más posibilidades de éxito.

En el Capítulo 3 introducimos los métodos ágiles propiamente dichos. Si bien Lean es un método ágil según sus creadores y es reconocido como tal por la comunidad ágil

3, su uso exige mucho conocimiento y está más allá

de los objetivos de este libro. En cambio, las técnicas que proponen Kanban, Scrum, XP (Extreme Programming) y Feature Driven Development (FDD) son del mismo modo exitosas y mucho más fáciles de adoptar, sobre todo si se lo hace en el orden en que las proponemos en este libro. Esta es una introducción a los métodos y en ningún momento pretende remplazar la lectura de los textos clásicos del tema, que se citan en la bibliografía y que recomendamos fuertemente al lector.

El Capítulo 4 se dedica al eje central de este libro, el modelo de Mejoría de Procesos de Software (MPS). Otra vez, el libro es incapaz de contener todo el conocimiento necesario para hacer buen uso del modelo, de modo que referimos al lector a las guías que Softex ha publicado y que se encuentran accesibles en el sitio web de esa organización

4. Las guías son un material indispensable para el lector que pretenda seguir nuestras sugerencias e

implementar siguiendo el MPS. Lo que sí exploraremos en detalle son las grandes pinceladas que es necesario comprender para que el modelo tenga sentido y no se pierda en los detalles que, necesariamente, hay que aplicar. Discurriremos sobre la evolución de la cultura imperante en la empresa que fuera inducida por la maduración de los procesos, manifiesta en el cambio de los niveles de madurez del modelo, concepto en el que nos detendremos en este capítulo, así como en la arquitectura del modelo que permite encontrar en él las herramientas para su implementación. Para concluir el capítulo explicamos el concepto de evaluación y como una organización puede aplicarlo a sí misma, para entender dónde se encuentra y qué camino le falta recorrer.

El Capítulo 5 introduce en detalle los problemas iniciales de T2. Utilizando ejemplos que han encontrado en su

actividad como consultores y evaluadores de procesos, los autores introducen al lector a los problemas típicos de una empresa que funciona bien cuando todas las cosas están en su cauce. Los pequeños problemas cotidianos (un embarazo, una zona sin recepción telefónica, un cliente apurado) pueden desencadenar una “tormenta perfecta” que arruine la mejor reputación. Es ahí cuando los amigos de T

2 deciden introducir métodos de control y

aconsejados correctamente comienzan a utilizar Kanban. Al mismo tiempo consiguen implantar, sin demasiado esfuerzo extra, procesos del modelo MPS. Tentados por la facilidad con que implementaron los procesos del Nivel G, los socios deciden realizar una evaluación formal con un evaluador líder y pasan con éxito. La adopción del MPS por la empresa T

2 es ahora un hecho.

En el Capítulo 6 los autores cuentan como los socios, alentados por el éxito obtenido por sus mejoras de proceso, deciden profundizar el camino y utilizan el modelo MPS para hacerlo. Los controles establecidos hacen lugar a la gerencia de configuración, que en germen ya comenzaran a implementar en el nivel G; la medición, que la formación profesional de los socios hace que sea considerada una actividad fundamental para controlar y dirigir la empresa; y el control de la calidad, impuesto por la realidad.

La llegada de nuevos clientes con pedidos de proyectos que son a veces de adaptación, a veces nuevos desarrollos, hace que los procesos de la gerencia de portafolio de proyectos les resulten valiosos para entender cómo organizar el crecimiento de la demanda. Este crecimiento les lleva a plantearse uno de dos caminos: crecer internamente, lo que significaría ampliar el espacio físico para admitir más desarrolladores, con la consecuente inversión fija; o subcontratar parte del trabajo. Para tomar la decisión, los socios se apoyan en los procesos de adquisición y deciden a favor, lo que les lleva a implementarlos. Aun así, su pequeño equipo inicial debe dividirse para atender el nuevo volumen de trabajo, e incorporan un número pequeño de desarrolladores. Para organizar los proyectos, los socios deciden utilizar prácticas de Scrum, que les resultan compatibles con el MPS. Para demostrárselo a sí mismos, la T

2 pasa por una nueva evaluación y alcanza el Nivel F.

En el Capítulo 7 comienza la tercera parte, que desarrolla los procesos intermedios del modelo MPS. A medida que se expanden los negocios y se abren nuevas oportunidades, los socios se ven obligados a expandir

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

4 http://www.softex.br/mpsbr/_guias/default.asp

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

10 Capítulo 1

asimismo sus oficinas. Una reunión fundamental los pone en la encrucijada: ¿A dónde queremos llevar a T2?

Finalmente se resuelve crear una visión ambiciosa: Ser una de las diez mejores fábricas de software del mundo. Preparándose para el crecimiento, los socios entienden que su visión se completa con una base de conocimientos que puedan ser compartidos, usados y expandidos por todos los ingenieros y demás empleados de su empresa. Sus procesos de gestión evolucionan asimismo para aprovecharse de este conocimiento de manera sistemática. De manera normal surge en la base de conocimientos la definición de los procesos organizacionales.

Cuando los empleados superan un número considerado crítico de manera arbitraria, las reuniones de proceso se sistematizan y se formalizan en un proyecto para su evaluación y mejoría permanente. Las constantes incorporaciones fuerzan asimismo a organizar la identificación, captación, preparación y retención de los recursos humanos. En todas estas tareas el MPS les resulta fundamental e indispensable, al darles un marco coherente y las pautas culturales para crecer. El resultado es una organización que aprende, con empleados motivados que continuamente hacen propuestas de mejora de sus propios procesos y los ajenos. Una iniciativa brillante resulta de una de estas propuestas, y T

2 incorpora prácticas de reuso para mejorar todavía más la calidad de sus productos y

el rendimiento de su personal.

En el segundo Capítulo de la tercera parte, el Capítulo 8, introducimos las técnicas y prácticas de Extreme Programming (XP) que no se superponen con las anteriores ya incorporadas. Una discusión en una retrospectiva lleva a identificar la variación en la interpretación de las técnicas de desarrollo en los equipos como la fuente de diferencias entre las estimaciones iniciales, ahora desarrolladas a partir de la historia, y los resultados reales. Discutiendo en la reunión del grupo de procesos organizacionales se vincula asimismo a esa indefinición con un grupo de defectos que están saliendo repetidamente al mercado. Una propuesta de adoptar XP es recibida tibiamente, pero de todos modos se la implementa, cuidando de que al hacerlo se respeten las condiciones para seguir cumpliendo con la implementación de procesos de MPS. Esto lleva a algunas variantes, como por ejemplo que pair programming, la técnica por la cual dos programadores trabajan juntos en un mismo programa, sea implementada con un coach que registra los defectos encontrados para permitir realizar análisis de los mismos. Los equipos incorporan asimismo software de control e introducen variantes a los procesos para continuar avanzando y seguir dentro del marco del MPS.

Enfrentados con la realidad de su crecimiento y los riesgos que trae, los socios incorporan una visión estratégica de su negocio y una vez más lo hacen siguiendo el modelo. En el Capítulo 9 se introduce la visión del riesgo como constante. La T

2 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 necesidad que puede reusar partes ya existentes en los proyectos concluidos, la T

2 organiza una fábrica de

componentes que se pueden articular rápidamente para formar productos, reduciendo aún más sus defectos por parte y aumentando a niveles muy altos su productividad. Cada decisión tiene un costo y un beneficio, pero hasta este momento en la historia de la T

2 no se aprendía sistemáticamente de las decisiones ya tomadas. Para evitar

que ese conocimiento se pierda, la T2 incorpora métodos de decisión formales que incluyen varias técnicas que

aprovechan la historia. Pronto los proyectos las usan para tomar decisiones sobre la velocidad, la calidad esperada, el reuso y la subcontratación a terceros. La T

2 es ya una organización con centenares de empleados y una sólida

reputación de calidad. Los llamados por referencias empiezan a ser internacionales. Debido a ese crecimiento y el consecuente alejamiento físico de los clientes, la T

2 añadió a su arsenal el método FDD, que le permite planificar

con mayor precisión los sprints. La T2 decide ser evaluada respecto al Nivel C del modelo MPS y a su vez, en una

evaluación conjunta, respecto al Nivel Definido del modelo CMMI-DEV, cosa que logra con singular éxito.

Al ingresar en la Cuarta Parte del libro, encontramos a T2 en su apogeo. Ha abierto oficinas en varios países

centrales, tiene centros de desarrollo en todas las regiones de Brasil y de Latinoamérica, y disfruta de un bien ganado prestigio. Sin embargo, los socios no descansan en sus laureles. En el Capítulo 10 vemos cómo se aprovechan de la base de datos históricos que han amasado a lo largo de los años para utilizarlos en su favor. Identifican los procesos críticos que se relacionan con sus objetivos de negocio, analizan su estabilidad relativa, construyen modelos que permiten prever resultados futuros en puntos tempranos de un proyecto y ayudar a corregir problemas. Extienden las técnicas que emplean en la toma de decisiones para incluir factores cuantitativos y mejoran sus análisis de causa raíz para que se considere el costo beneficio de las posibles alternativas. La gerencia de proyectos pasa de ser un arte con partes de ingeniería a ser una ciencia con partes de arte.

El Capítulo 11 cierra el libro con los socios discutiendo sobre la compra de dos líneas de negocios por una mega empresa. Para que su historia no sea un caso único, el capítulo hace la contabilidad de los factores que

Boria et al.

Capítulo 1 11

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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

12 Capítulo 2

CAPÍTULO 2 - EL MÉTODO DE MEJORA CONTINUA

2.1 Mejora de procesos

Si estamos de acuerdo con la literatura existente y la experiencia personal de los autores, la mejora de procesos es la herramienta que permite a las organizaciones entenderse a sí mismas profundamente, yendo de un conocimiento intuitivo a uno cuantitativo, pasando por etapas intermedias que sirven tanto para mejorar los resultados como para apoyar los pasos siguientes. Una anécdota sirve para hacer clara la diferencia entre seguir procesos acordados por las partes y no seguirlos. Los procesos acordados por las partes cambian cuando las partes así lo deciden, mientras que no seguir procesos implica que no hay un patrón reconocible que ha sido pactado por los interesados.

En una organización desarrolladora de software, Pedro, uno de los mejores programadores, era un ferviente defensor de los procesos. Rápidamente convenció a sus colegas de equipo de trabajo para que adoptaran procesos en la construcción de diversos documentos y, sobre todo, para definir la secuencia de pases y el criterio de finalización, basado en la calidad objetiva, de cada producto. Los proyectos en los que Pedro participaba eran exitosos con más frecuencia que todos los demás, y los clientes de los mismos elogiaban el producto generado. Finalmente las diferencias llegaron a los oídos de la dirección y nuestro joven programador fue recibiendo sucesivas promociones a cargos de cada vez mayor responsabilidad. No había pasado mucho tiempo cuando finalmente lo promovieron a jefe técnico de desarrollo. Convocó a sus hasta entonces colegas y les hizo ver que su promoción obedecía al reconocimiento que la alta gerencia hacía del trabajo que seguía procesos, por lo que esperaba que todos colaboraran con él para ampliar su utilización y contribuir a su mejora. Hubo muchas cabezas que asintieron y tras algunas preguntas y respuestas la reunión se dio por concluida. Solo Pablo, un programador, que hasta la llegada nuestro héroe era considerado el programador “estrella”, se quedó atrás.

- “Pedro”, le dijo. “Yo estoy contento por tu nombramiento, pero tú sabes bien que yo no sigo procesos ajenos y siento que intentar que los demás entiendan mis procesos es una pérdida de tiempo, porque me sirven a mí y solo a mí. Espero que no lo tomes a mal, pero pienso seguir haciendo lo que hice siempre”.

- “No esperaba otra cosa”, dijo Pedro.

- “Qué suerte que lo tomes así, me da gusto”, contestó Pablo.

Satisfecho, tomó sus notas y encaró para la puerta del salón. Pedro lo dejó alcanzar la puerta y lo detuvo:

- “Eso sí, no fracases. Nunca fracases. Los que siguen procesos pueden tener problemas, porque los problemas nos enseñan qué partes del proceso hay que cambiar. Pero si tú no sigues procesos, los fracasos no nos enseñan nada y tú cargarás con toda la responsabilidad. Espero que no lo tomes a mal, pero es así como pienso seguir haciendo lo que hice siempre”.

Los procesos que se siguen nos permiten identificar defectos tempranamente y detectar su origen. En cierto sentido, seguir un proceso es como comprar una póliza de seguros: uno no quiere que le pase nada de malo, pero invierte un poco para el caso en que algo malo ocurra. Lo mismo es con los procesos: Si todos tuviéramos memoria perfecta, no cometiéramos nunca errores y las especificaciones en lenguaje natural tuvieran un significado único e inamovible, entonces se relativizaría mucho la necesidad de seguir procesos. Todavía resultarían útiles para coordinar el trabajo, pero para personas con memoria total se podrían hacer procesos sumamente cortos. La realidad es bien otra: Los seres humanos erramos, olvidamos y malinterpretamos las comunicaciones en lenguaje natural. En consecuencia, la única manera de aprender como organización es capturar nuestros procesos para entender su funcionamiento (datos del proceso) y la calidad de los productos que generan.

No todos los procesos son iguales. Hay procesos administrativos que no nos ocupan en este libro. Hay procesos extra-organización que tampoco nos interesan. Los procesos que queremos resaltar y mejorar son aquellos procesos vinculados con el desarrollo de software en las organizaciones. Aun así, es posible obtener más detalle de lo que plantearemos en este libro en otras fuentes. Los autores nos limitaremos a exhibir el comportamiento mínimo para organizar proyectos que produzcan sistemas de software de buena calidad.

Las organizaciones que entienden sus procesos y les sacan provecho se dicen ‘maduras’. Una organización madura persigue sus objetivos con uso de ese conocimiento. Sabe lo que sus equipos son capaces de alcanzar y no hace promesas que no puede cumplir. Los equipos usan el conocimiento para adentrarse en el desarrollo con confianza en sus fuerzas y su capacidad de cumplir con sus compromisos. Las organizaciones inmaduras, entretanto, a veces cumplen con sus compromisos, pero muchas veces no. No conocen su capacidad y hacen promesas que nacen de su deseo de ganar el cliente. Lo que propondremos en este libro es un camino para llegar a

Boria et al.

Capítulo 2 13

la excelencia madurando como organización usando métodos ágiles, para lo cual usaremos un caso de ejemplo y un modelo.

Es el modelo MPS, en nuestro caso, aquél que orienta la secuencia de acciones en lo que hace al crecimiento de la madurez organizacional. El modelo MPS, que explicaremos con más detalle en el capítulo 4, es un modelo de desarrollo organizacional por niveles, que define los procesos que la organización debe implementar en su seno y los resultados esperados de ese accionar, para ir avanzando de nivel a nivel. Aun cuando es la intención de todos seguir el modelo, es imposible implementar todos los cientos de procesos a la vez, inclusive si nos restringimos a tomar los niveles de a uno, cosa por otra parte muy saludable, porque los hábitos que se construyen en uno se aplican en el que le sigue.

Hay necesidad, por lo tanto, de encontrar un método que nos ayude a organizar el crecimiento en términos más concretos de lo que hace el MPS, y que a su vez se compadezca de las necesidades de la organización en cuánto a sus negocios. Como se puede imaginar el lector, no hay una única manera de hacer esto. Por ello, hemos decidido anticipar la presentación de un proceso del MPS, no en detalle, pero si mostrando su uso. Tomando prestadas técnicas del MPS en su proceso Gerencia de Desiciones (GDE), comenzaremos por definir el problema que intentamos resolver.

Problema: Si bien en un marco ‘macro’ los niveles del MPS alcanzan para definir las pautas de la mejora continua, en cada caso es necesario atender a las necesidades de la organización que pretende mejorar sus procesos, teniendo en cuenta el ‘negocio’

5 de la misma.

Atributos deseables de una Solución: La solución debe de proveer un mecanismo de mejora continua que permita identificar cada paso sucesivo de un programa de mejora y este debe tener suficiente detalle como para que sea posible ejecutarlo sin demasiada ambigüedad, pero no tanto que implique una planificación detallada para cada selección (DETALLE). Debe proveer un marco teórico reconocible que ayude a medir el impacto de las decisiones sobre el sistema en conjunto, no solo la optimización local (MARCO). Debe permitir deducir las acciones derivadas que optimicen el sistema (SISTEMA). Debe retroalimentar el mecanismo que permita introducir mejoras a buen ritmo, sin que interfieran con el trabajo ni con el desarrollo personal de los empleados (NEGOCIOS). Estos atributos deseables constituyen los criterios bajo los cuales evaluaremos las alternativas de solución. El orden de su importancia relativa se muestra en la siguiente tabla:

atributos peso

NEGOCIO 5

DETALLE 4

SISTEMA 3

MARCO 2

suma

Tabla 2.1: Selección del Método de Mejora de Procesos

Alternativas de Solución: La literatura tiene muchos ejemplos de estos métodos. Los siguientes fueron incluidos en nuestro conjunto de soluciones: Plan-Do-Check-Act [SHEWHART, 1939], IDEAL [McFEELEY, 1996], Focus-Improve-Sustain-Honor [ARTHUR, 2004], y Lean Simplified [ARTHUR, 2006].

Método de Evaluación: Utilizaremos una matriz de Pugh [PUGH, 1991] para evaluar alternativas cuando los atributos son múltiples. Usado por Pugh en General Motors y descripto por él en su libro ya citado y previamente en un artículo [PUGH, 1981], es uno de los métodos de análisis de alternativas más difundidos entre ingenieros. Cada columna representa una solución y cada fila un atributo. Cada fila tiene un peso específico que representa el valor relativo de ese atributo frente a los otros. En cada intersección fila/columna se evalúa el aporte que la solución de esa columna hace al criterio de esa fila. Previamente se ha establecido un mecanismo de evaluación que permite ajustar la objetividad al respecto de la medición de cada atributo.

5 La referencia a un negocio está entre comillas porque se trata de los motivos de existencia de la organización. Si esa

organización es un hospital público que mide su impacto en la comunidad en la cantidad de curaciones que realiza o el estado general de salud de la población que atiende, entonces a esos efectos ese es su ‘negocio’. No se debe entender como que solo aplica a organizaciones con fines de lucro.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

14 Capítulo 2

Criterios de Evaluación por Atributo: DETALLE es medible como 3 (detalle adecuado), 2 (detalle un poco excesivo o no suficiente), 1 (detalle bastante excesivo, algo así como treinta páginas para entenderlo, o muy superficial, algo que permite muchas interpretaciones) o 0 (no tiene ninguna explicación clara asociada). MARCO se mide como 3 (se reconoce en el sistema qué otras cosas hay que atender), 2 (no se analiza el sistema de manera total, pero es bastante comprehensivo), 1 (hay algunas pistas para analizar acciones derivadas) o 0 (no se apoya para nada al cambio sistémico. SISTEMA se mide como 3 (las acciones derivadas que impactan al sistemas se reconocen mediante el método), 2 (hay una visión periférica pero el foco de las acciones es idéntico al foco de la mejora), 1 (se evalúan resultados globales a nivel sistema aunque no se los prevea en el análisis de impacto), o 0 (ninguna actividad relacionada con el efecto global forma parte del método). NEGOCIOS se mide como 3 (cuando se enfoca sobre todo en las necesidades del cliente como punto de partida), 2 (hay un alineamiento con el negocio pero es externo al método), 1 (se puede alinear al negocio pero el método es agnóstico y no lo menciona) o 0 (no hay ninguna relación evidente entre el método y el negocio).

Describiremos ahora las cuatro opciones, tratando de que el lector mismo pueda juzgar la calificación de cada una con respecto a cada atributo.

2.2 Plan-Do-Check-Act

Plan-Do-Check-Act (PDCA) es original de [SHEWHART, 1939], y difundido sobre todo por Deming en varias ocasiones

6. Deming se refería a este procedimiento basado en el método científico como el ‘Ciclo de Shewhart’. La

posteridad lo recuerda a menudo como el ‘Ciclo de Deming’, una de las consecuencias de la notoriedad de este que es todavía mayor que la de aquél. Hacia el final de su vida Deming cambió el “Check” (validar) por “Study” (estudiar) para enfatizar que el paso debe ser de análisis más que de inspección.

Puede justificadamente considerarse a Shewhart como el padre de la calidad industrial. Fue él quien introdujo los diagramas de control estadístico para el análisis de la estabilidad de un proceso a través de la medición de un atributo. Dada su fecha de origen, es difícil encontrar el material original, pero en la mayoría de las citas

7 el primer paso es identificar el problema y luego analizarlo. No hay una mención explícita de los objetivos de

negocios, aunque es difícil imaginar que Shewhart los haya eludido, leyendo sus otros materiales. Posiblemente se ha sacado (una vez más) del contexto al método y al hacerlo se perdió parte de su valor sistémico. Por lo tanto, sin juzgar al método en sí pero si juzgando su uso habitual, podemos decir que PDCA es sencillo, fácil de aplicar pero es factible de ser usado sin tener en cuenta el impacto en el negocio. Hay en varias versiones del método referencias a un proceso desarrollado por Deming para la mejora continua, lo que daría una mejor versión sistémica del mismo, así como un posible vínculo con los objetivos de negocios. A continuación describimos los pasos de PDCA.

PLAN (Planificar) Paso 1: Identificar el Problema. Actividades: Seleccionar el problema a ser analizado; definir claramente el problema y redactar un enunciado preciso del mismo; fijar un objetivo medible para el esfuerzo de resolución del problema; establecer un proceso para la coordinación con, y conseguir la aprobación de, la alta dirección.

PLAN (Planificar) Paso 2: Analizar el Problema. Actividades: Identificar los procesos que impactan en el problema y elegir uno; listar los pasos del proceso tal como se ejecutan en este momento; construir un mapa del proceso; validar el mapa del proceso; identificar posibles causas del problema; juntar y analizar datos relacionados con el problema; verificar o revisar el enunciado original del problema; identificar las causas raíces del problema; juntar datos adicionales si es necesario para verificar las causas raíces

DO (Hacer) Paso 3: Desarrollar Soluciones. Actividades: Establecer criterios para elegir una solución; generar soluciones potenciales que ataquen las causas raíces del problema; elegir una solución; conseguir aprobación y soporte para la solución escogida; planificar la solución.

DO (Hacer) Paso 4: Implementar la Solución. Actividades: Implementar la solución escogida en un piloto o ensayo. Si el proceso PDCA está siendo utilizado dentro del Proceso de Mejora Continua, pasar al Paso 6 de ese proceso. Si se lo está utilizando por separado, continuar con el Paso 5.

CHECK (Verificar) Paso 5: Evaluar los Resultados. Actividades: Juntar datos de la solución; analizar los datos. ¿Se alcanzó el objetivo buscado? Si es así, pasar al Paso 6. Si no es así, volver al Paso 1.

6 El libro [SHEWHART W., 1939] fue compilado por Deming con un prefacio de su autoría.

7 Véase por ejemplo http://quality.enr.state.nc.us/tools/pdca.htm

Boria et al.

Capítulo 2 15

ACT (Actuar) Paso 6: Estandarizar la Solución (y Capitalizar Nuevas Oportunidades). Actividades: Identificar cambios sistémicos y necesidades de entrenamiento necesarias para un implementación completa; adoptar la solución; planificar y monitorear permanentemente la solución; continuar buscando oportunidades incrementales para refinar la solución; buscar nuevas oportunidades de mejora.

El método PDCA es sólido, pero su edad ha hecho que varios de los detalles que su autor predicaba hayan sido dejados de lado en su implementación corriente, que es lo que un buen evaluador juzga: Su uso por encima de su definición. Eso no quita que para el lector avisado los pasos de PDCA no sigan teniendo utilidad. De hecho, como veremos en lo que sigue, el ciclo de Shewhart sigue siendo utilizado en diferentes variantes. Tampoco es frecuente que los usuarios de PDCA lo coloquen en el marco adecuado, simplemente es utilizado como un ciclo cuya repetición produce los resultados esperados. Recordemos que para Shewhart, y en consecuencia para Deming, hay un proceso de mejora continua en el que PDCA encaja. De otra manera se pierde parte de su impacto. Es en ese proceso marco que varias de las iniciativas sistémicas y el vínculo con los objetivos de negocios están inmersos, de modo que cambiar ese proceso como fuera definido y colocar otro en su lugar puede tener como consecuencia la pérdida de ese entorno y en consecuencia la desmejora del proceso de mejora. Veamos ahora como McFeeley lidia con ese problema, incorporando a su método el detalle necesario (en exceso, según nuestro punto de vista).

2.3 El Método IDEAL

Debido a la enorme influencia que Deming, y en consecuencia Shewhart, a quién aquél citaba constantemente, tienen sobre la comunidad de mejora de procesos, este método y los que describiremos más tarde están fuertemente influenciados por PDCA. La Figura 2.1 muestra una descripción gráfica del método IDEAL. Tiene cinco fases que se corresponden con etapas importantes de una iniciativa de mejora de procesos. Puesto que la mejora es continua, se espera que se continúe el ciclo una vez alcanzada la 5ª fase. Si bien el autor de IDEAL [McFEELEY, 1996] aclara que los límites entre fases son más borrosos que los que se describe en la referencia, es usual que las recomendaciones de éste no se sigan y se ejecute como una secuencia de actividades en un proyecto, así como otras desviaciones de alto impacto.

Figura 2.1: El Método IDEAL [McFEELEY, 1996]

La primera fase se denomina, con lógica, ‘Initiating,’ que traducido quiere decir Comenzando. Tiene tres bloques, pero en la descripción detallada no se las considera, siendo descriptas en cambio 10 tareas que se detallan, algunas hasta el nivel de subtareas. La misma situación de desacople entre la gráfica y la descripción textual se repite para todas las fases. La fase ‘Initiating’ culmina cuando la infraestructura para la mejora de procesos se ha construido, se han vinculado los objetivos de negocios al programa de mejoras de proceso, hay un sistema de recompensas alineado con las mejoras y un plan inicial para el proyecto de mejoras, que contiene el plan de comunicación de los avances.

La fase que sigue se denomina ‘Diagnosing’ y tiene seis tareas. Se traduce fácilmente, dada la similitud de los vocablos, por Diagnosticando. En efecto, es la fase en la que se realiza el análisis de la brecha existente entre las

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

16 Capítulo 2

necesidades de proceso y los procesos en uso, tal como se usan. El criterio de entrada de la fase no coincide totalmente con el criterio de salida de la primera fase, por lo que es difícil entender como se consigue llegar a su ejecución. La fase tiene como criterio de finalización que se hayan entregado las brechas halladas y las recomendaciones al comité de gestión y hayan sido aceptado, así como que ya haya un boceto del plan estratégico de acción.

La tercera fase de IDEAL se denomina ‘Establishing’, que quiere decir Estableciendo, pero se refiere acá al plan y no a los procesos. Si bien es confuso, da una linda sigla (IDEAL) que un nombre más lógico (Planificar, o Detallar) no conformaría. En esta fase se ajustan prioridades y se forman los equipos que llevarán adelante la definición y difusión de los cambios y mejoras a los procesos. Notablemente, el método recomienda que la planificación la realice el comité de gestión, es decir los gerentes que realizan la supervisión estratégica del plan de mejoras, y no el grupo de procesos. Este excelente consejo es ignorado en la práctica. La fase tiene 14 actividades. El criterio de finalización es que el plan estratégico se haya completado y aprobado, y que la visión organizacional, el plan de negocios y el plan estratégico de mejora de procesos tengan sinergia entre sí.

La fase que sigue se denomina ‘Acting,’ que se traduce por Actuando. Esta fase es la más interesante, aunque el modelo tiene muchas componentes útiles, porque ésta enfoca muy directamente en el negocio. Es cuando las mejoras se identifican, construyen, despliegan y se ponen práctica. Tiene diez pasos, de los cuales destacaremos una subtarea del paso 2, Desarrollar Soluciones: Analizar y Arreglar el Problema. Nos interesa porque en muchas formas anticipa y se parece a Lean, en que el planteamiento es puramente enfocado en el dolor y no en la mejora de procesos en sí. Se modifican procesos porque los procesos actuales toleran defectos y demoras que no se deben tolerar, se ataca sus causas, pero se enfoca en los síntomas. Esta fase tiene como criterio de éxito que la estrategia de despliegue y el plan se han ejecutado plenamente, o están en camino de serlo. Las soluciones que se han adoptado (o piloteado) se han documentado correctamente y están bajo control del grupo de procesos, y se tiene claro cómo se las va a mantener. La mejora de procesos ha comenzado a estar institucionalizada en la organización. Esta fase hace referencia a muchas pequeñas mejoras realizadas en paralelo, bajo un único plan estratégico y múltiples planes tácticos. Sin embargo, la gran mayoría de las implementaciones de IDEAL adolecen del mismo defecto: Un enorme plan táctico que nunca termina de ejecutarse y que sufre del síndrome del correo: las cartas (pedidos de nuevos cambios) siguen llegando y la tarea de planificar nunca se concluye.

La fase final, o si se quiere la que inicia una nueva iteración del ciclo IDEAL, se denomina ‘Leveraging’, que significa Aprovechando, o Sacando Provecho, en realidad es la variante de la primera fase, puesto que tendría poco sentido empezar de nuevo sin tener en cuenta lo que ya se avanzó. Se denomina así porque ante la alta gerencia se afirma el auspicio mediante la muestra del avance. Cuando las organizaciones caen en los errores que marcamos antes, el resultado es que el proyecto de mejoras tiene poco que mostrar. El ejemplo más común es que se definen soluciones pero no se las implementa ni en pilotos, lo que se justifica por el síndrome del correo: ya que se han aceptado nuevos pedidos de cambio, el grupo de mejoras se enfocará en la definición de soluciones y no en su implementación. Como consecuencia una larga lista de cambios es lanzada simultáneamente sin suficiente preparación, por la demanda de capacitación que eso conlleva, y el proyecto fracasa. IDEAL no es un mal método, pero es muy detallado (se describe en un documento de 236 páginas) lo que hace que mucha gente lo haya implementado sin haber leído esos detalles

8 con la consiguiente pérdida de varios elementos fundamentales,

como el vínculo con los objetivos de negocios, el paralelismo en la implementación9 y la visión sistémica

(multicausal, con lazos de retroalimentación y demoras entre causa y efecto visible) que son indispensables para establecer un programa de mejora continua.

Lo mejor de IDEAL es su visión de la mejora de procesos (Figura 2.2) basada en los objetivos de la organización y soportada en la visibilidad del proyecto, la comunicación horizontal y vertical entre las partes, la captura, retención y aprovechamiento de la experiencia (lecciones aprendidas), y una red de soporte de todo el proyecto. De ese modo se sostiene el plan táctico y el estratégico para culminarlos con éxito.

8 Si el lector no se siente cómodo con la afirmación de que un número muy grande de personas no lee los detalles antes de

implementar un modelo, los autores querrían remitirlo al trabajo de Royce, Managing the Development of Large Software Systems [ROYCE, W., 1970], a quién se considera el padre del ciclo de vida en cascada por ese mismo artículo, y que lamentablemente está mal citado: Lo que Royce dice en ese trabajo es que esa visión del proceso de desarrollo es infantil y llena de problemas.

9 Los usuarios de IDEAL tienden a desarrollar un proyecto secuencial con muchas iniciativas que demoran la fase de aplicación,

una de las maneras de resistir el cambio.

Boria et al.

Capítulo 2 17

Figura 2.2: Visión de Mejora de Procesos de IDEAL [McFEELEY, 1996]

2.4 Focus-Improve-Sustain-Honor

Focus-Improve-Sustain-Honor (FISH) de [ARTHUR, 2004] es una variante más de PDCA, con énfasis en las herramientas de Six-Sigma

10. El ciclo de Arthur se basa en la medición. El uso de los datos disponibles y la

búsqueda tipo “inteligencia de negocios” es el fundamento del análisis, en vez de los defectos o la brecha respecto de algún ideal. Esto por supuesto no está contra los preceptos de PDCA, pero si influye mucho en el impacto que tiene cada uno, porque en FISH es indispensable comenzar por el análisis de los datos antes de entrar en el ciclo.

El ciclo tiene cuatro fases, Focus, enfocar, la primera, está basado en un hecho estadísticamente demostrable por la distribución de los defectos: Unos pocos procesos son responsables de la mayoría de los mismos. Encontrar esas “fábricas de defectos” enfoca el proceso de mejora en donde más rendimiento tiene. Para Arthur, la aplicación de la ley de Pareto

11 predice grandes ganancias. Su razonamiento es que si el 80% de los defectos son

producidos por el 20% de los procesos, volviendo a aplicar la regla se tiene que el 64% (80% del 80%) de los defectos proviene del 4% (20% del 20%) de los procesos. De ese modo un minúsculo grupo de procesos permite eliminar un número sumamente grande de defectos, de donde enfocar es necesario.

La segunda fase, Improve, mejorar, es donde el defecto encontrado se elimina. Esta es la fase donde se identifican las causas profundas, se eligen las soluciones posibles y se define y lleva adelante su implementación. El MPS (ver el Capítulo 4) contiene resultados esperados de procesos que ayudan a entender la implementación de los pasos de mejora por identificación de las causas raíces. Utilizaremos a lo largo del libro esta capacidad de identificar las causas de las cosas para poder mejorarlas o difundirlas

12. Utilizar el análisis de causa raíz de forma

sistemática es una de las herramientas más poderosas de la mejora de proceso, y una de las tres herramientas intelectuales (junto con el análisis y gestión de riesgos y la visión sistémica del proceso) que más rendimiento tienen en los procesos intelectuales que acompañan, o deben acompañar, a la mejora de procesos.

La tercera fase, Sustain, sostener, es donde la mejora se intenta consolidar y mantener, para lo cual Arthur propone utilizar herramientas de “conocimiento profundo” como fueran introducidas por Shewhart y difundidas por Deming. Para comenzar, Arthur indica desarrollar el mapa del proceso, utilizando siempre herramientas

10

Six Sigma es una estrategia de gestión originada en Motorola en 1986 SPC and TQM in Manufacturing and Services [TENNANT, G., 2001] y usada mundialmente. Trata de mejorar la calidad de los resultados de los procesos identificando y eliminando las causas de los defectos. Utiliza una variedad de métodos, fundamentalmente estadísticos. El término surgió del análisis estadístico de la ocurrencia de defectos en manufactura. La madurez de un proceso de fabricación puede

expresarse como la cantidad de desvíos estándar () que se aleja de la media de la población total, o por el porcentaje de

piezas sin defectos que produce. Un proceso seis es uno que produce 99.99966% de las piezas sin defectos, que fue el objetivo fijado por Motorola y que dio nombre a los métodos que se conjuntaron en un proceso para alcanzarlo.

11 Pareto fue un estadígrafo francés del siglo XX que se destacó en el estudio de la distribución de la renta. En 1906 él hizo la

famosa observación de que el veinte por ciento de la población poseía el ochenta por ciento de la propiedad en Italia, posteriormente generalizada por Joseph M. Juran en el principio de Pareto (también conocida como la regla del 80-20).

12 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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

18 Capítulo 2

simples. En todos los casos, Arthur se inclina por la simplicidad, dedicándole tiempo al proceso intelectual y utilizando la herramienta que mejor se adapta al menor costo de aprendizaje posible. Por ejemplo, en este caso sugiere utilizar un diagrama de flujo, siendo que hay otras herramientas posibles

13 que son más poderosas e

igualmente difundidas.

Para poder afirmar que los resultados se han alcanzado es necesario saber que el proceso está normalizado, porque si no es así es imposible establecer comparaciones. Supongamos que el problema es que una receta culinaria viene dando resultados desparejos. Al analizar la causa profunda nos damos cuenta que diferentes cocineros le dan diferente interpretación a las instrucciones y que algunos pasos están faltando, porque el autor de la receta asumió que los que la intentarían ejecutar tenían conocimientos culinarios en grado suficiente, lo que no resultó una predicción verdadera. Además, hay un error en la receta que sugiere usar un tipo de harina que no es el correcto, digamos que dice “harina” a secas, que en el contexto de los cocineros que tienen problemas con la receta se entiende por “harina de trigo,” cuando el que diseñó la receta quería que fuera “harina de maíz”. El análisis de causa ha detectado estos defectos y se ha sugerido que se hagan cambios a la receta, definiendo con precisión los pasos para que no haya diferentes interpretaciones, y corrigiendo los errores y ambigüedades.

Un grupo de procesos sin la suficiente experiencia consideraría que ha cumplido su cometido: El proceso, de ejecutarse correctamente, “debería” funcionar. Jay Arthur (y los autores) no se conforman con esa definición, incompleta, de la responsabilidad del grupo de proceso: ¿Y si no funciona? Lamentablemente la resultante en esos casos es que el grupo de procesos le arroja la responsabilidad a los que debiendo ejecutar correctamente el proceso no lo hacen, sin constatar que, necesariamente, son ellos y no los cambios los que llevan a perpetuar el problema o introducir otros nuevos.

Por lo tanto, ‘sostener’ implica medir y analizar los resultados. Esto lleva a tener que entender cuándo, dónde y qué medir. Uno de los pasos más importantes en la definición de procesos y el cambio para la mejora es identificar los procesos clave y los atributos a medir. Esta capacidad es exigida por el MPS en los niveles más altos de madurez, a partir del Nivel B, pero es una de las cualidades más valiosas de un gerente. Por ejemplo, si nos preocupa que la mayoría de los proyectos termina después de su fecha de entrega y hemos hecho cambios en consecuencia para adelantar la producción de resultados, medir las demoras que se producen en aquellos puntos es de suma importancia. Medir solo el resultado final, el desvío en la fecha de entrega, es solo parcialmente útil porque una vez que hemos entregado tarde no se puede modificar el resultado. Arthur introduce acá herramientas

de 6 que el MPS no requiere sino hasta el Nivel B, como ya hemos dicho, y por lo tanto complica un poco más de lo necesario el análisis de resultados.

La última fase del ciclo es Honor, honrar. Arthur se refiere acá a la necesidad de respetar y premiar los compromisos con el cambio, con la mejora (no todo cambio es una mejora, pero toda mejora es un cambio). Gran parte del mensaje sobre la mejora de procesos está contenido en la manera que la organización resalta y recompensa los esfuerzos de su personal en relación a los cambios y las mejoras. Es importante destacar que no todos los intentos de mejora, sobre todo en las etapas tempranas del proceso de mejora continua, han de resultar igualmente exitosos. Algunos serán hasta negativos, pero es indispensable rescatarlos como esfuerzos válidos porque la organización aprende.

2.5 Lean Simplified

El último método es Lean Simplified [ARTHUR, 2006]. Jay Arthur desarrolló ese método como una extensión de su anterior FISH que vimos más arriba con el propósito de hacer más clara la aplicación del mismo, enfatizando la cadena de valor que lleva desde el pedido del cliente a su satisfacción por la entrega del producto. La palabra inglesa Lean significa delgado, sin peso demás. Arthur elige llamarlo Simplified, simplificado, porque ha reducido la demanda estadística que su método FISH tiene. Llamaremos a este método LS, para evitar usar términos en inglés.

LS, como lo explica Jay Arthur en [ARTHUR, 2006] es un método para la empresa manufacturera. Sin embargo, modificando o dejando de lado lo que no aplica para el desarrollo de software, es un método poderoso para identificar y resolver problemas con vista a la mejora continua. Presentamos acá nuestra versión de LS adaptada a la producción de software.

13

Los diagramas SADT, o IDEF0 en su versión norma internacional, son más detallados y de uso difundido. También los diagramas de flujo con andariveles que permiten discernir responsabilidades. Asimismo sería posible diseñar el proceso siguiendo técnicas de flujo de datos del Análisis Estructurado o con herramientas de UML.

Boria et al.

Capítulo 2 19

En el corazón de LS está el tema de la velocidad de producción14

. La velocidad no es apuro, es hacerlo mejor y sin interrupciones, no es trabajar los fines de semana o hasta altas horas de la noche. La velocidad es productividad puesta al servicio del producto. En un mundo conectado globalmente por la Internet los clientes esperan servicios casi inmediatos sin pérdida de calidad ni aumento de los precios. El libro de [RODIN, 2010] es una visión de cómo la demanda por servicios gratuitos entregados en el momento y sin costo alguno está revolucionando los negocios. Para las organizaciones que fabrican software el desafío está lanzado: Hay que eliminar los defectos y todas las demoras para entregar más que a tiempo y con bajos costos.

Las demoras no son justificables. El producto de software puede ser único e irrepetible, pero los procesos por los cuáles se lo produce no lo son. Cada proyecto se compone de las mismas fases, que realizan las mismas actividades. La resistencia a ese concepto es notable en empresas de baja madurez, y sin embargo vemos una y otra vez que la resistencia a hacer las cosas de otra manera es tan arraigada como la necesidad de sostener que siempre son diferentes. Lo único que se demora en cambiar es la creencia de que la organización está justificada en actuar como lo hace.

En cada empresa hay dos fábricas, la principal que diseña, vende, factura y entrega el producto, cuya fórmula es Velocidad con Calidad + Ganancias = Beneficio. La segunda es la fábrica de arreglos, que corrige todos los errores que se van cometiendo a medida que se diseña, vende y factura el producto. Hay siempre una fábrica de arreglos visible que se mide y se controla, pero hay otra que es oculta que hace que los errores se corrijan sin que haya atribución ni contabilización. Esa fábrica tiene otra fórmula: Defectos + Demoras = Pérdidas.

En el fondo, LS se centra en la velocidad de producción. La relación entre las etapas de un proceso es fundamental. Las etapas y actividades que no agregan valor deben ser eliminadas del proceso. Por eso la primera actividad en LS es hacer un mapa de la “cadena de valor”, la secuencia de actividades que van desde la recepción del pedido del cliente a la satisfacción de sus necesidades

15. Una vez más, el mapa tiene que ser sencillo, pero no

tanto que resulte fácil de malinterpretar. Además, puesto que se trata de un sistema de tracción donde la salida fuerza al proceso anterior y así sucesivamente, este método atiende principalmente la voz del cliente. Hecho correctamente, esto genera valor para el cliente y en consecuencia, la organización.

Foco en los Defectos

Al intentar reducir la “fricción” que demora los procesos, Toyota descubrió que hay muchas formas de desperdicio (“muda”).

1. Exceso de producción (en software, incluir código que no fue solicitado “por si lo vamos a necesitar”) 2. Inventario excesivo (en software, los procesos que se generan alrededor de la funcionalidad no

requerida, como testeo extra, volumen de manuales, etc.) 3. 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) 4. Movimientos innecesarios del producto (en software la ubicuidad de los productos en formato

electrónico hace de esto un problema inexistente, pero si se mantienen planos en papel o en pizarrones puede llegar a ocurrir)

5. Movimientos innecesarios del personal (típicamente en la instalación o en la validación, a menudo en la etapa de generar requisitos)

6. Procesamiento innecesario o inadecuado (no es muy común, pero en ciertas organizaciones burocráticas hay ocurrencias de esto)

7. Defectos que obligan a reparaciones y retrabajo (no hay porqué explicar esto en nuestra profesión)

Si la organización trabaja con plazos cortos y se concentra em mantener la flexibilidad se obtienen beneficios en calidad y satisfacción del cliente. En el capítulo 3 veremos cómo un grupo de desarrolladores de software

14

La empresa Toyota inventó el método de "producción esbelta" (lean production) tomando como referencia los supermercados de los EEUU, donde percibieron que cuando los anaqueles de los supermercados alcanzan el punto mínimo del inventario son reabastecidas tan rápidamente como los clientes "quitan" los productos de la góndola. En un sistema de tracción, el proceso anterior debe siempre hacer lo que el proceso subsecuente le pide. Para ver que el stock está bajo y, como consecuencia, reponerlo, se coloca una tarjeta que señala el punto exacto. El nombre en japonés de esa tarjeta es Kanban, palabra que hoy identifica tanto a la tarjeta como al sistema.

15 No es lo mismo oír y reaccionar que escuchar y satisfacer.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

20 Capítulo 2

construyó métodos que permiten aprovecharse de estos conocimientos. El movimiento que iniciaron se conoce como el Agile Manifesto

16 y ha marcado como se desarrolla software desde su aparición.

LS sigue con la organización del trabajo para eliminar el desperdicio. Son cinco las tareas a realizar: Sort, ordenar; Straighten, enderezar; Shine, pulir; Standardize, estandarizar; y Sustain, mantener.. Nosotros damos aquí nuestra interpretación de esas tareas en actividades de ingeniería de software

17. Ordenar significa decidir qué es

útil y qué no lo es y eliminarlo. Esto es la tarea de las personas o roles que identifican las mejoras de proceso. A menudo los pedidos de cambio de procesos se originan en los equipos, y un rol en particular, llamado afirmación o aseguramiento de la calidad es quien debiera detectar la necesidad del cambio y transmitirla. Enderezar es colocar cada cosa en su lugar y tener un lugar para cada cosa. Ese es el rol de la gestión de configuración en la ingeniería de software. Pulir es mantener el área limpia para exponer defectos y pérdidas. En software esto se manifiesta en la aplicación de formas y patrones que permiten el análisis y la inspección por terceros, por ejemplo el uso de estándares de programación que ayudan a leer un programa. Estandarizar es definir sistemas, procesos y procedimientos que ayuden a mantener las tres reglas anteriores. Este es nuevamente el rol del área de mejora de procesos. Mantener, por último, es conseguir que el flujo de trabajo sea estable y se respeten las reglas. Entre el área de mejora de procesos y el grupo de afirmación de calidad esto debiera ser alcanzable.

Otra de las normas que rigen LS es la preminencia de la demanda por sobre la producción. En vez de producir en anticipación de lo que se demandará se produce a partir de lo que se pide. En nuestra traducción al mundo de procesos esto significa que no intentaremos mejorar lo que no se siente que está roto. El vocablo inglés “pull” que significa halar, tirar, representa este pensamiento, contra el vocablo inglés “push” que significa empujar. Es común en la disciplina de mejora de procesos que se intente ‘empujar’ mejoras desde el centro hacia afuera, o desde arriba hacia abajo. En nuestra experiencia la resistencia así creada demanda mucho esfuerzo y no justifica el retorno de la inversión. Por el contrario, un enfoque de ‘halar’ hace que el cambio se vea como algo positivo ya que, efectivamente, resuelve un problema. Cuando una mejora de procesos se percibe como una eliminación de un obstáculo a la productividad se gana un aliado para los futuros cambios, que además cuenta ahora con tiempo extra para apoyar la creación y difusión de nuevos cambios.

LS tiene más para aportar, pero en lo esencial nos alcanza con lo expuesto para entender las ventajas y desventajas del método. Nuestra matriz de Pugh para los cuatro métodos queda así:

atributos peso PDCA IDEAL FISH LS

NEGOCIO 5 1 3 3 3

DETALLE 4 1 1 2 3

SISTEMA 3 2 1 1 3

MARCO 2 2 0 0 3

suma

19 22 26 42

Tabla 2.2: Selección del Método de Mejora de Procesos

Con estos valores es claro que nos inclinamos por LS. Por supuesto, se puede criticar esta decisión, porque los valores colocados en la intersección son arbitrarios hasta cierto punto. En una decisión de mayor impacto económico sería deseable que la puntuación estuviera mejor detallada para lograr mayor objetividad.

Puesto que vamos a utilizar LS en nuestros análisis y nuestras propuestas para la empresa que hemos tomado como caso de ejemplo, es bueno resaltar algunos valores y creencias que se asocian con LS.

1. El proceso exacto producirá los resultados exactos. 2. Desarrollar al personal y a los proveedores agrega valor. 3. La resolución continua de problemas raíces conduce al aprendizaje organizacional. 4. El flujo de una pieza aumenta la productividad, el lucro y la calidad. 5. A los productos no les gusta hacer fila esperando atención. Los materiales, piezas y productos son

impacientes.

16

http://www.agilemanifesto.org/ 17

Remitimos al el lector interesado en las definiciones originales en manufactura al sitio http://es.wikipedia.org/wiki/5S

Boria et al.

Capítulo 2 21

6. Lo único que agrega valor en un proceso es la transformación física o informacional de la materia-prima en algo que el cliente quiere.

7. Los errores son oportunidades para el aprendizaje. 8. La resolución de problemas es un 20% de herramientas y un 80% de aplicar la inteligencia.

Nuestro enfoque de mejora de procesos va a adoptar muchas de estas máximas, en lo que aplican a las áreas de desarrollo de software. No vamos a limitarnos a seguir al modelo MPS en su aplicación, vamos a procurar identificar y resolver los problemas que son comunes en las empresas desarrolladoras de software.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

22 Capítulo 3

CAPÍTULO 3 - LOS MÉTODOS ÁGILES: KANBAN, SCRUM, XP Y FDD

3.1 ¿Qué son los métodos ágiles?

En el capítulo anterior presentamos la mejora continua de procesos y decidimos tomar como referente a LS. Las ventajas de un método liviano, desprovisto de burocracia, que enfoca directamente en las necesidades de negocio no pasaron desapercibidas para los “metodólogos” de Ingeniería de Software. Ya en el siglo pasado habían nacido varios métodos de desarrollo que se apoyaban en las ideas de producción de Toyota, notablemente Extreme Programming [BECK, 2000], Scrum [SCHWABER, 2002], DSDM [STAPLETON, 1997], Adaptive Software Development [HIGHSMITH, 1999], Crystal [COCKBURN, 2005], Feature-Driven Development [COAD, 1999], Pragmatic Programming [HUNT, 1999] y otros más. En un intento de encontrar formas comunes se reunieron diecisiete de estos creadores en Febrero del 2001 en un centro de esquí en Utah. Lo que surgió fue un manifiesto que marcó la ingeniería de software de modo único, el Agile Software Development Manifesto

18.

El contenido del manifiesto se puede leer en línea, pero consideramos que su influencia es tan importante, y sus coincidencias con el método de Toyota TPS son tantas que lo incluimos acá.

Manifiesto para el Desarrollo de Software Ágil

Estamos descubriendo mejores métodos para desarrollar software ejercitándolos y ayudando a otros a usarlos. A través de este devenir apreciamos:

Los individuos y las interacciones por sobre los procesos y las herramientas

Software que funciona por sobre una documentación completa

Colaboración con el cliente por sobre la negociación del contrato

Responder a cambios por sobre seguir un plan

Es decir, aunque hay valor en los ítems de la derecha, valoramos los ítems de la izquierda aun más.

(firman) Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

Aunque el manifiesto describe las ideas más básicas, hay entre los autores más acuerdos que los allí expuestos. Muchas de las coincidencias provienen de la misma fuente: El foco en la calidad, con las reglas de Toyota que mencionáramos ya en el capítulo anterior en la sección “Foco en los Defectos”. Así como Toyota tiene su método TPS que es una forma de “Kaizen”, los métodos ágiles se apoyan en períodos de producción cortos y mucha colaboración dentro del equipo de proyecto, apoyado en la sinergia que genera el trabajo en equipo de la estructura formada para alcanzar las metas establecidas por la dirección de la compañía. En gran parte, su popularidad entre el personal de desarrollo se deriva de la independencia que los equipos sienten al tomar sus decisiones en conjunto y en alto grado libres de las redes burocráticas que se tejen en las grandes empresas, lo que trae consigo resultados concretos, tanto cualitativos como cuantitativos.

Al dejar que el equipo de trabajo tome las decisiones para el próximo período de trabajo, llamado en la jerga de los agilistas

19 un “Sprint”

20, los métodos ágiles consiguen motivar al personal de los proyectos y

comprometerlos con el resultado al permitirles tomar decisiones de peso. Dada la corta duración de un Sprint, usualmente nunca más de cuatro semanas, los equipos pueden ver sus resultados de inmediato. También es importante la participación del cliente. Junto con un representante del cliente que esté comprometido a su vez con

18

http://agilemanifesto.org/ 19

Usaremos este neologismo para designar a aquellos que adhieren a los métodos ágiles y los practican. 20

Los diccionarios definen ‘Sprint’ como la mayor velocidad alcanzada por un corredor en una carrera, especialmente en el final. Las carreras de hasta 200 metros se consideran todas Sprints, de principio a fin. Por analogía, cada tramo de un proyecto ágil se considera un Sprint.

Boria et al.

Capítulo 3 23

el resultado, se define el alcance de cada Sprint. Es un deber de los equipos ágiles definir una parte del producto que en sí misma tenga valor para la organización del cliente. De ese modo el producto parcial es concreto y mantiene la concentración y el foco en el negocio.

Los métodos ágiles nacieron como respuesta a las burocracias que ignoran las particularidades del desarrollo de software y en su ignorancia presionan a los equipos a llevar adelante proyectos con compromisos irracionales realizados por los que no saben. Al poner metas cortas y priorizar la participación del cliente en las decisiones de negocio, además de poner un freno concreto a los cambios caprichosos, los métodos ágiles rescatan el valor de la ingeniería de software ante los embates burocráticos de ciertos niveles en las corporaciones. Entre otras virtudes, la decisión por el equipo es visible para todos, DEBE ser visible para todos. En consecuencia la transparencia de los proyectos ágiles es uno de sus atributos más valiosos y más revolucionarios.

Los agilistas se consideran un movimiento pro-métodos. Los que creen que la agilidad es contraria a los procesos y las herramientas, a la documentación o los planes se equivocan. Lo que buscan es que estas entidades estén al servicio de las actividades del equipo y no a la inversa. Si el lector cree que ser ágil es no planificar, no seguir procesos por ligeros que estos sean, no tener más herramientas que el ambiente de desarrollo interactivo y un par de lenguajes, no documentar las decisiones, se equivoca de plano. El que así piensa es un hacker, no un agilista. Los agilistas piensan que la planificación de detalle no puede llevar más que unas pocas horas y debe involucrar al equipo, que los procesos son flexibles pero deben de ser acordados por los que los llevan a la práctica, que la documentación debe ser fácil de mantener y responder a una necesidad orgánica del proyecto y debe ser hecha cuando esa necesidad se manifiesta y no como una condición contractual después de que el producto se haya concluido. En cuanto a herramientas, baste recordar que la integración continua, uno de los baluartes de los métodos ágiles, requiere excelentes herramientas de gestión de configuración con testeo integrado por lo tanto es claro que los agilistas trabajan en pro de la eficiencia y no en contra de la misma.

Los cuatro métodos ágiles que encontramos más útiles en diferentes etapas de una empresa son Kanban21,22

, Scrum

23, XP

24 y FDD

25. El orden en que los describiremos va del más sencillo (Kanban) al más complejo (FDD).

Scrum y XP se apoyan en Kanban y en particular describiremos XP en su versión XBREED, que mezcla los conceptos de XP con las prácticas de Scrum para obtener un proceso más sólido y confiable.

3.2 Kanban: Midiendo el flujo

Quién introdujera Kanban como método ágil fue [ANDERSON, 2011]. El método Kanban es parte de una familia de sistemas que se denominan “pull”, o de arranque, contra el enfoque tradicional de sistemas “push” o de empuje. Otra manera de ver la diferencia entre unos y otros sistemas es que el sistema de arranque es guiado por la demanda mientras que el sistema de empuje es guiado por la producción. En un sistema “pull” el proceso espera que haya demanda de su producto para producirlo, tratando de que se llegue justo a tiempo con el mismo, de manera de que no haya inventario

26. El inventario es característico de los sistemas “push” puesto que es el

amortiguador que permite el desacoplamiento entre procesos consecutivos. El problema es que el inventario consume mucho capital y tiene un alto costo, siendo que además no se sabe si el producto final tiene comprador o no. De ese modo se desperdicia trabajo y materiales.

El método Kanban permite alcanzar un ritmo de producción sostenible e introducir cambios a los procesos con muy baja resistencia. Es por eso que lo usamos de preferencia con aquellas organizaciones de muy baja madurez institucional. Como vimos, el método Kanban es uno de los mecanismos que subyace el TPS

27 pero la

adaptación para ingeniería de software es del 2004 y fue realizada por Anderson en Microsoft. Anderson lo presentó en la conferencia Agile 2007 de Washington y comenzó el entusiasmo por el método, puesto que los resultados eran muy alentadores.

21

KNIBERG, H. e SKARIN, M., 2010 22

Cuando usamos Kanban con mayúsculas nos referimos al método Kanban desarrollado por Anderson, cuando se lo usa en minúsculas, kanban, hace referencia a cualquier otro uso, como el sistema kanban de Toyota o el tablero kanban que veremos más adelante.

23 KNIBERG, H., 2007

24 KNIBERG, H., 2007

25 PALMER, S. R. e FELSING, J. M., 2002

26 Esto también es conocido como sistema “Just in Time”, o con las siglas JIT.

27 Toyota Production System.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

24 Capítulo 3

El método es en sí muy simple, pero al usarlo de determinada manera trae consigo múltiples ventajas que señalaremos al explicarlo. Si bien el texto [ANDERSON, 2011] es la base que permite entenderlo profundamente, para el lector que aspira a un manejo más pragmático aconsejamos [KNIBERG & SKARIN, 2010] que se remite a lo esencial de la implementación, sin por ello dejar de lado lo anecdótico que permite la comprensión, o como se dice en México, el “aterrizaje” del material.

Un elemento central en el método es el uso del tablero kanban. No se debe confundir el uso del tablero con la aplicación del método; es posible usar el tablero sin seguirlo, como de hecho se hace en muchas adaptaciones de Scrum y XP, porque el tablero es un excelente medio para comunicar el progreso de un proyecto.

El tablero kanban es simplemente un registro del avance del proyecto materializado según le convenga al equipo. Lo más frecuente es usar un tablero donde se puedan pegar notas autoadhesivas que llamaremos pósit

28,

como en la Figura 3.1, dividido en columnas verticales. Cada columna indica un estado de las tareas. Las pósit contienen los nombres de las tareas. La primera columna de la izquierda típicamente contiene lo “pendiente”, es decir la lista de las tareas a realizar que aún no se han comenzado. Cuando un miembro del equipo tiene disponibilidad para comenzar una tarea, toma de esa columna la tarea que corresponda, ya sea por prioridad prestablecida o por alguna otra razón que se haya convenido en el equipo, y la corre a la columna siguiente hacia la derecha. En algunos métodos que usan el tablero kanban el miembro del equipo que hace esto coloca la fecha y hora del comienzo, su nombre y la fecha estimada de finalización en los rincones del pósit, diseñados para ese uso, como se muestra en la Figura 3.2

29. Cuando termina de realizar su tarea, toma el pósit de donde lo colocó y lo

mueve una columna más a la derecha, de donde a su vez lo tomará alguien más para continuar con el proceso hasta que la tarea alcance el punto donde se acordó se la considerará completa, punto en el cuál alcanza la columna de la extrema derecha del tablero.

Figura 3.1: Tablero kanban

No hay ningún motivo especial para utilizar tarjetas autoadhesivas o los tableros en sí. Pueden utilizarse planchas de cartón a las que se pinchan con chinches tarjetas de cartulina, pueden usarse filas horizontales en vez de columnas o puede utilizarse un tablero virtual de los muchos que se ofrecen por la Internet. El objetivo es el mismo, dar claridad a las tareas pendientes de resolución y entender tanto el estado actual del proyecto como la ocupación del personal.

Figura 3.2: Nota pósit del Tablero kanban

28

Pósit es un artículo nuevo en el diccionario de la Real Academia Española, avance de la vigésimatercera edición. Su definición es (Del ingl. Post-it, marca reg.). 1. m. Hoja pequeña de papel, empleada generalmente para escribir notas, con una franja autoadhesiva en el reverso, que permite pegarla y despegarla con facilidad.

29 En el ejemplo mostrado el rincón superior izquierdo contiene el nombre de la persona responsable, el superior derecho la

fecha y hora de apertura del ítem, el inferior derecho la estimada de finalización y el inferior izquierdo (sin llenar en el ejemplo) la fecha real de finalización. Cuando se usa esta convención a menudo los pósit se copian y se pegan unos sobre otros para tener la historia de su desarrollo.

Boria et al.

Capítulo 3 25

En el método Kanban se limita el número de tareas en cada columna. El objetivo es identificar claramente la capacidad del sistema y balancear la demanda contra la capacidad del equipo. El método Kanban permite comprender el tiempo de tránsito de cada tarea, desde que ingresa al sistema por la izquierda hasta que culmina en la columna de la derecha. (Hay algo de satisfacción personal para cada miembro del equipo en mover la tarea hacia la columna “completado” que motiva a usar kanban). Una vez que se han ajustado los parámetros de producción, el equipo alcanza un ritmo sustentable, es decir, que puede mantenerse indefinidamente, consiguiendo en efecto predictibilidad que otros métodos tardan mucho en alcanzar.

Puesto que esa regularidad se hace presente muy rápidamente, toda obstrucción a esa regularidad es rápidamente visible, potenciando al equipo para detectarlos y, en consecuencia, resolverlos. El impacto que tienen en la regularidad los defectos, las demoras, los cuellos de botella y la mala estimación del tamaño y la complejidad del producto aparecen muy pronto en el tablero. Es fácil relacionar estos problemas con el costo del proyecto, dado que al restringir el número de tareas en cada columna las personas tienen que atender los cuellos de botella para ayudar a resolverlos. De esta manera el método Kanban vincula rápidamente los problemas técnicos del proyecto a los resultados de negocio, sin tener que establecer complicados mecanismos de análisis. Este es un resultado que no se anticipaba al introducir el método pero que es uno de los puntales de su adopción.

Una de las ventajas de Kanban es que al producir con calidad y a tiempo se genera confianza en los clientes, que reciben productos con regularidad y con la calidad esperada. Otra ventaja es que, al hacer que el equipo mejore constantemente sus procesos para evitar demoras, las entregas se hacen más frecuentes y con mayor funcionalidad. A su vez, esta situación hace que el equipo se sienta más a gusto y ponga más ahínco en mejorar el flujo de trabajo.

Para implementar Kanban el primer paso es identificar el flujo de trabajo, lo que se conoce como la “cadena de valor” que ya viéramos en el Capítulo anterior en las discusiones sobre el método de mejora de procesos a seguir. Dado el origen común de esos métodos (las diferentes versiones de calidad total) y el hecho de que el método Kanban es una adaptación al desarrollo de software de una técnica con el mismo nombre (kanban) derivada del TPS, a su vez del mismo origen que los anteriores, las coincidencias no deben sorprendernos. Kanban usa cinco principios para crear comportamientos en las organizaciones donde se lo aplica: Visualizar el Flujo de Trabajo; Limitar el Trabajo en Realización; Medir y Manejar el Flujo; Explicitar Políticas de Proceso; y Utilizar Modelos

30 para Reconocer Oportunidades de Mejoras.

El primer punto saliente en la construcción de un tablero kanban para el flujo de trabajo es que la columna de la derecha corresponde al estado de tarea completada. Antes de que se pueda proseguir con la implementación del método es imprescindible que el equipo, junto con el proveedor de información (más adelante llamaremos a este rol ‘Dueño del Producto’ siguiendo la costumbre introducida por [SCHWABER & BEEDLE, 2002]) defina los atributos necesarios de una tarea para que se la considere completada. Por ejemplo, la densidad de defectos remanentes conocidos, o los estados por los que ha debido pasar (inspecciones, pruebas unitarias, etcétera).

La columna de la derecha está así bien identificada y su sentido es claro. La columna de la izquierda es donde se colocan los pendientes. Entre medio hay tantas columnas como el equipo quiera y que tengan significado para ellos. Por ejemplo puede que la siguiente columna a la derecha de “Pendientes” sea “En Análisis”, la que le sigue a esta sea “Analizado”, la siguiente “En Desarrollo”, la siguiente “Listo para Prueba”, la siguiente “Listo para Integración”, y así sucesivamente. Por otra parte puede que un equipo determine que todo lo que necesitan saber se contiene en tres columnas: “Pendiente”, “En Desarrollo”, “Listo para Entregar”. Las decisiones que así se toman tienen repercusiones muy grandes. Por ejemplo, la primera elección sugiere que dentro del equipo hay especialidades que van pasando la tarea de una a otra. La abren los analistas que la pasan a los desarrolladores que la pasan a los testers. La segunda sugiere que el equipo trabaja en células integradas donde todos esos roles se cumplen dentro de la célula. Un caso extremo poco recomendable es el de la célula unipersonal.

Recomendamos la adopción del tablero más complejo con divisiones técnicas del trabajo, por lo menos mientras no se incorporen técnicas especiales como programación por pares y diseño dirigido por las pruebas. El motivo es que las diferentes etapas dentro del proceso permiten avizorar mejor estados intermedios, de modo que los atrasos potenciales y los cuellos de botella puedan ser rápidamente detectados y la duración de las tareas mejor estimadas. Además, este esquema de trabajo es muy flexible y permite crecer con facilidad hacia otros

30

Los modelos a que hace referencia Anderson son más generales que los que presentaremos en el próximo Capítulo, pero dada la apertura que sugiere el texto ya citado, los autores no encontramos contradictorio utilizar el MPS para introducir mejoras de proceso compatibles con Kanban.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

26 Capítulo 3

métodos, en particular Feature Driven Development, que recomendamos más adelante como un método ventajoso para proyectos grandes con equipos de mucha personas. Por si estas dos características no fueran suficientes, otra ventaja consiste en que los estados intermedios de pase

31 permiten al proyecto contar con el

apoyo de grupos organizacionales, como Aseguramiento de la Calidad, que puedan tomar esos traspasos como referencias e intervenir sin violencia en la calidad del proceso.

Hasta acá lo descripto constituye generalidades del uso de un tablero kanban. Para que sea una aplicación del método Kanban, es necesario limitar el número de pósit en cada columna. Si en una columna hay tantos pósit como indica el límite, generalmente anotado en el tope de la columna junto a su nombre, no se puede pasar un pósit más a esa columna. Esto implica que aunque se haya terminado el paso anterior para una tarea la columna está bloqueada y no se puede hacer avanzar el pósit correspondiente. Claramente las personas que quedan ociosas notan esto, las personas que están trabajando en las actividades de la columna saturada notan esto y la cadena de producción se detiene. En esta situación se detecta un cuello de botella, que debe ser resuelto por los mismos miembros del equipo. A diferencia de la gran mayoría de los métodos existentes, Kanban no es prescriptivo. En eso lo sigue Scrum, pero Kanban es todavía menos prescriptivo que Scrum. El equipo elige, adapta y adopta sus procesos según su necesidad.

Lo que diferencia notablemente a Kanban de los otros métodos ágiles es su flexibilidad, pero sobre todo es la limitación del volumen de trabajo en cada etapa. Es esta restricción la que pone en juego los mecanismos de adaptación, y en consecuencia los mecanismos de mejora, que en otros métodos quedan a cargo de reuniones especiales llamadas “retrospectivas”. Lo que en los demás es una visión de lo que pasó, en Kanban es la necesidad lógica de operar sobre lo que está pasando.

Siguiendo nuestra opción de mejora de procesos que definiéramos en el Capítulo anterior, utilizaremos los mismos preceptos que usa Anderson para Kanban puesto que son compatibles: Foco en Calidad, Reducción del Trabajo en Desarrollo, Entregas Frecuentes, Balanceo de la Demanda contra la Producción, Fijación de Prioridades, y Atacar las Fuentes de Variación para Mejorar la Predictibilidad. La receta de Anderson no sólo es compatible con la de LS que eligiéramos antes, ¡Es totalmente compatible con el MPS! En el Capítulo 5 expandiremos las técnicas de Kanban utilizando el ejemplo de Tahini-Tahini.

3.3 Scrum: Organizando el sistema para un estado de equilibrio orgánico

Scrum no debe ser considerado un método, a pesar de que tiene reglas claras que se deben seguir, porque deja muchas resoluciones abiertas para que el equipo del proyecto las resuelva. Al describir Kanban dijimos que después del mismo, Scrum es el enfoque ágil menos prescriptivo. Esto es cierto, pero la gran diferencia entre el número de reglas de uno y otro (3 contra más de 10) hace que estén cerca pero no demasiado.

Para implementar Scrum en una organización hay que hacer cambios profundos antes. Con Kanban los cambios originales son solo tres: reflejar el flujo en un tablero Kanban, limitar el número de tareas por etapa y mejorar el flujo total haciendo las alteraciones que demande el proceso. Kanban se adapta fácilmente a cualquier proceso subyacente, porque las entregas rápidas pueden ser internas al equipo y la participación de los involucrados externos al mismo es deseable pero no indispensable. En cambio, en Scrum es indispensable restructurar la organización en varios sentidos: Primero se tiene que contar con una persona que conozca el producto, o tenga la visión del producto, y que esté disponible para trabajar con el equipo durante la duración del proyecto. La dedicación que se requiere no es de tiempo completo, pero esta persona debe permanecer accesible para que el equipo pueda tomar decisiones de negocios conjuntamente con ella. Asimismo, está persona debe poseer la suficiente autoridad para que sus decisiones no se revean

32. En el lenguaje de Scrum esta persona se

conoce como el “Dueño del Producto”.

En segundo lugar, el personal debe ser dividido en equipos interdisciplinarios pequeños, auto-organizados, que cuentan con la supervisión y colaboración para allanar problemas de parte de un especialista, llamado en Scrum el Scrum Master. El Scrum Master se encarga de que se sigan los procesos de Scrum y de mantener la relación del equipo con el medio que lo rodea. En ese sentido, es mucho más un perro pastor que cuida del ganado que un gerente que dirige las operaciones. La auto-organización del equipo es fundamental en Scrum. El Scrum

31

En inglés, “hand-off” entre un rol y el otro. 32

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.

Boria et al.

Capítulo 3 27

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 quién fija las reglas de colaboración y producción, 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 pequeños, no una funcionalidad excesiva sino pequeñas parcelas de trabajo que tengan sentido para el negocio y puedan ser ordenadas por su prioridad, fijada en conjunto entre el usuario Dueño del Producto y el Scrum Master. Se fijan objetivos, llamados del release, que establecen plazos de larga duración (meses) para la entrega del producto completo. Luego el tiempo de duración del proyecto se parcela en hitos pequeños, llamados Sprints. Cada Sprint tendrá una duración fija, usualmente entre 1 y 4 semanas. Los equipos de trabajo elegirán de la lista de requerimientos priorizados (Backlog) aquellos que entran en el Sprint (Sprint Backlog). El equipo invierte un día de trabajo en planificar el Sprint. Hay reglas claras sobre como planificar, y varios métodos que han sido probados y adoptados por muchos equipos. Fundamentalmente, la estimación se basa en la historia de trabajo del equipo, la velocidad con que se construye en general el producto.

El equipo se reúne todos los días por un período corto, no más de quince minutos, para revisar las tareas del día anterior y el plan del día. El Scrum Master dirige y facilita esta reunión. Es a estas reuniones que se denomina Scrum y que dan el nombre al método.

El objetivo de un Sprint es entregar una parte del producto al finalizar cada Sprint, lo que se manifiesta por una demostración hecha al cliente. El fragmento de funcionalidad que se entrega el cliente se llama “sashimi”, por analogía con el plato de pescado crudo japonés donde cada trozo es un plato en sí mismo pero también una componente del plato total. Cada demostración permite al cliente entender mejor el producto que pidió, y hacer los ajustes necesarios para obtener el mejor retorno de la inversión 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 críticos: “momentos de verdad”, por analogía con el mismo concepto en Marketing

33.

33

[CARLZON, 1989] Moments of Truth.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

28 Capítulo 3

El primer síntoma de que no debemos implementar Scrum es el del Dueño Desconocido. Se manifiesta cuando se inicia el proyecto usando las herramientas tradicionales de planificación y no se identifica al Dueño del Producto. Esto tiene inmediatas consecuencias. Al no tener la guía de un usuario CRACK

34, el proyecto adolecerá

de falta de visión del producto, falta de claridad en las prioridades, mala conducción del “juego de planificación” al entrar a los Sprints, que serán 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 utilizándolo. Hay que volver a métodos 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 Dueño del Producto. Si esto es imposible pero se puede generar un “sosías” interno a la empresa, siempre fuera del equipo, ésta es una solución aceptable. NUNCA un miembro del equipo puede ser Dueño del Producto, puesto que esto origina conflicto de intereses.

Aun cuando haya un Dueño del Producto, éste puede adolecer de diferentes problemas: falta de visión del producto, prioridades poco claras, ser muy inflexible o tener los objetivos poco claros. En todos los casos es deseable intentar educar al Dueño del Producto para conseguir el comportamiento deseado, o si esto no es posible, cambiar de Dueño del Producto. Sin un Dueño del Producto CRACK, el equipo queda a la deriva y la calidad del producto se compromete mucho.

No sólo el Dueño del Producto puede ser la causa del desbarrancamiento del proyecto. También es necesario que el Scrum Master conozca los procesos y sepa cómo actuar en cada caso. El Scrum Master es responsable de que se elija el juego de planificación correcto, salvando los problemas cuando falta historia del equipo. Si bien el Dueño del Producto y el Scrum Master participan en ese juego, su intervención es limitada. El Dueño 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 reunión, pudiendo pedir precisiones (por ejemplo, la definición de “completo”) pero no influir en la elección de valores. De todos modos, es útil recordar que la estimación 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 definición correcta de cuando un producto está “completo”. Si el Scrum Master es demasiado flexible puede ceder ante presiones del Dueño del Producto, como cambios en medio de un Sprint, que no son beneficiosos para nadie. Si el Scrum Master es demasiado rígido, puede degenerar en dirigir los Scrums, tratándolos en efecto cómo reuniones de avance. El Scrum Master tiene que impulsar asimismo la mejora de procesos, a través de retrospectivas frecuentes o cuando la ocasión 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 duración de los Sprints en una retrospectiva.

Un problema común es que se entienda “ágil” como codificar y arreglar. No hay documentación ni siquiera mínima, faltan métodos de ingeniería de software en la confección de modelos o en la prueba de los programas. Se olvidan todas las buenas prácticas 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 organización 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 frágil ante cambios.

Otra crítica con fundamento del método Scrum es que no hace referencia a métodos o técnicas de ingeniería a ser utilizadas en medio del Sprint. Por supuesto, esto es así por diseño, pero sigue siendo cierto que se deben adoptar herramientas de ingeniería de software que apoyen las tareas del equipo. Un equipo ágil reconoce técnicas ágiles, como Test Driven Development (TDD), refactoring, requerimientos iterados, y otras igualmente útiles, y las aplica. En lo que sigue veremos algunas de estas técnicas, de uso común en equipos de Scrum.

3.4 XP: Inspecciones, Diseño, Cooperación, y Muchas Pruebas

Extreme Programming, usualmente conocida como XP, es un conjunto de técnicas condensadas de la ingeniería de software tradicional, adaptadas para su uso en equipos pequeños que iteran rápidamente sus ciclos de desarrollo. De hecho, Kent Beck

35, el pionero de XP, fue de los primeros en sugerir iteraciones cortas con

34

Usuario “CRACK” (collaborative, representative, authorized, committed and knowledgeable) que traducido es colaborativo, representativo, autorizado, comprometido y con conocimiento [BOEHM e TURNER, 2003].

35 BECK, K., 2000, Extreme Programming Explained, Addison-Wesley.

Boria et al.

Capítulo 3 29

participación intensa del usuario en las mismas. En el libro citado, Beck explica su posición “extrema”, diciendo que si las técnicas de la ingeniería de software son buenas, hacerlas todo el tiempo es mejor.

XP se apoya en cuatro valores: Comunicación, Simplicidad, Retro-alimentación y Coraje. De esos cuatro valores Beck deriva cinco principios, más prácticos y cercanos a la producción que los valores: Retroalimentación rápida, para acelerar el aprendizaje; Presunción de Simplicidad, para buscar la solución más simple; Cambio Incremental, para reducir el impacto del cambio en las organizaciones; Adopción 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 ingeniería de software, centrándose fundamentalmente en cuatro actividades: Codificar, Testear, Escuchar y Diseñar. 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 diseña para poder seguir codificando, testeando y escuchando indefinidamente”

36. Beck ofrece un repertorio de técnicas que funcionan bien en equipos chicos y han

sido ampliamente adoptadas, muchas veces con éxito, pero también a veces criticadas.

Las técnicas de Beck son: El Juego de la Planificación; Pequeñas Entregas (de producto); Metáfora; Diseño Simple; Prueba; Refactoreo; Programación en Parejas (o de a Pares); Propiedad Colectiva (de los productos por el equipo); Integración Continua; Semana de 40 Horas (hoy llamada Paso Sostenible); Cliente Presente; y Estándares de Código. Puesto que son de uso común en muchas aplicaciones de ágil, sea que adoptan conscientemente XP o no, daremos acá una síntesis de su contenido, intentando explicar lo suficiente como para que aquellas que despierten el interés del lector puedan ser investigadas en la bibliografía ofrecida. Recomendamos al lector [KNIBERG, 2007], Scrum and XP from the Trenches. How we do Scrum, por su estilo práctico y abarcador.

El Juego de la Planificación.

Beck intenta balancear las necesidades del negocio con las necesidades (técnicas) del equipo. Ninguna, para él, debe dominar a la otra. Propone un diálogo donde la organización cliente define el alcance, prioridades y la programación y composición de las entregas (releases) de código. Michael Cohn, en [COHN, 2006], y Anderson en [ANDERSON, 2011], describen en detalle una variante que se llama el juego de planificación. Básicamente es similar a lo que Barry Boehm hizo popular como “Wide Band Delphi” en [BOEHM, 1981], es decir, una estimación 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, reduciéndola en cada iteración mediante la justificación de cada uno sobre su pronóstico. Es importante que los equipos discutan con el cliente sus estimaciones, pero no para que el cliente arbitrariamente fije la duración de las tareas. El equipo técnico tiene la responsabilidad de alertar sobre consecuencias de elegir ciertos diseños o elementos técnicos.

Entregas Rápidas

Todas las entregas en XP se hacen en períodos cortos, idealmente cada dos semanas. Esto mantiene al cliente interesado y comprometido, puesto que la retroalimentación así obtenida aumenta el valor del producto.

Metáfora

En vez de esperar que la arquitectura brinde cohesión a la estructura del producto, XP utiliza una “metáfora”, una explicación 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 automática’. 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 diseño.

Diseño Simple

Según Beck, el mejor diseño es el que mejor se ajusta a los casos de prueba, los ejecuta todos, no tiene lógica 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. Traducción de los autores.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

30 Capítulo 3

Prueba Dirigiendo el Desarrollo

En XP cualquier característica del programa que no tenga una prueba asociada, no existe. Los programadores escriben sus pruebas para ganar y mantener la confianza en el código que generan, los clientes lo hacen con el mismo motivo. Al ir acrecentando la cantidad de pruebas asociadas con el código es imposible romper el código al introducir cambios sin que los defectos salten a la vista. De hecho, se realiza la prueba de regresión permanentemente. En XP el programador primero escribe el caso de prueba del cambio que quiere implementar, y lo ejecuta contra el código actual, o sea sin modificar, asegurándose que no pasa. De ese modo prueba el caso de prueba. Luego escribe el código correspondiente hasta que el caso de prueba no encuentra defectos.

Figura 3.4: Ciclo de Desarrollo de XP

Refactoreo

Este enfoque de cambios pequeños puede tener un efecto indeseado, puesto que optimiza localmente el código, pudiendo anular otras optimizaciones locales y perdiendo de vista la optimización global A veces es necesario realizar cambios al diseño porque surgen ciertos patrones de comportamiento indeseables. Una de las tareas a realizar al cambiar el código es investigar la existencia de patrones que no son considerados “buena programación”, como código duplicado, datos vagabundos, y otros más que se pueden encontrar en la página citada en las referencias

37.

Programación en Parejas (o de a Pares)

La programación en parejas o de a pares, como su nombre lo indica, es una técnica en la cual dos o a veces tres personas trabajan juntas en el desarrollo de un segmento del código. Es de ese modo que justifica el éxito de productividad de su técnica particular de programación por pares

38, 39. Son varios los sitios de web que discuten los

pro y los contra de la programación por pares. Los autores nos inclinamos sobre todo a creer que la socialización de la tarea entre dos evita interrupciones y permite a los dos programadores a entrar en “flow” según la definición del mismo en [CSIKSZENTMIHALYI’S, 1991], de modo que la tarea misma ‘fluye’ (de ahí el nombre) y se extrae placer en llevarla adelante. Estudios realizados hace ya muchos años por [DE MARCO & LISTER, 1987] muestran que una persona en un ambiente con baja cantidad de interrupciones es hasta 3,8 veces más 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 día es mucho más “ruidoso” que su contrapartida de fines de los ’80.

37

Véase code smells, http://c2.com/cgi/wiki?CodeSmell 38

Los autores argumentan además que al trabajar en un equipo de dos personas (o tres, si hay un coach), las interrupciones usuales de correos electrónicos, conversaciones en línea y otras distracciones que se pueden notar en los cubículos de los programadores, desaparecen por completo.

39 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.

Boria et al.

Capítulo 3 31

Es poco probable que un par de personas trabajando ostensiblemente acepten interrupciones, mientras que una persona sola en su escritorio es víctima del correo electrónico, el “Messenger” y hasta el celular, en sus distintas variantes. Por si esto fuera poco, las empresas fabricantes de teléfonos se aprestan a agregar más “inteligencia” a sus productos, lo que hará que recibamos más interrupciones todavía: El vuelo de Dorita la Exploradora está saliendo con retraso, mi tía Rosita se compró nuevos zapatos y lo publicó en Facebook, y así sucesivamente. La programación en parejas nos ahorra la humillación de sucumbir a todas esas tentaciones y nos permite gozar del “flow”.

Una variante importante de la programación en parejas es cuando deja de serlo, al participar un tercero. Este suele ser el líder técnico, o el programador más respetado por el equipo. Su participación tiene intenciones formativas. Generalmente participa cuando uno o los dos programadores carecen de experiencia en esta técnica. En lo que sigue la aprovecharemos para juntar estadísticas que se puedan usar en la recolección y análisis de datos de revisiones por pares.

Propiedad Colectiva (de los productos por el equipo)

Si dos personas pueden participar en el evento de programación, y estas parejas pueden rotar, ¿Quién es el dueño 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.

Integración Continua

Parte de la posibilidad de que se pueda tener propiedad colectiva del código es el hecho de que la calidad del mismo se pone a prueba todo el tiempo, dejando en evidencia cualquier defecto casi tan rápido como se incurre en él. Para empezar, el diseño guiado por las pruebas inicia un camino basado en la calidad como meta, y para seguir la integración continua aprovecha la generación de los casos de prueba para que se verifique cada cambio contra la base de datos de prueba, asegurando que no hay regresión de defectos anteriores. Esto implica que cada nuevo añadido de código es integrado tan pronto como se pueda al producto en evolución. Para concluir, el equipo presenta con regularidad en períodos cortos su producto parcial al cliente, de modo que la retroalimentación es frecuente y se hace sentir. A menudo se generan reglas en los equipos relacionadas con esta integración continua, que requiere un software especializado y una disciplina de gestión de la configuración 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 más 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 participación del cliente. Ya vimos (nota 32 de este capítulo) 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, aún más que para Scrum. Durante el Sprint, en Scrum el Dueño del Producto está ausente y sólo participa convocado por el equipo. En XP es parte del equipo, convive con ellos. Esto permite validar ideas rápidamente y contar con una voz que permita seguir caminos alternativos cuando sea necesario.

Estándares de Código

El último punto que tocaremos acá es sobre estándares de código. Si los programadores eligen el código que quieren modificar, trabajan con distintos colegas varias veces por día, y el código tiene que ser leído y entendido por todos, más vale que haya un único estilo de programación. Hace muchos años que [KERNIGHAN & PLAUGER, 1974] hablan del estilo de programación. Nosotros aconsejamos mucho más que un estándar. El equipo tendría que leer el libro sobre estilos de programación y adoptar sus propias reglas. La manera de introducirlas es siendo fiel a la programación por parejas, con o sin el “coach” presente.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

32 Capítulo 3

Escalamiento

Casi desde el principio de su existencia, la ingeniería de software se ocupa de dos problemas ligados entre sí: “Programming in the Large” y “Programming in the Many”

40. El primer problema es el de atacar proyectos

grandes. El concepto de ‘grande’ es relativo a la media que produce la organización. Si una organización habitualmente genera 100.000 líneas de código por año, un incremento de 10.000 líneas para un año es un problema logístico pero no uno que cambia radicalmente la naturaleza del asunto. En cambio, para la organización que habitualmente genera 6.000 líneas de código anuales, 10.000 líneas más pueden resultar en un salto cuantitativo imposible de absorber. Por supuesto, una parte de la solución consiste en agregar gente, lo que se conoce como “Programming in the Many”. Como es conocido, el aprendizaje de la programación 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 métodos á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 método Crystal Clear es en realidad una familia de métodos crecientemente más complejos. Las ideas de Coad, en cambio, están basadas en sólidos argumentos arquitectónicos; las usaremos porque lo enunciado hasta aquí no es útil para sistemas grandes y complejos a ser desarrollados entre muchos.

Ninguno de los tres métodos esbozados en este Capítulo “escala” bien, en el sentido de que a medida que es necesario un equipo de mayor tamaño para poder entregar un sistema más grande y complejo en tiempos de mercado razonables, todos ellos comienzan a perder propiedades que son manifiestas cuando el equipo es pequeño. Kanban es aquél que por tener menos reglas también tiene menores expectativas, pero ocurre que su propio objetivo, el de reducir el número 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 métodos ágiles con alta escalabilidad. Utilizando algunas técnicas de alto impacto extraídas de las buenas prácticas de ingeniería de software, FDD consigue armonizar el uso de modelos y planificación con prácticas á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 información del desarrollo del modelo y otras actividades que pudieran haber tenido lugar respecto a la identificación de requisitos, el equipo construye una lista de particularidades y características del producto (“features”) expresándola como funciones formuladas bajo un patrón <acción> <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 función’.

Cada una de estas funciones es suficientemente pequeña 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 sólo se dividan en otras más pequeñas cuando se intuye que en dos semanas no van a poder ser implementadas, de otro modo se las mantiene en ese nivel de abstracción.

Ahora se puede seguir el modelo para hacer una planificación rápida y poner a trabajar en paralelo varios equipos que coordinen sus interfaces a través del mismo modelo, asignándoles las funciones de la lista. Mediante este simple procedimiento se ahorran muchísimos 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 definición más parecida a los procesos típicos de las organizaciones grandes. Puede que sea porque los autores quieren una clara definición de los pasos y los roles, puede que haya sido una exigencia del ambiente para conseguir su adopción en las primeras implementaciones. El caso es que los cinco procesos que mostraremos en la Figura 3.5 están perfectamente definidos, así como los roles de los actores que los ejecutan.

40

[BORIA, J., 1987, Ingeniería de Software, Kapelusz]

Boria et al.

Capítulo 3 33

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 dotación del proyecto.

El segundo rol fundamental es el de Arquitecto en Jefe. Este rol es la contrapartida técnica del Gerente. Si bien el Arquitecto es responsable del resultado del diseño, sus tareas incluyen facilitar talleres que permitan a los expertos en el dominio y miembros escogidos del equipo diseñar las características del producto. Sin embargo, el cargo implica tener la experiencia necesaria para poder realizar la decisión definitiva sobre el diseño arquitectónico. 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 técnicamente 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 simultáneamente, lo que puede traer conflictos sobre el uso de recursos. El Gerente de Desarrollo tiene como principal tarea resolver esos conflictos utilizando criterios técnicos y conocimiento de las necesidades del cliente. A menudo el rol es adjudicado al Gerente de Proyecto o al Arquitecto en Jefe. Nótese que el rol demanda conocimiento técnico, 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 múltiples profesionales, de hecho uno por cada equipo que se forma, y su nombre es Programador en Jefe

41. El Programador en Jefe es una persona de grandes habilidades técnicas que ha

pasado por varias iteraciones del ciclo de vida de desarrollo varias veces y es capaz de liderar un grupo pequeño. Responde al plan general del Arquitecto y coordina con el Gerente de Desarrollo y los demás Programadores en Jefe.

El quinto rol es el de los que hacen el desarrollo cotidiano, a lo que se llama Dueño de Clase en FDD. Cada Dueño de Clase es un programador de mérito (en FDD no hay lugar para la mediocridad) y tiene a su cargo el desarrollo, prueba y documentación de una parte del producto final, siguiendo la guía 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 más impacto tenga en la calidad final del producto y el éxito del proyecto. Además 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 características de CRACK que ya mencionáramos (ver la nota 34). Sin disponibilidad de estos usuarios es muy difícil que el equipo concrete un producto exitoso.

41

Los equipos de “Programador en Jefe” están descriptos por [BROOKS, F. P., 1995] siguiendo la implementación que en IBM hiciera Harlan Mills.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

34 Capítulo 3

Una vez que los protagonistas quedan determinados para todos los roles, con la posible excepción de los Dueños 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 planificación lo es todo”, el modelo no es lo que importa en esta etapa. Es mucho más importante usar la construcción del modelo para construir una relación 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 quiénes son los expertos en el dominio, con qué apoyo pueden contar y cuáles son las ‘grandes ideas’ que guían al cliente.

De todos modos, si no hay un producto no hay un criterio de finalización, y como ya dijimos, FDD tiene muy claramente definidos cada uno de ellos para cada uno de los cinco procesos, a diferencia de los métodos anteriores que dejan la definición del criterio de finalización 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 participación de los Dueños de Dlase, éstos debieran rotar entre los equipos para ir empapándose de los conocimientos de los expertos y tratarlos personalmente.

FDD tiene su propia descripción 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 artículo de [ZAHNISER, 1995] en su sitio de internet, para tener una idea clara de las opciones, técnicas 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 proceso, construir la lista de funciones

42. En este paso el equipo se reduce a los Programadores en Jefe. Partiendo

de la partición arquitectónica inicial resultante del primer paso, los Programadores en Jefe, o el equipo de la lista de funciones, construye la lista de las características que se van a implementar. El proceso es iterativo. Se juntan alrededor del diseño arquitectónico, para el cual ya hay una lista preliminar de tareas asignadas, y las reasignan en áreas. Cada área es un conjunto afín 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 más detallado y reducido de la funcionalidad de un área.

Por ejemplo, al nivel más alto, la arquitectura tiene una componente con el nombre “Administración”, debajo de la cual se listan ciertas actividades: administrar clientes, cuentas, revisiones, arreglos, etc. Al definir áreas, administración global puede ser una de ellas, conteniendo una lista de funciones relacionadas a la vez con todas las otras áreas. Habría asimismo áreas para clientes, cuentas y ajustes, la última categoría siendo una síntesis de las dos actividades listadas en la arquitectura como separadas. Es decir, la creación 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 función. Por ejemplo, la actividad de administrar clientes en el área de administración 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 raíz hasta el nodo más 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 descripción arquitectónica 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: Ejecución y Código.

El lector interesado puede combinar las técnicas de FDD con las sugeridas en el libro “Applied Software Architecture” [HOFMEISTER, 1999] para obtener resultados superlativos en aplicaciones críticas.

42

Estamos usando funciones, o características, para traducir el original en inglés “features”.

Boria et al.

Capítulo 3 35

Figura 3.6: Árbol de Funciones derivada de la Arquitetura

El tercer paso de FDD es la aplicación del proceso de hacer el plan del proyecto completo contemplando cada función. El Gerente de Proyecto, el Gerente de Desarrollo y los Programadores en Jefe se reúnen con la lista de funciones delante de ellos y asignan cada una de las funciones a los programadores, que se convierten así en Dueños de Clase. Cada programador puede ser dueño 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 Dueños de Clase.

La asignación de las funciones tiene en cuenta muchísimas variables, tales como la prioridad del cliente para la implementación de áreas, la interdependencia de las funciones, su complejidad y su tamaño, la facilidad con que se pueden probar dependiendo del orden de implementación 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 ocupación global del proyecto sino asociada a cada tarea de la lista, busca las clases asociadas a cada una y a través de ellas reconoce los programadores que van a participar. Si hubiera nuevas clases las asigna. Este proceso se aplica a una o más 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 diseñar el trabajo. Esto implica desarrollar la documentación que le permita al Dueño de Clase modificar, extender o crear el código correspondiente sin intervención de expertos en el dominio. En el caso contrario, el Programador en Jefe pide ayuda a los Expertos para realizar una revisión del dominio correspondiente al conjunto de funciones a implementar.

El Experto, o los Expertos, recorren el dominio en una presentación hecha al equipo donde cubren las reglas del negocio, los algoritmos de aplicación 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 definición de los ítems de configuración, 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 Dueño de Clase toma sus clases y las actualiza para reflejar los cambios en el modelo y añade los comentarios, el prólogo y si se acuerda hacerlo así, el invariante que resulta de la ejecución de los métodos de la clase

43. Finalmente el equipo revisa el diseño resultante

para garantizar su completitud, consistencia y que se puede realizar según el plan. Este es el criterio de salida de la fase

44.

El último paso es la fase de construcción de cada paquete. El paquete ha de haber quedado definido en el paso anterior. En esta fase se escribe o modifica el código necesario, se hace una inspección de código y se realiza la prueba unitaria, para comprobar que el producto que se va construyendo no pase a la línea base del código con

43

Para ver el uso del invariante de clase en ingeniería de software, ver [BORIA, J., 1987] o para un tratamiento más profundo y sistemático, [GRIES, D., 1987]

44 Usamos indistintamente fase, paso y proceso para referirnos a las cinco fases de FDD.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

36 Capítulo 3

defectos conocidos. Al aprobarse el producto se lo integra siguiendo los procedimientos habituales de gestión de configuración.

3.6 Resumen

Este Capítulo ha cubierto cuatro de los mejores métodos ágiles que se usan en la disciplina. Es habitual que se tomen prácticas de uno y se las utilice en otro. Tan es así que existió un nombre propio para la combinación de Scrum con XP, XBREED, que ya no denota nada (el sitio ha sido ocupado por un abogado especialista en daños por accidente). Kanban es especial para empezar un proceso de mejoras. La visibilidad que brinda y la bajísima 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 adopción de mejoras. Scrum sube las exigencias, pero su reputación está justificada: Es un método que acelera dramáticamente la producción de software y genera sistemas de buena calidad. Como también deja mucha libertad al equipo al respecto de las técnicas de ingeniería, es muy frecuente que se le adopte junto con XP, RUP u otra (así llamada) ‘metodología’. Todas estas prácticas son sumamente útiles pero escalan relativamente mal: puesto que los límites al crecimiento son muy rígidos, la adopción de un método más 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 código 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 podríamos haber escogido Crystal Clear. FDD es para los autores el formato ideal para encajar con los modelos de madurez inspirados en CMM

45, tales como el

MPS o el CMMI.

45

[PAULK, M., WEBER, C., CURTIS, B., 1994] siguiendo a [HUMPHREY, W., 1989]

Boria et al.

Capítulo 4 37

CAPÍTULO 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 mayoría el negocio es producir mejor que la competencia a menor costo. Utilizan su conocimiento del dominio para mejorar la satisfacción de sus clientes y ampliar su cartera, haciendo cada vez más caro el costo de transferencia hacia productos competidores y reteniendo y ampliando su cuota de mercado. En ese contexto los costos de desarrollo son más importante que los precios, porque la falta de monopolio hace que la competencia intente entrar en el mercado bajándolos.

Para la empresa pequeña 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 términos que la persona de la calle puede entender, el ingeniero de software tira una de cada cinco cosas que hace. Si fuera una lavandería, una de cada cinco prendas que lava debe volver a la lavarropas.

Figura 4.1: Relación del Retrabajoo vs. Nivel de CMM [DIAZ & KING, 2002]

Las pequeñas y medianas organizaciones no pueden soportar un costo tan excesivo. Como ya explicáramos en el Capítulo 2, cuando propusimos el uso de LS (Lean Simplified) como el método de acercamiento al problema, es necesario identificar las fuentes de defectos y removerlas. Si bien es posible hacer uso de LS sin ningún otro apoyo, la búsqueda de los defectos es un arte no menor. La mayoría de nosotros nos encontramos más cómodos siguiendo una guía que nos oriente en el sondeo de la organización. La gran contribución de Watts Humphrey [HUMPHREY, 1989] consiste en la creación de un modelo de estados que ofrecen precisamente esa guía

46.

De hecho, los modelos de estado son anteriores al trabajo de Humphrey. En un trabajo eminente47

, Richard Nolan introduce un modelo de estados para la gestión del recurso de cómputos. Como preludio, Nolan describe diferentes usos de los modelos de estados, en campos tan diversos como la astronomía (la formación de estrellas, galaxias y sistemas solares), biología, ecología y desde el siglo XIX la economía de los países. En particular hace referencia a dos criterios para la ‘buena formación’ de modelos de estados, descriptos por Simon Kuznets

48: los

estados deben estar bien definidos y ser claramente distintos y demostrables empíricamente; y la relación analítica 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 sólido modelo de estados.

46

Una anécdota que circulaba en TeraQuest a finales de la última década del Siglo pasado relataba que Watts Humphrey había tenido su Eureka a bordo de un avión que lo llevaba de vuelta a Pittsburgh desde un seminario del Instituto Juran. Fervoroso admirador de las teorías de Deming, Juran y Crosby, Humphrey se puso como objetivo eliminar la dificultad de aplicar las técnicas de la calidad total, incluyendo las cartas de comportamiento de procesos, a la ingeniería de software. Su revelación vino de comprender la necesidad de establecer procesos comunes que puedan ser analizados estadísticamente. De ahí su modelo de estados.

47 [NOLAN, R., 1973]. Nótese el homenaje implícito a este artículo como fuente de inspiración en el nombre del libro de

Humphrey op.cit. 48

[KUZNETS, S., 1966]

Nivel

CMM

Porciento

de

Retrabajo

Efectividad

de la

Contención

en Fase

Densidad de

Defectos

Únicos

Reportados

por el Cliente

por KSLOC

Productividad (x

factor relativo

al nivel 2)

2 23.2% 25.5% 3.20 1 x

3 14.3% 41.5% 0.90 2 x

4 9.5% 62.3% 0.22 1.9 x

5 6.8% 87.3% 0.19 2.9 x

Tabla 1: Desempeño de Proyectos de los Sistemas de Decisión de

General Dynamics Contra el Nivel CMM

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

38 Capítulo 4

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]. Históricamente la mayoría de los enfoques sobre calidad han desarrollado ‘normas’ de buenas prácticas a ser aplicadas. Si bien éstas cumplen una función importante al difundir métodos probados y ayudar a enfocar esfuerzos en calidad, se centran en su cumplimiento y no en el desenvolvimiento de la organización.

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 más que la suma de las partes. En cambio, un modelo, cuando se lo interpreta bien, además de indicar las mejores prácticas también enseña los posibles ordenamientos al presentar la secuencia más lógica de implementación. Los modelos más útiles tienen formas de evaluar el grado de implementación que una empresa lleva del mismo. El MPS-SW no es una excepción, 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, además de sugerir los próximos pasos. La desventaja de un modelo es que los caminos de implementación son múltiples y dependen de la empresa en cuestión.

En cierto modo la articulación de Lean Simplified con un modelo del tipo del MPS es la herramienta ideal, puesto que permite identificar los cambios más significativos con LS y utilizar recomendaciones del modelo para llevarlos a cabo. En tanto que si bien las normas son mucho más fáciles de interpretar e implementar, el efecto sinérgico que poseen es muy escaso y difícil 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 través de la mejora continua. En particular, “Se intenta que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, si bien con especial atención a las micro, pequeñas y medianas empresas. También 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 ingeniería de software de forma adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para definición, evaluación y mejora de procesos de software”

49.

Figura 4.2: Organización del MPS.BR [SOFTEX, 2011l]

En particular, el MPS se ajusta al nomenclador internacional de guías. Hay una Guía General MPS de Software, MR-MPS-SW [SOFTEX, 2012a], ya citada, cuya lectura es indispensable para entender la génesis

50, los

objetivos del modelo y el modelo de negocios. Hay una Guía General MPS de Servicios [SOFTEX, 2012b], una Guía de Adquisición [SOFTEX, 2011a] y una Guía de Evaluación [SOFTEX, 2012c]. A esta última la volveremos a ver antes de cerrar este capítulo. Hay también una Guía de Implementación para cada nivel [SOFTEX 2011b; SOFTEX, 2011c; SOFTEX, 2011d; SOFTEX, 2011e; SOFTEX, 2011f; SOFTEX, 2011g; SOFTEX, 2011h;] además de las guías de

49

[SOFTEX, 2012a], página 6 50

[SOFTEX, 2012a], página 15, Apartado 7, Base técnica para a definição do modelo MPS

Boria et al.

Capítulo 4 39

implementación para Fábrica de Software [SOFTEX, 2011j], para Fábrica de Pruebas [SOFTEX, 2011k] y para empresas que hacen adquisición de software [SOFTEX, 2011i], uno más con orientaciones para la implementación y evaluación de MR-MPS-SW en conjunto con CMMI-DEV [SOFTEX, 2012d], otro [SOFTEX, 2012e] con un análisis de adherencia del MR-MPS-SW en relación 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 límites 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 propósito 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 través 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 organización debe cumplir con todos los resultados esperados de los procesos definidos hasta e incluyendo el nivel de madurez en cuestión. 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 están por debajo. Puede el lector imaginar a los niveles como muñecas rusas, uno dentro del otro. Además, hay que mostrar que los Atributos de Proceso correspondientes al nivel en cuestión también están 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 también están descriptos en términos de resultados esperados, como los procesos en sí. La Capacidad del Proceso expresa el grado de refinamiento e institucionalización con que el proceso se ejecuta en la organización.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

40 Capítulo 4

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

En el Modelo de Referencia MPS, a medida que la organización evoluciona por los niveles de madurez, la capacidad para realizar los procesos debe mejorar asimismo. Sin embargo, los beneficios en términos de desempeño no surgen del rigor con que se implementan éstos sino de la cultura que se genera por su aplicación correcta y consistente. La capacidad para realizar los procesos queda manifestada por la implementación de los Atributos de Proceso (AP), que a su vez queda manifestado por la implementación de los Resultados esperados de los Atributos de Proceso (RAP). La figura 4.5 describe la arquitectura gráficamente.

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

Los detalles de cada proceso y los Atributos de Proceso de cada nivel serán discutidos en más detalle en los respectivos capítulos 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 Capítulo.

4.4 Los Niveles de Madurez del MPS

Los dos criterios para la ‘buena formación’ de modelos de estados definidos por Kuznets son que los estados deben estar bien definidos y ser claramente distintos y demostrables empíricamente; y que la relación analítica 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 condición 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 evolución de los homónimos anteriores y, por ende, diferentes. Los niveles además están 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 hagámosla madurar a través 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

Boria et al.

Capítulo 4 41

está el monitoreo. Aparece la cultura básica 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 información verídica. El otro resultado importante de este nivel es la institución 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 organización 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 decisión. 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 gestión. El Sistema de Mediciones está alineado con las necesidades de información de los distintos niveles y provee de retroalimentación veraz a los que toman decisiones. Además, la organización encara la protección 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 sólo al adquirente. Se comienza a integrar a los proveedores dentro de la línea de producción con el propósito 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 noción de portafolio de proyectos permite aprovechar al máximo los esfuerzos de la organización.

Del F al E: El valor de lo repetible pasa a ser el valor de lo compartible. La organización 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 quién, es responsable de problemas y se mejora el proceso para incrementar los márgenes del negocio. Estos procesos estándares de la organización permiten compartir las mejores prácticas en aras de mejorar la eficiencia y la efectividad de los proyectos. Acompañados de los correspondientes activos de proceso, cultivan la mejora a través de la experimentación 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 básicas, se forma al personal de manera sistemática para que apliquen los procesos. Los actores son entonces efectivos y eficientes. Los procesos compartidos facilitan las mejoras al facilitar la comunicación y el compartir experiencias. Se trata de una verdadera organización que aprende, la organización 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 integración. Se atiende al ciclo de vida completo del empleado, desde la definición de los cargos a la selección, contratación y preparación del personal. Se crean los equipos tomando en cuenta la eficiencia de su funcionamiento futuro. Se establece y mantiene la coordinación entre equipos. Se identifica el trabajo a realizar y se definen activos que pueden ser reutilizados para incrementar el reuso y bajar los costos. Aún antes de pensar en diseño de detalle se empieza a pensar en arquitecturas de líneas de producto.

Del E al D: La organización pasa a centrarse en la ingeniería. Culturalmente empieza la cultura de los grupos de interés 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 rotación de personal y aumenta la productividad. Los equipos se integran aún más 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 organización se orienta a la proactividad. Comienza la cultura de previsión y calidad total. Puede empezarse a hablar de cero defectos y de la búsqueda 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 reutilización, basándose en criterios de oportunidad y calidad, en este nivel, dada su característica de mirar hacia adelante, se identifican oportunidades de generar activos para la reutilización. De ese modo la organización se vuelca más y más hacia una línea de producción de software.

Del C al B: Nace la cultura del conocimiento profundo a través del conocimiento de la variación y la estabilidad. Aparece la cultura de la previsión mediante conocimiento estadístico. La institucionalización de la gestión cuantitativa tiene a todos pensando cómo podían vivir sin este conocimiento antes.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

42 Capítulo 4

Del B al A: De la previsión se pasa a la competencia con la excelencia. La organización busca limar cada costo, mejorar cada día más.

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 ingeniería. De nada vale la ingeniería sin disciplina. Es por eso que Scrum es tan reverenciado, porque consigue atrapar la imaginación de las personas que creen que al hacer Scrum no siguen procesos. De hecho es sumamente disciplinado y tiene claros procesos, sólo 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 organización) Nivel E: Disciplina de Conocimiento Compartido (aprender de las buenas prácticas y compartirlas) Nivel D: Disciplina de Ingeniería (ordenar el desarrollo a nivel de detalle) Nivel C: Disciplina de Previsión (cultivar el pensamiento proactivo) Nivel B: Disciplina de Calidad Total (entender los procesos críticos cuantitativamente y prever su

comportamiento en un proyecto) Nivel A: Disciplina de la Excelencia (buscar el panteón 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 fábrica para que se puedan entender los procesos cuantitativamente.

4.5 Para que el Cambio Tenga Lugar

Las organizaciones que sobreviven son aquéllas que mejor se adaptan al cambio. La mejora de procesos no es la modificación de los documentos que describen los procesos, es la modificación de la conducta de las personas que deben seguir esos procesos. Esto no es un tema sencillo, por el contrario es algo muy difícil de lograr y requiere profunda atención. Dependiendo del alcance y profundidad de un cambio es más difícil conseguir que llegue a buen éxito. Si el alcance es individual, como cuando hay un cambio menor en un procedimiento, la difusión e instalación del cambio es sencilla y se puede realizar a nivel individual. Cuando el alcance supone la modificación del comportamiento de equipo el cambio es no trivial. El cambio más difícil de lograr es el cambio de cultura. Pocas veces esto resulta en una situación de fácil adopción, siendo que la mayoría de las veces las organizaciones que lo intentan sin la adecuada planificación fracasan. Visto desde el punto de vista del desarrollo organizacional, la maduración de una organización puede o no suponer el cambio de cultura de la misma.

En realidad, no es que el cambio en sí sea difícil, es el cambio orientado a ciertos objetivos lo que es complicado. Si miramos a nuestro alrededor nada permanece estático, inmutable, todo cambia permanentemente. Pero ese cambio espontáneo no es equivalente a mejora. Lo que buscamos es orientar el cambio hacia la mejora de desempeño. Cuando queremos que las personas realicen algo de manera diferente a lo que lo están realizando en la actualidad, el cambio produce una disrupción con lo conocido. Más allá de que las ventajas del cambio sean evidentes, lo familiar es el presente, el ahora. Aun cuando las personas estén de acuerdo con la necesidad del cambio, esto no es equivalente a decir que estén de acuerdo con la dirección que se le quiere dar al cambio

51.

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 mayoría 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

"... Nótese bien que no hay cosa más ardua de manejar, ni que se lleve a cabo con más peligro, ni cuyo acierto sea más dudoso que el obrar como jefe, para dictar estatutos nuevos, pues tiene por enemigos activísimos a cuantos sacaron provecho de los estatutos antiguos, y aun los que puedan sacarlo de los recién 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 sólida. De donde resulta que los que son adversarios de tales innovaciones lo son por haberse aprovechado de las antiguas leyes, y hallan ocasión de rebelarse contra aquellas innovaciones por espíritu de partido, mientras que los otros sólo las defienden con timidez cautelosa, lo que pone en peligro al príncipe ... " El Príncipe, Nicolás Maquiavelo, Capítulo VI, DE LOS PRINCIPADOS QUE SE ADQUIEREN POR EL VALOR PERSONAL Y CON LAS ARMAS PROPIAS (agradecemos a Kival Weber la cita).

Boria et al.

Capítulo 4 43

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 sección al final de este Capítulo.

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 posición que permita a las personas alterar sus prioridades sin violentar su posición en la organización. 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 quiénes 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 transición.

Hablando de la transición, se habla mucho del cambio, pero es indispensable entender que el cambio no es un objeto, sino un proceso, un devenir

52, algo que ocurre a través 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 estaríamos describiéndolo 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 ‘transición’ y es el que causa todos los problemas, en general fruto de malas interpretaciones sobre que es la transición.

La Figura 4.7 muestra una visión muy cándida sobre la transición. En ella la transición es dibujada como una línea recta entre el estado inicial y el deseado. Se supone entonces que la introducción del cambio es gradual y no ofrece problemas mayores.

Figura 4.7: Modelo de Transición Ilusoria (1)

La realidad es que no es posible conseguir el cambio de esa manera. Al menos es necesario tomar en consideración la curva de aprendizaje, como lo muestra la Figura 4.8.

52

Movimiento por el cual las cosas se transforman.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

44 Capítulo 4

Figura 4.8: Modelo de Transición Ilusoria (2)

Esta ilusión está menos errada que la anterior, pero sigue siendo una visión altamente optimista de la realidad. Cuando hay una transición importante lo nuevo es desconocido y debe ser aprendido. El aprendizaje sí sigue la curva S, pero la productividad baja durante el período de aprendizaje. De hecho hay que planificar una estrategia que haga que la transición 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 transición cuando es planificada y llevada adelante con una estrategia adecuada.

Figura 4.9: Modelo de Transición Administrada

Si no se planifica el cambio, si se considera que la adopción está asegurada por la auto-evidencia de su necesidad, lo que probablemente obtengamos sea un gradualismo que mantenga la productividad en baja durante un período que haga el cambio insostenible y el resultado sea la cancelación 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 pequeñas como sea sustentable. La otra es brindar apoyo para la instalación 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 momento que se lo necesita y con los procesos reales

53.

Figura 4.10: Modelo de Transición Sin Administrar

Durante la transición 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 individual no alcanza para conseguir el cambio de la organización. Como dice Peter Senge en [SENGE, 2006],

54

“Cuando pensamos en la organización que aprende, son los equipos los que aprenden”. Dicho de otra manera, no

53

En TeraQuest llamábamos a esto por las siglas JIT, OTJ, JET, (Just in Time, On The Job, Just Enough Training) 54

When we think of a learning organization, it is the teams that learn. Peter Senge, “The fifth Discipline”

Boria et al.

Capítulo 4 45

es hasta que los equipos modifican su comportamiento que los procesos se institucionalizan en una organización. La Figura 4.11 muestra los diferentes pasos, umbrales y estados en el proceso de construcción de compromiso personal con el cambio. Más abajo elaboraremos cómo 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 preparación para la aceptación. Sólo cuando el individuo acepta el cambio puede intentarlo y sólo intentándolo 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 organización, en reuniones mensuales con la alta gerencia, en reuniones de avance de proyecto, en donde sea posible, para que no pueda ser ignorado. Es fácil ignorar un cambio: Basta pensar que no se me aplica. Una vez que no tengo recurso a la ignorancia el próximo 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 confrontación, la resistencia puede ser inútil pero no por ello ser ilegítima. 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 cuáles es bueno recordar que la percepción del hecho es igual al hecho para quién lo percibe. En otras palabras: No importa quién tiene razón, lo percibido es cierto para quién 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 disposición, evitando caer en la confusión y llevándolo a la comprensión.

Que el individuo comprenda el cambio no implica que se sienta favorecido por él. Si no se continúa trabajando con la persona, ésta caerá en la desconfianza. Para ayudarlo a avanzar hacia el próximo paso, la decisión, es imprescindible allanarle el camino, escuchando sus objeciones y reduciéndolas 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 común. Llegado a la decisión la persona está lista para cruzar el umbral del compromiso.

No es lo mismo estar dispuesto a pasar a la instalación 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 instalación sea positiva y no traumática. De ese modo se evita caer en el desengaño y se le permite, ahora a los equipos, avanzar del compromiso hacia la adopción. La adopción puede caer en el desuso o seguir hasta la institucionalización, pero desde el punto de vista de la estrategia del cambio la adopción 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 definición de [CAMERON & QUINN, 2011] para hablar de tipos de

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

46 Capítulo 4

cultura, encontramos que son cuatro dimensiones, como muestra la Figura 4.12, derivadas de los dos ejes sobre los que se apoya una organización

55:

En la dirección horizontal el eje se mueve desde adentro hacia afuera, según el énfasis que la organización pone hacia adentro o hacia afuera de sí. Hacia la izquierda la empresa enfoca sus esfuerzos hacia adentro, mientras que hacia la derecha la atención 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 cómo se toman las decisiones en la organización. La estabilidad o flexibilidad de la cultura depende de si las decisiones dentro de la organización se toman en el punto más alto posible, en este caso representado por la parte inferior del eje; o si se toman en el punto más bajo posible, en este caso representado por la parte superior del gráfico. 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 básicos. Toda organización muestra hasta cierto punto variantes e integraciones de estos, pero para los efectos del análisis 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 rápido a cambios y hay mucha participación colectiva. Son capaces de mantener la calidad de un servicio por mucho tiempo y mejorarla indefinidamente. Es difícil para el clan construir productos muy grandes y complejos. Éste es el arquetipo de cultura que intenta desarrollar el movimiento de los agilistas.

La ‘Jerarquía’ 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 altísima calidad, como las fábricas 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 organización, aunque hay una relación, sino a que la empresa en sí a todos sus niveles opera como un mercado, realizando transacciones internas y externas para

55

La afirmación de que los ejes son dos no es caprichosa, proviene de un estudio de más de 1500 empresas que respondieron con un total de más de 50.000 datos, que analizados estadísticamente mostraron que la cultura se puede explicar por estos cuatro cuadrantes respecto de los dos ejes.

Boria et al.

Capítulo 4 47

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 diferenciación de su personal. En una Ad-hocracia se da más mérito a las invenciones y las patentes que a los ascensos y promociones.

Cambiar de cuadrante, o moverse significativamente en la dirección del cambio, es muy costoso. Para hacerlo conscientemente es necesario hacer un diagnóstico profundo y planificar las actividades con aun más cuidado de lo que enunciamos en el apartado anterior. Es conveniente contratar un consultor que tenga experiencia en el tema y buscar intensamente la participación de todos los involucrados.

4.7 Evaluación 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 retroalimentación positiva. Esta tarea es difícil e ingrata. El responsable o responsables de llevar adelante el proyecto de mejoras es el encargado natural de realizar esta actividad, pero la auto-evaluación no es un camino fácil, así como se desaconseja a los médicos (y a los no-médicos más aun) auto-medicarse o a los programadores verificar su propio trabajo, es necesario contar con una visión externa, objetiva, para verificar el grado de implementación de los resultados esperados.

El MPS tiene una Guía [SOFTEX, 2012c] para la evaluación de los procesos de una organización. Esta guía tiene como objetivo “permitir la evaluación objetiva de los procesos de software de una organización/unidad organizacional

56; permitir la atribución de un nivel de madurez del MR-MPS basándose en el resultado de la

evaluación; ser aplicable a cualquier dominio en la industria de software; ser aplicable a organizaciones y unidades organizacionales de cualquier tamaño”

57. El documento aclara que está destinado fundamentalmente a las

instituciones que realizan evaluaciones o implementaciones del MPS bajo su auspicio. Quizás, como en algunas publicidades de la televisión, debiera advertirse al público que este material es para uso profesional, y que la auto-evaluación es una mala idea.

Para sustentar esta afirmación, veamos el trabajo que tiene que realizar el equipo de la evaluación: examina una planilla, construida por la organización siendo evaluada, para verificar la evidencia de implementación de los resultados esperados para cada proceso y de los Atributos de Proceso, según le sean asignados por el evaluador líder. Entre otras consideraciones, la Guía no permite participar en el equipo a socios de la organización a la que pertenece la unidad organizacional, parientes en grado alguno de los socios de la empresa, o de la dirección de la empresa. El motivo es claro: los conflictos de interés impiden ejercer la tarea de juzgar el grado de implementación de los resultados esperados. En nuestra experiencia, es difícil para los empleados de la organización ser totalmente objetivos, sin por ello juzgar mala voluntad de su parte. A menudo son más exigentes ellos que los evaluadores externos.

Por lo tanto, el monitoreo y control de un plan de mejoras debiera incluir frecuentes y periódicas visitas de una persona experta en evaluaciones para garantizar que no haya sorpresas llegado el momento de la evaluación formal. Estas evaluaciones son aconsejables desde el primer momento. Conocidas como análisis de brecha son evaluaciones cortas que permiten a la organización contar con una versión objetiva de su programa de implementación de mejoras de procesos y a la vez recibir consejos de una persona con mucho más conocimiento y diferentes experiencias.

56

La frase “unidad organizacional” denota el área de una organización que representa el alcance de la evaluación. Puede ser parte de la empresa o toda ella, un área particular (por ejemplo, la fábrica de pruebas) o un sector (nuevos productos). El evaluador líder y el auspiciante de la evaluación de parte de la organización son quienes definen el alcance al contratar la evaluación.

57 SOFTEX, 2012i

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

48 Capítulo 5

PARTE II – Primeros Pasos

CAPÍTULO 5 - UNA ORGANIZACIÓN CON PROBLEMAS (NIVEL G DE MPS-SW)

5.1 La Pequeña Historia de Tahini-Tahini

La empresa Tahini-Tahini, internamente conocida como T2, como la denominaremos también nosotros en lo

que sigue, es una pequeñísima empresa de una ciudad de Latinoamérica. Trabajan en ella siete profesionales que se conocieron en las aulas del Instituto Politécnico local. Todos los empleados son socios con mayor o menor participación, y las tareas administrativas, así como los cargos representativos (Presidencia, Secretarias, Gerencias) son ejercidos rotativamente. La empresa se fundó basada en la tesis de graduación de dos de los ingenieros y fundamentalmente ofrece ciertos servicios de liquidación de haberes para empresas muy pequeñas 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 todavía 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 homónimo al inglés “tiny” (pequeño). El chascarrillo lo inventó una de las socias, Marcela, cuando dijo juntando el índice y el mayor de la mano derecha en el símbolo universal de pequeñez “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 año de la universidad de cada uno. Algunos fueron ayudantes de cátedra en materias en las que otros cursaban, otros fueron compañeros de clase. Al momento en que los encontramos T

2 está alcanzando sus veinte meses de

funcionamiento continuo y los gemelos están por dar su último examen para graduarse.

En un principio T2 tenía un mercado único, el de los negocios de ropa de mujer con uno o dos locales a lo

sumo. En ese mercado continúan siendo hegemónicos, pero en previsión 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 organización consiste en tomar un cliente para que pague el desarrollo. El cliente queda asociado a un “oficial de cuenta”, asignado en general en la reunión semanal, generalmente aquél 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 diseño frente al mapa del sistema ISP y usando tarjetas autoadhesivas del tipo de Post-It Notes, adjudican los requerimientos a diferentes módulos. Cuando se agota la lista, revisan los módulos 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 lo que en T

2 pasa por ser un proyecto.

El proyecto, en realidad, sólo tiene de proyecto el nombre. Hay un responsable nominal, pero se sobrentiende que de haber problemas o emergencias todos estarán 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 código del ambiente de la persona que lo desarrolló y lo copia en el archivo propio, donde realizará las pruebas de programa. Quién 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 más requerimientos a la persona que quedó libre. Es la persona que recibe la tarea quién elige al ganador.

Cuando el oficial de cuentas siente que hay suficiente cantidad de producto, comienza a probarlo con pruebas ad-hoc. Cuando no encuentra fallas, libera el producto, subiéndolo al sitio de T

2, de donde el cliente puede

hacer uso del mismo.

Boria et al.

Capítulo 5 49

En el momento en que nuestro equipo es llamado a colaborar con ellos para realizar mejoras a sus procesos, T

2 está a punto de concretar un lanzamiento importante en el área de los dentistas.

5.2 ¿Quién Está A Cargo?

Hoy es un gran día en T2. Después de asistir a una clase en el Politécnico sobre la calidad total, los gemelos

indujeron a todos a tener una reunión plenaria con nuestra empresa, Vitalería, empresa oficialmente reconocida por Softex como implementadora del MPS. Nuestro equipo de consultoría llega a la reunión temprano, como es su costumbre, y se va empapando de las novedades internas: en veinticinco días se debe concretar la entrega del sistema ajustado para odontólogos. Es viernes y los gemelos, pese a haber llamado a la reunión, se tomaron el día 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 ginecóloga. 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 diseño, tomando café con Mariano y Alfredo y a punto de empezar a hablar de nuestra propuesta, cuando llama el contacto con los clientes odontológicos, el Doctor Molar Corona Puente, Presidente de la Asociación Odontológica local. La Asociación ha recibido una oferta de una importante empresa consultora internacional para instalar un sistema centralizado de ERP que resolvería también algunos de los problemas de los asociados que se quieren resolver con el ISP para Odontólogos. El Doctor Molar no está muy dispuesto a conceder ante la presión de algunos de sus miembros para cancelar el contrato con T

2 pero necesita de

nuestra ayuda para resistir los embates. La consultora está haciendo promesas de entrega en tiempos imposibles, ignorando la necesidad de adaptación del ERP en cuestión, lo que además seguramente obligará a algunos cambios importantes en las interfaces de los futuros clientes. Por todo eso, el Doctor Molar le pide a T

2 que:

1. Indique el estado actual del proyecto de adaptación de ISP a los problemas de los odontólogos; 2. Dedique un par de horas, hacia mediados de semana, a hacer una demostración del producto cómo sea

que esté, al efecto de convencer a los asociados a que esperen el lanzamiento antes de cortar con T2;

3. Estime que porcentaje del producto va a estar listo para la demostración. Alfredo le da garantías al cliente, diciéndole “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:

- ”¿Estás con el programa de los odontólogos?”.

Mariano contesta que no, y que eso es de exclusiva responsabilidad de Marcela y los gemelos. Alfredo nos pide perdón por interrumpir la reunión y llama al celular de Marcela. Le responde un aviso que dice que el celular está apagado. Con cierta preocupación 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 número de teléfono 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 físicamente, es fácil de leer y nuestros consultores saben hacerlo. Una fina línea de transpiración aparece en el labio superior de Alfredo, respira con mayor dificultad, sus mandíbulas están 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 preocupación, eliminar el temor que provoca, crear un plan que lo pase de la inseguridad que siente a una situación creativa, donde haya esperanza. También saben que tienen que tomar la decisión 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 empatía, 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 pérdida del control, pese a que es consciente de estar pasando por dificultades para pensar.

El primer paso en toda resolución de un problema es identificarlo con claridad. Nuestro consultor líder, Máximo, hace un resumen de su entendimiento del problema: hay un cliente importante (el Doctor Molar) en situación crítica (la presión 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 están a cargo, por una serie de circunstancias totalmente fortuitas, no están presentes. Alfredo asiente tibiamente al análisis presentado. Mariano coincide con más interés que Alfredo.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

50 Capítulo 5

El segundo paso es encontrar las causas raíz del problema. Para garantizar la participación y compromiso de Alfredo y Mariano, Máximo 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 “Capacitación”. Los nombres y la cantidad de espinas pueden cambiar, siendo esta elección en parte dependiente de la percepción del problema al enfrentarlo. De todos modos, esta es una emergencia y es más importante mostrar iniciativa que una precisión total. Ahora que ya tiene la audiencia siguiéndole, Máximo empieza a indagar a los dos socios usando otras técnicas.

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 Máximo.

No se trata de identificar más síntomas, 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 también responde a la pregunta “¿Cómo 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 Máximo haya elegido las categorías 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 graduación, ni el personal ni la capacitación merecen mayor atención. El pequeño grupo se centra en procesos y herramientas. La primera respuesta es que los procesos actuales no que registran el estado. Los siguientes porqué continúan indagando hasta que se llega a detectar la causa raíz. Puede que se requiera preguntar cinco veces “¿Porqué?” o puede que se arribe antes a una causa raíz. Es fácil detectar una causa raíz porque generalmente es inmediato ofrecer una solución. Por ejemplo, al segundo porqué se contesta que los procesos existentes no están preparados para identificar tareas, responsables ni estado del proyecto. la solución es obvia, si bien no sea fácil 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é, Máximo pasa a la espina de las herramientas. También aquí es fácil 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 sensación de que es inmediato reconocer la solución (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 discusión de las soluciones. La aplicación de los cinco porqués no es el único camino posible, puesto que parte de nuestro repertorio es una alternativa llamada las Ocho Disciplinas:

D1: Formación de un equipo de expertos que en su conjunto cubran todas las funciones; D2: Identificación y definición completa del problema; D3: Implementación y verificación de una acción de freno provisional para que el daño no se propague; D4: Identificación y verificación de la causa raíz; D5: Determinación y verificación de acciones correctivas permanentes; D6: Implementación y verificación de las acciones correctivas permanentes; D7: Prevención de la re-ocurrencia del problema y/o su causa raíz; y D8: Reconocimiento de los esfuerzos del equipo.

Boria et al.

Capítulo 5 51

Como nuestros consultores son eclécticos, no desdeñan ninguna enseñanza que sea útil. En este caso Máximo reconoce la necesidad de aplicar D3: es necesario detener la propagación 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, Máximo 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 Máximo se comunican con los gemelos y acuerdan en una reunión de exploración ni bien terminen de festejar, el martes a primerísima hora. Mariano llama al Doctor Molar y le anuncia que el miércoles antes del mediodía recibirá una propuesta completa para invitar a los interesados a una demostración, propuesta que incluirá la proporción del sistema que se demostrará.

Una vez detenida suficientemente la hemorragia, y ya identificadas claramente las causas, Mariano y Máximo definen un proceso que solucione la causa y evita que se repita. Nuestro hombre en T

2 parte por definir, siguiendo

el método, las características deseables del proceso:

• Evitar que se repita el problema en el futuro • Ser muy fácil de implementar (dos o tres días en T

2)

• Contar con soporte en software existente en la empresa, o fácil 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 cuál conoce una respuesta) le hace propuestas para que las valore. Dado el análisis 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 método de funcionamiento es simple y, lo que es muy importante, pude considerarse una evolución de lo que hacen hoy en día. Cuando Mariano describe el “remate” por el que se adjudican prioridades, Máximo asocia con el libro de Kanban y Scrum y sugiere dar juntos una leída a [KNIBERG & SKARIN, 2010]. Una rápida lectura de los materiales de Kanban les hace tomar conjuntamente la decisión de buscar en la red herramientas de software que se ajusten a las necesidades de T

2 para llevar el tablero Kanban en

la nube o en servidores locales, gratuitamente. Hay suficientes como para que Mariano se entretenga por varios días comparándolos. Revisan juntos varios de ellos y, si bien no toman la decisión avanzan mucho en el tema.

Tres horas más tarde, Mariano y nuestro consultor se despiden. Han recibido una llamada tranquilizadora de Alfredo: Marcela y Ana adelantaron la visita a la ginecóloga, donde está prohibido el uso de celulares, de ahí que no hubiera respuesta de ninguna de las dos. Todo está bien en el universo de T

2. Máximo se despide diciéndole a

Mariano que si quieren continuar con un contrato permanente las horas que trabajó se considerarán inversión de marketing. Mariano no da garantías, pero expresa que lo discutirán en la reunión semanal y que la moción contará con su apoyo.

QUE HA PASADO HASTA AHORA

1. El consultor Máximo ha establecido el contacto inicial con el cliente, coincidentemente con un problema grave y facilitó su identificación.

2. Introdujo una primera técnica de análisis de causa, el diagrama de Ishikawa.

3. Utilizando la técnica llegó junto a los clientes a la conclusión 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 diagnóstico concreto que ya apunta a la mejora de procesos Máximo se ha concentrado en el problema inmediato para evitar uno mayor, comenzando por definir las características (o atributos) deseables de la solución.

5. Máximo ha sugerido el método 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 Máximo como consultor, para que facilite la reunión 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 jóvenes emprendedores han recibido el mensaje y están muy satisfechos de poder contar con nuestros servicios.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

52 Capítulo 5

Llegada la mañana del martes, todos los miembros del equipo están sentados alrededor de la mesa de diseño. Ana está un poco pálida, todavía el embarazo no le sienta bien, pero por lo demás hay efervescencia y energía a derrochar. Apreciando el lugar, nuestro consultor elogia la disposición de la sala: hay cuatro pizarras para usar con rotuladores, una de ellas todavía 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 electrónica y sirve para registrar decisiones mediante la simple pulsación de un botón 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 pósit, representando “historias” de cliente por ser implementadas.

Máximo se dirige hacia esa pizarra y llama la atención sobre las pósit, solicitando una explicación de su uso. Marcela se la ofrece, detallando como se mueven las notas de la columna de la izquierda, ahora vacía, a los diferentes módulos, para más adelante realizar el remate. Máximo saca una fotografía de la arquitectura con su laptop y aprovechando el proyector la muestra a la audiencia. Máximo indica que las notas asignadas a los módulos 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 percepción sea más completa.

Tomando una pila de pósit 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, Máximo dicta rápidamente los contenidos de cada pósit, 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, están 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 están todas las historias. Completas, a la derecha, que está vacía. La gran columna del medio está vacía y sin título, por ahora (Figura 5.2).

Figura 5.2: Tablero kanban elemental

Máximo solicita entonces que cada uno, por turno, diga una tarea derivada de implementar esa función. Ana empieza por decir “Codificar las pruebas” y Máximo lo escribe en un pósit, que acto seguido pega debajo del original. Marcela añade, casi sin pausa: “Diseñar las pruebas”. Esto también 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 características”. Todos ríen, claro. Máximo pregunta entonces cuál es el ciclo de vida de una historia. Resulta ser que es analizada, desglosada en funciones, se construyen las pruebas de cada función, se codifica y se prueba. Máximo hace notar que las funciones pueden ya estar claras y que no siempre, necesariamente, hay análisis. Los presentes asienten. Modifica entonces el tablero para incluir esa información (Figura 5.3) y quita las notas que había agregado, puesto que las tareas son parte del ciclo.

Figura 5.3: Tablero kanban con ciclo de vida de las historias -1-

Boria et al.

Capítulo 5 53

- “¿Quién es el dueño del producto?”, pregunta Máximo.

- “Yo”, dice Marcela.

- “¿No el Doctor Molar?”, vuelve a preguntar Máximo.

- “No”, dice Marcela, “el Doctor no conoce los detalles de las liquidaciones, yo estudié la legislación vigente y soy la que sabe cómo se debe hacer para pagar los sueldos y qué opciones tiene el odontólogo individual”.

- “¡Felicitaciones!”, dice Máximo. “Entonces, el primer paso es que entre todos, y bajo tu dirección, prioricemos las historias”.

Marcela se para y comienza a mover las historias que ahora están en la fila de más abajo del tablero. Máximo interrumpe.

- “Cuéntanos tu criterio, Marcela”.

Marcela comienza a explicar las prioridades y los gemelos intervienen casi a coro, recordándoles a todos la inminencia de la demostración pedida por el grupo de clientes. Pronto todos están parados alrededor de la pizarra y moviendo las notas para adelante y para atrás. La primera prioridad resulta para la historia ‘Modificar Interfaces con el Usuario’ por el impacto que tiene en una demostración. Cuando por fin se estabiliza la lista, Máximo aprueba.

- “Perfecto, tenemos un Backlog de producto. Ahora, a estimar el tamaño”.

Escribe en la pizarra electrónica una tabla que diferencia entre tamaños de tarea (Tabla 5.1). Aclara que las definiciones no son las de lo que corresponde a “tamaño” en el idioma Castellano, pero que es un buen lugar para empezar. Enfatiza asimismo que la tabla intenta que las categorías, si bien son atributos ordinales, tengan relación entre sí, de modo que la diferencia entre ‘muy sencillo’ y ‘sencillo’ resulte comparable con la diferencia entre ‘normal’ y más que normal’. El propósito es que las categorías, cuando más 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 lápiz escribe ‘tamaño estimado’ en el cuadrado superior de la izquierda (Figura 5.4) y pide que se haga una estimación del tamaño de esta historia. Hay un gran silencio, roto por Ana, quién, sacudiendo la cabeza en negación, dice:

- “Esta no es una historia de usuario, es una tarea transversal a todas las historias”.

Tamaño 1 2 3 4 5 6 7

Categoria muy

sencillo Sencillo

menos que normal

normal más que normal

complicado muy

complicado

Funciones Derivadas

1 2 3 4 5 a 6 7 a 10 más de 10

Días en el día 1 a 2 2 a 4 más de 4

Tabla 5.1: Tamaños de Tareas

Con el consentimiento de todos, Máximo 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 módulo de Liquidación de Horas Extra”.

Figura 5.4: Historia en el Tablero kanban

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

54 Capítulo 5

Vuelve a pararse en frente de la tabla de tamaños y pide que se haga una estimación del tamaño de esta historia. Hay una discusión de pocos minutos, antes de que los participantes converjan a que el tamaño es ‘más que normal’. Máximo pregunta entonces si no sería mejor romper esa historia en sub-historias, dado que son cinco o seis funciones derivadas las que están 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: “Añadir Opción de Cargar Horas Extras al Módulo de Liquidación Mensual”, “Añadir una Fórmula de Cálculo al Módulo del Empleado”, “Modificar Secuencia de Liquidación para Incluir Horas Extra”, “Modificar la Liquidación del Salario Extra para Admitir Horas Extras” y, claro, “Modificar Interfaces con el Usuario”.

- “¡Ahora tenemos una épica58

!”, intervienen los mellizos.

- “Épicas, historias, sub-historias, temas, funciones, características, 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 raíz y que de esa raíz se ‘derivan’ otros requisitos, y que de esos se pueden derivar otros más, formando una jerarquía. 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 jerarquía que nos sirve para identificar las historias y los usuarios que las generan. Podríamos usar un patrón que diga – Como usuario X, en este caso un odontólogo, 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 Máximo.

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 después 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.

QUE HA PASADO HASTA AHORA

6. Máximo ha inducido el uso del tablero Kanban, sin dictarlo.

7. Introdujo los conceptos de sub-historia y estimación por tamaño.

8. Hay una clara definición del alcance del trabajo a realizar, encarnado en la lista de historias, con su correspondiente estimación de tamaño.

9. Se ha hecho una desagregación de las historias, donde el tamaño de estas la hacía útil.

10. Los conceptos de historia, sub-historia, desagregación y tarea se han entendido en la práctica y han sido aplicados. Se distingue entre ‘tarea’ y ‘sub-historia’.

5.4 Planificación, Monitoreo y Control del Proyecto en Dosis Homeopática

La reunión continúa a pedido de Máximo, por media hora más. Antes de dejar a T2

librada a sus esfuerzos, Máximo quiere dejar clara la definición de LISTA para cada etapa del tablero.

- “¿Cuándo se puede afirmar”, pregunta, “que el análisis de la historia está concluido?”.

Las caras de los asistentes lo dicen todo: Nunca lo habían pensado. Se aventuran tibiamente algunas definiciones, hasta que Mariano da en la tecla: la realidad es que el análisis, pese a la tradición en contrario, no se hace por separado. Es parte del Diseño. Máximo borra la columna de ANALISIS del tablero y redistribuye las demás, cada una tiene dos sub-columnas: EP, que se lee En Proceso, y LISTA. Las definiciones de ‘lista’ para Diseño, Código, Desarrollo de Pruebas y Completas queda así definida:

Diseño: El diseño está LISTO cuando hay un diagrama de cambio de estados que ha sido aprobado por el Dueño del Producto, el que se encargue del desarrollo del código y el que se encargue del desarrollo de las pruebas.

58

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Boria et al.

Capítulo 5 55

El Código está LISTO cuando se ha hecho la revisión 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 revisión de todas las pruebas con un colega y se han cargado las pruebas unitarias en la herramienta de monitoreo de las pruebas automáticas.

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 regresión.

Todo esto induce un último cambio del día en el tablero Kanban: la columna A Probar pasa a llamarse Integración y Completa pasa a llamarse LISTA. Máximo borra todo el tablero, ingresa una nueva columna a la izquierda llamada En Espera, donde se pondrán las dos historias de mayor prioridad, y las columnas Diseño, Desarrollo, Integración y Listas. El tablero se ve ahora como en la Figura 5.5.

Figura 5.5: Tablero kanban con ciclo de vida de las histórias -2-

A continuación, Máximo trabaja con Marcela y los mellizos en definir el procedimiento para el uso del tablero en las actividades de los próximos días. Cada vez que alguien esté libre se acercará a Marcela y elegirán 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 ‘Diseño’. 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 terminación, cuando la tarea esté concluida. Una vez que esté completa según el autor, se espera que alguien tome la tarea de codificar y de diseñar los casos de prueba. Si se trata de la misma persona (aunque se procurará que se involucre alguien más, para tener ‘más ojos’ en el proyecto) lo revisará con Marcela y la nota pasará a EP bajo ‘Codificación’ 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 integración la realizará la persona a cargo del proyecto, en este caso, Marcela. Muy satisfechos, se cierra la sesión, y todavía queda poco más de una hora para trabajar en la mañana.

QUE HA PASADO HASTA AHORA

11. Máximo ha mostrado que el uso del tablero Kanban es dinámico 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 fácilmente 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 Odontólogos Profesionales en Actividad (SOPA) local. La demostración del producto convence a casi todos, y la simpatía y juventud de los profesionales hacen el resto y se firma un memorándum de acuerdo entre T

2

y la SOPA. Lo que piden algunos de los menos entusiastas es que se demuestre la capacidad de modificar el servicio, para lo cuál han encargado algunos cambios, la mayoría cosméticos, pero algunos que afectan los módulos de cálculo. T

2 tiene una semana para responder con un plan y una propuesta de honorarios. Establecida

ya una buena relación entre T2 y Máximo, lo llaman directamente para que facilite otra reunión para dar la

respuesta.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

56 Capítulo 5

Máximo hubiera preferido seguir con sus planes de implementación de las prácticas de MPS, pero los negocios de su cliente siempre tienen prioridad para él, por política de Vitalería. 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 prácticas. Además, ni ha sacado el tema del MPS con T

2, algo que tiene pensado hacer más adelante, cuando la

ocasión para hacer una evaluación exitosa pueda avizorarse cercana. Así que ordena su calendario y, moviendo una cita acá y otra allá, por la tarde del viernes está de nuevo en la sala de diseño de T

2 con los mismos actores del

martes.

Máximo repasa con los asistentes los pasos que llevaron al pequeñísimo plan de implementación del martes pero utiliza esta vez la herramienta de software (sprint.er) que instalaron en T

2. La secuencia de pasos es la misma:

identificar el Backlog, hacer la asignación a las componentes, ordenar las historias por prioridades, estimar el volumen del trabajo, desagregar las historias demasiado voluminosas en pequeñas historias y tareas derivadas, revisar y cerrar. Pero esta es la primera propuesta con desarrollo a medida que T

2 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 código para eliminar errores o adecuaciones a cambios en la legislación. Es por eso que el equipo no posee un patrón de presentación de planes para propuestas.

Máximo introduce ahora la plantilla para la definición de historias que ha desarrollado Vitalería. Los asistentes sugieren pequeños cambios y la plantilla queda aprobada, aceptada y adoptada (Figura 5.6). Utilizando las facilidades de diseño en la herramienta sprint.er ingresa los campos necesarios. Sobre la base de la plantilla se rearma el Backlog, ahora mucho más completo, y se realiza la estimación con sprint.er. Los resultados arrojan la necesidad de utilizar tres sprints de dos semanas. El primero implementará los cambios más de fondo, el segundo introducirá los cambios de interface sugeridos, y el tercero servirá de garantía de estabilidad. Sobre la base de lo planificado se agregan costos a la estimación.

Figura 5.6: Plantilla para Definición de Historias

Para poder medir el posible impacto de algún riesgo que se materialice, Máximo introduce una planilla de definición y análisis de riesgos (Figura 5.7). Toda esta documentación es simple y no lleva tiempo extra para ser llenada, mientras que sí arroja mucha luz sobre el proyecto, obligándoles a los miembros del equipo a pensar sobre lo que hacen usando otras facultades además de su capacidad de construir

59.

Figura 5.7: Plantilla para Definición y Análisis de Riesgos

Llegado este punto Máximo introduce la plantilla que Vitalería usa para sus propuestas de consultoría, que sigue una estructura que contiene el Backlog del producto, el plan de sprints y el tablero original del primer sprint. También se explicitan en ella tiempos y costos, así como un resumen extraído de la planilla de análisis de riesgos y un listado de las responsabilidades mutuas (ver Figura 5.8).

59

[DE BONO, E., 1985]. El libro hace referencia a cinco maneras de pensar acerca de un problema. Información: (blanco), Emociones (Rojo), Discernimiento (Negro), Optimista (Amarillo),Creativo (Verde). También hay un sombrero Azul para discutir las reglas del juego en sí.

ID NOMBRE IMPORTANCIA TAMAÑO VALIDACION RIESGOS ASOCIADOS CAPACIDADES REQUERIDAS

1

2

3

4

5

PLANTILLA DE DEFINICION DE HISTORIAS

Nombre del Proyecto:

Fecha:

Preparado por:

ID - identificador del riesgo Añada las columnas que sean necesarias para monitorear la evolución de los riesgos.

Descripción del Riesgo - problema potencial ( condición y consecuencia)

Prob - probabilidad de que el riesgo se transforme en un problema Perd - Pérdida - potencial relativo de la pérdida (monetaria) o un número entre 1 y 100)Exp - Exposición - producto entre prob y perd

Prioridad en este análisis - ranking pro exposición Prioridad la última vez - muestra el cambio ocurrido # Veces en la lista - resistencia a las acciones

Acción - acciones a llevar a cabo para lidiar con el riesgo Quién - persona responsable por las acciones Cuando - fecha en la que se revisarán las acciones

ID

Prob Perd Exp

Prioridad

en este

análisis

Prioridad

la última

vez

# Veces

en la

lista

Quién Cuando

Condición

1

2

3

4

5

6

7

8

9

10

Planilla de Definición y Control de Riesgos

Descripción del Riesgo Acción

Consecuencia

Boria et al.

Capítulo 5 57

• Introducción • Resumen Ejecutivo de la Propuesta • Alcance del Proyecto

– Método de Desarrollo de las actividades • Descripción general • Ciclo de vida de cada actividad • Preparación del personal involucrado

– Historias <link al documento Historias> • Identificador • Nombre • Importancia • Tamaño • Validación • Riesgos <link a la planilla de riesgos> • Capacidades Requeridas

– Calendario de Trabajo • Sprint 1 • Sprint 2 • Sprint … • Sprint de estabilización

– Presupuesto económico 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. Máximo pide dos cosas: una es que los presentes se comprometan a firmar su acuerdo con la propuesta, la segunda es que el cliente también lo haga. Los gemelos lo miran un poco raro, pero Máximo 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.

QUE HA PASADO HASTA AHORA

15. Máximo ha incorporado mejoras al documento del Backlog, haciéndolo más sólido y más ú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 dinámico al Backlog y el presupuesto y añadir 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 más que tratar, se disuelve la reunión. Máximo es llevado aparte por Claudio. En el salón de las conversaciones privadas le explica que la empresa tiene pocos fondos y que le gustaría mucho contar con su apoyo como consultor, pero que carecen de presupuesto para ello. Quizás, a pesar de ello, esta intervención haya sido la última.

Máximo sonríe con afabilidad, porque esperaba que este problema se presentara.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

58 Capítulo 5

- “Justamente de eso quería que habláramos”, dice. “Hay un programa60

que permite invertir en calidad y recibir fondos del estado para hacerlo”.

Máximo explica el programa y los ojos de Claudio se abren cada vez más.

- “De nuestra experiencia, pese a ser relativamente nuevo en el ambiente, el modelo más adecuado para empresas como T

2 es el MPS”.

- “¿Qué es el MPS?”, pregunta Claudio.

Sigue una precisa explicación de parte de Máximo sobre las ventajas del modelo, matizada con conceptos como evaluaciones, evidencia directa y otros términos que hoy son nuevos en T

2 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 todos los socios, mientras que Máximo tiene que hablar en Vitalería para que se ingrese a T

2 en la lista de

empresas que aspiran al soporte para implementación.

5.6 Avances en la Implementación del MPS

Unas semanas después T2 está preparando su evaluación de Nivel G del MPS. La primera actividad en el plan

que Vitalería preparó con ellos es la realización de un análisis de la brecha que media entre los procesos, como están implementados, y los resultados esperados de implementación 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 en T

2:

Gestión de Proyectos (GPR) en el Nivel G

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 métodos 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 ejecución de las tareas y de los productos de trabajo son estimados con base en datos históricos o referencias técnicas;

GPR 5 El presupuesto y el cronograma del proyecto, incluyendo la definición 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 recolección, almacenamiento y distribución. 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 ejecución del proyecto es establecido con la integración de planes específicos;

GPR 11 La viabilidad de lograr las metas del proyecto es explícitamente 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 relación a lo planificado;

GPR 14 Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados con relación a lo planificado;

GPR 15 Los riesgos son supervisados con relación a lo planificado;

GPR 16 La participación de las partes interesadas en el proyecto es planificada, supervisada y mantenida;

60

En varios países de Latinoamérica esto es una realidad. La forma que adopta el programa varía de país en país, por lo que se evitó en este texto hacer una referencia más explícita. Los programas suelen pagar a las empresas una parte sustancial de los egresos en consultoría cuando la empresa acredita o certifica bajo un modelo internacional, como el MPS, el CMMI o ISO.

Boria et al.

Capítulo 5 59

Gestión 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 análisis de cuestiones pertinentes, incluyendo dependencias críticas, son establecidos y tratados con las partes interesadas;

GPR 19 Acciones para corregir desvíos de lo planificado y para prevenir la repetición de los problemas identificados son establecidas, implementadas y acompañadas hasta su conclusión.

Tabla 5.2 Proceso GESTIÓN 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 análisis 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 también 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 periféricos como los que están almacenados en la herramienta sprint.er y la planilla de riesgos (GPR10). En cada sprint se realiza el análisis 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).

De las tareas de planificación solo faltan GPR 8 y GPR 9. Máximo y el equipo de T2 tendrán que trabajar en

generar los cambios para que los procesos los implementen. Mientras tanto, es más productivo abocarse a la tarea de garantizar que los procesos de monitoreo y control están siendo implementados.

La primera acción 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 orgánico” del Capítulo 3, Marcela pasa a cumplir funciones de Scrum Master y junto con los gemelos y Ana, como equipo del sprint, se reúnen diariamente en la sala de diseño para evaluar los avances del día anterior y el estado general del sprint, incluidos los riesgos asociados. Esta reunión 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 análisis 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 reunión el alcance, las tareas, las estimaciones, el presupuesto y el cronograma del proyecto son supervisados con relación a lo planificado; GPR 14, porque los recursos materiales y humanos así como los datos relevantes del proyecto son supervisados con relación a lo planificado para el sprint; GPR 15, dado que se supervisan las tareas relacionadas con los riesgos y GPR 16 porque la participación 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 participación de todos los interesados está completamente evidenciada. Con todos estos elementos Máximo 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

Todavía 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 Máximo 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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

60 Capítulo 5

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 aprobación por los clientes, cubre de ese modo el resultado esperado GRE 1; que la revisión 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 través 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 análisis 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 demostración de lo realizado, surge la evidencia necesaria para GRE 5. El próximo paso para Máximo 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.

Gestión 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 técnico 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 GESTIÓN DE REQUISITOS [SOFTEX, 2012a]

Conforme con los resultados hasta este momento, Máximo 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 ejecución. Con la conformidad de la organización, la estructura contiene una carpeta para cada uno de los pasos del proceso que la organización sigue, más 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 Máximo está seguro que los dos resultados faltantes de GPR han quedado cubiertos.

QUE HA PASADO HASTA AHORA

19. Máximo ha introducido el Scrum diario para evaluar los avances día a día 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 organización incorpora una demostración del producto al final de cada sprint como criterio de aceptación por el usuario que sirve para evidenciar su participación.

21. El análisis de brecha ejercido como actividad continua muestra que los resultados esperados para GRE surgen de los procesos ya implementados.

22. Máximo ha introducido un corto procedimiento para definir la estructura de carpetas de un proyecto en el sitio de cada proyecto, que evidencia la implementación de GPR 8 y GPR 9.

5.7 Preparando la Evaluación

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. También hay que definir el mecanismo para acceder a ellos incluyendo cuando fuera necesario restricciones de acceso. Además es necesario revisar los atributos de los procesos GPR y GRE, esos que hablan de la capacidad de la organización 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 Máximo tiene en cuenta es que los resultados definidos, salvo los ya identificados, están 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:

Boria et al.

Capítulo 5 61

RAP 2 Existe una política organizacional establecida y mantenida para el proceso;

RAP 3 La ejecución del proceso es planificada;

RAP 4 La ejecución del proceso es supervisada y se realizan los ajustes necesarios;

RAP 5 Las informaciones y los recursos necesarios para la ejecución del proceso son identificados y puestos a disposición 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 términos de formación, entrenamiento y experiencia relacionados;

RAP 8 La comunicación entre las partes interesadas en el proceso se planifica y ejecuta de modo que se asegure su participación;

RAP 9 Los resultados del proceso son revisados con la alta gerencia para proporcionar visibilidad sobre su situación en la organización;

RAP 10 El proceso planificado para el proyecto es llevado a cabo.

Máximo produce una política 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 tamaño y esfuerzo, y las etapas en las que se realizarán se planifican y se coordinan con los clientes. El personal que se escoge para las tareas es idóneo, 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 violación a esta regla será considerada motivo de sanciones y eventualmente suspensión de los que la violen reiteradamente”. En discusiones con los gemelos, que se oponían a una mención de sanciones, Máximo logró convencerlos de que una regla sin sanción más que una regla es un deseo, y que además la sanción era discrecional, si la razón por detrás de la violación era atendible, no había porqué llegar a la sanción. Este enunciado aparece hoy encabezando la página de procesos de T

2. Con esto ya se tiene evidencia de la implementación de RAP 2.

Luego Máximo atacó los siguientes RAP, uno a uno: planificar, supervisar la ejecución y ajustar si es necesario, poner a disposición de aquellas personas y roles responsables los recursos, datos e informaciones necesarias para llevarlo adelante y otorgarles autoridad para hacerlo, brindándole capacitación cuando no tengan la competencia adecuada, o nombrar a quién la tenga en el rol, garantizar la participación de las partes interesadas, revisar con alta gerencia para proporcionar visibilidad sobre su situación en la organización y por último, llevar a cabo todo lo anterior.

Incorporó un proceso de iniciación de proyectos que describe como se debe completar una propuesta, obviamente basándose en el proceso que describió para llevar adelante un proyecto usando el tablero virtual, pero extendiéndolo para que se cubran todas las etapas de planificación, control y gestión de requisitos. En el más alto nivel describe la secuencia de procesos de manera gráfica. Para cada actividad usa la plantilla de procedimiento (Figura 5.10) y un diagrama de andariveles que dibuja usando un programa gráfico.

Por ahora deja de lado las mediciones de cada actividad pero sí incluye el diagrama. El proceso incluye todas las actividades de generar el plan, definiendo los roles y funciones de cada actor e interesado. Cuando T

2 comience

su próximo 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 planificación de la planificación, dado que identifica quién o quiénes son responsables por generar la propuesta, cómo se adjudica la responsabilidad y que recursos le dan soporte. De este modo T

2 atiende

a los resultados esperados de los Atributos de Proceso.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

62 Capítulo 5

PLANTILLA DE DETALLE DE PROCEDIMIENTO

Nombre de la Actividad:

Propósito. (¿Qué se espera lograr con esta actividad?)

Involucrados (al menos el responsable)

Entradas requeridas

Productos de trabajo creados (salidas)

Criterio de Ingreso (¿Cómo se sabe cuando comenzar esta actividad?)

Criterio de Salida (¿Cómo 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 serán incorporadas en el diagrama de andariveles)

Mediciones. (¿Cómo se puede medir el rendimiento de esta actividad?)

Secuencia. (¿Qué actividades se llevan a cabo antes y después de esta?)

Figura 5.10: Planilla de Detalle de un Procedimiento

Uno de los principales impulsores de la mejora continua en una organización es la realización de reuniones periódicas que analicen lo actuado y sugieran cambios a los procesos para mejorar. Esas reuniones reciben el nombre de retrospectivas, y T

2 las adopta bajo la preparación y supervisión

61 de Máximo.

Lo más 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 situación crítica 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 propósito, siendo que la duración justa depende de la participación y de la cantidad de temas que se anticipan serán discutidos en la reunión. Es importante que participen todos los interesados, incluido el Dueño del Producto. El lugar de la reunión no puede ser la misma sala de trabajo, porque es sumamente importante no sufrir interrupciones. Máximo eligió la sala de diseño porque tiene los tableros que permiten trabajar cómodos y no tiene teléfonos ni pantallas de computadoras. No se permiten las laptops en la reunión de análisis 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 más propuestas para ninguna de ellas, se inician las rondas de sugerencias.

Las técnicas para esto son múltiples y es valioso conocer tantas como sea posible. Ya hemos mencionado el diagrama de Ishikawa, o de espina de pescado, así como los cinco ‘porqués’, 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 crítico. Estas y muchas otras técnicas tienen mérito y su aplicación medida da excelentes resultados.

El informe de Máximo para su jefe incluye la siguiente tabla (Figura 5.11), que muestra las evidencias que se tienen de la obtención de los resultados esperados por la implementación del proceso GPR del modelo. Las columnas definen la documentación existente, de izquierda a derecha: Tablero Kanban, Plantilla de Historias, Propuesta, Script de Definición de Carpetas y Recursos, Demostración 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 implementación elegida. Asimismo hay otras tablas de cobertura para GRE y las RAP.

61

Hemos elegido ‘preparación y supervisión’ para englobar el significado de ‘coaching’, que lamentablemente no tiene una buena traducción en un solo vocablo en Castellano.

Boria et al.

Capítulo 5 63

Figura 5.11: Evidencias para GPR en el Nivel G

QUE HA PASADO HASTA AHORA

23. Máximo ha definido y codirigido varias implementaciones del procedimiento de análisis retrospectivo, que brinda evidencia de GPR 17, GPR 18 y GPR 19.

24. Máximo ha redactado una política que la organización aprobó para establecer los lineamientos de lo que se espera del personal de T

2.

25. 25. Máximo ha desarrollado un proceso que permite evidenciar las capacidades de proceso de Nivel G del MPS para las actividades de planificación, a través de la propuesta, y gestión de requisitos, a través del Backlog del producto y la evolución del tablero Kanban.

Dejamos a Máximo y T2 organizando la evaluación formal de Nivel G del modelo MPS.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

64 Capítulo 6

CAPÍTULO 6 - UNA ORGANIZACIÓN EN CRECIMIENTO (NIVEL F DE MPS-SW)

Este capítulo tiene como objetivo discutir la implementación de prácticas que se requieren en el nivel F del modelo de referencia MPS. En el nivel F, Gestionado, los procesos son Adquisición (AQU), Gestión de la Configuración (GCO), Garantía de la Calidad (GQA), Gestión de Portafolios de Proyectos (GPP) y Medición (MED). Nótese lo que dice el modelo:

“La implementación de los procesos para el nivel F puede hacerse en cualquier secuencia, visto que los procesos de ese nivel son de apoyo a la gestión 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, gestión de configuración, medición, gestión de portafolio de proyecto y adquisición de productos. Sin embargo, note que la existencia de un nuevo perfil no obliga necesariamente a la contratación de nuevas personas, sino más bien, a la definición de nuevas competencias necesarias y delimitación de nuevas responsabilidades”

62.

QUE HA PASADO HASTA AHORA

26. T2 ha alcanzado el nivel G del MPS - SW en una evaluación oficial

6.1 Crecen los pedidos

Tahini-Tahini ha pasado a constituir el bien ponderado círculo de empresas que han sido evaluadas en el Nivel G del MPS. Aunque hubo algunos detalles aquí y allá descubiertos por el equipo de evaluación, fueron arreglados prontamente por el personal de T

2 y la organización recibió su diploma en el congreso anual del Simpósio Brasileiro

de Qualidade de Software (SBQS). La noticia circuló rápidamente en los medios locales y T2 tuvo sus quince

minutos de notoriedad. Por breve que haya sido esa notoriedad los amigos de T2, como el Doctor Molar, se

sintieron obligados a compartir el orgullo que les trajo la noticia. La consecuencia inmediata es que otros clientes se acercaron a T

2 para inquirir sobre sus servicios.

Una oferta muy tentadora llegó desde el Consejo Profesional de Contadores Públicos (CoProCoP) para que se brinden los tradicionales servicios de liquidación 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 administración. La oferta es sumamente interesante, porque aumentaría de inmediato la facturación con clientes existentes al ofrecer las nuevas funcionalidades y también ampliaría el mercado potencial.

Tras unas breves charlas iniciales con CoProCoP se hace una reunión plenaria de T2 para tomar una decisión

sobre el camino a seguir. Esta reunión es crucial porque la oferta plantea una encrucijada real: Crecer o no crecer. Sin duda crecer es algo a lo que toda organización cree aspirar. Más clientes, más facturación, mejores salarios, vacaciones pagas, un futuro venturoso. Pero también implica dejar de lado la cotidianeidad de los amigos, profesionalizar la administración, despegarse de las tareas divertidas o tener que hacerlas de otro modo. Las emociones entre asistentes a la reunión oscilan desde los que están asustados a los que están eufóricos. Las vías de crecimiento se les antojan extrañas y complicadas. Tras dos horas de reunión no se llega a ninguna conclusión. Es entonces que uno de los gemelos propone llamarlo a Máximo.

6.2 Buscando Ayuda Fuera de Tahini-Tahini

Dos días más tarde, Máximo facilita la reunión plenaria de T2 en la sala de diseño. Esta vez ha traído 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 método que se sigue, es decir, pensamientos sobre el método de trabajo. El sombrero Blanco se usa para trabajar con los datos concretos, con la información disponible. Con el sombrero Rojo se expresan los sentimientos. No hace falta alguna justificarlos. La lógica de la cautela se expresa con el sombrero Negro. Tiende a mostrar los problemas, de ahí el color. El Amarillo expresa la lógica del optimismo, lo que puede ocurrir que nos gustaría que pase. El Verde es para provocar. No hay un orden predeterminado de su uso, en general se comienza a usarlos para alentar la discusión y evitar que el pensamiento se estanque en la lógica 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. También es posible que una persona

62

SOFTEX, 2012c, página 7

Boria et al.

Capítulo 6 65

tome el sombrero que corresponde a lo que quiere expresar antes de decirlo, de modo que todos sepan que está haciendo esa comunicación desde el punto asociado al color.

Máximo se calza el sombrero Azul y explica los roles de los colores y propone usarlos en ronda. Primero todos usarán 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. Máximo los ha ido registrando en la pizarra electrónica 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 rápido

Muchas líneas de producto

Pérdida del control Tabla 6.1: Pensamientos Negativos sobre el Cambio

Máximo ha copiado los pensamientos negativos de todos. Algunos fueron repetidos o suficientemente relacionados como para ser expresados en una sola oración. 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 sesión de análisis de lo enunciado para llegar a una estrategia de crecimiento. Dibuja con gracia un esqueleto de sardina y escribe la primera oración 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. Máximo los deja seguir un par de minutos y luego interrumpe.

- “¿Para qué sirve el diagrama de Ishikawa?”.

La pregunta es retórica, pero tiene su resultado. De inmediato todos caen en la cuenta de que se han vuelto a poner el sombrero Negro, algunos también el Rojo. Haciendo que vuelvan al ejercicio de búsqueda de soluciones, escribe él mismo la solución. (Figura 6.2)

Figura 6.2: Diagrama Ishikawa sobre Crecimiento 2

Se hace un silencio de asentimiento. Máximo deja que la idea se vaya haciendo fuerte en los socios y encabeza su lista con este título: “Preparándonos Para Crecer” y borra la primera fila. La reunión se anima de a poco, y donde se veían problemas se ven ahora soluciones. Algunas se descartan, por ejemplo el crecimiento acelerado puede ser controlado mediante la contratación de personal, pero el costo en esfuerzo del personal actual y la inversión en facilidades es demasiado grande. En cambio, es posible considerar la contratación de servicios de desarrollo de un proveedor establecido. La tabla completa ha quedado así constituida (Tabla 6.2):

PREPARANDONOS PARA CRECER

Crecimiento demasiado rápido

implica contratar servicios externos

Muchas líneas de producto implica contar con gestión de configuración

implica seleccionar entre opciones de inversión

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

66 Capítulo 6

Pérdida del control implica controlar objetivamente mediante decisiones basadas en datos

implica controlar objetivamente la aplicación de normas y políticas

Tabla 6.2: Preparándonos para Crecer

Ahora Máximo sugiere atacar uno a uno los riesgos, empezando por la contratación de una empresa proveedora. Produce una lista de riesgos que proyecta en la pared, que dice así:

Contratación 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 Máximo, uno a uno. Van asintiendo, con algunas preguntas. El ítem 5 se discute un poco más que los demás. Claudio quiere saber por qué es importante hacer un contrato que sirva a las dos partes, además de las consideraciones éticas. Máximo 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 caída.

Máximo pregunta si alguien quiere agregar algún riesgo más, y espera la respuesta. Después 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”.

Máximo no se preocupa en definir los términos 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 conclusión para cada uno de los riesgos:

Para no contratar los servicios equivocados hay que planificar la adquisición, 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, cuáles son los atributos que deberán poseer para participar en la compulsa de precios.

Para no elegir de un subconjunto inadecuado de proveedores hay que investigar el mercado basándonos en el tipo de adquisición y los atributos requeridos de los proveedores.

Para no elegir subjetivamente entre los candidatos hay que construir un modelo de decisión que permita elegir entre ellos basándose 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 disposición y buscando el “ganar-ganar” con coraje, madurez, imaginación 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, cuándo y en qué condiciones.

- “Esta es una buena lista”, dice Máximo. “Lo más interesante es que se pueden implementar estas acciones de manera de cumplir con la implementación de todos los resultados de proceso correspondientes a Gerencia de Adquisición del MPS”, y sonríe al decirlo.

Proyecta entonces esos resultados:

Adquisición (AQU)

AQU 1 Las necesidades de adquisición, las metas, los criterios de aceptación del producto, los tipos de adquisición y la estrategia de adquisición son definidos;

AQU 2 Los criterios de selección del proveedor son establecidos y usados para evaluar los proveedores en potencial;

AQU 3 El proveedor es seleccionado con base en la evaluación de las propuestas y de los criterios establecidos;

Boria et al.

Capítulo 6 67

Adquisición (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 análisis de los potenciales candidatos;

AQU 6 La adquisición 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 relación 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 ADQUISICIÓN [SOFTEX, 2012a]

Los socios se abocan a la creación de guías, criterios y procesos para realizar adquisiciones. Rápidamente algunos criterios surgen claramente: la adquisición 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 colaboración que estén dispuestos a prestar para ello serán objeto de análisis y se dará importancia a quiénes demuestren esa voluntad. Esos y otros van dando forma a los procesos de adquisición. Las primeras dudas y los miedos se disipan en la actividad creativa.

Queda la duda, sin embargo, sobre la decisión de “fabricar o comprar”, ya que hay que considerar factores como las características del producto que los proveedores ofrecen y cómo 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 necesitarán por ser del proveedor, más la administración del contrato, el costo de adquirir versus el costo del desarrollo interno; las fechas críticas de entrega e integración; 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 están 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 estarán comprando, así como la disponibilidad del producto, las cuestiones relacionadas con la propiedad y si la decisión aumenta o disminuye los riesgos. Máximo propone crear una matriz de Pugh

63 que

contenga las alternativas y usarla cuando se necesite. Con esa tarea pendiente se levanta la reunión.

QUE HA PASADO HASTA AHORA

27. Máximo ha utilizado la técnica 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. Máximo ha ayudado a revisar los riesgos de contratación de proveedores y estudiar las alternativas de comprar, reusar o fabricar introduciendo la técnica de la matriz de Pugh.

6.3 ¿Qué deberíamos fabricar?

Al día siguiente Máximo 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 farmacéuticos al que no le vendría mal un sistema de liquidación de salarios. La pregunta es cuando puede Máximo ayudarlos a resolver ese tema facilitando la reunión de los socios. Cuando Máximo llega a las oficinas de T

2 ya hay dos propuestas más de trabajo conjunto: a los contadores y los fabricantes de software

para farmacias se agregaron un llamado de la asociación de servicios de salud, que está interesada en desarrollar un sistema nuevo, en la nube, por lo que la experiencia de T

2 les es sumamente apetecible, y un proveedor de

servicios a agentes de seguros que también quiere “mudarse” a la nube para integrar más fácilmente nuevas tecnologías (laptops, tabletas, netbooks, y también teléfonos inteligentes) a la oferta. Las cuatro propuestas están siendo evaluadas como proveedores usando la matriz de Pugh que dejara como tarea Máximo.

- “Un momento”, pide Máximo. “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?”.

63

Ver Capítulo 2.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

68 Capítulo 6

El silencio es casi audible. La selección de proyectos que una organización encara debe resultar de un profundo conocimiento del mercado y la visión del rumbo que llevará el crecimiento de la organización. La gobernanza de los recursos a nivel de organización, por encima del nivel de los proyectos, es esencial para el máximo aprovechamiento de los patrimonios colectivos. Cualquier otra forma de definir la asignación de recursos a los proyectos puede dar lugar a adjudicaciones inadecuadas. La falta de visión es un primer obstáculo. Máximo se dirige a la pizarra y escribe: ‘Visión para T

2: En los próximos dos años nos comprometemos a’ y deja el escenario.

Claudio habla el primero:

- “Me gustaría que fuéramos una fuerza decisiva en el mercado de SaaS”.

Máximo le pasa el marcador y Claudio pasa a la pizarra y escribe su oración textualmente. Máximo se levanta, toma el marcador y corrige la oración. Ahora se lee ‘En los próximos dos años nos comprometemos a ser una fuerza decisiva en el mercado de SaaS para Latinoamérica’. Ahora se levanta Marcela, toma el marcador de manos de Máximo 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 visión dice entonces ‘En los próximos dos años nos comprometemos a ser el referente entre las cinco mejores empresas en el mercado de SaaS para Latinoamérica’. El silencio ahora es solemne.

- “Si ese es el caso”, interrumpe Máximo, “vender sistemas contables con liquidación 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’, según el [PMI, 2008], como “(...) un conjunto de proyectos, programas y otros trabajos que se agrupan para facilitar la gestión efectiva del conjunto del trabajo para cumplir con los objetivos estratégicos específicos. Los componentes de la cartera no necesariamente tienen que tener alguna relación de dependencia o estar directamente relacionados”. Además, se puede entender que ‘gestión de la cartera’ se refiere a la “gestión centralizada de una o más carteras, lo que incluye la identificación, priorización, autorización, administración y control de proyectos, programas y otros trabajos relacionados, para alcanzar los objetivos estratégicos específicos" [PMI, 2008].

- “Entonces”, pregunta Máximo, “¿Cuáles de las propuestas están alineadas con la visión?”.

- “Todas, menos la de los agentes de seguros”, responde con seguridad Marcela.

Máximo tacha de la matriz de Pugh a esa oferta y borra todos los atributos deseables de la solución de la matriz, dejando en blanco la columna de la izquierda.

- “¡NOOOO!”, gritan todos.

El trabajo no había sido copiado a ningún lado todavía. Por suerte Mariano tiene la costumbre de sacar fotografías de lo escrito en las pizarras cada tanto, y se puede recrear la información borrada sin demasiado esfuerzo. Máximo entonces escribe los atributos de la nueva matriz, la de selección de aliados. Los atributos que pone son: esfuerzo (demandado por el proyecto), dominio (de aplicación), sinergia (con los otros proyectos), inversión (monto de la misma), alineamiento (con la visión estratégica) y mercado pot. (mercados de potencial venta del producto resultante). Llenan la matriz y el resultado parcial es el siguiente:

atributo contadores software para

farmacias Asociación servicios de

salud servicios a

agentes de seguros

Esfuerzo 1 sistema completo

1 sistema migración a SaaS

1 sistema integrado para hospitales

domínio contabilidad manejo de stocks ERP completo

sinergía buena mediana Total

Inversión media media Enorme

alineamiento Bueno mediano Enorme

mercado pot. muy ampilo Farmacias hospitales, farmacias,

médicos ????????

Tabla 6.4: Matriz de Pugh sobre Propuestas

Los signos de pregunta los escribieron los mellizos Galarraga, que de repente se levantaron al unísono y se disputaron el marcador.

- “¿Qué pasa si”, dijo Alberto,

Boria et al.

Capítulo 6 69

- “… La tecnología que quieren usar los de los agentes de seguros la empleamos…”, siguió Armando,

- “… la usamos para conectar a los médicos, enfermeros y administrativos del hospital?”, continuó Alberto,

- “…y a los pacientes, las salas de primeros auxilios, las historias clínicas”, terminó Armando.

Los ojos de todos brillaban de excitación. Máximo fue el encargado de echar un baldazo de agua fría al conjunto:

- “Esperen, esperen. Nada de soluciones todavía. Tomemos un café y pensemos la estrategia entre todos”.

Máximo ha utilizado acá una táctica de facilitación que consiste en romper la reunión en pequeños grupos para que las ideas se crucen. Esta táctica es una de las variantes de lo que se llama “polinización cruzada” que adopta varias formas pero que en su centro consiste en activar la participación de todos para cruzar ideas. Algunas otras formas son más divertidas, como “El Cóctel”, 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 común. Máximo ha quitado todo formalismo a la situación para permitir un intercambio menos rígido, pero espera que la falta de consignas no derive en otros temas dado el interés manifiesto de todos los presentes.

De vuelta alrededor de la mesa de diseño, cada uno con su cafecito, Máximo 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 rápido. 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 rápido hay que tomar riesgos. En particular, hay que conseguir capital”.

Otra vez el silencio es incómodo. Claudio mira uno por uno a todos para enfatizar las ideas y continúa:

- “Para conseguir capital hay que tener un plan de negocios. Tenemos que considerar expandir nuestro propio capital humano, por ejemplo contratando más profesionales que trabajen a nuestras órdenes. Esto nos va a llevar a una división técnica del trabajo y a la especialización. Podemos rotar posiciones si alguien está incómodo con la que le puede llegar a tocar, pero no vemos otra solución. 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. Máximo 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: mitigación:

elegimos las líneas de producto sin base en una visión estratégica

seguimos un proceso ordenado para fijar la visión, la estrategia y las líneas de negocio

no hay suficiente presupuesto para todas las líneas de producto

las líneas de producto elegidas son financiadas proporcionalmente a su importancia estratégica

nadie queda a cargo de cumplir la visión estratégica adjudicamos claramente la responsabilidad por cada línea de produto con énfasis en los resultados de negocio

con el tiempo se pierde la visión estratégica controlamos que la línea elegida es la línea seguida

cuando hay desvíos de la estrategia implementamos acciones correctivas

la escasez de recursos implica desbalances entre líneas utilizamos la visión estratégica para resolver conflictos de recursos y dependencias críticas

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

70 Capítulo 6

riesgo: mitigación:

ciertos proyectos pierden valor para la estrategia revisar la visión estratégica periódicamente y redefinir las líneas de producto, cancelando o continuando proyectos

la organización en su conjunto no visualiza las decisiones estratégicas

comunicar la visión y el estado de los proyectos

Tabla 6.5: Riesgos del Crecimiento

“Bueno, dice Máximo, ya estamos preparados para implementar el proceso de gerencia de cartera.”

Proyecta entonces la siguiente tabla (Tabla 6.6)

Gestión de Portfolio de Proyectos (GPP)

GPP 1 Las oportunidades de negocio, las necesidades y las inversiones son identificadas, calificadas, priorizadas y seleccionadas con relación a los objetivos estratégicos de la organización 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 gestión de los proyectos son establecidas;

GPP 4 El portafolio es supervisado con relación a los criterios que fueron utilizados para la priorización;

GPP 5 Acciones para corregir desvíos en el portafolio y para prevenir la repetición de los problemas identificados son establecidas, implementadas y acompañadas hasta su conclusión;

GPP 6 Los conflictos sobre recursos entre proyectos son tratados y resueltos, de acuerdo con los criterios utilizados para la priorización;

GPP 7 Proyectos que cumplen con los acuerdos y requisitos que llevaron a su aprobación son mantenidos, y los que no cumplen son re -direccionados o cancelados;

GPP 8 La situación del portafolio de proyectos es comunicada a las partes interesadas, con periodicidad definida o cuando el portafolio es alterado.

Tabla 6.6: Proceso GESTIÓN DE PORTFOLIO DE PROYETOS [SOFTEX, 2012a]

QUE HA PASADO HASTA AHORA

29. Para poder desarrollar más opiniones en paralelo Máximo ha inducido la técnica de “polinización cruzada” mediante un oportuno corte en la actividad.

30. Utilizando el análisis de riesgo como herramienta de exploración, Máximo induce las prácticas que implementan los resultados esperados del MPS correspondientes a la gestión de portafolio (o cartera) de proyectos.

6.4 Midiendo resultados

La primera consecuencia de la decisión de crecer es un nuevo organigrama (Figura 6.3). Alfredo y Ana compartirán la conducción de la empresa hacia afuera y coordinarán las actividades de los demás hacia adentro.

Ana será la Arquitecta en Jefe, dada su posición como docente de la cátedra de Arquitectura de Software, mientras que Marcela será el soporte de ellos en lo administrativo y contable, con inclusión de la gestión de personal, y además la gerente de calidad. Claudio hará las veces de Gerente de Finanzas, los gemelos manejarán los equipos de desarrollo (uno de ellos) y soporte y mantenimiento (el otro gemelo). Los socios renunciaron a nombrar quién ocupará cada cargo porque de todos modos no pueden distinguir entre ellos. Mariano, finalmente, se ocupará de atención al cliente. Esta función se encarga de marketing, ventas, desarrollo de nuevos productos y la verificación y validación de las versiones antes de su lanzamiento al público. Toda una reorganización. Para facilitar la definición, Máximo comparte con el grupo su planilla de Misión y Funciones (Tabla 6.7).

Boria et al.

Capítulo 6 71

Figura 6.3: Organigrama Tahini-Tahini

Establecidas las funciones y los canales de comunicación orgánicos, es necesario contar con un sistema de decisión. Las decisiones deben ser lo más objetivas posible. La objetividad surge de la existencia de datos que soporten la decisión. Sin el soporte de datos, la información no existe, es simplemente una opinión y no es realmente información. Un sistema de decisión debe basarse en un sistema de información, y un sistema de información debe de estar sustentado por datos colectados de la ejecución de los procesos. Hay dos lugares donde ya vimos la necesidad de recolectar datos: en la plantilla de procesos, para poder medir como se están comportando los procesos cuando son ejecutados, y otro en los indicadores de gestión que ocupan una columna en la planilla de la Tabla 6.7.

Tabla 6.7: Misión y Funciones

Hemos hablado de datos, de información y de decisión. Aclaremos ahora lo que queremos decir. Un dato es simplemente una secuencia de símbolos, gramaticalmente bien formada, pero cuya interpretación es poco clara. El ejemplo más extremo de esto es una cadena de unos (1) y ceros (0) que codificados en la memoria de una computadora puede ser una instrucción, un dato numérico o un carácter que se puede imprimir. Menos extremo que eso es, por ejemplo, una celda de una planilla de cálculo que nos indica $118. Si en el contexto de la planilla el símbolo $ indica dólares de los Estados Unidos de Norteamérica, se puede entender el contenido de la celda: Es un dato que significa ciento dieciocho dólares de EEUU. Pero ese es un nivel sintáctico, muy poco útil, no nos sirve para entender mucho. Necesitamos más contexto para subir de ese nivel sintáctico a un nivel semántico. 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 título “Precio a Futuro del Barril de Crudo en Tirkit”. Ahora la combinación del valor de la celda con el valor del título nos dan una interpretación válida y posiblemente única del mensaje. De todos modos, sin un propósito para la decisión nos quedamos en el mensaje. Para que el mensaje tenga información es necesario que nos sirva para la decisión. Así, si la decisión es vender o no vender mis valores a futuro en petróleo, este mensaje contiene información.

Nombre del

cargo

Nombre del cargo

al cual reporta

Experiencia Formacion

profesional

deseable o requerida

Contactos dentro

de la organizacion

Contactos fuera

de la organizacion

Funciones del

cargo

Que hace Como lo hace Con quien lo hace Indicadores de

gestion

Habilidades

requeridas

Mision del cargo

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

72 Capítulo 6

Figura 6.4: Datos vs. Información

Un buen sistema de información se apoya tanto en datos fidedignos como en la construcción de indicadores que permitan visualizar fácilmente la decisión. Por ejemplo, para la decisión que hemos usado como ejemplo en esta sección, una línea paralela al eje X del tiempo por el punto 105 del eje de los Precios Futuros constituye un indicador del punto de venta según un criterio fijado de antemano. Cuando el gráfico de los precios pasa la recta la decisión es automática, o por lo menos, se puede automatizar.

Figura 6.5: Gráfico sobre Precios Futuros del Petróleo

Partiendo de las decisiones que se deben tomar se define qué indicadores permiten tomar la decisión con confianza. Por ejemplo, una decisión típica de un líder de proyecto es si debe redefinir el alcance en términos de los requerimientos que ha comprometido. Para poder decidir eso necesita un indicador que le señale si a la fecha de entrega el producto estará completado con la calidad prevista. Un posible indicador surge de un método conocido como valor ganado, EVM. Lo interesante de EVM es que es más 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 automóvil y está detenido en una población distante 375 Kilómetros de donde Usted se encuentra al recibir el llamado. Si Usted no llega a la comisaría en menos de cuatro horas, su primo pasará la noche en la cárcel. Si llega antes y paga la fianza, su primo dormirá en su casa.

Su propio automóvil tiene el tanque parcialmente lleno y Usted cree que la autonomía y velocidad necesaria para que pueda llegar a tiempo. Baja a su banco para retirar el dinero de un cajero automático y en minutos está en camino. ¿Qué puede pasar? En realidad, puede que el tránsito de hora pico haga que llegue después de cerrada la comisaría 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 además le roben su automóvil a la vera del camino. ¿Cómo saber si esto puede pasar?

Los indicadores son dos: Cuántos kilómetros recorre por hora su automóvil, y cuánto combustible consume, ya sea por kilómetro o por hora. Por supuesto, el primer indicador se conoce como la “velocidad” y lo volveremos a encontrar en este Capítulo cuando hablemos en más detalle de la estimación. El segundo es el consumo, pero es diferente considerarlo por kilómetro que por hora. Por ejemplo es posible bajar el consumo a cero si uno detiene el automóvil, pero entonces se pierde el objetivo de rescatar al primo de la cárcel. Con EVM se calculan estos dos indicadores. El primero es el desempeño calendario y es el equivalente de la velocidad. El segundo es el desempeño de costos y es el equivalente del consumo.

Boria et al.

Capítulo 6 73

En un automóvil medimos los kilómetros recorridos, mientras que en un proyecto de software hemos de medir el avance mediante el tamaño del producto o el número de tareas que se completan. Como las tareas no son todas idénticas y a veces cuesta compararlas, es mejor tomar una medida del tamaño (veremos una más adelante). Un buen indicador nos diría 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 ejecución de la misma. Definimos aquí cinco medidas básicas [PUTNAM & MYERS, 2003] que deben estar presentes desde el primer momento, en la definición inicial de los procesos. Lo que vamos a medir, y para qué, tiene que ser parte integral de la definición de las tareas. De ese modo se establecen de inmediato las condiciones para controlar los procesos (una tarea no es más que la encarnación, instanciación, o ejecución de un paso de un proceso). Esas mediciones son: tamaño y número de defectos relacionados con el producto, y duración, esfuerzo y costo de la tarea. Con esto en mente, T

2 ha

comenzado la revisión de sus procesos y completado la definición de mediciones que dejara pendiente en ese nivel.

El siguiente nivel es el de los indicadores de gestión que requieren los nuevos roles. Otra vez la sala de diseño ve a nuestros viejos conocidos reunidos. Máximo facilita la creación de una tabla de riesgos asociados (Tabla 6.8) a una posible mala definición del sistema de decisión

64 que los lleva a establecer medidas para evitarlos o

minimizarlos.

riesgo: mitigación:

el sistema de decisión se define arbitrariamente sin considerar la visión estratégica

establecer objetivos de medición que correspondan a la visión estratégica, considerando las decisiones derivadas

las mediciones e indicadores que se utilizan en los proyectos son decididos sin consideración a las necesidades organizacionales

las mediciones que se usan en los proyectos son decididas en conjunto por la gerencia del proyecto y la PMO

cada proyecto tiene una versión distinta del sistem de decisión

se especifica claramente el procedimiento de medición con responsabilidades y controles

se tiene un sistema de decisión pero no se tienen datos se controla que los datos requeridos son colectados y analizados

no se puede reproducir una decisión basada en datos porque los datos no se guardan

se guardan los datos y los resultados de los análisis de manera de que puedan ser recuperados

no todos los interesados entienden el porqué de las decisiones

se difunden a los interesados los resultados y el análisis de las mediciones obtenidas

Tabla 6.8: Riesgos Asociados

Como siempre que Máximo facilita la reunión, los resultados coinciden con los esperados por el MPS-SW:

Medición (MED)

MED 1 Objetivos de medición son establecidos y mantenidos a partir de los objetivos de negocio de la organización y de las necesidades de información de procesos técnicos y gerenciales;

MED 2 Un conjunto adecuado de medidas, orientado por los objetivos de medición, es identificado y definido, priorizado, documentado, revisado y, cuando pertinente, actualizado;

MED 3 Los procedimientos para la recolección y el almacenamiento de medidas son especificados;

MED 4 Los procedimientos para el análisis de las medidas son especificados;

MED 5 Los datos requeridos son recolectados y analizados;

64

T2 ha decidido que su sistema de apoyo a la decisión basado en datos, que otras empresas llaman su sistema de medición, se

denomine en cambio “sistema de decisión”. Es en parte un nombre que no representa completamente la realidad, pero por ahora veamos a donde los lleva.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

74 Capítulo 6

Medición (MED)

MED 6 Los datos y los resultados de los análisis son almacenados;

MED 7 Los datos y los resultados de los análisis son comunicados a los interesados y son utilizados para apoyar decisiones.

Tabla 6.9: Proceso MEDICIÓN [SOFTEX, 2012a]

Máximo comparte con el grupo dos activos más, la plantilla de definición de mediciones (Tabla 6.10) y la plantilla de definición de indicadores (Tabla 6.11).

La situación respecto de las expansiones queda entonces así: Se trabajará con los contadores internamente. Los gemelos conducirán sendos equipos para desarrollar el nuevo sistema e integrarlo al existente, al que a su vez darán mantenimiento. No buscarán nuevos clientes para el sistema actual, la financiación deberá proveer la liquidez para mantener a T

2 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 participación en el negocio y las patentes que puedan surgir. Con la empresa que quiere fundir su software para farmacias con el existente de T

2 se llevará

adelante un convenio por el cuál ambas partes contribuirán para la generación del código requerido.

Nombre de la Medición

Estado de la Codificación

Cuenta el número de programas que han completado la codificación y el test unitario. Se la utiliza durante la etapa final para entender el trabajo que resta por hacer, comparándolo al estimado inicialmente. Permite planificar nuevas fechas de entrega con cierta anticipación

Mediciones Básicas Fuente de Datos Criterio de Validez

Fecha Planificada de finalización del Programa

Planilla de construcción de programas del líder técnico de proyecto

El plan está aprobado y bajo control de configuración

Fecha Real de finalización del programa

Subversion La fecha de ingreso es generada automáticamente por la herramienta

Atributos

Identificador Único de Programa (UPI)

Nombre del programador responsable

Fecha estimada de comienzo de la programación

Fecha real de comienzo de la programación

Fecha estimada de finalización de la programación

Fecha real de finalización de la programación

Mediciones Derivadas Cálculos utilizados

Programas Acumulados Planificados para la Semana

Cuenta; el número de programas cuya fecha de finalización según el plan cae dentro de la semana en cuestión.

Programas Acumulados Realizados en la Semana

Cuenta; el número de programas cuya fecha de finalización según Subversión ocurrió dentro de la semana en cuestión.

Tabla 6.10: Definición de Mediciones

QUE HA PASADO HASTA AHORA

31. Máximo ha contribuido a la definición de roles aportando la plantilla con la misión y función y la comunicación entre ellos.

32. Máximo ha hecho énfasis en la definición de los indicadores de gestión que requieren los nuevos roles basándose en los riesgos.

33. Máximo ha compartido con el grupo dos activos: la plantilla de definición de mediciones y la plantilla de definición de indicadores.

Boria et al.

Capítulo 6 75

El trabajo es intenso pero prolífico. La nueva estructura comienza a dar frutos en forma de acciones paralelas. El ambiente se electrifica y T

2 comienza a preparar su despegue. Claudio inicia acciones que incorporarán apoyo

financiero a la empresa. Marcela prepara los procesos con ayuda de una pasante de la Politécnica. Los gemelos cursan un taller de Scrum Master en California. Alfredo firma acuerdos y estrecha lazos. Mariano mantiene la continuidad con los clientes. Prácticamente, él solo sintetiza lo que T

2 era hasta una semana antes. Ana ocupa sus

últimas semanas antes de ser madre en dejar todas las decisiones arquitectónicas bien documentadas.

Fecha de creación <fecha>

Especificación del Indicador Para

<nombre del indicador, explica su uso>

Muestra del Indicador

Modelo de Análisis 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 análisis de causa profunda y notificar de la situación a la Alta Gerencia, el Comité de Control del Producto y el área de Gestión de la Calidad".

xxx

Criterio de Decisión Identifica los umbrales que disparan nuevas acciones o sirven para determinar futuras investigaciones

xxx

Mediciones Utilizadas Identifica las mediciones básicas o derivadas que se usan en la construcción del indicador

Medición Derivada: xxx Medición Derivada: yyy Medición Básica: zzz Medición Básica:aaa

Construcción del Indicador Describe los pasos a seguir en la construcción 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 medición derivada yyy, que es la media ponderada del valor hora del personal de proyectos. Grafique en diagrama de barras como se ejemplifica más arriba. Puede utilizar la planilla 'muestra' para generar el gráfico".

Medición Derivada: xxx Medición Derivada: yyy Medición Básica: zzz Medición Básica:aaa

Tabla 6.11: Definición 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 código y hay diferentes versiones instaladas. Los riesgos de no controlar los activos de la empresa son varios:

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

76 Capítulo 6

riesgo: mitigación:

si no sabemos donde se almacenan los productos y los resultados, perdemos tiempo y posiblemente trabajo

se adopta un sistema de gestión de documentación

si "no se puede encontrar una hoja en particular en el bosque" se pierde mucho tiempo identificando cada parte

se adopta un sistema de clasificación de los ítems almacenados

si los documentos se actualizan sin que los interesados se enteren pueden haber “choques” entre cambios

se adopta un criterio de línea base donde solo se puede modificar un documento de la línea base bajo estrictas reglas de control

si no sabemos quién cambió qué ni cuando puede ser difícil reproducir los motivos y decisiones alrededor de un cambio

se lleva la historia de los cambios de línea base

se sigue un proceso estricto para cambiar un producto

si las personas no respetan las reglas y los activos se almacenan en cualquier parte y cualquiera los accede y modifica se puede introducir mucho retrabajo

se controla que los productos de trabajo sean almacenados, leídos y liberados al uso siguiendo las formas del proceso

Tabla 6.12: Riesgos Derivados de la Falta de Control de Activos

Máximo introduce al grupo la noción de línea base de productos65

. Una línea 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 sólo pueden ser modificadas por medio del procedimiento establecido de control de cambios. El propósito de definir una línea 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 línea base es necesario definir claramente las responsabilidades respecto del producto en cuestión. Para T

2 hay tres tipos de archivos, según su contenido. Los hay de código, de documentación de línea

base y de comunicación. 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 especificación funcional, tienen una versión única que se mantiene simplemente con restricciones de acceso: Un dueño único, o al menos un rol único que puede modificarlo. En otros el dueño único es indeseable, en particular cuando se trata de código, donde es deseable que coexistan varias versiones. En definitiva la Tabla 6.13 muestra las propiedades de cada tipo.

TIPO Dueño acceso actualización versiones

código Múltiples check out check in y merge múltiples

línea base único (por rol) read only write del dueño única en vigencia

comunicación Nadie read only no aplica no se versionan

Tabla 6.13: Propiedades de Cada Tipo de Ítem de Configuración

Para almacenar cada uno de los diferentes tipos, el grupo tiene que tomar decisiones sobre el sistema que utilizarán. En principio adoptan para el código el modelo de [MOREIRA, 2010] de integración continua. El mismo producto freeware que estaban utilizando les sirve para almacenar el código con las características definidas en la Tabla 6.13. Hay varias posibilidades para los otros dos tipos: línea base y comunicaciones. Pueden usarse productos denominados DMS (Document Management Systems) o soluciones más 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 Dueño del Producto, las mediciones, el código y los casos de prueba. Puede que las carpetas a su vez estén 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 auditorías. Hay auditorías físicas que controlan que en un repositorio no hay menos de lo que tiene que haber ni más de lo que tiene que haber. De este modo se protege la integridad de la organización: No queremos distribuir caballos de Troya con nuestro software. También hay auditorías lógicas. En este caso lo que se pone en juego es la secuencia con que se llegó al producto. Por ejemplo, si para subir el código fuente al área de pruebas antes debe de haber pasado por tres etapas (digamos que primero se diseñó el caso de prueba que tenía que señalar un defecto, por falta del código a agregar; luego se codificó este código y se confirma

65

Hay otras líneas base: las de un cronograma y las de comportamiento de un proceso que veremos más adelante.

Boria et al.

Capítulo 6 77

que ya no lo rompía y en un tercer paso se lo integró corriéndolo contra el conjunto de casos de regresión), la auditoría lógica buscaría evidencia de que todos los pasos se han cumplido antes de aceptar que se suba el código en cuestión.

Otra vez la responsabilidad de escribir los procesos y catalogarlos cae en manos de Marcela, pero ya su experiencia le hace fácil lo que al principio le costaba esfuerzo. Marcela sigue utilizando los materiales que introdujera Máximo, definiendo los productos de cada procedimiento y las mediciones e indicadores pertinentes. La nomenclatura de los productos surge de las prácticas habituales, lo demás se ha decidido entre todos. La pasante ayuda a escribir y corregir los procesos.

El conjunto de prácticas así definidas cuando sea implementado cubre los resultados esperados de Gerencia de Configuración:

Gestión de Configuración (GCO)

GCO 1 Un Sistema de Gestión de Configuración es establecido y mantenido;

GCO 2 Los elementos de configuración son identificados con base en criterios establecidos;

GCO 3 Los elementos de configuración sujetos a un control formal son colocados bajo una línea base;

GCO 4 La situación de los elementos de configuración y de las líneas base es registrada a lo largo del tiempo y colocada a disponibilidad;

GCO 5 Cambios en elementos de configuración son controlados;

GCO 6 El almacenamiento, la manipulación y la entrega de elementos de configuración y líneas base son controlados;

GCO 7 Auditorias de configuración son realizadas objetivamente para asegurar que las líneas base y los elementos de configuración estén íntegros, completos y consistentes.

Tabla 6.14: Proceso GESTIÓN DE CONFIGURACIÓN [SOFTEX, 2012a]

QUE HA PASADO HASTA AHORA

34. Como van a crear productos con sistemas externos y usar otros en varios subsistemas Máximo ha inducido el uso de prácticas de gestión de configuración 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 están en su fase de implementación. Hay doce personas nuevas trabajando en T

2 y la sala de diseño ha pasado a ser la sala de uno de los dos equipos de Scrum. Media calle más

hacia el rio se abrió la sucursal de T2, con la dirección general y financiera, y el lugar que antes ocupaban los

escritorios de Alfredo, Ana y Claudio ahora es un pequeño laberinto de puestos de trabajo. Las ruedas de la producción giran aceleradas. Marcela tiene una preocupación: Poder juzgar si el crecimiento altera la calidad de los productos, para lo cuál necesita revisar lo que se produce y como se lo produjo.

Pudiéramos pensar que en una cultura que respeta la decisión de elegir los propios procesos no es necesario que alguien verifique que se los sigue, pero es el conjunto de la organización quién así lo requiere. Marcela conoce la técnica de las auditorías pero lucha contra el problema de su carencia de valor agregado. ¿Para qué, se pregunta, le sirve el resultado de auditoría a la organización? ¿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 cómo se usan los procesos y qué normas se aplican, pero vacila ante el retorno que pueda tener para el proyecto individual.

Cuando Máximo explicó la escritura de procesos a T2 partió de la plantilla de la Figura 5.12, pero luego utilizó

una planilla de hoja de cálculo, una línea para cada paso de proceso. Las columnas ahora representan los ítems de la plantilla: Propósito, Involucrados, Entradas Requeridas y así sucesivamente, incluso con la secuencia en previsión de que algunos pasos sean condicionales o se puedan ejecutar en paralelo con otros y no sean todos simplemente secuenciales. Con esa hoja de cálculo en la mano, Marcela tuvo una inspiración. Buscando entre sus carpetas en la computadora, encontró un webinar que bajó de SlideShare

66. Volvió a leerlo y decidió montar auditorías

proactivas, una contradicción en términos, pero que parece sugerido por el webinar. En vez de establecer un programa de auditorías frecuentes, Marcela se propone participar en eventos de lanzamiento de etapas, como el comienzo de cada sprint y las presentaciones al dueño del producto, y hacer la apertura recordándoles a todos los 66

http://www.slideshare.net/jorgeboria/qa-3-best-practices

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

78 Capítulo 6

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.

Puesto que el Dueño del Producto es interno a T2, Marcela decide utilizarlo en función de auditor de cierre.

Además, los miembros del equipo recibirán aleatoriamente mensajes de correo electrónico pidiéndoles que confirmen la ejecución del proceso en todos sus pasos. De ese modo las auditorías tendrían lugar sin entorpecer el desarrollo y sólo sobre aquellos puntos donde Marcela, como gerente de calidad, sienta necesidad de enfatizar.

Para introducir sus procesos de afirmación de calidad, Marcela le roba una técnica a Máximo y presenta los riesgos de no seguir sus procesos:

riesgo: mitigación:

si no se puede compartir los productos porque tienen diferentes formatos es posible que cometamos muchos errores involuntarios

verificar que los productos se adhieren a las reglas que son políticas de la organización

si las personas no siguen los procesos que hemos establecido no es posible asegurar que lo que sucede es lo que se espera y además de no aprender de los errores es probable que cometamos muchos

verificar que las personas siguen las reglas y los procesos que son política de la organización

si detectamos problemas pero no los comunicamos no van a resolverse solos y es posible que todos les pierdan el respeto a los procesos

comunicar los problemas y las disconformidades para que se puedan resolver

si no nos ponemos de acuerdo con las acciones a seguir para arreglar disconformidades o las que se acuerdan no se controlan es posible que se abandonen las buenas prácticas

cuando haya disconformidades o problemas hay que acordar un plan de acción para que se mantengan las buenas prácticas o se corrija el proceso

Tabla 6.15: Riesgos de no Auditar

Con esos riesgos presentes, los asistentes a la reunión aprueban el proceso de auditoría que presenta Marcela: Para cada proyecto,

1. revisar los riesgos 2. revisar el plan 3. seleccionar procesos críticos 4. seleccionar productos críticos 5. planificar auditorías 6. realizar auditorías 7. analizar resultados

Marcela también 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 próximo hito, escalar si no se arregló;

SEV 3 NEGOCIABLE: (a) Arreglar antes del próximo hito o (b) auditar en la próxima 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 Auditorías

El procedimiento “realizar auditorías” contiene un método de escalamiento que también es sometido al juicio de los socios. Dependiendo de la severidad, el procedimiento permite alcanzar niveles de dirección más y más 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.

Boria et al.

Capítulo 6 79

Figura 6.6: Proceso de Auditoría de Calidad

Para completar la reunión, el equipo de conducción revisa los resultados esperados correspondientes al proceso de Garantía de la Calidad.

Aseguramiento de la Calidad (GQA)

GQA 1 La adherencia de los productos a los estándares, 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, estándares 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 solución.

Tabla 6.17: Proceso ASEGURAMIENT DE LA CALIDAD [SOFTEX, 2012a]

QUE HA PASADO HASTA AHORA

35. Marcela ha utilizado la técnica de identificar riesgos para inducir la introducción de prácticas de aseguramiento de la calidad.

6.7 La pequeña fábrica de software con Scrum

Los mellizos han hecho progresos enormes con el desarrollo de software utilizando las prácticas de Scrum, poniendo a buen uso la inversión de T

2 en su formación 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 técnicas de Scrum, pero con el añadido de un sprint corto de análisis que requerirá la intervención 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 tecnología de desarrollo, por ejemplo creando un framework para scripts de pruebas y diversas extensiones a la herramienta de integración continua. El equipo de desarrollo “puro” se encargará de introducir mejoras sistemáticas, como nuevas funcionalidades y Refactoreo del código, para el contrato con los contadores. Dada la aceptación del tablero Kanban, los gemelos lo mantienen dentro del grupo de técnicas que van a aplicar en los sprints. Para aumentar la visibilidad y transparencia, los equipos utilizarán también un gráfico de “quemado” que muestre los avances y retrocesos en un sprint.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

80 Capítulo 6

Asimismo, los gemelos han compilado una lista de las componentes más importantes de Scrum y las han transformado en una lámina 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

Tomando en cuenta las técnicas que han incorporado, los gemelos realizan una autoevaluación del grado de cobertura que tienen los resultados esperados del MPS-SW en T

2. Revisan los resultados con Máximo y con

satisfacción reafirman que el camino elegido es el correcto. (Figura 6.8). T2 comienza a preparar su evaluación nivel

F.

Figura 6.8: Cobertura de los Resultados Esperados con Scrum y Kanban

QUE HA PASADO HASTA AHORA

36. Marcela ha utilizado la técnica de identificar riesgos para inducir la introducción de prácticas de aseguramiento de la calidad.

37. Los gemelos han implementado Scrum en dos equipos conservando los tableros Kanban para entender el estado del trabajo, añadiendo el gráfico de quemado de tareas y el Backlog del sprint como herramientas de control del proyecto.

38. Tahini-Tahini se prepara para la evaluación de Nivel F.

Gerencia de Proyectos en los Niveles G y F

Ka

nb

an

Ba

cklo

g

Jue

go d

e P

lan

if.

Vel

oci

da

d H

istó

rica

Tasa

de

"Qu

ema

do

"R

etr

osp

ecti

va

De

mo

Scru

m D

iari

oGerencia de Proyectos en los Niveles G y F

GPR 1 El alcance del trabajo para el proyecto está definido a

GPR 2 Las tareas y los productos de trabajo del proyecto son dimensionados, utilizando métodos apropiados a a a

GPR 3 El modelo y las fases del ciclo de vida del proyecto son definidos a a

GPR 4 El esfuerzo y el costo para la ejecución de las tareas y de los productos de trabajo son estimados con base en a a

GPR 5 El presupuesto y el cronograma del proyecto, incluyendo la definición de hitos (marcos) y puntos de a

GPR 6 Los riesgos del proyecto son identificados y su impacto, probabilidad de ocurrencia y prioridad de a a

GPR 7 Los recursos humanos para el proyecto son planificados considerando el perfil y el conocimiento necesarios

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 recolección,

GPR 10 Un plan general para la ejecución del proyecto es establecido con la integración de planes específicos

GPR 11 La viabilidad de lograr las metas del proyecto es explícitamente evaluada considerando restricciones y a a

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 a a a a

GPR 14 Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados con a a a a

GPR 15 Los riesgos son supervisados con relación a lo planificado a a a

GPR 16 La participación de las partes interesadas en el proyecto es planificada, supervisada y mantenidao a a

GPR 17 Revisiones son realizadas en hitos (marcos) del proyecto y conforme lo establecido en los planes a

GPR 18 Registros de problemas identificados y el resultado del análisis de cuestiones pertinentes, incluyendo a

GPR 19 Acciones para corregir desvíos de lo planificado y para prevenir la repetición de los problemas identificados a

Boria et al.

Capítulo 6 81

QUE HA PASADO HASTA AHORA DESDE EL PRIMER DIA

1. El consultor Máximo ha establecido el contacto inicial con el cliente, coincidentemente con un problema grave y facilitó su identificación.

2. Introdujo una primera técnica de análisis de causa, el diagrama de Ishikawa.

3. Utilizando la técnica llegó junto a los clientes a la conclusión 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 diagnóstico concreto que ya apunta a la mejora de procesos Máximo se ha concentrado en el problema inmediato para evitar uno mayor, comenzando por definir las características (o atributos) deseables de la solución.

5. Máximo ha sugerido el método Kanban, sin imponerlo, y se lo ha escuchado.

6. Máximo ha inducido el uso del tablero Kanban, sin dictarlo.

7. Introdujo los conceptos de sub-historia y estimación por tamaño.

8. Hay una clara definición del alcance del trabajo a realizar, encarnado en la lista de historias, con su correspondiente estimación de tamaño.

9. Se ha hecho una desagregación de las historias, donde el tamaño de estas la hacía útil.

10. Los conceptos de historia, sub-historia, desagregación y tarea se han entendido en la práctica y han sido aplicados. Se distingue entre ‘tarea’ y ‘sub-historia’.

11. Máximo ha mostrado que el uso del tablero Kanban es dinámico 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 fácilmente 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. Máximo ha incorporado mejoras al documento del Backlog, haciéndolo más sólido y más ú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 dinámico al Backlog y el presupuesto y añadir 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. Máximo ha introducido el Scrum diario para evaluar los avances día a día 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 organización incorpora una demostración del producto al final de cada sprint como criterio de aceptación por el usuario que sirve para evidenciar su participación.

21. El análisis de brecha ejercido como actividad continua muestra que los resultados esperados para GRE surgen de los procesos ya implementados.

22. Máximo ha introducido un corto procedimiento para definir la estructura de carpetas de un proyecto en el sitio de cada proyecto, que evidencia la implementación de GPR 8 y GPR 9.

23. Máximo ha definido y codirigido varias implementaciones del procedimiento de análisis retrospectivo, que brinda evidencia de GPR 17, GPR 18 y GPR 19.

24. Máximo ha redactado una política que la organización aprobó para establecer los lineamientos de lo que se espera del personal de T

2.

25. Máximo ha desarrollado un proceso que permite evidenciar las capacidades de proceso de Nivel G del MPS para las actividades de planificación, a través de la propuesta, y gestión de requisitos, a través del Backlog del producto y la evolución del tablero Kanban.

26. T2 ha alcanzado el nivel G del MPS - SW en una evaluación oficial

27. Máximo ha utilizado la técnica 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).

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

82 Capítulo 6

QUE HA PASADO HASTA AHORA DESDE EL PRIMER DIA

28. Máximo ha ayudado a revisar los riesgos de contratación de proveedores y estudiar las alternativas de comprar, reusar o fabricar introduciendo la técnica de la matriz de Pugh.

29. Para poder desarrollar más opiniones en paralelo Máximo ha inducido la técnica de “polinización cruzada” mediante un oportuno corte en la actividad.

30. Utilizando el análisis de riesgo como herramienta de exploración, Máximo induce las prácticas que implementan los resultados esperados del MPS correspondientes a la gestión de portafolio (o cartera) de proyectos.

31. Máximo ha contribuido a la definición de roles aportando la plantilla con la misión y función y la comunicación entre ellos.

32. Máximo ha hecho énfasis en la definición de los indicadores de gestión que requieren los nuevos roles basándose en los riesgos.

33. Máximo ha compartido con el grupo dos activos: la plantilla de definición de mediciones y la plantilla de definición de indicadores.

34. Como van a crear productos con sistemas externos y usar otros en varios subsistemas Máximo ha inducido el uso de prácticas de gestión de configuración como medida para proteger los distintos activos.

35. Marcela ha utilizado la técnica de identificar riesgos para inducir la introducción de prácticas de aseguramiento de la calidad.

36. Los gemelos han implementado Scrum en dos equipos conservando los tableros Kanban para entender el estado del trabajo, añadiendo el gráfico de quemado de tareas y el Backlog del sprint como herramientas de control del proyecto.

37. Tahini-Tahini se prepara para la evaluación de Nivel F.

Boria et al.

Capítulo 7 83

Parte III – Evolución

CAPÍTULO 7 - ORGANIZANDO LA ORGANIZACIÓN (NIVEL E DE MPS-SW)

Este capítulo tiene como objetivo discutir la implementación 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 Evaluación y Mejoría del Proceso Organizacional (AMP), Definición del Proceso Organizacional (DFP), Gestión de Recursos Humanos (GRH) y Gestión de Reutilización (GRU). Asimismo el proceso de Gestión de Proyectos (GPR) sufre su primera evolución, pasando a tener como propósito el utilizar un proceso definido para el proyecto como la base de la gestión, a través de planes bien integrados. También 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 Capítulo 4 para mayores detalles de estos atributos de proceso).

7.1 Una Empresa en Crecimiento Franco

Ni bien se terminan los mensajes de felicitación 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 también. Alberto Galarraga requiere duplicar el número de equipos para desarrollo y mantenimiento, para lo cuál utiliza el análisis de cartera que ya se aplicara para decidir el crecimiento. Trabajando con Marcela, que ha comenzado hace meses una maestría en ciencias de administración, intentan duplicar el proceso de selección de personal que funcionara relativamente bien en la creación de los dos primeros equipos de Scrum, pero agotada la cantera de jóvenes del último año de la carrera de Sistemas del Politécnico, se ven en figurillas para conseguir personal idóneo. Incluso cuando alguna persona está capacitada y su perfil es promisorio la incorporación es larga y dolorosa.

Acostumbrados ya a las técnicas de Máximo, se juntan con Marcela para analizar los problemas e identificar las causas raíz de los mismos. El tema de la reunión es el esfuerzo que demanda incorporar nuevos empleados:

1. No se tiene bien definido el perfil de empleado que se solicita 2. No hay un repositorio de conocimientos que ayude a minimizar el aprendizaje individual de técnicas y

métodos 3. No hay una definición del ambiente de trabajo que permita solicitar los recursos necesarios con

anticipación para que el recurso humano “entre en acción de inmediato” 4. No hay una inducción a los procesos de T

2 que acelere la formación de equipos

5. No se toma en cuenta para la selección de personal el retardo que requiere el análisis de los candidatos.

Como resulta ya tradición, se listan las medidas que se van a tomar, claramente en este caso alcanza con la negación de los problemas: Definir bien los perfiles, armar un repositorio de conocimiento, definir el ambiente de trabajo, etcétera.

Marcela es la encargada de realizar las búsquedas, selección y contrataciones en la nueva estructura y por ende le corresponde la mayoría de las actividades que surgen de la reunión. Trabaja con los gemelos en elaborar un modelo de competencias

67 para miembros del equipo, para eliminar rápidamente 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 organización. Comienza utilizando el formulario de misión y funciones de T

2 que es una variante de la plantilla que

presentáramos en el Capítulo anterior. Como ejemplo damos acá el formulario completado para el cargo de Ingeniero de Pruebas.

Misión 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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

84 Capítulo 7

Nombre del Cargo al Que Reporta

Gerente de Pruebas (matricialmente), Scrum Master (técnicamente), Equipo de Scrum (funcionalmente)

Misión (Porqué existe el cargo)

La misión 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 política exceder la satisfacción del cliente en nuestros envíos.

Factor(es) Crítico(s) de Éxito (Los aspectos más visibles del cargo)

1. Fallas detectadas por el usuario (previo a y en los primeros seis meses tras el lanzamiento)

2. Satisfacción de los ingenieros de software con los informes recibidos 3. Efectividad de los casos de prueba diseñados (rendimiento en errores por caso sobre

total de errores) 4. Eficiencia en la corrida de casos de prueba e informe de los resultados

Mediciones de Desempeño (Como se puede medir el éxito del cargo)

1. Número de errores no previamente detectados que se encontraron en el test de aceptación

2. Número de errores detectados por los usuarios en los primeros seis meses de uso que no fueron previamente detectados

3. Número de errores informados no reproducibles a partir del informe 4. Número de informes rechazados por los ingenieros de software 5. Número de defectos que pasan de ‘abierto’ a ‘cerrado’ sin pasos intermedios después

del informe 6. Rendimiento promedio de los casos de prueba diseñados 7. Número total de informes no rechazados por los ingenieros de software 8. Número de casos corridos por unidad de tiempo 9. Número de defectos reportados por unidad de tiempo

Funciones (Qué hace el ocupante del cargo para cumplir con la misión)

1. Interpreta el Plan de Pruebas de Software 2. Revisa y prueba documentos de requisitos (con técnicas como Gráficos de Causa y

Efecto) 3. Diseña Procedimientos de Prueba 4. Diseña Casos de Prueba 5. Ejecuta los procedimientos de prueba usando los casos de prueba 6. Informa los resultados de cada prueba 7. Diseña casos de prueba críticos para asegurar la identificación del error 8. Ejecuta los casos de prueba bajo un arnés de monitoreo de cobertura y analiza las

mediciones resultantes 9. Escribe scripts de casos de prueba para automatizar su ejecución 10. Entiende las prioridades entre casos y optimiza el tiempo para aumentar el rendimiento

Comunicación dentro de la organización

• 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.)

Boria et al.

Capítulo 7 85

Comunicación fuera de la organización

• En casos particulares, con los usuarios finales o un representante de ellos, para planificar y realizar la prueba de aceptación del usuario

Calificación para el cargo

• Tres o más años en posiciones técnicas relacionadas (redactor técnico, programador) o dos años de experiencia de prueba en proyectos similares

• Experiencia con integración continua • Experiencia con automatización de pruebas de software • Claridad de pensamiento y capacidad de comunicación • Buena memoria visual • Atención a los detalles • Experiencia en TDD deseable • Experiencia en métodos ágiles deseable

Educación formal

• Título superior o terciario técnico relacionado con la profesión • Certificaciones profesionales MS o semejantes, deseables.

Figura 7.1: Formulario Misión y Función

Esta es la definición del cargo. Para construir el modelo de competencias, Marcela tiene que considerar tres dimensiones de cada rol: Las competencias básicas, las competencias técnicas y las competencias específicas. Las mismas competencias básicas son requeridas para todas las posiciones. Una competencia básica, también llamada nuclear o elemental, se define como un conocimiento, habilidad o comportamiento esencial para que uno pueda actuar correctamente como personal efectivo de T

2. Las competencias básicas aplican generalmente a todos los

cargos de igual manera. Una competencia técnica es una habilidad particular relacionada específicamente con el rol en cuestión, por ejemplo el ingeniero de pruebas tiene que ser capaz de realizar el diseño de un caso de pruebas. Las competencias específicas de un cargo son aquellas que son distintivas de los procesos de T

2, por

ejemplo un Scrum Master debe poseer las competencias que le permitan hacer funcionar a su equipo pero además debe hacerlo de la manera que se espera en T

2, es decir siguiendo sus políticas, procesos y procedimientos.

Típicamente las competencias básicas y las técnicas son utilizadas en el proceso de selección, aunque a veces los empleados pueden acceder a capacitación para adquirir o extender sus competencias técnicas, y existen programas de sensibilización respecto de las competencias básicas.

A continuación se presenta una lista de las competencias básicas que Marcela y los gemelos entienden son indispensables para trabajar en T

2, con la descripción del comportamiento esperado en cada una:

Ética e Integridad: Constantemente se comporta con honradez y admite los errores cuando le son señalados, 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, esforzándonos constantemente para alcanzarlos y hasta superarlos;

Comunicación: Se comunica efectivamente verbalmente y por escrito;

Resolución 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 desempeño productivo;

Tecnología: Utiliza el equipamiento y la tecnología de manera segura, eficiente y eficaz;

Seguridad: Cumple con las normas de seguridad, observa las prácticas de trabajo seguras, y proporciona información sobre cuestiones de seguridad;

Autogestión: Maximiza el tiempo propio y aprovecha su talento para alcanzar los objetivos de la organización;

Crecimiento: busca oportunidades para innovar y mejorar continuamente;

Adaptación: desarrolla enfoques eficaces para la gestión de sí mismo en el cambio organizacional;

Trabajo en equipo: Trabaja efectivamente con el equipo de trabajo y aún con aquellos que están fuera de la línea formal de autoridad para lograr los objetivos organizacionales;

Prudencia: Utiliza los recursos basándose sensatamente en las prioridades de la organización.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

86 Capítulo 7

Además, el modelo que desarrollan contiene las competencias técnicas para cada uno de los cargos. Todavía no han desarrollado un modelo completo, que debiera contener un mecanismo de evaluación del grado de adecuación del personal al modelo, así como las competencias específicas, cuyos detalles surgirán de los procesos que deban seguir los roles. Por ahora, Marcela se conforma con tener una descripción 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 búsquedas técnicas.

Por ejemplo, para el cargo de Ingeniero de Pruebas, en el proceso de “Diseño de la Estrategia de Pruebas” el propósito 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 “Análisis 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 técnicas como Gráficos de Causa y Efecto. Utiliza estas técnicas de generación sistemática de pruebas para identificar requisitos faltantes o encontrados entre sí. Estos son los elementos técnicos que servirán para la selección, las entrevistas y los exámenes 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 documentación de software. Buscando en un el mercado, las etapas de difusión del llamado, los filtros iniciales de las respuestas, las comunicaciones, las entrevistas, la preparación de ofertas y la contratación resultaron en una demora de varias semanas. Marcela vuelve a reunir a los socios para proponerles una actitud proactiva en la búsqueda. Usando los números de sus búsquedas y datos del estudio de búsqueda de personal que la auxilia, advierte sobre las demoras que se presentan en la contratación 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 mitigación que consiste en ir generando una base de datos de candidatos. Su mecanismo será el que sigue: una vez por mes se reúnen los socios para revisar la cartera de proyectos y hacer ajustes al plan estratégico. En esa reunión se establecerán los potenciales cargos a cubrir. Con ese fundamento, Marcela armará un plan táctico de incorporaciones.

Marcela presenta la tabla (Tabla 7.1) con las actividades del proceso de reclutamiento e incorporación de personal. Además, 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, cuántas búsquedas de currículo 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 búsquedas (Tabla 7.2). De ese modo puede calcular cuántas instancias de cada actividad tiene que realizar en cada caso y con qué anticipación. 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 técnicas, 6,4 entrevistas funcionales, que se envían a 12,9 candidatos seleccionados entre 143,2 curriculum vitae de la base de datos. Si las oportunidades no se concretan la búsqueda 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 técnicas

6 Realizar entrevistas técnicas

7 Realizar oferta inicial

8 Obtener aprobación

9 Realizar oferta final

10 Contratar

11 Inducir conocimiento empresa

12 Capacitar en el rol Tabla 7.1: Actividades de Reclutamiento e Incorporación de Personal

Boria et al.

Capítulo 7 87

De este modo Marcela tiene un proceso de incorporación de personal y un sistema de medición que permiten anticipar el tiempo y esfuerzo del reclutamiento. Esto permite cubrir las previsiones para la selección, ahora falta eliminar los riesgos en el proceso de incorporación, 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 primerísimo lugar, Marcela propone reforzar la estructura y rol de su Gerencia de Recursos Humanos. He aquí sus argumentos, nuevamente analizados como riesgos a T

2:

Desarrollo de Recursos Humanos

riesgo: mitigación:

si crecemos sin previsión de recursos humanos vamos a tener mucha demora en ingresar personal y no siempre podremos responder a la demanda

Estudiar las necesidades estratégicas de la organización y prever las necesidades de recursos, anticipándonos a ellas

Identificar los candidatos a ocupar puestos y desarrollar relaciones para reclutarlos

dados nuestros particulares procesos es probable que el

período de aprendizaje y ajuste a las necesidades de T2

sea demasiado largo para nuestros negocios

identificar las necesidades estratégicas de capacitación de personal

generar un plan de largo plazo para cubrir las necesidades de capacitación

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 propósito

si queremos ser proactivos en la mejora de desempeño debemos entender como evaluarlo y mejorarlo constantemente o corremos el riesgo de invertir en lo que no rinde

definir métodos objetivos de medir desempeño 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 interés en cada disciplina y apoyarla

generar medios de difundir y compartir conocimiento y habilidades entre pares

Tabla 7.3: Riesgos a T2 Derivados de Políticas Pobres en Recursos Humanos

Por suerte para todos, varias de las actividades ya están en marcha. Por ejemplo, el método adoptado para revisar la cartera de proyectos incluye ya estudiar las necesidades estratégicas de la organización y prever las necesidades de recursos, cosa que Marcela propone profundizar aún más utilizando las herramientas de un modelo de competencias. También el modelo de competencias, junto con el proceso de reclutamiento, va a ayudar en la identificación de los candidatos a ocupar puestos y desarrollar relaciones para reclutarlos. Marcela se

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

88 Capítulo 7

propone contratar una persona de recursos humanos que tenga conocimientos de modelos de competencias y diseño instruccional, una combinación no frecuente pero tampoco extravagante. Juntando esto con el análisis mensual de cartera se pueden identificar las necesidades estratégicas de capacitación de personal y de ese modo generar un plan de largo plazo para cubrir las necesidades de capacitación e implementar las partes principales del plan en el corto y mediano plazo, como plan táctico. Por supuesto, habrá que llevar claros registros de los entrenamientos realizados y validar que los entrenamientos cumplen con su propósito.

En ese sentido el modelo de competencias adoptado permite, o deberá permitir, el definir métodos objetivos de medir desempeño y utilizarlos para mejorar el rendimiento del personal e identificar oportunidades de mejoras. Midiendo ese desempeño antes y después del entrenamiento realizado permite adjudicar la mejora de desempeño a la capacitación. 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, amortización de los metros cuadrados ocupados, etcétera) y desempeño individual (el ingreso que se puede adjudicar al desempeño 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 capacitación.

Se pueden asimismo hacer análisis del período de repago, el valor presente de la capacitación y otros análisis financieros. A punto de recibir su título de Magister en Ciencias de la Administración, Marcela confía en que los análisis de tipo financiero aplicados a todo tipo de inversiones les rendirán beneficios a la hora de tomar decisiones. Si bien esto puede parecer una forma de “cazar mosquitos a cañonazos”, es una necesaria pauta cultural para tomar decisiones basadas en datos y no en sensaciones. En las palabras de D. Edwards Deming, “In God we trust, all the others bring data” (En Dios confíamos, los demás vengan con datos)

68.

COMPETENCIA POR NIVELES DE UN GERENTE DE CUENTAS

COMPETENCIA

Fase 1 2 3 4 5

Tarea Lego Principiante Junior Senior Experto

Apoyo a la Venta

Participa de la reunión inicial

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 desambiguación

Toma apuntes, hace preguntas de seguimiento y desambiguación; y participa en las discusiones

Conduce y facilita la actividad

Realiza la presentación del método de desarrollo de T2

No conoce el material y no es capaz de presentarlo

Ayuda en la explicación sobre el uso de los materiales en el ejercicio

Presenta el material con mínimos problemas y conduce los ejercicios

Prepara la presentación, presenta el material sin problemas y conduce los ejercicios

Prepara la presentación, presenta el material con aplomo 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

Evalúa cambios midiendo su impacto en costo y tiempo de entrega y gestiona los cambios en sí

Mantiene la integridad de la propuesta sin confrontar al cliente y se asegura que los cambios de impacto se reflejan en el alcance

Coordina los cambios con todos los interesados y balancea los intereses colectivos para llegar al ganar-ganar

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ó Máximo. En la versión utilizada, cada paso crítico 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 descripción de lo que se entiende por ese grado (Tabla 7.4). Asimismo, la Tabla 7.5 muestra la lista evaluativa correspondiente

68

En realidad no hay confirmación de que haya sido Deming quién dijo esto, pero es parte del mito que le acompaña. Ver http://en.wikipedia.org/wiki/W._Edwards_Deming

Boria et al.

Capítulo 7 89

para la primera tarea. De ese modo es posible relacionar el rendimiento con los individuos y medir el resultado de la capacitación como la diferencia de productividad antes y después del evento.

LISTA DE EVALUACIÓN

Fase de Apoyo a la Venta

Participa de la reunión inicial

Tarea

Toma notas

Hace preguntas adecuadas para

que todos entiendan mejor

la discusión

Participa y facilita la reunión

Es capaz de sintetizar los resultados alcanzados

Casi Nunca (0% - 10%)

Muy Poco (1% - 33%)

A Menudo (34% - 66%)

Casi Siempre (67% - 95%)

Sistemáticamente (96% - 100%)

Tabla 7.5: Lista evaluativa Correspondiente a la Primera Tarea

Marcela implementa las acciones y llama a Máximo para revisar su pertinencia. Máximo se muestra complacido de los progresos logrados y sugiere evaluar las prácticas contra los resultados del modelo MPS, esta vez contra el proceso de Gestión de Recursos Humanos:

Gestión de Recursos Humanos (GRH)

GRH 1 Las necesidades estratégicas de la organización 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 organización 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 organización;

GRH 5 Un plan táctico de entrenamiento es definido, con el objetivo de implementar una estrategia entrenamiento;

GRH 6 Los entrenamientos identificados como responsabilidad de la organización son conducidos y registrados;

GRH 7 La efectividad de los entrenamientos es evaluada;

GRH 8 Criterios objetivos para evaluación del desempeño de grupos e individuos son definidos y supervisados para proveer informaciones sobre este desempeño y mejorarlo;

GRH 9 Una estrategia apropiada de gestión de conocimiento es planificada, establecida y mantenida para compartir informaciones en la organización;

GRH 10 Una red de especialistas en la organización 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 organización.

Tabla 7.6: Proceso GESTIÓN DE RECURSOS HUMANOS [SOFTEX, 2012a]

Máximo está contento, sus ahijados están resultando mejores que el profesor.

QUE HA PASADO HASTA AHORA

38. Tahini-Tahini alcanza el nivel F del modelo MP – SW.

39. Marcela y los gemelos analizan las causas-raíz de las dificultades para contratar personal idóneo y hacerlos rendir en corto plazo.

40. Marcela y los gemelos comienzan la construcción de un modelo de competencias para Tahini-Tahini.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

90 Capítulo 7

QUE HA PASADO HASTA AHORA

41. Marcela propone un mecanismo de selección proactivo para la contratación de personal.

42. Máximo revisa y aprueba la implementación elegida de los procesos de Gestión de Recursos Humanos.

7.2 La Necesidad de Activos de Proceso

Al hacer el análisis de las necesidades de capacitación es frecuente encontrarse que algunos de los recursos necesarios para ayudar al personal en la realización de sus tareas están faltando: Planes, herramientas de software, guías de apoyo, formularios tipo, estándares de trabajo, evidencia anecdótica y numérica del desempeño 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 realización de las tareas cotidianas. Su ausencia representa una mala inversión, 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 capacitación centralizada es solo una parte de la solución: La organización 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 organización, una corriente de grupos de interés en cada disciplina y apoyarla con múltiples medios de difusión y compartir conocimiento y habilidades entre pares, como blogs internos, fórums internos, wikis para almacenar conocimiento, refuerzo de las actitudes de compartir con los que saben menos, etcétera. Marcela elige una herramienta de gestión de conocimientos entre varias opciones

69 y con la ayuda de Armando la implementan en la organización. De inmediato se produce

una corriente de interés que empieza a generar artefactos que poco a poco se van agregando a aquellos activos que ya hemos descripto, almacenados en la red interna de T

2.

Con el crecimiento organizacional una empresa que alcanzó esto por estar relativamente bien organizada, puede encontrar que en realidad esa evolución la ha hecho retroceder, empujada por el influjo de personal nuevo y la multiplicación del número de proyectos, hasta recalar en un mundo de procesos caóticos. La solución 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 fáciles de usar, aun cuando se deben detallar los procesos para que se pueda evaluar fácilmente su aplicación o falta de ella en cada proyecto individual, según sus características. Un proceso demasiado flexible no es un proceso evaluable. Ya vimos en el Capítulo 5 qué atributos describen un proceso, con la plantilla que introdujo Máximo. Sin cambiar esa estructura, lo que se pide es que los pasos para su ejecución 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 espontáneamente 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 inspiración para la gestión de proyectos, por lo que decide que en “su” biblioteca de procesos habrá siempre lugar para definir ciclos de vida en uso en T

2 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 recién nacido, y que tienen que ver con Feature Driven Development

70.

Dada su experiencia con el reclutamiento de nuevos empleados y los objetivos fijados para controlar desempeño, sobre todo como medida de la efectividad de los entrenamientos, Marcela está segura de la utilidad de mantener un repositorio de datos de desempeño de los procesos. La plantilla de definición de procesos ya incorpora mediciones, pero Marcela va agregando indicadores de desempeño, 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 ningún sentido, Marcela propone que sólo bajo excepciones justificadas y aprobadas por la dirección (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

http://bsix12.com/knowledge-sharing-tools/ es un buen punto para empezar la búsqueda. 70

Ver Capítulo 3

Boria et al.

Capítulo 7 91

seguimiento71

, se pueden comparar resultados. Si los caminos para ejecutar los procesos fueran individuales la comparación de resultados no sería posible.

La ‘sanción’ de un proceso, según piensa Marcela, se efectiviza en la publicación 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 anticipación para la compra. Por otra parte, la experiencia muestra que la incorporación de personal con experiencia en otro tipo de proyectos a los proyectos ágiles es dificultosa, por lo que un patrón de la capacitación a recibir es sumamente útil. Marcela opta por un mecanismo que hace la incorporación menos traumática: 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 primeros días en T

2 están pautados en la Guía de Incorporaciones, desde la presentación a la dirección, el recorrido

de las instalaciones, las pautas de uso de la BiPro, los cursos en línea y el ambiente de trabajo.

La BiPro contiene prácticamente cualquier cosa. Marcela ha ido acumulando experiencias propias y ajenas, filtrando los mejores activos de la herramienta de gestión 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 sección que sigue. Este plan permite a cualquiera que esté interesado conocer las necesidades de mejoras de procesos que han sido reconocidas por la organización y como se propone ésta cubrirlas, identificando las estrategias, enfoques y acciones para encarar mejoras de procesos.

En el nivel más alto hay una descripción de la arquitectura de los procesos organizacionales, que se instancian en el Proceso Maestro de T

2, con su Guía de Adaptación para su uso en los proyectos. Marcela ya ha incorporado

algunas Políticas Organizacionales, para comunicar los principios guía de la organización, y Descripciones Organizacionales de Ciclos de Vida, que permiten guiar la determinación de las fases principales de un proyecto o producto sobre las cuales se pueda determinar el alcance del planeamiento.

También hay un Ejemplo de Plan de Proyecto, que ilustra el nivel apropiado de estimación, definición de roles, y otros atributos críticos relacionados al planeamiento de un proyecto, y Definiciones Operacionales de Mediciones para proveer descripciones precisas e inequívocas de los atributos de las entidades que puedan ser útiles medir en un proceso. Para auxiliar en la estandarización de los procesos hay plantillas y guías de uso, como las Plantillas para Procedimientos y Criterios de Pruebas de Validación y Verificación, y Normas de Desarrollo de Producto. En general hay claras definiciones de las expectativas de la organización para procesos, herramientas, técnicas y métodos a ser usados en el ambiente de desarrollo. Hay también otras guías particulares, como las Guías de Análisis de Decisión para guiar la selección de temas que deben ser sometidos a evaluaciones formales. Ilustrar varios atributos que deberían considerarse en la evaluación de diseño de componentes de producto

Hay asimismo materiales para ayudar en la selección y uso de técnicas y herramientas, como los Ejemplos de Técnicas de Extracción de Requerimientos para proveer apoyo con ejemplos de técnicas para la recolección 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 más relevantes. Hay más, pero para muestra basta con señalar 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 guía de uso y los criterios asociados para su elección ante alternativas.

Puesto que algo tan diverso y amplio es difícil 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 aplicaciones para reuso de conocimiento. Desarrolladas en primera instancia para el reuso de software

72, las wiki

semánticas, como se las llama, simplifican el almacenamiento de información al utilizar algoritmos que relacionan los contenidos de manera automática, 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 rápidamente. Por eso el uso de auto organización disminuye el esfuerzo y permite

71

Ver en Capítulo 6 Aseguramiento de la Calidad 72

DECKER, B., et al, 2005.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

92 Capítulo 7

que una empresa pequeña como T2 pueda almacenar con facilidad el aprendizaje que se genera a partir de la

herramienta de gestión de conocimiento.

Marcela mantiene un indicador de uso de los elementos de la BiPro. Por las herramientas de soporte elegidas, es siempre más fácil acceder al documento o conocimiento en la biblioteca que guardar copias en carpetas locales y accederlas en ocasión de su uso. Esto hace que las estadísticas 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 práctica. Analizando estos datos llegan a las siguientes conclusiones, que publican en la BiPro para su difusión y uso.

Orientación Sugerida por Perfil de Sprint

condición elección sugerida

el tamaño de la funcionalidad excede la capacidad del sprint

Kanban con un mini-equipo dedicado

la funcionalidad es nueva y tiene muchas aristas inexploradas

mini-espiral de Boëhm dentro del sprint o partir el sprint a partir del análisis para hacer demos más frecuentes

la funcionalidad es totalmente central al funcionamiento del producto (control)

usar TDD a full e inspecciones además de programación de a dos

el dueño del producto tiene dudas sobre la funcionalidad que sugiere

ampliar el juego de la planificación hasta incluir un bosquejo de modelo dinámico usando técnicas de UML y FDD

disminuir la duración del sprint para hacer demos más frecuentes

el equipo no tiene miembros con experiencia usar inspecciones y programación de a dos con el scrum master en uno de los roles

la arquitectura es crucial en el desempeño futuro del producto

usar un sprint para definir la arquitectura, a la manera de FDD, y decidir después sobre Kanban, Scrum o Scrumban

Tabla 7.7: Orientación Sugerida por Perfil de Sprint

Cuatro semanas después de contar con la presencia del consultor en las oficinas de T2, se vuelve a llamar a

Máximo para la revisión del proceso Definición del Proceso Organizacional, con resultados perfectos.

Definición del Proceso Organizacional (DFP)

DFP 1 Un conjunto definido de procesos estándar es establecido y mantenido, en conjunto con la indicación 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 estándar son identificados y detallados, en conjunto con el desempeño esperado del proceso;

DFP 4 Las descripciones de los modelos de ciclo de vida a ser utilizados en los proyectos de la organización son establecidas y mantenidas;

DFP 5 Una estrategia para la adaptación del proceso estándar es desarrollada considerando las necesidades de los proyectos;

DFP 6 El repositorio de medidas de la organización es establecido y mantenido;

DFP 7 Los entornos estándar de trabajo de la organización son establecidos y mantenidos;

DFP 8 Reglas y guías para la estructuración, formación y actuación de equipos son establecidas y mantenidas.

Tabla 7.8: Proceso DEFINICIÓN DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a]

QUE HA PASADO HASTA AHORA

43. Marcela incorpora una herramienta para compartir conocimiento entre los miembros de Tahini-Tahini.

44. Marcela define una arquitectura para organizar los activos de proceso.

Boria et al.

Capítulo 7 93

QUE HA PASADO HASTA AHORA

45. Marcela define indicadores a partir de una base de datos de desempeño 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 incorporación de personal nuevo a los equipos.

48. Marcela conecta la herramienta de gestión 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 guía de uso.

50. Máximo revisa los procesos y activos de Definición del Proceso Organizacional y los aprueba.

7.3 Retrospectivas y procesos

Así como el crecimiento del personal y la multiplicación de los proyectos puede, como ya se dijo, recalar en un mundo de procesos caóticos, la aceleración del cambio puede hacer que se pueda llegar a confundir cambios de proceso como mejora de proceso, perdiendo tiempo y dinero. Marcela es un espíritu práctico con formación contable y de sistemas, una combinación 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 estratégicos de proceso de T

2, lo que se realiza durante las reuniones mensuales de revisión de cartera. La revisión permanente de

esos objetivos se hace a partir del sistema de mediciones de la capacidad de los procesos que Marcela pusiera en práctica.

Con estos datos Marcela mantiene su plan de mejoría basado en la medición de la capacidad y los objetivos estratégicos de negocio. El plan parte de actividades que realizan los proyectos, en particular las autoevaluaciones que se hacen al final de cada sprint, llamadas retrospectivas

73, donde se discuten tanto nuevas necesidades como

mejoras ya realizadas, para seleccionar y adoptar mejorías que se difunden implantándolas en los otros proyectos. El plan es uno más 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 confección de los activos, sean estos procesos, procedimientos o guías, o todos los anteriores, y se les asigna su dedicación, 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 práctica que se ha adoptado es la de hacer que todos los expertos trabajen a la vez el mismo día de la semana, para obtener resultados más rápidos y asegurar su participación. La asignación es por múltiplos de 10% de dedicación semanal, de modo que si se considera la semana de cuarenta horas cada múltiplo es de medio día. De ese modo es posible controlar los compromisos con el proyecto.

La inclinación de Marcela por los números la lleva a que sea sistemática al medir los resultados obtenidos contra los resultados esperados del plan de mejorías, que documenta en cada caso y presenta en las reuniones mensuales de revisión de cartera. La planificación estricta no le impide incorporar mejoras oportunistas cuando las haya, como las ideas que Ana trae de sus cátedras. Marcela revisa por su cuenta los resultados del proceso Evaluación y Mejoría de Procesos Organizacionales y, satisfecha con los resultados, envía un informe a Gerencia General recomendando comenzar preparativos para una evaluación de nivel E del MR-MPS SW.

Evaluación y Mejora del Proceso Organizacional (AMP)

AMP 1 La descripción de las necesidades y los objetivos de los procesos de la organización son establecidos y mantenidos;

AMP 2 Las informaciones y los datos relacionados al uso de los procesos estándar para proyectos específicos existen y son mantenidos;

AMP 3 Evaluaciones de los procesos estándar de la organización son realizadas para identificar sus puntos fuertes, puntos débiles 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;

73

Ver Capítulo 3

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

94 Capítulo 7

Evaluación y Mejora del Proceso Organizacional (AMP)

AMP 6 Un plan de implementación de mejoras en los procesos es definido y ejecutado, y los efectos de esta implementación son supervisados y confirmados con base en los objetivos de mejora;

AMP 7 Activos de proceso organizacional son implantados en la organización;

AMP 8 Los procesos estándar de la organización son utilizados en proyectos a ser iniciados y, en caso de que sea pertinente, en proyectos siendo llevados a cabo;

AMP 9 La implementación de los procesos estándar de la organización 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 EVALUACIÓN Y MEJORA DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a]

QUE HA PASADO HASTA AHORA

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 Evaluación y Mejoría de Procesos Organizacionales.

7.4 Disminución de costos por reuso de componentes

Pero antes de alcanzar el nivel E, T2 debe atender algunos otros procesos. A pesar de los esfuerzos de

contratación de personal, creación y difusión 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 dirección y cuando es invitada a revisar artefactos en conjunto con el equipo que lo genera) señala que ya que se usa el algoritmo que aplicara uno de sus alumnos en el trabajo de graduación para la auto-organización del conocimiento en las wikis, se podría 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 selección 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 técnicos 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 organización. Esto sugiere que haya algunos criterios especiales para su construcción y prueba. La primera consideración es el ajuste arquitectónico. Las componentes se agrupan por tecnología e interfaces, y su versión es actualizada constantemente. Las API se publican en un reporte que se indexa para ser utilizado más adelante. Esto evita que haya que hacer un proceso manual de búsqueda, porque los filtros son automáticos, lo que pone a disposición del equipo un reservorio de oportunidades a explorar justo cuando están 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 diseño 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 quién decide los criterios.

Lo resuelto es que los proyectos incorporen a su procedimiento de planificación, en el momento de establecer el Backlog del sprint, un análisis de opciones que sigue los pasos del proceso de reuso. Brevemente, los pasos son los siguientes:

1. Enunciado de objetivos, es decir, para qué se busca reusar componentes. Algunos ejemplos son acortar plazos sin pérdida de calidad, permitir mantener la duración del sprint desarrollando más puntos de usuario, bajar costos, etcétera.

2. Elección de atributos deseables, donde el equipo discute si vale la pena o no seguir el proceso de reuso, a partir de los requisitos, el diseño 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. Identificación de candidatos, que se realiza automáticamente usando el algoritmo neural basado en los atributos elegidos.

4. Evaluación de candidatos, lo que se realizan por pruebas ad-hoc, que son diseñadas contra los atributos elegidos, y la historia de la componente.

Boria et al.

Capítulo 7 95

5. Análisis de opciones, esto se realiza siguiendo un método prestablecido que utiliza una matriz de Pugh como la que ya se vio en el Capítulo 4. Una de las opciones es siempre no utilizar una componente para reusar.

6. Selección de alternativas, también siguiendo el método anterior.

7. Adopción 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 evaluación de alternativas con resultado negativo y se decida no usar ninguna componente.

8. Evaluación del resultado, se compara con los objetivos enunciados en el primer paso para continuar armando la historia de la componente y añadir los conocimientos adquiridos.

Figura 7.2: Análisis 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 código. Los criterios requieren que se añada una documentación especial para guiar en el reuso a quienes en el futuro seleccionen la componente, que la prueba sea exhaustiva y el criterio de aceptación sea cero defectos, que el diseño y la arquitectura, o arquitecturas con las que interactúa normalmente también formen parte de esa documentación, que debe ser inspeccionada formalmente. Además hay un criterio especial para el análisis estático del código, que requiere seguir normas organizacionales

74, como la indentación

75, los comentarios, los nombres de variable y la documentación de

cambios en el mismo código. La biblioteca de componentes para reuso tiene su propio mecanismo de gestión de configuración, y su propia rastreabilidad entre activos, que es simplemente un subconjunto con restricciones mayores que las normales, del sistema de gestión de configuración organizacional para líneas de base. Los usuarios de este subsistema reciben los informes que se realizan sobre los activos así gestionados.

QUE HA PASADO HASTA AHORA

53. Ana sugiere introducir reuso de componentes como práctica para aumentar la capacidad de los equipos.

54. Se define y despliega un proceso de creación, adopción y mantenimiento de componentes de reuso con un procedimiento para decidir cuando se reusa una componente y se extiende la guía de ajuste del proceso para que contenga este criterio.

Gestión de Reutilización (GRU)

GRU 1 Una estrategia de gestión de activos es documentada, contemplando la definición de activo reutilizable, además de los criterios para aceptación, certificación, clasificación, discontinuidad y evaluación de activos reutilizables

GRU 2 Un mecanismo de almacenamiento y recuperación de activos reutilizables es implantado

GRU 3 Los datos de utilización de activos reutilizables son registrados

GRU 4 Los activos reutilizables son periódicamente mantenidos, según 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 GESTIÓN DE REUTILIZACIÓN [SOFTEX, 2012a]

7.5 Utilizando el conocimiento histórico en los proyectos

A partir del nivel E, algunos resultados esperados de los procesos evolucionan y otros nuevos se incorporan. La gestión de administración del proyecto se debe ahora realizar a partir de un proceso especialmente definido para el proyecto, seleccionado en base a activos de la organización. Dicho proceso debe contemplar todos los elementos constitutivos del proyecto desde la construcción de planes integrados a su cierre. Marcela es consciente de las ventajas que estos cambios arrojan, pero su espíritu práctico la obliga a ponerle un marco firme en las necesidades de T

2.

74

En los métodos ágiles los equipos escogen las normas que utilizarán, pero al promover una componente a la biblioteca de componentes para reuso es necesario seguir normas de la organización.

75 Se consigue fácilmente con herramientas de “Pretty Printing”

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

96 Capítulo 7

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 ejecución. Su argumento es que sin uniformidad no hay claridad en la interpretación 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 objetiva, es un atributo de la relación entre un objeto y el sujeto que evalúa la calidad

76. No existe la calidad

“absoluta”, siempre es calidad “para” y en un contexto. Por lo mismo, la calidad está ligada a las expectativas de los clientes. En el modelo de Kano

77 se puede ver que hay tres tipos de requisitos: los llamados Indispensables,

también llamados básicos, 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 satisfacción. Por otra parte, los requisitos lineales son los más visibles, los más usuales. La satisfacción del cliente es proporcional al grado de satisfacción de los mismos, mientras más se cumple con los objetivos, mayor la satisfacción del cliente y viceversa. Por ejemplo la capacidad del baúl de un automóvil, o la cantidad de kilómetros que se pueden hacer sin repostar en el mismo. A menudo los clientes exigen explícitamente estos requisitos. Hay una tercera categoría llamada por Kano Requisitos Atractivos, también llamados “deleites”. Son aquéllos que el cliente ni espera ni requiere explícitamente (sorpresas positivas). Cubrirlos lleva a satisfacciones excepcionales pero si no se los cubre no hay sentimiento de insatisfacción. Un ejemplo puede constituir un canasto para transportar infantes o una rueda extra al comprar una bicicleta. Lo que se saca en conclusión del modelo de Kano es que lo que se define por calidad es la percepción que el cliente tiene, no los atributos en sí. Hay atributos esperados, por supuesto, que marcan el mínimo, 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 normalización y la consistencia que deviene de ella.

Por lo tanto, en una reunión mensual de análisis de cartera, levanta la solicitud de discutir varios temas relacionados. Los gemelos aportan señalando 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 espontáneas de los equipos de proyecto, que las responsabilidades sobre las decisiones pueden demorar el proyecto si no se expresan correctamente con antelación. 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 reunión concluye Marcela, que es la encargada de las minutas de la reunión, sale con la lista de acciones pendientes:

a. utilizar la historia de los sprints en el juego de planificación para tener una mejor aproximación al esfuerzo real

b. fijar el uso78

del estándar de recursos necesarios en los planes de proyecto para poder comenzar su provisión anticipadamente (escritorio, PC, SW, etc.)

c. establecer normas de comportamiento de los equipos y hacerlas respetar, con las variantes necesarias

d. darle a las experiencias el lugar importante que merecen y almacenar juiciosamente los resultados para aprovecharlos en futuros proyectos

e. establecer procesos estándar y mecanismos de elección entre ellos, con criterios para elegirlos y adaptarlos.

76

[PIRSIG, 1974], Zen y el arte del Mantenimiento de la Motocicleta. Puede decirse que es uno de los ensayos más 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, patológicamente obsesionado con la cantidad.

77 http://kanomodel.com/

78 De poco vale tener una guía si no se la sigue!

Boria et al.

Capítulo 7 97

Marcela sonríe, ya muchas de las acciones ya han sido incorporadas en su biblioteca, pero ahora cuenta con el mandato necesario para que se cumplan. Confía que pronto se materializará el progreso alcanzado en una evaluación formal del Nivel E.

Gestión de Proyectos (GPR) – a partir del Nivel E

GPR 4 (A partir del nivel E) La planificación 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 estándar de trabajo de la organización;

GPR 20 (A partir del nivel E) Equipos involucrados en el proyecto son establecidos y mantenidos a partir de las reglas y directrices para estructuración, formación y actuación;

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 adaptación del proceso de la organización.

Tabla 7.11: Proceso GESTIÓN DE PROYECTOS (A partir del nivel E) [SOFTEX, 2012a]

QUE HA PASADO HASTA AHORA

55. En la reunión mensual de análisis de cartera se presentan los problemas de desempeño que continúan disminuyendo la capacidad de T

2, como personal sin suficiente idoneidad, equipos

que no aprovechan la historia o las experiencias anteriores, indefinición en roles en los equipos, etcétera.

56. Marcela queda encargada de transformar la lista de acciones en realidades, parcialmente implementadas en la BiPro pero todavía no desplegada en los proyectos.

57. T2 se encamina a una evaluación del Nivel E.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

98 Capítulo 8

CAPÍTULO 8 - ELIMINANDO LOS DEFECTOS (NIVEL D DE MPS-SW)

Aun antes de que se publique el resultado de la evaluación de Nivel E, Marcela está tomando acciones para hacer que los resultados sean lo más firme posibles, según 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 Psicología Aplicada a la Empresa y un Diplomado en Diseño Instruccional. Jessica, tal es su nombre, estará a cargo de completar y mejorar el modelo de competencias de T

2 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 conducción, siendo, como ellos, joven, entusiasta y con mucha formación. No pasa mucho tiempo hasta que es invitada a formar parte de las reuniones mensuales de dirección.

8.1 Determinando el Problema

El primer orden del día en esas reuniones, desde que la BiPro y la base de datos están funcionando en la empresa, es revisar los números. Mariano prepara un informe sobre los datos de satisfacción de los clientes y la correlación con componentes del producto. Esto se plantea como un indicador de tendencia con dos datos que se reflejan como series temporales en el gráfico: Densidad de Defectos Hallados por el Cliente por Componente, que es una cantidad que cambia mes a mes, al modificarse el tamaño 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 cuál de los módulos 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 módulo con peor desempeño indica la magnitud.

De ese modo se puede diseñar la estrategia para identificar aquellos defectos que vale la pena analizar en la reunión. Si la variación es muy grande desde el mes pasado, Marcela toma para sí una acción de realizar un análisis más profundo de causa raíz con participación de los expertos en el tema. Si el módulo responsable acapara demasiados defectos es posible prever que se lo rehaga.

A partir del análisis de los defectos encontrados por el cliente y el grado de satisfacción correspondiente se itera sobre un proceso que Jessica introdujo al grupo, conocido como la hoja de resultados balanceados

79, de uso

común en empresas de cierto tamaño. Se lo utiliza para asegurar que la organización entiende su misión, alinea sus objetivos con ella y canaliza adecuadamente los recursos y energías para cumplir con sus objetivos. El método consiste en identificar primero la visión de negocios, el ‘hacia donde queremos ir’, para poder encontrar significado en las actividades. Luego de clarificar la visión, que en el caso de un ejercicio tan frecuente como el que se realiza en T

2 es simplemente revisada en cada oportunidad

80, se analizan los resultados, se fijan objetivos y se discuten las

inversiones en diferentes categorías. T2 ha adoptado como ejes de su análisis las categorías clásicas: ‘Resultados

Financieros’, ‘Satisfacción del Cliente’, ‘Procesos Internos’ y ‘Conocimiento y Crecimiento del Personal’. La Figura 8.1 resume los pasos de su construcción.

79

[Kaplan y Norton, 1996], The Balanced Scorecard: Translating Strategy into Action. 80

La visión se expresó como “Tener un crecimiento sostenible de al menos 15% anual con aumento de los márgenes proporcional o mayor cada año”.

Boria et al.

Capítulo 8 99

Figura 8.1: Estructura Típica de una Hoja de Resultados Balanceados

Para cada una de las categorías listadas se eligen “temas” que están alineados con la visión de negocios de la empresa. Por ejemplo, para que los resultados financieros estén alineados con la visión de crecimiento hay por lo menos cuatro cosas que pueden hacerse: aumentar las ventas con clientes actuales, (1) vendiéndoles nuevos productos o (2) extendiendo las prestaciones, (3) aumentando la cartera de clientes, o (4) subiendo los precios. A su vez, para analizar como estas metas financieras se traducen en metas con los clientes, en T

2 se usan tres temas

para (1) expandir (que ellos compren más licencias), (2) profundizar (que nos soliciten nuevas prestaciones) o (3) redefinir relaciones (den mejores referencias de la empresa y se transformen en vías de ventas) con los clientes. En todo caso se trata siempre de incrementar la satisfacción de los clientes con los productos.

Está claro que si los objetivos de gestión con el cliente se cumplen tienen un impacto claro en las metas financieras, pero el análisis 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 más impactan a los clientes son el plazo de entrega y el número de defectos que entregamos. Es necesario disminuir ambos para aumentar significativamente la satisfacción, la percepción del cliente. Si al llevar a cabo acciones tendientes a esos objetivos podemos alcanzarlos disminuyendo también los costos, mejor, porque aún si las ventas no suben mucho, al bajar los costos aumentan los márgenes. El análisis se completa con el diagnóstico de los aprendizajes necesarios para que los procesos permitan reducir plazos y defectos para que los clientes tengan una mejor satisfacción 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 también realizar un análisis objetivo de los resultados. Comparando la densidad de defectos producida por los equipos de T

2 con las medias históricas en la literatura

81 la conducción de T

2 está

incómoda con los resultados: Quiere que los defectos bajen. Uno de los problemas detectados por las retrospectivas es que pese a la BiPro hay poca preparación técnica. La BiPro ayuda mucho cuando la tarea es de 81

Capers Jones, [JONES, C., 1986], Programming Productivity

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

100 Capítulo 8

gestión o de apoyo, pero las técnicas de ingeniería de software, pese a que los ingenieros se han comenzado a agrupar en disciplinas, todavía son primitivas. La programación no es el problema, puesto que el Politécnico (como tantas buenas universidades) se encarga con creces de generar buenos programadores, pero las disciplinas colindantes, como la definición y análisis de requisitos, el diseño a todo nivel y la ingeniería de pruebas dejan mucho que desear. La falta de un taller de trabajo en esas capacidades es notoria.

QUE HA PASADO HASTA AHORA

58. Jessica se incorpora al equipo de Marcela e introduce BSC82

en las reuniones mensuales.

59. En un análisis 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 Búsqueda de la Solución

La solución pudiera ser armar un método propio y ajustado a las necesidades de negocios específicas de T2,

pero tanto Ana como Marcela son partidarias de una respuesta que les permita crecer en número de empleados seleccionando personal ya pre-capacitado en la parte técnica. Por lo tanto esa respuesta es descartada. Consultados los gemelos, sin pensarlo siquiera sugieren la capacitación integral en XP: Programación entre dos, desarrollo guiado por pruebas (Test driven development o TDD), Diseño incremental, integración continua, pertenencia colectiva del código, conocimiento compartido, estándares de codificación, paso sostenible y trabajo energizado, además de las prácticas comunes con Scrum, como los sprint y el juego de la planificación. Ustedes pueden imaginárselos hablando a la vez y terminando las frases uno del otro. En esas partes donde difieren Scrum y XP, como la participación del usuario en el equipo, obligada en esta última y desechada en Scrum, los gemelos prefieren mantener las técnicas del primero. Para Ana XP es una posibilidad, pero no la única. Propone identificar muchos métodos y compararlos entre sí, siguiendo el esquema de análisis 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 múltiples temas que se le aparecen a los equipos como problemas o riesgos de los proyectos relacionados con su quehacer técnico. Marcela convence a los cuatro a realizar un análisis de los mismos.

Entre ella, Ana y los gemelos van leyendo los problemas detectados y copiándolos 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 definición de criterios nos ha llevado a tomar decisiones erróneas 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 creíbles’ y al hacerlo se los coloca a ambos bajo el título ‘Problemas en Pruebas’. Al finalizar quedaron cinco clases. La primera se intitula “Problemas de Requisitos’ y se listan los problemas con la mitigación o solución a la derecha del mismo en la Tabla 8.1, de ese nombre

83.

riesgo o problema: mitigación:

1 los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo

se sigue un proceso sistemático para la identificación de lo que el cliente necesita para que tenga lo que quiere según lo que dice

2 la especificación de un módulo, componente o sistema es a veces incompleta, resultando en un producto sub-óptimo

se construye un documento que permite priorizar los requisitos y especificarlos de modo que su revisión y análisis sea posible

82

Balance Score Card 83

Las otras cuatro se denominan ‘Problemas de Diseño’, ‘Problemas de Integración’, ‘Problemas de Verificación’ y ‘Problemas de Validación’. En el contexto del modelo MPS SW la diferencia entre verificación y validación es clara: la verificación es relativa a los requerimientos, se ‘verifica’ cuando se compara un producto, final o intermedio, contra los requerimientos de los cuáles deriva, tomando en cuenta su completitud respecto de los mismos y su consistencia intrínseca.

Boria et al.

Capítulo 8 101

riesgo o problema: mitigación:

3 suelen quedar funciones sin especificar y los requisitos no funcionales son demasiado frecuentemente añadidos hacia el final del proyecto resultando en mucho retrabajo

la especificación de los requisitos debe permitir identificar funciones así como los atributos de calidad no funcionales del producto

4 hay mucho impacto en los compromisos por la cantidad de requisitos derivados que surgen después del juego de planificación

antes de encarar un sprint se deben definir los detalles de la porción de funcionalidad que se va a incluir

5 la integración continua fracasa más de lo necesario porque no hay una clara definición de las interfaces

parte de la especificación debe dirigirse expresamente al entorno de funcionamiento del producto, sean interfaces internas o externas

6 se malinterpretan las funciones pedidas porque no hay un contexto donde situarlas, resultando en demostraciones fallidas

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

7 hay cierto apresuramiento en pasar a la estimación sin hacer un análisis más profundo de la funcionalidad que se implementa, resultando en oportunidades perdidas e ineficiencias

la selección de procesos en un sprint se basa en el análisis de requisitos y necesidades del cliente balanceadas contra las restricciones de capacidad del equipo

8 aun en aquellos casos en los que se construyen modelos del producto estos son pocas veces discutidos con el dueño del producto

durante el juego de planificación los requisitos menos comunes serán validados usando modelos y los casos de uso o historias de usuario

Tabla 8.1: Problemas de Requisitos

Este es el punto de partida de la futura tabla de decisiones. La columna de la derecha, ‘mitigación:’, da la definición de atributos deseables de la solución. Cuando se compara contra las prácticas 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 podría ayudar, pero que también podría hacer las cosas más difíciles: Un usuario que disponga de 8 horas diarias para trabajar en desarrollo de software posiblemente no tenga mucho poder de decisión en la empresa que representa, haciendo más compleja la elaboración 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 elaboración de requerimientos que finalmente los dos se resignan a expandir el horizonte de las prácticas aplicables por los equipos de desarrollo (sobre todo) y mantenimiento. Sin renunciar a XP es necesario adquirir técnicas que enfoquen en la primera parte del proceso de elaboración del producto, la captura y elaboración de las especificaciones técnicas.

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 ‘métodos’ de creación de modelos. Los gemelos no quieren creer lo que están oyendo, pero prestan atención de todas maneras: ¡En su mundo, modelar no es tarea de programadores! Marcela explica las bases de construcción de modelos, haciendo una breve reseña de A System Modeling Language, ASML

84, que luego se conoció como Yourdon Software Development Methodology

(YSDM). Lo que rescata Marcela es que se reconocen más fácilmente las características a implementar de un sistema si se construye un modelo del mismo, puesto que ese modelo obra como ‘objeto de frontera

85’ entre el

cliente y el ingeniero de software. El modelo, entonces, es factible de análisis tanto por los usuarios como por los técnicos. 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 estímulos (flujos de entrada) a los que el sistema tiene que dar una respuesta automática (flujos de salida). Esta simple estructura tiene la excelente propiedad de poder ser “ejecutada” con usuarios para detectar diferencias de opinión. Como ejemplo, Marcela realiza en pocos trazos el diagrama de la Figura 8.2 y lo “narra”, mostrando como el sistema interactúa con clientes, propietarios y administrador en un sistema de mediación de propiedades para

84

[WARD, P., e MELLOR, S., 1986], Structured Development for Real-Time Systems, Volume I: Introduction and Tools 85

Un “objeto de frontera” se define como una entidad que tiene uso plástico, que varía de una comunidad a la otra. De ese modo su interpretación permite detectar discrepancias entre las comunidades.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

102 Capítulo 8

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 autorización para registrar un inmueble”) al Administrador, quién 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 están convencidos, ya no hay en el mercado quién maneje ASML o análisis estructurado.

Las mujeres les recuerdan que ASML es el antecesor directo de UML, y que UML sí se enseña en las Universidades. Ana toma entonces el liderazgo de la reunión y comienza a explicar su experiencia en las cátedras de Arquitectura y Diseño con lo que se conoce como FDD, pero haciendo énfasis en una de sus componentes, ‘Java Modeling in Color’

86 (JMC). En JMC se utiliza notación de UML

87, una norma de expresión de modelos que

evolucionó de los viejos lenguajes y que continua siendo soportada por herramientas y bibliografía, 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 más claramente su función. Las rosas se llaman <<intervalo o evento>>; representan eventos o actividades para las que tenemos que realizar un seguimiento por razones de negocios o jurídicas en el sistema a desarrollar. Si tomamos como un caso ilustrativo una empresa de bienes raíces, ejemplos de clases de color rosa son Venta y Alquiler. Siempre las clases rosas son las más importantes, porque si no hubiera transiciones y eventos no habría necesidad de historia, luego no habría necesidad de sistemas de información.

Figura 8.3: Diagrama de Clase de Acuerdo

Una clase se pinta de color verde si denota una <<entidad>> y se clasifican además en <<grupo>> (generalmente una persona u organización), <<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 más de uno), e Inmueble.

86

[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.

87 [FOWLER, M., 2003], UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)

Boria et al.

Capítulo 8 103

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 <<descripción-como-entrada-de- catálogo>> (Descripción para abreviar), y representa la diferencia entre algo como un departamento en un edificio de varios pisos y la descripción del tipo de departamento en el catálogo de ventas. La descripción 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 físico está representado por una clase verde <<entidad>>.

En estas clases no importa tanto la precisión con la que se pueden instanciar porque su papel es permitir identificar clases faltantes y ayudar a realizar el análisis dinámico del modelo. Las clases que pertenecen a una clase arquetipo particular tienen más o menos el mismo tipo de atributos y operaciones, pero no tienen que ser iguales. Estas clases particulares de arquetipos también tienden a interactuar con las clases de otros arquetipos en formas generalmente predecibles. Estos patrones de características y comportamiento nos pueden ayudar a construir rápidamente modelos de objetos que resultan muy sólidos y son fácilmente extensibles, al identificar rápidamente atributos y operaciones que de otro modo podrían perderse, y nos dará mayor confianza en la estructura de nuestro código.

Notablemente, un modelo dinámico, tal como un diagrama de transición de estados, se puede deducir de la estructura. Por ejemplo, dado un Acuerdo de Alquiler se comenzaría con una búsqueda del identificador único del mismo para acceder al Cliente y a través de él a datos de domicilio legal. Esta secuencia se repite si el objeto de la búsqueda es un Libro prestado a un Lector en una biblioteca, para averiguar donde vive. Esta característica de los modelos UML en color hacen que la investigación sea mucho más sistemática y hasta una persona sin conocimiento del dominio sea capaz de conducir entrevistas productivas con usuarios. Los arquetipos se combinan entre sí de manera natural, que los autores de JMC llaman “componentes independientes del dominio

88”. La Figura

8.4 muestra una componente de este tipo. Como dijéramos, la característica de estas componentes independientes es que tienen una dinámica implícita. Esta dinámica implícita se puede traducir de modo semiautomático en un diagrama de transición de estados que muestra explícitamente las conexiones dinámicas 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 diseño de diagramas UML, y que las universidades preparan personal con este conocimiento, no necesitan más pruebas.

Los gemelos solo están convencidos a medias y piden tiempo para leer más sobre el tema. Sugieren que mientras tanto un método sistemático de diseño de las pruebas que incluya la redacción de caos de uso sería suficiente para muchos de los riesgos. Han estado siguiendo las ideas de Richard Denney desde su primera

88

Domain Neutral Components, traducción de los autores.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

104 Capítulo 8

publicación en StickyMinds89

, y encuentran su último libro90

sumamente útil. Presentan entonces una propuesta alternativa: Usar historias de usuario para mantenerse dentro de eXtreme Programming, elaborar con ellas un diagrama de casos de uso, identificar casos faltantes usando una matriz CRUD

91, y desenvolver un perfil de

operaciones siguiendo las técnicas del libro de Denney y para aquellos casos que lo ameriten92

, desarrollar casos de uso completos siguiendo los parámetros del libro de Allistair Cockburn

93. Se puede así certificar que todas las

entidades necesarias están siendo consideradas en los requisitos. Para asegurar que la transición desde los requerimientos al código se realiza fluidamente, se utiliza el Desarrollo Basado en Pruebas (Test Driven Development o TDD

94). De ese modo, opinan, solucionarán la mayoría de los problemas sin modificar demasiado el

tratamiento actual de los requerimientos.

Como T2 es una organización que ha madurado mucho, las opiniones no se discuten sino que son sometidas a

análisis y comparaciones. Los cuatro arman una matriz de Pugh que cruza los problemas con las soluciones. En la intersección de cada fila (problemas) y cada columna (soluciones) se coloca una letra que indica la contribución de la columna para esa solución. Por ahora basta con categorizarlas como A (alto), M (medio) o B (bajo). Si no hay ningún impacto de la solución 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 diseño de pruebas. La Tabla 8.2, Comparación entre Métodos de Desarrollo por su beneficio, muestra los resultados según los entiende el equipo de análisis. De la matriz queda claro que ambos enfoques son bastante poderosos pero ninguno es completo. Hay elementos de proceso que añadir en todos los casos y es poca la ventaja que tiene un método sobre el otro. Dada la paridad, el equipo decide incorporar un análisis más, esta vez basándose en la curva de aprendizaje y el riesgo de la adopción.

riesgo: mitigación: JMC XP + TST

los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo

se sigue un proceso sistemático para la identificación de lo que el cliente necesita para que tenga lo que quiere según lo que dice

información incompleta sobre necesidades y requerimientos

proceso sistemático de identificación A M

especificaciones incompletas documento donde priorizar requisitos y especificarlos

M A

funciones y requisitos no funcionales sin especificar

identificar funciones así como atributos de calidad

B M

demasiados requisitos derivados después del juego de planificación

definir detalles de la porción de funcionalidad en el sprint

M M

no hay clara definición de las interfaces especificar interfaces internas y externas A A

no hay contexto donde situar las especificaciones

construir historias de usuario, narrativas y/o casos de uso

A A

se pasa a la estimación sin hacer un análisis más profundo de la funcionalidad

balancear requisitos y necesidades del cliente contra restricciones del equipo

M A

los modelos no son discutidos con el dueño del producto

validar requisitos menos comunes temprano

A A

Tabla 8.2: Comparación entre Métodos de Desarrollo por su Beneficio

89

http://www.stickyminds.com/ 90

[DENNEY, R., 2012], Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test Design.

91 CRUD es la secuencia de iniciales de las palabras inglesas CREATE, READ, UPDATE, DELETE. Estas actividades surgen del uso

típico de un sistema de información y la falta de una de esas funciones sugiere una especificación incompleta, siendo la más frecuente falta la de las eliminaciones de registros que ya no se necesitan.

92 Siguiendo a Denney, los casos que tengan mayor frecuencia de uso se desarrollan primero.

93 [COCKBURN, A., 2000], Writing Effective Use Cases.

94 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 código sin modificar tiene que hacer que esa prueba falle, sino se la rehace. El nuevo código que se produce puede entonces ser validado por verificación a través de la nueva prueba. Si hiciera falta reacomodar el código para que cumpla con normas de legibilidad o semejantes, se lo rediseña usando Refactoreo y “Smells”.

Boria et al.

Capítulo 8 105

JMC XP + TST

curva de aprendizaje A B

riesgo de adopción A B

Tabla 8.3: Comparación entre Métodos de Desarrollo por el Riesgo

Pese a que es un poco mejor usar UML con las extensiones de modelado en color, es mucho más sencillo continuar como hasta ahora con el agregado de los casos de uso y las técnicas propuestas por Denney.

Rendidas ante la evidencia, Ana y Marcela se ponen a trabajar con los gemelos en la mejora, resumiendo las técnicas 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 planificación, en particular durante la discusión con el Dueño del Producto. El Dueño del Producto participa activamente en la creación de estas historias.

Una historia de usuario es una o más frases en el lenguaje cotidiano del usuario final, que capta lo que hace o precisa hacer como parte de su función. Captura 'quién', '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 también escritas por los mismos ingenieros de desarrollo para expresar requisitos no funcionales (seguridad, calidad, desempeño, etc.) o requisitos derivados, por ejemplo aquellos que se omitieron en la definición del Backlog del sprint porque se dieron por sentados como obvios (una verificación 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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

106 Capítulo 8

Según el nuevo proceso, el próximo paso es generar el diagrama de casos de uso con los actores como ilustra la Figura 8.7.

Figura 8.7: Diagrama de Arquitectura

Según Denney uno se asegura ahora que no haya más casos de uso que estén 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.

Luego se listan las clases que surgen de los casos de uso y se analizan para constatar si las cuatro funciones CRUD están 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.

CASOS DE USO

CLASES................................ Reg

istr

arse

Bu

scar

inm

ueb

le

Ofe

rtar

Alq

uila

r

Ofe

rtar

Co

mp

rar

Cer

rar

Acu

erd

o

Ingr

esar

Inm

ue

ble

Rec

haz

ar o

fert

a

Rea

lizar

co

ntr

aofe

rta

Ace

pta

r o

fert

a

Au

ten

tica

r p

rop

ieta

rio

Elim

inar

pro

pie

tari

o

Cliente C U

Propietario C R U D

Inmueble C

Acuerdo de Alquiler C U U C

Acuerdo de Compra C U U C

Oferta C C D D

Tabla 8.4: Matriz CRUD sin Completar

La matriz se completa colocando en la intersección de cada fila y columna una C, R, U o D según 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.

Boria et al.

Capítulo 8 107

CASOS DE USO

CLASES................................ Reg

istr

arse

Bu

scar

inm

ueb

le

Ofe

rtar

Alq

uila

r

Ofe

rtar

Co

mp

rar

Cer

rar

Acu

erd

o

Ingr

esar

Inm

ue

ble

Rec

haz

ar o

fert

a

Rea

lizar

co

ntr

aofe

rta

Ace

pta

r o

fert

a

Au

ten

tica

r p

rop

ieta

rio

Elim

inar

pro

pie

tari

o

Cliente C

U

Propietario C R

U D

Inmueble

U C

Acuerdo de Alquiler

C U

U C

Acuerdo de Compra

C U

U C

Oferta

C C D

D

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 idénticos. Quizás se trata de un requerimiento redundante, habrá que desglosarlo en detalle con el Dueño del Producto. La gran cantidad de espacios en blanco sugiere que debemos analizar con el Dueño del Producto las reglas del negocio más profundamente. Por ejemplo, si la creación de un acuerdo actualiza los objetos que se relacionan con él, el cliente y el propietario además del inmueble. Parece lógico que así sea y deberíamos 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 características son poco útiles en general. Luego, en un caso real, preguntaríamos si existen reglas de negocio que nos dicen que hacer con un Cliente, como se actualiza su información y como, si acaso, se lo da de baja del sistema.

Análogamente, nos falta información 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 parecía cuando mirábamos la Figura 8.7, ahora nos parece demasiado sumario. Con un método 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 propósito de esta actividad es evitar detallar casos de uso que son poco frecuentes y que por lo tanto conllevan poco riesgo. En las palabras de Denney

95, “es mejor tener una estrategia

para utilizar el tiempo sabiamente, y saber cuales técnicas 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 más, Limpiar Datos, que tendrá en cuenta eliminaciones de objetos que caducaron, y Actualizar Datos, que usarán 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 visión del Dueño 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 desconocida. Según Denney

96, la precisión es despreciable en este momento, basta con conocer un orden de

95

Use Case Level of Test, op.cit., página 6. 96

Use Case Level of Test, op.cit., páginas 40 y 41.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

108 Capítulo 8

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 año. Lo importante es que sirva para estimar números razonables. En nuestro caso digamos que se cuenta con estimados mensuales para cada actor, de modo que el intervalo elegido es el mes. En la matriz que estamos generando (llamada QFD

97 por Denney, dada la

similitud existente entre su matriz de cuantificación de perfil con la usada por el método 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 número es un número 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 ingresarán 59 Propietarios por mes que en total (nuevos y ya registrados) darán 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 clientes nuevos

59 propietarios nuevos

63.13 inmuebles nuevos

4000 búsquedas compra

8500 búsquedas alquiler

1000 oferta compra

3000 oferta alquiler

80 contraoferta compra

12 contraoferta alquiler

2 rechazos

3830 acuerdos cerrados

59 autenticaciones de propietario

0.01 eliminar propietario

Tabla 8.6: Estimaciones de Actividad

Con esas estimaciones, la matriz de QFD queda con los datos siguientes:

Cantidad 10000 1000 1

ejec

uci

on

es p

or

mes

pes

o r

elat

ivo

ran

kin

g

po

rcen

taje

de

es

fuer

zo

ACTORES

CASOS DE USO................................ C

lien

te

Pro

pie

tari

o

Ad

min

istr

ado

r

Registrarse 0.06 0.059 659 18% 3 20%

Buscar inmueble 0.125 1250 34% 1 38%

Ofertar Alquilar 0.03 300 8% 5 9%

97

Despliegue de la función calidad (QFD) es un método de gestión de calidad basado en transformar las demandas del usuario en la calidad del diseño, implementar las funciones que aporten más calidad, e implementar métodos para lograr calidad del diseño en subsistemas y componentes, y en última instancia a los elementos específicos del proceso de fabricación. http://es.wikipedia.org/wiki/QFD (N.A.: la redacción de esta página indica su origen en alguna traducción automática, lo que la hace de bajo valor estético, pero es todavía legible).

Boria et al.

Capítulo 8 109

Cantidad 10000 1000 1

ejec

uci

on

es p

or

mes

pes

o r

elat

ivo

ran

kin

g

po

rcen

taje

de

es

fuer

zo

ACTORES

CASOS DE USO................................ C

lien

te

Pro

pie

tari

o

Ad

min

istr

ado

r

Ofertar Comprar 0.01 100 3%

Cerrar Acuerdo 0.0383 0.383 766 21% 2 23%

Ingresar Inmueble 0.06313 63.13 2%

Rechazar oferta 0.002 2 0%

Realizar contraoferta 0.02 20 1%

Autenticar propietario 59 59 2%

Eliminar propietario 1 1 0%

Limpiar Datos 110 110 3%

Actualizar Datos 330 330 9% 4 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 número 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 números anteriores da el porcentaje que corresponde a cada uno. Así 1250 dividido 3660 da aproximadamente 34%, que es el caso de uso de más 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 proporción para multiplicarlo por el esfuerzo esperado y obtener como calcular la dedicación a cada caso de uso.

Dados los números 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 elección, el método es claro: se elijen para ser detallados los casos de uso que más peso tienen en términos de utilización por los usuarios. La excepción 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 términos 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 cómo 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 mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar centenares de casos de uso para definir completamente el nuevo sistema. Los proyectos ágiles, con su definición de ‘sashimi’ para cada sprint no necesitan tantos. Si además se seleccionan, como vimos en la sección anterior, aquellos que son más representativos, el resultado es manejable por el equipo en pocas horas.

Un caso de uso contiene una descripción textual de todas las maneras que los actores que se espera lo ejecuten interactúan con el sistema. Los casos de uso no describen funcionalidad interna del sistema, ni exponen cómo se implementará, en cambio muestran los pasos de la interacción 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 período 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 tamaño y extensión y por ende

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

110 Capítulo 8

incomparables. En este caso Marcela se inclina por el formato propuesto por Allistair Cockburn en su libro98

. A menudo se propone la siguiente estructura en el diseño de casos de uso:

Componentes de un Caso de Uso Definición

ID Según nomenclador de configuración

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 ejecución 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 más abajo. Posiblemente un caso de uso complejo pueda requerir todos esos campos y algunos más, por ejemplo a veces se separan los flujos alternativos en dos categorías, una de ellas dedicadas al tratamiento de excepciones, como cuando una condición 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 diseñados e incluidos. La decisión de que plantilla usar depende exclusivamente de las necesidades de cada situación, basta que se utilicen uniformemente los campos para que se puedan revisar.

QUE HA PASADO HASTA AHORA

61. Marcela, Ana, y los gemelos analizan los problemas y los agrupan para buscar soluciones.

62. Haciendo un análisis de causas profundas se decide incorporar métodos y técnicas para el desarrollo de los requerimientos en el Sprint.

63. Comparando métodos por su impacto y costo de implementación se decide utilizar una mezcla de XP -TDD con técnicas 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 práctica 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.

riesgo: XP + TST

los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo

se sigue un proceso sistemático para la identificación de lo que el cliente necesita para que tenga lo que quiere según lo que dice

98

[COCKBURN, A., 2000], Writing Effective Use Cases.

Boria et al.

Capítulo 8 111

riesgo: XP + TST

los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo

Se utilizan diagramas de CU y matriz CRUD

la especificación de un módulo, componente o sistema es incompleta resultando en un producto subóptimo

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 añadidos hacia el final del proyecto resultando en mucho retrabajo

Las planillas de CU identifican funciones y permiten añadir requisitos no funcionales

hay mucho impacto en los compromisos por la cantidad de requisitos derivados que surgen después del juego de planificación

El juego de la planificación pasa a incluir el detalle de los requisitos

la integración continua fracasa más de lo necesario porque no hay una clara definición 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 estimación sin hacer un análisis más profundo de la funcionalidad que se implementa, resultando en oportunidades perdidas e ineficiencias

Los perfiles operativos se ocupan de establecer ese equilibrio cuando hay presiones de recursos

aun en aquellos casos en los que se construyen modelos del producto estos son pocas veces discutidos con el dueño del producto

El juego de la planificación pasa a incluir el detalle de los requisitos y su revisión

Tabla 8.9: Lista de Control de Mitigación de Riesgos en Requisitos

Marcela ha incorporado a los pasos de aprobación de un procedimiento la creación 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 evaluación. El resultado se detalla en la Tabla 8.10.

Resultados Esperados de DRE en el MPS Evidencia de implementación en Tahini-Tahini

DRE 1 Las necesidades, expectativas y limitaciones del cliente, tanto del producto como de sus interfaces, son identificadas

se sigue un proceso sistemático para la identificación de lo que el cliente necesita para que tenga lo que quiere según lo que dice

DRE 2 Un conjunto definido de requisitos del cliente es especificado y priorizado a partir de necesidades, expectativas y limitaciones identificadas

se construye un documento que permite priorizar los requisitos y especificarlos de modo que su revisión y análisis sea posible

DRE 3 Un conjunto de requisitos funcionales y no-funcionales, del producto y de las componentes del producto que describen la solución del problema a ser resuelto, es definido y mantenido a partir de los requisitos del cliente

la especificación de los requisitos debe permitir identificar funciones así como los atributos de calidad no funcionales del producto

DRE 4 Los requisitos funcionales y no-funcionales de cada componente del producto son refinados, elaborados y asignados

antes de encarar un sprint se deben definir los detalles de la porción de funcionalidad que se va a incluir

DRE 5 Interfaces internas y externas del producto y de cada componente del producto son definidas

parte de la especificación debe dirigirse expresamente al entorno de funcionamiento del producto, sean interfaces internas o externas

DRE 6 Conceptos operacionales y escenarios son desarrollados

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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

112 Capítulo 8

Resultados Esperados de DRE en el MPS Evidencia de implementación en Tahini-Tahini

DRE 7 Los requisitos son analizados, usando criterios definidos, para balancear las necesidades de los interesados con las restricciones existentes

la selección de procesos en un sprint se basa en el análisis de requisitos y necesidades del cliente balanceadas contra las restricciones de capacidad del equipo

DRE 8 Los requisitos son validados durante el juego de planificación los requisitos menos comunes serán validados usando modelos y los casos de uso o historias de usuario

Tabla 8.10: Implementación de DRE en T2

QUE HA PASADO HASTA AHORA

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 implementación 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 reunión posterior a los cuatro meses de pilotaje, los números 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 atención ahora.

Este fenómeno es frecuente y una de las causas más habitual de frustración con la mejora de procesos: Arreglar un problema hace evidente la existencia de otro que antes, la existencia del primer problema enmascaraba. El fenómeno, conocido por los diseñadores de sistemas operativos, se denomina ‘problema del embotellamiento’, porque se lo ilustra con esta conocida molestia del tránsito. La historia es así: Supongamos que un punto de un camino produce embotellamientos diarios a un costo anual al público de cien mil horas de espera, sumadas todas las partes involucradas. Digamos que el erario público calcula que una hora de espera tiene un costo social asimilable a cincuenta dólares. Luego el punto en cuestión ‘cuesta’ a la sociedad cinco millones de dólares anuales. El estado inicia planes para eliminar el problema que cuestan diez millones de dólares, que una vez concluidos se espera que lo gastado se repague en dos años. Una vez entregadas las obras el embotellamiento no se produce más en ese punto, pero en un tramo un poco más abajo en la misma ruta surge uno nuevo, que antes no se detectaba porque el tránsito 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 también. 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 estación el producto es transformado (de necesidad del cliente en caso de uso, de caso de uso en código, de caso de uso en caso de prueba, de código no probado en código 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 estación, en este caso la detección de errores, hace que otra estación más hacia la salida tenga ahora una cola de espera. Vimos el tratamiento que ocurre en Kanban sobre este tema en el Capítulo 3, enfocado a liberar el servicio de la mejor manera posible y cuanto antes. En esta sección 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 inyección 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 que hasta años antes. T

2 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 Diseño’, ‘Problemas de Integración’, ‘Problemas de Verificación’ y ‘Problemas de Validación’, los cuatro protagonistas de nuestra historia en T

2 concluyen que hay motivos para seguir modificando lo que hacen.

Primero consideran los problemas de Validación, porque en el sentido más estricto afectan al cliente. De las notas que se tomaron en el análisis rescatan la Tabla 8.11.

Boria et al.

Capítulo 8 113

riesgo o problema: mitigación:

en ocasiones hemos preparado validaciones con el cliente que no cumplían las expectativas de lo que ellos querían ver, por ejemplo omitimos documentación, perdiendo credibilidad y tiempo

acordar con el cliente y el equipo la estrategia de validación, los productos a evaluar, el cronograma de esta, los criterios de entrada y aceptación y los ambientes de aplicación

en ocasiones hemos preparado validaciones que seguían un orden incorrecto y confundían al cliente, haciendo que tuvieramos que remontar la presentación

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 sincronización a la línea de base

reforzar el seguimiento del proceso de aceptación del usuario aumentando la frecuencia de las auditorías y ayudando a prevenir disconformidades, asegurando que los criterios de aceptación se cumplen, basados en documentación fehaciente

hemos arreglado de más y de menos en muchas ocasiones, desperdiciando esfuerzo o perdiendo calidad

en ocasiones hemos liberado código sin el suficiente respaldo

Tabla 8.11: Problemas de Validación

Comparando las acciones de mitigación de esta tabla con las de la Tabla 8.12, Problemas de Verificación, Marcela encuentra similitudes que sugieren que la mejora del proceso de ingeniería de pruebas puede atender tanto Validación como Verificación.

riesgo o problema: mitigación:

si bien el plan de pruebas es comprehensivo, la inspección es selectiva y no hemos siempre elegido bien los productos o partes de los mismos que se deben inspeccionar, o sino hemos elegido métodos más débiles de los que debiéramos

acordar con el equipo la estrategia de verificación, los productos a evaluar y con qué métodos, el cronograma de las diferentes evaluaciones, los criterios de entrada, discontinuación y aceptación (garantizando que la cobertura mínima es uno de ellos) y los ambientes de prueba cuando aplican

no siempre planificamos con la anticipación suficiente las actividades de prueba o verificación y perdemos participantes importantes

la falta de cobertura en la definición de criterios nos ha llevado a tomar decisiones erróneas sobre la calidad del producto demostrada por la densidad de errores

cuando el sprint se está por acabar se ha cortado camino salteándose pruebas importantes, como la de estrés

aplicar a rajatabla auditorías de proceso y producto hasta que se fije la conducta de prueba sistemática

no siempre la densidad que calculamos está basada en datos creíbles

automatizar todas las pruebas

debiéramos poder justificar ante el equipo el retorno de la inversión que supone verificar usando inspecciones

los datos obtenidos de las pruebas y las inspecciones, recorridas y revisiones técnicas, deben ser analizados y discutidos en la reunión mensual de cartera

Tabla 8.12: Problemas de Verificación

Desde el comienzo Marcela ha dejado claras las diferencias entre Validación y Verificación. A pesar de que hay escuelas opuestas en lo que hace al significado de estos dos términos, Marcela, siguiendo los consejos de

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

114 Capítulo 8

Máximo, utiliza las interpretaciones que de ellos hace Barry Boëhm en su obra99

. 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.

Para verificar sus productos, T2 utiliza múltiples herramientas. Las revisiones

100, ya sean inspecciones por

pares, recorridas101

, revisiones estructuradas o revisiones continuas102

; se usan para constatar que el producto bajo revisión 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 caídas o fallas del sistema con el propósito de detectar errores en el producto

103, pero también como herramienta

de diseño104

y guía para la construcción del programa, como ya viéramos en el Capítulo 3. Desarrollaremos tanto las revisiones en general como métodos y técnicas de prueba de programas.

Para validar sus productos T2 hace uso de actividades en las que participa el DP105

. Al planificar el Sprint el equipo crea el modelo que representa la funcionalidad deseada y lo “ejecuta” frente al DP. Esto permite validar la visión 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 visión. Al finalizar el Sprint el equipo presenta una demostración del producto al DP, para constatar que se materializó correctamente la visión compartida. Estas dos actividades son efectivamente actividades de validación, apuntan a evaluar la efectividad del producto para el cliente.

8.7 Procedimientos de Verificación

Ya hemos cubierto en el Capítulo 3 la revisión continua, como programación por pares o de a dos. Acá desarrollaremos en detalle los procedimientos de revisión clásicos: la recorrida, la revisión formal estructurada, y la inspección.

Las revisiones son una parte fundamental de toda actividad de creación de un producto. En particular en la ingeniería 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 definición que fue evolucionando en la década del 60 del siglo pasado, por la que el proceso de construcción de un artefacto de software puede verse como la traducción de un contenido semántico de una sintaxis a otra, con preservación de la semántica y el posible agregado de detalles en cada paso. Por ejemplo, el documento de especificación 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 semántica) del documento anterior. Asimismo el caso de prueba puede verse como un refinamiento del caso de uso con otras reglas sintácticas, y el código generado como una nueva iteración de ese proceso de traducir y refinar con otra sintaxis. Esto se visualiza en la parte izquierda de la Figura 8.8, bajo el título Actividades de Traducción.

99

De manera muy general, se puede decir que la verificación se ocupa de constatar si el producto está siendo desarrollado correctamente, mientras que la validación busca asegurar que se está desarrollando el producto correcto, es decir, aquél producto que el cliente necesita [BOEHM, B., 1981].

100 Véase para mayor detalle [FREEDMAN e WEINBERG, 1990].

101 N. del A. Hemos traducido walkthroughs como “recorridas”, manteniendo la consistencia histórica con [BORIA, J., 1987].

102 Siguiendo a [BECK, K., 2000] consideramos a la programación de a dos una forma extrema de revisión continua.

103 Probar el programa para “asegurarse que funciona” es un error de enfoque que disminuye la efectividad de la prueba.

104 Test Driven Design en [BECK, K., 2000]

105 Dueño del Producto, Capítulo 3.

Boria et al.

Capítulo 8 115

Figura 8.8: Modelo V de Desarrollo de Software

La rama derecha del modelo en V define la correspondencia entre las actividades de traducción y las actividades de detección de defectos introducidos por las mismas. La hipótesis es que cada traducción introduce “ruido” en el sentido que ese término tiene en teoría de información, es decir, un elemento que dificulta la recepción del mensaje. Cada actividad, entonces, inyecta defectos. Si se espera hasta que el código ha sido escrito para remover defectos el resultado es caótico. 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 todavía no alcanza el punto donde les pueden hacer llegar el producto. En esas circunstancias la detección de errores no es diferente en primera instancia, pero la falta de tiempo conspira contra el arreglo: las modificaciones se hacen rápido y sin pensar demasiado. El resultado es que la reparación introduce nuevos errores con mayor probabilidad de la que tendría repararlo con tiempo

106. Si la

detección de todos los defectos introducidos se posterga se puede esperar que el resultado sea una zona de alta fricción hacia el final del esfuerzo, como muestra la Figura 8.9.

Figura 8.9: Zona de Caos por Postergación de Actividades de Remoción

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 detección temprana (revisiones indicadas por la letra R en un círculo, donde la flecha ‘CRUCIAL’ señala las dos más importantes), el resultado es un menor esfuerzo de retrabajo, realizado en el momento justo.

106

[MYERS, G., 1979],

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

116 Capítulo 8

Figura 8.10: Modelo en V con Revisiones entre Actividades de Traducción

8.8 Revisiones

Los tres métodos de revisiones que se aconsejan, además de la programación en pareja, son la inspección, que detallaremos a continuación, la revisión 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 especificación, y el código mismo. Siempre es conveniente identificar las componentes más riesgosas para cubrirlas antes de quedarnos sin tiempo.

Comencemos entonces por las inspecciones, para luego, por diferencia, definir los otros dos métodos. ¿Qué se gana al hacer inspecciones? Calidad, porque al inspeccionar productos se detectan y eliminan defectos, pero también comunicación, ya que eligiendo convenientemente a los participantes se consigue comunicar contenidos con precisión, así como mejorar el conocimiento de los más nuevos. Al inspeccionar materiales generados por expertos aprenden de ellos mejores prácticas. Una inspección es un proceso muy formal que identifica un producto, escoge un equipo de inspectores, escoge las herramientas de inspección, detecta los defectos en el producto, y garantiza la calidad resultante. Un equipo de inspección 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, también llamados inspectores. Uno entre ellos, o el Moderador, actúa 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 pequeño, no más de siete personas en total, contando al Moderador, el Autor, y dos a cinco Inspectores. Los inspectores se eligen de modo de conseguir el máximo beneficio de la inspección, por ejemplo conocen o son los autores del producto anterior o serán los autores del producto que sigue. Individualmente son representantes de categorías importantes dentro de la organización, como arquitectos o testers. Lo que es seguro es que comprenden el producto y el proceso y son expertos o están para ser educados. Posiblemente alguien de aseguramiento de la calidad participe con funciones especiales, pero también es útil que aseguramiento de la calidad haya hecho antes de la inspección una auditoría del producto.

8.9 Actividades del Proceso de Inspección

El proceso de inspección se activa cuando el autor del producto avisa que este está completo. El encargado que recibe este aviso consigue la participación de un Moderador del cuadro de Moderadores entrenados de la empresa. Este se comunica con el Autor y comienzan la primera actividad de preparación, que consiste en la Selección del Material. En ella el Autor con el Moderador deciden juntos qué partes del producto se van a inspeccionar. Como criterio de selección, 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 críticas para que valga la pena evaluarlos. Entonces Autor y Moderador eligen y preparan materiales acerca del producto (márgenes, presentación, etc.) y las listas de chequeo y guías que apliquen, o patrones que ayuden a entender el material, así como productos referenciados que sirven para esto.

La logística se prepara también 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 revisión del material, que es a lo sumo unas 2 horas de esfuerzo, puede que en 2 días de duración; para la junta de instrucción (unos 30 minutos); para la junta de unificación de defectos (no más de 2 horas) y comunica las decisiones al equipo. Se consideran las

Boria et al.

Capítulo 8 117

respuestas al pedido de participación, y una vez estabilizado el equipo y el calendario de actividades se procede a la Junta de Instrucción.

Junta de Instrucción

En la junta de instrucción 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 también 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, diseñador, ingeniero de pruebas, aseguramiento de calidad). En ese caso cada rol puede tener su propia lista de ítems de chequeo. El autor provee de información 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 líneas numeradas o identificadas de forma clara, y si no es todo el producto, se destaca lo que hay que revisar. Se entrega también la plantilla usada para preparar el producto, así como los estándares y referencias, los materiales relacionados y las listas de ítems de inspección que servirán para identificar los defectos. Para juntarlos, se entrega una plantilla de ingreso de defectos.

Inspección Individual del Producto

Cada inspector revisa los materiales por su cuenta, e intenta encontrar TODOS los defectos, para lo cuál usa las guías, 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 ubicación del problema, el tipo de ítem (pregunta, defecto, ambigüedad, 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 inspección personal pero no más de media hora. En cualquier caso, cuando se acaba el plazo sin terminar marca hasta donde inspeccionó y da por concluida la inspección personal. Si el producto no está listo para ser revisado por la baja calidad del mismo, o de existir algún otro motivo para que no se haga la junta de unificación, como que el producto es redundante o está desactualizado, informa al Moderador. Si se sigue el proceso normal, cada Inspector envía la planilla completada al Moderador para que este la unifique en la que presentará en la Junta de Unificación.

Junta de Unificación

Las diferentes cuestiones encontradas individualmente son unificadas en una junta especial, cuyo objetivo es incrementar la calidad del producto. La sinergia obtenida de la discusión incrementa en un 20% el número de cuestiones documentadas en la sesión.

Es el Moderador quién conduce dicha junta. El Moderador la prepara verificando que todos han enviado sus planillas completadas. Si alguien no lo hizo se posterga la reunión, lo que es un grave problema porque demora el proyecto. Se podría hacer sin el Inspector holgazán, pero el precedente así sentado haría que la inspección pierda la prioridad que debe tener.

En la reunión, 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 inspección 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 común, el Moderador presenta las estadísticas 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 ubicación, de modo de ir de lo general a lo particular y del principio al fin. De cada cuestión da la descripción, tipo y severidad. Una vez leída una cuestión hace una pausa para permitir comentarios de los participantes. Los inspectores pueden hacerse preguntas entre sí, por ejemplo si tal o cuál cuestión 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 redacción de la cuestión 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 sesión. 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,

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

118 Capítulo 8

solo se registran. El Autor contesta preguntas si le son dirigidas, pero puede también preguntar sobre cuestiones levantadas, sin defender su posición, para que se le aclaren.

La discusión se limita para que la sesión dure no más de una hora. Generalmente el Moderador intenta llevarla a su conclusión en noventa minutos para que sea muy probable que termine antes de las dos horas. Si las dos horas se cumplen la inspección se cancela, lo que da un aliciente muy grande para que el equipo intente darle cierre. En la Junta de Unificación no se discuten o resuelven las cuestiones; se las anota. Quizás se aclara el tipo o la severidad que puede cambiar si el que levantó la cuestión acepta hacerlo. Como dijéramos, se puede pedir aclaración sobre porqué eso se considera una cuestión o un defecto.

Disposición del Producto

Cuando ya no hay más 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 inspección por este equipo u otro; o no hay retrabajo, se rechaza el producto, hay que rehacerlo entero. En los casos en que la decisión no sea completa (aprobar o desaprobar) el equipo tiene que fijar criterios de aprobación para el Autor que el Moderador garantizará. El Moderador facilita esta discusión de cierre y la ordena. Se envía el resultado completo, con la resolución y las cuestiones levantadas a todos los participantes, sobre todo al Autor.

Retrabajo y Conclusión

Para cada cuestión levantada, el Autor se reúne 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 todavía. En todos los casos apunta su decisión en la planilla de la inspección que recibió del Moderador. Si el Moderador lo autoriza, puede cambiar la severidad. Esto es para que si hay personas que se comportan con fanatismo

107 en la reunión se pueda dejar de discutir en un punto y avanzar. Se completa entonces el trabajo

según sea necesario y el moderador verifica la completitud del trabajo realizado, es decir que se hayan corregido los defectos severos, que el criterio de aprobación 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 disposición 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 opción preferida) o en una nueva junta. También puede ocurrir que todo el producto se re-inspeccione cuando los problemas eran de fondo y el producto crítico para el proyecto.

Informe Final

La inspección se completa con un Informe de Cierre o Informe Final de Inspección. 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 clasificación final de severidad y tipo para cada ítem, puesto que pueden haber cambiado con anuencia del Moderador, y envía la planilla actualizada al Moderador. El Moderador o el Autor se ponen de acuerdo para ver quien es que envía 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 disposición final del producto de trabajo e incluye las estadísticas finales: severidad por tipo, esfuerzo, etc. Estos números se consolidan y son analizados especialmente para medir la efectividad y eficacia de las inspecciones.

8.10 Factores Críticos de Éxito

El hecho de que una revisión se denomine una “Inspección” no la transforma en una actividad efectiva. Es necesario planificarla bien y tener en cuenta los factores de éxito. Al planificar su inspección elija los participantes con cuidado, siguiendo las pautas anotadas (al final de la sección Revisiones, página 116). Siempre es útil contar con un ingeniero de pruebas porque se los entrena para encontrar problemas. Incluir personal novato permite mostrarles buenas prácticas. Asegúrese 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 preparación a los Inspectores para la revisión inicial. La duración de la junta de unificación debe restringirse a dos horas; en una organización con problemas de disciplina las inspecciones comenzaron a ser usadas para otro tipo de reuniones porque eran las únicas Juntas que los ingenieros respetaban, convirtiéndolas 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 fanático es una persona que no está dispuesta a cambiar de opinión ni a cambiar de tema”. Winston Churchill.

Boria et al.

Capítulo 8 119

8.11 Factores de Fracaso

Las pautas para que una inspección sea exitosa no acaban acá. Hay ciertas decisiones que matan la inspección. Si se incluye a la alta gerencia en la junta es muy probable que no se levanten cuestiones para no dañar la reputación del Autor.

Si se revisan toneladas de material las cuestiones levantadas no resultarán significativas y las inspecciones perderán fuerza rápidamente. Si la junta de unificación se transforma en una junta de solución degenerará muy pronto en un concurso de opiniones, deje que el Autor sea el responsable de elegir los arreglos. La inspección no es una propuesta de diseño por comité, sino de calidad por apoyo del equipo. Si la junta de unificación dura para siempre las personas comenzarán a poner objeciones y excusas para no participar en ellas. Si durante la junta el Moderado acepta comentarios personalizados o cargados de emoción (“Esto es una porquería de producto” o “Quienquiera que escribe así no puede trabajar conmigo”) las peleas serán moneda corriente y el propósito de la inspección, 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 ‘género’, 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 más débil de las tres, medida en capacidad de encontrar defectos, la recorrida. Hay un libro de Yourdon

108 que describe con detalle el proceso de

recorrida, pero que en nuestra opinión describe una revisión estructurada, de modo que si se está interesado en esta última esa es una buena referencia.

A diferencia de la inspección, la recorrida no exige un moderador. El propio Autor la organiza y facilita. El equipo no está limitado a un número máximo y no necesita ser convocada con anticipación alguna. El autor puede reunir un grupo que dispone del tiempo y pedirles que se presenten en un salón en minutos u horas. La duración de la reunión también es flexible, y los roles se asignan, si acaso, en el momento de comenzar la junta. Si la inspección es una tarea premeditada, la recorrida es una actividad apenas formal. El propósito es obtener retroalimenta-ción rápida de un grupo de personas para mejorar la calidad de un producto en el momento. La toma de notas, captura de datos y resolución 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 revisión estructurada, que como ya dijimos está bien documentada en la literatura. Nuestra descripción coincide con la realizada en el libro de Gilb ya citado y en muchas partes con el libro de Yourdon, también citado.

En la revisión estructurada quién convoca es el encargado del proyecto, sea líder técnico, gerente de proyecto, o líder de proyecto. El propósito es conocer el estado de un producto. El encargado designa al facilitador y este puede elegir si el autor participa en la logística. Es decir, puede no tenerlo en cuenta para las decisiones de composición de equipo y demás. El facilitador cumple un papel más directo que el Moderador en la inspección puesto que pese a su nombre toma más decisiones que el Moderador. En general se sigue el procedimiento descripto para la inspección, salvo que la junta de instrucción es opcional, siendo remplazada a menudo por una comunicación electrónica para los participantes. Las listas de chequeo son semejantes, aunque es menos frecuente que sean diferentes para los distintos participantes según sus roles, que tampoco son asignados con la misma frecuencia que en las inspecciones. Cambia también la capacidad del equipo de disponer del producto. En vez de elegir la disposición, el equipo recomienda al encargado del proyecto un camino a seguir, que este no está obligado a considerar.

Una de las aplicaciones más interesantes es su uso combinado en proyectos de cierto riesgo. Para más información ver [BORIA, 2010].

Resumiendo las diferencias en una tabla, son las siguientes:

Recorridas Revisiones Estructuradas Inspecciones

Objetivos Obtener retroalimentación temprana sobre la manera de avanzar con el

Mostrar que el producto tiene la calidad esperada

Ubicar todos los errores posibles y corregirlos hasta alcanzar un nivel de calidad prefijado

108

YOURDON, Edward, 1989, Structured Walkthroughs. Prentice-Hall.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

120 Capítulo 8

Recorridas Revisiones Estructuradas Inspecciones

producto y corregir errores si hubiera

Criterio de Entrada

Se identifica la necesidad en el calendario del proyecto o el autor u otro lo deciden

La gerencia estima que el producto está listo, se han publicado los criterios de calidad, el autor confirma que se puede empezar

El autor solicita la inspeción y confirma que el producto cumple con los criterios para ser inspeccionado

Decisiones Las decisiones las toma el autor

El equipo de inspección informa y recomienda, la gerencia decide

El equipo define la disposición del producto y acciones futuras

Cierre de las Cuestiones

Fuera del alcance del procedimiento

La gerencia controla como parte del proyecto

El moderador controla de acuerdo a los criterios del equipo

Tamaño Dos o más personas, sin límites

Al menos tres, no más de los

Tres por lo menos, no más de siete

Composición del Equipo

Quién esté disponible Líderes técnicos y colegas del autor

Colegas del autor elegidos bajo criterios

Liderazgo Autor Generalmente un líder técnico del proyecto

Moderador capacitado

Preparación Opcionalmente se distribuye el material con horas de anticipación

Hay una revisión individual previa siguiendo criterios establecidos en lista de chequeo

Hay una revisión individual previa siguiendo criterios establecidos en lista de chequeo y con materiales de soporte

Presentador Usualmente el autor Autor o lector designado Lector designado o nadie

Mediciones Recogidas

Opcional, raramente se hace

Generalmente se hacen como en inspeciones pero no son requeridas, depende de la empresa

Requeridas formalmente, esfuerzo, tiempo, tipo y número de cuestiones

Informes Lo emite el autor a su discreción

Informe con la lista de defectos, cuestiones y acciones realizadas

Informe con detalle de lo detectado, invertido y actuado

Captura de Datos

No es requerida No es requerida Colecta con fines estadísticos de todos los datos catastrales y esfuerzo, tiempo, costo, etc.

Tabla 8.13: Comparación entre Revisiones

8.13 Usos Ágiles

Las revisiones, así descriptas, tienen demasiado sabor a proyecto largo para ser útiles en un ambiente ágil. Sin embargo, veamos como las adaptaron Marcela y los gemelos en T

2. En primer lugar, la revisión elegida por los

gemelos es revisión continua, llamada en la literatura programación por pares, a la que para que se puedan juntar los datos han hecho cambios en el proceso: cuando el módulo es crítico el programador con más experiencia actúa 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 análisis estadístico de los defectos detectados. Asimismo Marcela y Jessica han adaptado el método de revisiones estructuradas para su uso en sprints. Recordando los inicios de T

2, cuando se

realizaba el “remate” de tareas, cuando un equipo de trabajo termina un producto que amerita ser revisado, lo que se define en el juego de planificación del Sprint, invoca mediante la Intranet de T

2 (llamada festivamente ITT) a

los otros equipos para una revisión. Cada equipo tiene la obligación moral de prestar un miembro en las dos horas que siguen al llamado que pueda revisar el material. Al cierre del día los revisores se reúnen con los autores para presentarles sus cuestiones. El Scrum Master del equipo que solicitó la revisión es el Moderador y tiene las mismas responsabilidades respecto del informe que en una inspección. 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 reunión mensual.

Boria et al.

Capítulo 8 121

QUE HA PASADO HASTA AHORA

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 ingeniería de pruebas puede atender tanto Validación como Verificación.

68. Marcela, Jessica y los gemelos adaptaron el proceso de revisiones estructuradas a sus sprint y modificaron el procedimiento de programación por pares para que produzca evidencia de revisión continua.

Tabla 8.14: Plantilla de Registro de Cuestiones

8.14 Pruebas de Producto

Para continuar con la mejora de la percepción 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 evaluación continua, que consiste en descartar la evaluación anual de desempeño y en cambio realizar evaluaciones del resultado de cada tarea, inspirada por el material de [CULBERT 2010]. Como parte del sistema de recompensas los más destacados por su desempeño reciben un título honorario de Campeones y un curso de su elección de entrenamiento anual pago por T

2. En consecuencia, Evelina Kahn ha resultado la Campeona de Pruebas

y como su recompensa escogió un taller de ingeniería de procesos y técnicas 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 validación y verificación, Marcela ya se ha ocupado de reforzar el seguimiento del proceso de pruebas, tanto para la aceptación del usuario como para las pruebas que lo preceden, aumentando la frecuencia de las auditorías 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 aceptación y los ambientes de aplicación.

8.15 Criterios Relacionados con Pruebas

Se entiende por criterio, según la Real Academia Española, a una norma que se sigue para conocer la verdad. En segunda acepción 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 ¿Cómo sabremos que el producto está listo para pasar a la próxima fase o ser liberado al usuario? Llamamos a criterios de ese tipo Criterios de Aceptación.

Para cada tipo de prueba, se define:

1. El conjunto de casos de prueba que se tiene que usar

2. Los datos que tienen ser utilizados cada vez que se corran los casos

3. Los ambientes en los que tienen que correr las pruebas

4. Las pruebas de regresión incluidas en las pruebas de dicho tipo

Cuestiones Levantadas Por la Inspección

Proyecto Autor

Producto Moderador

Logging Date Revisores

Hora de Comienzo

Hora de Fin

Duración

Ubicación (Página,

Línea)

Descripción de la Cuestión)

(Si el ítem se levantó en la reunión señálelo con *)Tipo Severidad Comentarios del Arreglo

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

122 Capítulo 8

5. El número de defectos tolerados por categoría de severidad

6. El mínimo de funcionalidad cubierta por las pruebas (cobertura)

7. Objetivos de desempeño de las pruebas a ser alcanzados (performance)

8. Objetivos específicos de volumen (si aplican)

9. Objetivos de confiabilidad (si aplican)

10. Objetivos de usabilidad (si aplican)

Otros dos criterios útiles sirven para responder a la pregunta: ¿Cómo 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 acumularán 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:

Cuál es el estado que tiene que tener el producto para ingresar a la fase (generalmente el criterio de aceptación 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 más de tantos defectos según la severidad). Garantizar que el criterio de entrada se cumple implica una buena inversión 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 todavía sin terminar.

El siguiente criterio a incluir es el que responde a la pregunta: ¿Cuándo 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 código que fatalmente va a cambiar significativamente. Es bastante usual conectar este criterio con el de aceptación en lo que hace a la cantidad de errores por severidad. Claramente se sigue probando el producto mientras que el criterio de aceptación relacionado con la densidad de defectos (el 5 en nuestra lista) se sigue cumpliendo y el criterio de cobertura no todavía (el 6 en nuestra lista).

8.16 Cobertura

La cobertura que proveen las pruebas es un aspecto sumamente importante en la definición de criterios. Podemos ser más específicos 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 redacción 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

3 El sistema presenta la pantalla de opciones para usuarios registrados o nuevos

4 El usuario escoge la opción para usuarios nuevos

5 El sistema presenta la pantalla de registro de datos

6 El usuario ingresa sus datos personales y los confirma haciendo "ENTER"

7 El sistema almacena los datos del nuevo usuario en su base de datos y pasa al CU de Ingresar

FLUJOS ALTERNATIVOS

7a El sistema encuentra un usuario con la misma identidad (nombre, tipo y número de documento) pero otros datos de catastro (dirección y bancos)

7b El sistema consulta al usuario sobre los datos existentes solicitando permiso para actualizar con los datos recién ingresados

7c El usuario autoriza al sistema a realizar la actualización

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

Boria et al.

Capítulo 8 123

tanto es importante definir que se quiere decir con la cobertura de los casos de prueba. Obviamente, al nivel más 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 mayoría 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 clásica de diseño de casos de prueba asocia cobertura de los casos de prueba con los métodos de caja de cristal, o caja blanca como se los llamaba en un principio. Los métodos de diseño de pruebas se clasifican en dos grandes tipos: el diseño de casos haciendo caso omiso del código que fue o será construido, llamados “caja negra” por su similitud con métodos de diseño de pruebas que ignoran el diseño de las componentes a probar, y caja de cristal, o “caja blanca” originalmente (hasta que alguien tomo en consideración que el problema es distinguir entre opacidad y transparencia, y no entre colores de cajas igualmente opacas). Los métodos de caja de cristal se asocian fácilmente a cobertura, puesto que las categorías de cobertura son: sentencias (porcentaje de líneas de código ejercitadas durante la ejecución del conjunto de datos de prueba), condiciones (porcentaje de las condiciones probadas en ambos sentidos, es decir Falso / Verdadero, ejercitadas durante la ejecución del conjunto de datos de prueba), y caminos (porcentaje de todos los caminos posibles ejercitados durante la ejecución del conjunto de datos de prueba). Las categorías 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 CÓDIGO INALCANZABLE, es decir código que no puede ser ejecutado en condiciones normales de uso. Es el caso de porciones de código que se han separado del conjunto colocando un salto (GOTO) a la primera sentencia que le sigue a la porción en la sentencia anterior a la que le da comienzo o que están condicionados por una condición inalcanzable.

Volvemos ahora a Denney y su libro Use Case Levels of Test. Lo habíamos dejado con la construcción del Perfil Operativo del sistema y la construcción de aquellos casos de uso que se justificaban. Ahora ya podemos elaborar sobre estos casos de uso que valen la pena para analizar cuáles pasos hay que cubrir. Del perfil operativo ya no podemos sacar más 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 construcción 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 decisión 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 número de casos de prueba que necesitaremos generar.

Comencemos por hacer abstracción de lo que pasa en un nodo para poder mostrar el método de construcción de casos de prueba progresivamente más la cobertura a medida que agregamos casos al conjunto. Tomando nuevamente prestado de Denney usaremos su ejemplo de la Figura 8.12.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

124 Capítulo 8

Figura 8.12: Diagrama de Flujo de Control con Funcionalidad Abstraída

Dependiendo de si este es un caso de uso de muy alta frecuencia los caminos que vale la pena cubrir con casos de prueba serán diferentes. Imaginemos el peor caso, en el que la cobertura de todos los casos de uso es parte de los criterios de aceptación de una fase de pruebas pero el caso de uso así representado tiene muy baja frecuencia de utilización. Entonces intentaremos hacer lo menos posible para cumplir con el criterio, pero sin usar recursos demás. Cuando hay que elegir un único caso de prueba para un caso de uso generalmente se diseña sobre la base de que el empleo más 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 podríamos tener una misma secuencia de prueba con diferentes datos, pero hablaremos de esto más 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 ejecución de un nodo implica la ejecución de todas las sentencias que forman parte de ese nodo en el código, por lo que “cobertura de nodos en el diagrama de flujo de control” es equivalente a “cobertura de sentencias en el código”. 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 sistemáticamente 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 opción 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 numéricamente 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 método de Denney sugiere… ¡Adivinar! Pero no sin fundamentos. Basándose en la conocida distribución de los bienes del matemático italiano Pareto, Denney propone asignar probabilidad 80% al paso más probable y 20% al otro, si son dos. Por ejemplo, en la Figura 8.13, el paso de salida (1, 2) tendría 80% de probabilidad y el (1, 1a) tendría 20%. Cada paso del camino feliz tiene 80% y las alternativas 20%. Cuando hay solo un camino de salida este tiene un peso probabilístico 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).

Boria et al.

Capítulo 8 125

Figura 8.13: Secuencia de Selección de Caminos para Cubrirlos Todos

Marcela y los equipos técnicos 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 gestión. Finalmente se decide que los criterios serán establecidos por el dueño del producto en conjunto con el equipo durante el juego de planificación, 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 diseñar e implementado para la prueba de integración continua del sprint. Como parte del diseño se acuerda seguir los pasos descriptos por Denney. Para el sprint de estabilización se fijarán criterios especiales ligados a los objetivos de negocio de la empresa respecto del producto en cuestión.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

126 Capítulo 8

Figura 8.14: Probabilidad de Cada Transición del Grafo

QUE HA PASADO HASTA AHORA

69. Jessica incorporó entre las mejoras al sistema de compensaciones la evaluación continua

70. Los gemelos encabezan un grupo de expertos para modificar y mejorar las técnicas de pruebas de producto.

71. Evelina ha resultado Campeona de pruebas y viene de un taller de ingeniería de pruebas dispuesta a aplicar lo recientemente aprendido.

72. Se adoptan las técnicas de diseño de casos de prueba guiadas por riesgos y frecuencia de empleo.

73. 73. Los criterios de cobertura, con diferente énfasis, se emplean en la fijación de objetivos para cada sprint.

74. 74. El Sprint final de estabilización recibirá sus propios criterios de cobertura.

Como último paso en la mejora de procesos de la ingeniería de pruebas Marcela y Jessica exploran la brecha existente entre los procedimientos en uso por T

2 y los resultados esperados del MPS para los procesos de

Verificación y Validación.

Resultados Esperados de VER en el MPS Atividades Internas en Tahini-Tahini VER 1 Los productos de trabajo a ser verificados son

identificados acordar con el equipo la estrategia de verificación, los productos a evaluar y con qué métodos, el cronograma de las diferentes evaluaciones, los criterios de entrada, discontinuación y aceptación (garantizando que la cobertura mínima es uno de ellos) y los ambientes de prueba cuando aplican

VER 2 Una estrategia de verificación es desarrollada e implementada, estableciendo el cronograma, revisores involucrados, métodos para verificación y cualquier material a ser utilizado en la verificación

VER 3 Criterios y procedimientos para verificación de los productos de trabajo a ser verificados son identificados y un ambiente para verificación es establecido

VER 4 Actividades de verificación, incluyendo pruebas y revisiones por pares, son ejecutadas

aplicar a rajatabla auditorías de proceso y producto hasta que se fije la conducta de prueba sistemática

VER 5 Los defectos son identificados y registrados automatizar todas las pruebas

VER 6 Los resultados de actividades de verificación son analizados y puestos a disposición de las partes interesadas

los datos obtenidos de las pruebas y las inspecciones, recorridas y revisiones técnicas, deben ser analizados y discutidos en la reunión mensual de cartera

Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T2

Boria et al.

Capítulo 8 127

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 validación, los productos a evaluar, el cronograma de esta, los criterios de entrada y aceptación y los ambientes de aplicación

VAL 2 Una estrategia de validación es desarrollada e implementada, estableciendo um cronograma, participantes involucrados, métodos para validación y cualquier material a ser utilizado en la validación

VAL 3 Criterios y procedimientos para la validación de los productos de trabajo a ser validados son identificados y un ambiente para validación es establecido

VAL 4 Las actividades de validación 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 aceptación del usuario aumentando la frecuencia de las auditorías y ayudando a prevenir disconformidades, asegurando que los criterios de aceptación se cumplen, basados en documentación fehaciente

VAL 6 Los resultados de las actividades de validación son analizados y puestos a disposición de las partes interesadas

VAL 7 Las evidencias de que los productos de software desarrollados están listos para su uso previsto son provistas

Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T2

Los resultados son muy buenos, lo que la conducción de T2 recibe con mucha alegría. La pregunta que se hacen es si vale la pena hacer una evaluación para el Nivel D o esperar hasta tener el C implementado. Marcela les recuerda que todavía no revisaron todos los procesos del nivel D, falta que se ocupen de Integración del Producto – ITP y de Diseño y Construcción del Producto – PCP.

8.17 Diseño y Construcción

Siguiendo el hilo que surgió de los requisitos, la construcción de casos de prueba, se puede ir hacia ITP considerando que la integración tiene una fuerte componente de pruebas, o hacia PCP, porque el equipo ha elegido Test Driven Design como técnica de diseño. Esto último los guía hacia revisar la brecha con PCP. Estos son los procesos de PCP:

Diseno y Construcción del Producto (PCP)

PCP 1 Las alternativas de solución y los criterios de selección 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 diseñado y documentado

PCP 4 Las interfaces entre las componentes del producto son diseñadas tomando como base criterios predefinidos

PCP 5 Un análisis de las componentes del producto es conducida para decidir sobre su construcción, compra o reuso

PCP 6 Las componentes del producto son implementadas y verificadas de acuerdo con lo que fue diseñado

PCP 7 La documentación es identificada, desarrollada y puesta a disposición de acuerdo con los patrones establecidos

PCP 8 La documentación es mantenida de acuerdo con criterios definidos

Tabla 8.18: Proceso DISENO Y CONSTRUCCIÓN DEL PRODUCTO [SOFTEX, 2012a]

Revisando los materiales derivados de las reuniones de retrospectiva se analizan los problemas que se vinculan al diseño y construcción de los productos. Se refleja este análisis en la Tabla 8.19.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

128 Capítulo 8

Diseño y Construcción del Producto – PCP

riesgo o problema: mitigación:

nos dedicamos a explorar la primera opción de diseño y si no hay razón para descartarla la implementamos sin considerar los objetivos del diseño y buscar alternativas mejores, arriesgando sub-optimizar el mismo

desarrollar criterios universales para iniciar un análisis de alternativas de diseño basados en los objetivos de negocios de T

2 y el proyecto

el sprint de estabilización está teniendo problemas porque el equipo no reconoce algunas decisiones de diseño tomadas que impactan en las pruebas

documentar el diseño, sobre todo el porqué de la selección de componentes, apoyado en los requisitos, sobre todo los no funcionales

la integración a menudo fracasa en el primer intento, haciendo perder un día de pruebas cada vez

realizar un análisis de causa para identificar acciones

hemos intentado reinventar la rueda en varias ocasiones aplicar el análisis de reuso ampliándolo con componentes del mercado

en ocasiones el equipo se ha desviado significativamente de las decisiones de diseño, en aras de mejoras hipotéticas, incrementando la probabilidad de tener que rehacer los casos de prueba a último momento

reforzar el sentimiento de YAGNI109

utilizando solo pruebas que han sido aprobadas por el equipo en el momento de aprobar el plan del sprint

en casos particulares se ha entregado la documentación incompleta o en formato diferente del acordado

añadir una plantilla de revisión de documentación para ser utilizada por afirmación de calidad antes del cierre del sprint

rehacer la revisión de la documentación en el sprint de estabilización

Tabla 8.19: Problemas de Diseño

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 implementación que alcanza esos resultados esperados. Algunas acciones son muy fáciles de implementar, por ejemplo ampliar el análisis de reuso que ya viéramos

110 para incluir entre las opciones componentes que se pueden adquirir fuera de

T2. Esto de inmediato da frutos porque Mariano mantiene un cuaderno de tecnología en la misma wiki que se

guarda la información de componentes reusables. El motivo por el cuál hace esto es porque quiere tener muy claro cuáles son los productos que compiten con las líneas de producto de T

2 y orientarlas hacia las necesidades del

mercado. De ese modo, los equipos no tienen que cambiar ni un ápice sus procesos, un pequeño cambio en el método de búsqueda en la wiki da el resultado esperado. Pero la investigación sobre reuso trajo un regalo inesperado: Se puede adaptar el método de análisis de decisiones para reuso para que sea un método de análisis para diseño en general, de modo que al comenzar el diseño ya se esté pensando en alternativas. De ese modo se ataca la raíz del problema de diseño, el primero de los puntos. Modificado el análisis que debe regir en el juego de planificación queda así:

1. Enunciado de objetivos, es decir, para qué se realiza el diseño del producto del sprint. Algunos ejemplos son acortar plazos sin pérdida de calidad, permitir mantener la duración del sprint desarrollando más puntos de usuario, bajar costos, etcétera.

2. Elección de atributos deseables, donde el equipo discute a partir de los requisitos qué atributos debe tener el diseño, por ejemplo debe ser integrable fácilmente, compatible con el diseño actual, fácil de probar, ejecutar muy rápido, etc.

3. Identificación de soluciones candidatas, que se realiza automáticamente 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 identificación.

4. Evaluación de candidatos, lo que se realizan por pruebas ad-hoc, que son diseñadas contra los atributos elegidos, y la historia de la componente cuando existe, o por métodos menos formales cuando se trata de soluciones originales.

5. Análisis de opciones, esto se realiza siguiendo un método prestablecido que utiliza una matriz de Pugh como la que ya se vio en el Capítulo 4. Una de las opciones es “siempre no utilizar una componente para reusar”.

6. Selección de alternativas, también siguiendo el método anterior.

7. Adopción o Diseño de componente, si aplica, se realiza el ajuste de la componente, de acuerdo a las

109

You Ain't Gonna Need It (No vas a necesitarlo) 110

Capítulo 7, Figura 7.2: Análisis de Opciones sobre Reuso, página 22.

Boria et al.

Capítulo 8 129

necesidades del equipo. Puede que llegado este punto el resultado de la evaluación de alternativas sea totalmente negativo y se deba volver a revisar el diseño.

8. Evaluación del resultado, se compara con los objetivos enunciados en el primer paso para continuar armando la historia de la componente y añadir los conocimientos adquiridos cuando se trata de reuso, y si es un diseño nuevo capturar lo aprendido en la wiki. Si aplica, registrar la componente como útil para reuso.

Tabla 8.20: Análisis de Opciones sobre Diseño

De este modo se extiende la aplicación de reuso a componentes aún no construidas o ya existentes en el mercado.

Realizado un análisis de causa sobre los problemas del fracaso de la integración 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 solución 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 configuración hace que este pequeño cambio sea fácil de implementar. Pese a todo, los primeros Sprints utilizando el cambio todavía muestran trazas de ese problema, por lo que el grupo de Calidad, que ahora depende de Jessica, se aboca a realizar auditorías tempranas para garantizar que las API y las interfaces de usuario están 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 mañana a una oficina vacía y encontrar que los resultados de la noche son nulos.

Ya en el tema de auditorías de calidad, se incorpora la sugerencia de las retrospectivas de agregar un ítem de control que permita conocer el estado de la documentación pactada con el usuario en cada caso. Todas las auditorías pre-demo las incluyen, así como las de ingreso y salida al Sprint de estabilización.

Volviendo al tema de diseño de pruebas, dado que las pruebas se desarrollan de modo sistemático ahora, se hace más deseable utilizarlas como elemento de diseño. Los equipos ratifican su política de usar las pruebas diseñadas 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 Diseño. Para verificarlo construye la siguiente Tabla 8.21.

Resultados Esperados de PCP en el MPS Cobertura en Tahini-Tahini

PCP 1 Las alternativas de solución y los criterios de selección son desarrollados para atender los requisitos definidos del producto y componentes de producto

desarrollar criterios universales para iniciar un análisis de alternativas de diseño basados en los objetivos de negocios de T

2 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 diseñado y documentado

documentar el diseño, sobre todo el porqué de la selección de componentes, apoyado en los requisitos, sobre todo los no funcionales

PCP 4 Las interfaces entre las componentes del producto son diseñadas tomando como base criterios predefinidos

controlar las interfaces de todo tipo para que sus modificaciones se propaguen a los interesados

PCP 5 Un análisis de las componentes del producto es conducida para decidir sobre su construcción, compra o reuso

aplicar el análisis de reuso ampliándolo con componentes del mercado

PCP 6 Las componentes del producto son implementadas y verificadas de acuerdo con lo que fue diseñado

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 documentación es identificada, desarrollada y puesta a disposición de acuerdo con los patrones establecidos

añadir una plantilla de revisión de documentación para ser utilizada por afirmación de calidad antes del cierre del sprint

PCP 8 La documentación es mantenida de acuerdo con criterios definidos

rehacer la revisión de la documentación en el sprint de estabilización

Tabla 8.21: Cobertura de Resultados Esperados de PCP

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

130 Capítulo 8

8.18 Integración

Las retrospectivas también dejaron enseñanzas sobre los procedimientos de integración. En ellas se habían detectado varios problemas relacionados, y se habían propuesto asimismo soluciones. Algunas de estas soluciones propuestas están vinculadas a procedimientos ya implementados para ingeniería de pruebas, por lo que resultan muy fáciles de implementar.

riesgo o problema: mitigación:

la integración continua se está usando muy limitadamente, sin considerar las componentes ya desarrolladas, lo que puede traer consecuencias en el sprint de estabilización (y ya las ha traido en alguno casos)

ampliar el uso de la integración continua para conseguir que las pruebas de regresión se corran con cierta frecuencia para minimizar el esfuerzo de estabilización en el sprint final

cuando el producto comienza a estabilizarse y crecer el ambiente de desarrollo es muy lento y la integración obstaculiza el desarrollo, resultando en horas perdidas

contar con ambientes de integración definidos para los proyectos que sean acordes a sus necesidades, a partir de una definición básica estándar y criterios de ajuste

la integración puede fracasar porque las interfaces no son compatibles, lo que puede llevar a pérdidas de eficacia en el uso de los recursos

asegurar la compatibilidad de las interfaces mediante una mini-inspección antes de subir un módulo a integrar

los cambios a las interfaces tienen efectos negativos en las pruebas de regresión que no siempre se consideran en el análisis de impacto

dedicar parte del procedimiento de análisis de impacto al análisis de interfaces

cediendo a presiones propias los programadores suelen subir código defectuoso al ambiente de integración

utilizar inspecciones breves para analizar los productos y auditar que se han corrido las pruebas unitarias y se cubrieron los criterios

la integración se realiza espontáneamente sin seguir demasiadas pautas, salvo lo que está en scripts de la herramienta

orientar a los equipos para que generen sus propias reglas siempre que incluyan a las normas organizacionales o reciban dispensa para no hacerlo

en el pasado hemos creído haber aprobado una integración cuando en realidad no se había corrido todavía

los datos de la integración deben ser cuidadosamente ingresados en la herramienta y los resultados deben ser analizados como parte del scrum diario

algunos casos de la base de pruebas de regresión han dejado de ser útiles y nuevos casos que debieran haber sido incluídos no lo han sido

añadir a la descripción del rol de ingeniero de pruebas el procedimiento de mantenimiento de la base de regresión

no en todos los casos se ha desarrollado la documentación prevista por contrato a la par del producto en sí, lo que a menudo provoca sofocones sobre el final

orientar a los scrum master para que revisen el backlog y cuestionen la falta de tareas relacionadas con documentación contractualmente obligatoria cuando sea pertinente

Tabla 8.22: Acciones Relacionadas con Integración Derivadas de Retrospectivas

Como parte del procedimiento habitual de integración continua se añadió el correr pruebas de regresión todos los viernes al salir para el fin de semana, para minimizar el esfuerzo de estabilización 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 integración, a partir de una definición básica estándar y criterios de ajuste que integran la BiPro.

Cuando se sube un programa a la línea base para su integración continua, el colega que realizó las pruebas correspondientes debe asegurar la compatibilidad de las interfaces mediante una mini-auditoría antes de subirlo.

En el juego de planificación se dedica ahora parte al análisis de interfaces.

Se realizan mini-auditorías de configuración y procesos para asegurar que se han corrido las pruebas unitarias y se cubrieron los criterios de aprobación de los módulos antes de que puedan ser integrados.

Los equipos adaptan las normas organizacionales para realizar procedimientos de integración, o reciben dispensa para no hacerlo bajo justificación bien documentada.

Los datos de la integración 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 regresión.

Boria et al.

Capítulo 8 131

Es tarea de los Scrum master revisar diariamente el backlog y cuestionar la posible falta de tareas relacionadas con documentación obligatoria cuando sea pertinente por el acuerdo con el cliente.

Con todas estas mejoras el Comité de Gestión espera obtener buenos beneficios, manifestados en los objetivos de negocio.

QUE HA PASADO HASTA AHORA

75. Los cambios introducidos permiten suponer que se cubren los resultados esperados de VER y VAL.

76. La conducción duda si esperar a llegar a implementar el Nivel C o hacer una evaluación 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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

132 Capítulo 9

CAPÍTULO 9 - AMPLIANDO LA CAPACIDAD DE DECISIÓN (NIVEL C de MPS-SW)

9.1 Una Gestión Ambiciosa

Hasta acá la gestión de T2 ha sido, en los dos años y un mes que la hemos estado siguiendo, un proceso

sólido, basado en decisiones estructuradas y con un profundo sentido de las opciones posibles y los riesgos que entrañaban. El éxito obtenido con la implementación de los ajustes a la ingeniería, 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 sólida, y ese es el mensaje que transmite a la conducción. En la reunión mensual de Diciembre, la más importante del año porque coincide con el cierre del ejercicio anual, Marcela hace su anuncio oficial: la ya no tan pequeña Tahini-Tahini va a realizar una evaluación conjunta del Nivel C del MPS y del Nivel 3 (Definido) del CMMI en el año que abre. Ana, que ya sabía 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 están encarando, así como las extensiones a los sistemas de farmacia y hospital que se producen cada cuatrimestre, podrán recibir el apoyo de recursos que requieren o si la demanda por las evaluaciones va a dificultar su éxito. Marcela se dirige a Mariano, interrogándolo 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 galardón sin detener a los proyectos ni un segundo. Hasta que no venga el momento mismo de la evaluación lo único que necesitamos es fondos para dos recursos, uno empleado tiempo completo y el otro, Máximo, para que nos conduzca en las decisiones más importantes”.

9.2 Líder en Acción

"Managers are people who do things right and leaders are people who do the right thing"

111

Marcela presenta un cuadro comparativo de las ganancias haciendo uso de una herramienta nueva (otra más) que introdujo Jessica, el árbol de decisión. 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 expansión 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 añade la expansión al mercado del hemisferio norte.

Figura 9.1: Árbol de Decisión

111

[BENNIS, 1997], Learning to Lead

Boria et al.

Capítulo 9 133

Status Quo Nivel C SCAMPI112

Ingresos Gastos Ingresos Gastos Ingresos Gastos

32.1 25.3 0.8 0.032 1.6 0.069

Probabilidad 0.98 1 0.9 1 0.85 1

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 Decisión

Mariano interviene para señalar que ya han iniciado contacto con una importante farmacéutica que quiere hacer ingresar el producto de T

2 en el mercado de Canadá. Obtener el Nivel de Madurez 3, según Mariano,

terminaría de convencerlos y cerraría el negocio. La votación es unánime a favor de la evaluación conjunta. La Tabla 9.1 muestra los cálculos 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 gestión de riesgos, la gestión de las decisiones y desarrollar métodos para que el reuso sea sistemático.

- “Los tres puntos”, señala Marcela, “ya están en nuestros procesos. Solo es cuestión de detallarlos aun más, ponerlos en papel y documentar su uso de manera más estricta”.

Los gemelos objetan el giro empleado por Marcela: Alberto la acusa de ser ‘ecológicamente incorrecta’ por hablar de papel, Armando explica que en un mundo sin árboles el oxígeno pasa a ser un bien de los muy ricos. El ambiente se distiende y la reunión termina con un brindis: Los Galarraga cumplen años y han traído a la mesa de trabajo Champagne Mumm Cordon Rouge del que se da buena cuenta en minutos.

9.3 Visión Estratégica de los Riesgos

T2 hace más de un año 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 interés en cada una de las disciplinas. Las anomalías en la entrega de los productos y los retrasos en los proyectos están empezando a verse como excepciones y no como la regla. Cuando aparecen problemas son rápidamente identificados y resueltos. Los ingenieros están alerta, detectando los patrones que permiten anticiparse a los problemas, y ha introducido un método 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 Gestión de Riesgos del MPS.

Consciente de los desvíos y excesos en el uso de la palabra “riesgo”, como ilustra su abuso en varias tablas que vimos ya en el Capítulo 8

113, Marcela procede a definir con precisión el significado y el uso del término dentro

de T2. Siguiendo el uso de IEEE, el MPS y el CMMI, “Riesgo” en T

2 es un problema potencial, es decir algo que no ha

ocurrido aun. Existe riesgo en todas las actividades, porque el futuro es incierto. Se le atribuye a Niels Bohr114

la frase “Nada es más difícil de prever que el futuro” e ironías aparte, nada es más cierto desde nuestro conocimiento científico. Marcela elige la forma más amplia de definir un riesgo. Su uso en T

2 parte de la definición de problema.

Habitualmente reconocemos un problema como una situación incómoda, molesta, un obstáculo en nuestra vida o proceso de negocios. Es, en definitiva, algo malo. Si miramos al problema como un problema intelectual, algo que nos desafía a encontrar una mejora aun cuando la situación no es mala, tenemos una mejor definición de problema. Por clasificarlos de algún modo para aclarar, podemos hablar de problemas de desempeño cuando la situación actual es peor que la esperada, problemas de mejora cuando la situación actual no es tan buena como deseamos, y problemas de mantenimiento cuando la situación actual debe ser mantenida. En ese caso hay riesgos de los tres tipos, el primero de los tipos coincide con la definición 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 innovación y lo

112

SCAMPI son las siglas de Standard CMMI Appraisal Method for Process Improvement, el método estándar y oficial de evaluar la madurez de procesos contra el modelo CMMI

113 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 “mitigación” aunque en realidad era un plan de acción para resolver el problema.

114 http://www.aps.org/policy/reports/popa-reports/energy/modeling.cfm

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

134 Capítulo 9

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 tecnología, la ubicación de las oficinas y hasta los métodos de evaluación

115. Una modificación a la política de calidad de T

2 define el alcance de la

aplicación de la gestión de riesgo con precisión.

Lo que Marcela se propone es que todos los que trabajan en T2, desde Alfredo al ingeniero más

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 quiénes tienen capacidades directivas, ¿Cuál es el riesgo? Marcela piensa en una organización 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 evaluación de como actuar al respecto. Por ejemplo, no se puede descartar que antes de finalizar el año 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 países. 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 inversión 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 mitigación posible, pero eso pone en cuestión si vale la pena continuar con el proyecto.

Marcela define el proceso de gestión 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 análisis financiero, valor presente, período de repago y otras maneras de analizar el riesgo monetario. A cada momento se siguen los pasos definidos por Boehm

116: Hay dos etapas, la de evaluación del riesgo y la de control de los riesgos.

En la etapa de evaluación se distinguen las siguientes actividades: Identificación, Análisis y Priorización. En la de control las actividades son: Planificación, Resolución y Monitoreo. En los detalles de cada actividad Marcela se ha tomado libertades para adaptarlos a las necesidades de la empresa.

Fase Fuente de riesgos a evaluar

Categorias

alto medio bajo

preventa cliente nuevo, procesos débiles, teoría X de

gestión117

nuevo, procesos OK, gestión moderna

conocido, procesos OK, gestión moderna

dominio desconocido, baja tecnología, alto impacto en clientes del cliente

conocido en parte, tecnología moderna, impacto medio en clientes del cliente

conocido, tecnología de avanzada, impacto manejable en el cliente

tecnología novedosa, nuevas API, nuevas herramientas

conocida, algunas nuevas herramientas

conocida y compatible 100%

competencia existen buenos proveedores con mucha experiencia

existen buenos proveedores con nuestra misma experiencia

dominamos el mercado

reuso escasísima probabilidad de reuso

algo de reuso pero no en ciertos módulos críticos

fundamentalmente adaptaciones a productos nuestros

115

Ya vimos en el Capítulo 8 que se ha eliminado la evaluación anual, remplazada por la evaluación continua. 116

BOEHM, B., 1989, Software Risk Management. 117

http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

Boria et al.

Capítulo 9 135

Fase Fuente de riesgos a evaluar

Categorias

alto medio bajo

kickoff tradeoff de sprints con requisitos

demasiada funcionalidad para el release planificado

se puede modular la funcionalidad para reducir la duración

se prefiere calidad en lo entregado a muchas funciones

dueño del producto no entiende el problema y está totalmente impedido de tomar decisiones

entiende el problema pero está limitado en su capadidad de decisión

operativo, resolutivo, independiente, capaz

costos del proyecto muy altos, relacionados con la tecnología a incorporar y la curva de aprendizaje

un poco más alto que lo habitual por su duración

habituales

sprints 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 dueño del producto entiende los problemas y apoya que se solucionen antes de llegar a la estabilización

mucha funcionalidad

hay presión por incluir siempre 'un poco más'

hay presión por incluir siempre 'un poco más' pero hay posibilidad de bajar el ritmo cada dos sprints

se puede descartar alguna historia si no se llega con la fecha

requisitos débiles el dueño del producto no sabe definir con claridad lo que necesita

el dueño del producto duda sobre lo que necesita

el dueño del producto sabe lo que necesita y sabe explicarlo

estabilización costos de mantenimiento

no hubo mucho tiempo para arreglar y el sprint de estabilización es corto

quedan cosas para arreglar pero entran en el sprint si no surgen algunos defectos enmascarados

llegamos con muy poco para arreglar, se puede usar tiempo par refactorear

entrega tardía el dueño del producto es terminante respecto de la fecha de entrega y no hay negociación

el dueño del producto negocia calidad por fecha de entrega

el dueño del producto prefiere un producto estable a que se entregue a tiempo

Tabla 9.2: Estrategia de Riesgos de Alto Nivel, Fuentes y Categorías

La estrategia se refina después de la preventa. La captura de conocimiento acerca de riesgos abarca las fuentes, categorías y las medidas asociadas a su eliminación, mitigación, transferencia, disminución, o tratamiento de la contingencia. Hay ya ciertas mitigaciones que se han detectado y forman parte del conocimiento

almacenado. Por ejemplo, la primera decisión de un proyecto es el método organizativo que se va a dar. En T2 los

ciclos de vida autorizados están asociados al tipo de proyecto, para mitigar los riesgos: Kanban para proyectos muy simples con tareas técnicas difíciles de separar en sashimi y que duran algo más 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 pirámide de Scrums haría que de hecho se estuviera trabajando como en una cascada simple. De hecho FDD no ha sido ensayado todavía, la organización no quiere tomar el riesgo de introducirlo cuando el cliente no es suficientemente comprensivo.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

136 Capítulo 9

9.4 Definición de un Riesgo

Detectar el riesgo no es equivalente a definirlo correctamente. Para poder hacer la gestión del riesgo más efectiva y eficiente es importante dedicarle tiempo a la redacción de la definición del riesgo. Se debe indicar claramente la situación actual, presente o potencial que dispara el riesgo. Esta formulación 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 situación 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 definición 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 más, está descripto de tal manera que las condiciones resultantes en la pérdida (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 estabilización al no poder contar con ella 24 x 7” está redactado en términos 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 más personas para que ella pueda dirigirlos remotamente con poca interacción, o conseguir alguien para ese sprint que la suplante. Como se ve, es importante redactar el enunciado del riesgo de manera que sea clara cuál es la fuente del problema, no el embarazo ni la ausencia, sino la falta de experiencia en el momento del sprint de estabilización.

La definición en términos 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 mención a probabilidad, es un problema que ya existe y hasta enuncia el plan de acción a seguir.

9.5 Captura de los Riesgos

Marcela ha adaptado una planilla para que sirva en la captura y gestión del riesgo.

Al explicar la planilla quedará claro el procedimiento de definición, análisis, priorización, monitoreo y control

de riesgos en T2. La planilla comienza con una lista de datos correspondientes al proyecto en cuestión. Las

columnas de izquierda a derecha contienen: el índice del riesgo, un número natural; el enunciado del riesgo, dividido en Condición y Consecuencia; la probabilidad de que el riesgo se materialice, es decir que se transforme en un problema, calculada arbitrariamente como un número real entre cero y uno (ni cero, porque entonces no haría falta controlar ese riesgo por ser imposible de afectar al proyecto, ni uno, porque entonces ya es un problema); la pérdida estimada para el proyecto en caso que el riesgo se materialice, medida en una escala de uno a cien; la exposición que trae el riesgo, definida como el producto entre probabilidad y pérdida, y que es el valor usado para priorizar el riesgo entre los demás, a mayor exposición, mayor prioridad; el orden de prioridad que ocupa ese riesgo en este análisis, donde 1 es el de más prioridad y 10 el de menor; la misma información respecto a la última vez que se realizó el ejercicio de control de riesgos; el número de veces que el riesgo lleva en la lista, lo que es indicativo de su maduración o no; la acción, sea eliminación, mitigación, transferencia, disminución, o tratamiento de la contingencia que se va a tomar, incluyendo, cuando es un plan de contingencia, un disparador para largarlo; y quién va a llevar adelante las acciones y cuando va a reportar su resultado.

Boria et al.

Capítulo 9 137

Figura 9.2: Planilla de Definición, Monitoreo y Control de Riesgos

9.6 Estrategias de Control de Riesgos

En toda estrategia lo que cuenta es la secuenciación de los esfuerzos. La primera parte de un análisis estratégico 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

proyecto se resienta por ellos. En primer lugar las estrategias de T2 (T2

tiene en sus guías de control de riesgos dos

estrategias para ser aplicadas por los proyectos) comienzan por analizar si es posible o deseable la eliminación del riesgo. Dado el ejemplo de la sección 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” debiéramos 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 información. Si hiciéramos un pequeño ensayo en un ambiente especialmente diseñado para ello y viéramos si A y B son realmente incompatibles podríamos tomar mejores decisiones y eliminar el riesgo de nuestra lista.

Si es imposible eliminarlo el próximo paso es intentar transferirlo. Si ha sido el cliente el que exige el uso de las componentes, o si es el que tiene parámetros rígidos sobre la fecha de entrega o el costo, debiéramos ser capaces de ir con ellos y explicar el riesgo, pidiéndoles una cláusula de riesgo que cubre el trabajo extra de construir los envoltorios para generar la compatibilidad entre ellos, cláusula que entra en efecto si el riesgo se materializa. Si hemos sido nosotros mismos los que hemos tomado la decisión apresuradamente

118, 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 algún compromiso. Por ejemplo, puede que si en vez de B usamos C el resultado sea una pérdida menor de desempeño pero una ganancia muy grande en compatibilidad. De este modo se transfiere el riesgo de incompatibilidad a un riesgo de desempeño.

Cuando no se puede eliminar o transferir el riesgo, el procedimiento pide que se intente mitigarlo. La mitigación es exitosa si se reduce la exposición 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 pérdida que el riesgo provoca. Siguiendo con nuestro ejemplo, dada que la situación de incompatibilidad es nuestro ‘gato de Schrödinger

119,

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 pérdida. La pérdida la hemos expresado

118

Tarea para Marcela: modificar el método de decisión de adquisiciones para incluir en la lista de chequeo la compatibilidad entre componentes cuando se compran más de una.

119 Gato de Schrödinger: es un experimento imaginario concebido en 1935 por el físico Erwin Schrödinger para exponer una de

las consecuencias menos intuitivas de la mecánica cuántica. 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 radiación, el frasco se rompe, liberando el veneno que mata al gato. La interpretación de la mecánica cuántica de la Escuela de Copenhague, implica que después de un tiempo, el gato está al mismo tiempo vivo y muerto

Nombre del Proyecto:

Fecha:

Preparado por:

ID - identificador del riesgo Añada las columnas que sean necesarias para monitorear la evolución de los riesgos.

Descripción del Riesgo - problema potencial ( condición y consecuencia)

Prob - probabilidad de que el riesgo se transforme en un problema Perd - Pérdida - potencial relativo de la pérdida (monetaria) o un número entre 1 y 100) Exp - Exposición - producto entre prob y perd

Prioridad en este análisis - ranking pro exposición Prioridad la última vez - muestra el cambio ocurrido # Veces en la lista - resistencia a las acciones

Acción - acciones a llevar a cabo para lidiar con el riesgo Quién - persona responsable por las acciones Cuando - fecha en la que se revisarán las acciones

ID

Prob Perd Exp

Prioridad

en este

análisis

Prioridad

la última

vez

# Veces

en la

lista

Quién Cuando

Condición

1

2

3

4

5

6

7

8

9

10

Acción:

eliminación, mitigación, transferencia, disminución, o

tratamiento de la contingencia

Planilla de Definición y Control de Riesgos

Descripción del Riesgo

Consecuencia

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

138 Capítulo 9

como el esfuerzo invertido para construir artificialmente esa compatibilidad. ¿Se le puede disminuir? Dejamos este ejercicio de la imaginación a cargo del lector, porque no se nos ocurre como.

Por último, si todo lo demás falla o si sospechamos que las acciones pueden no ser efectivas, el

procedimiento de T2 llama al tratamiento de la contingencia. Se entiende por esto que se planifica tomar acciones

que actúan 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 través de ellos. ¿Cuánto 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 pérdida 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 guía de control de riesgos contempla el procedimiento de ataque a cada riesgo, pero la vida no es tan simple. ¿Cómo organizar los esfuerzos si son múltiples los riesgos que hay que atender? Marcela ha recogido dos métodos, uno simple y fácil de aplicar, la matriz de riesgos (Figura 9.3), y otro más sofisticado que llama el espectro de riesgos. Veamos ahora el más sencillo primero.

Se ubican los riesgos en la matriz de la Figura 9.3, construida como se ve sobre dos ejes, la pérdida en el vertical y la probabilidad de ocurrencia en el horizontal. Se han elegido cinco intervalos en cada eje, aunque podrían haber sido otro número. 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 método es el del espectro de riesgos. La guía lo propone para proyectos que tengan muchos riesgos pero cuya importancia estratégica 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 distribución de la exposición siga un patrón parecido con el espectro luminoso, no se distribuye uniformemente sino que hay franjas con un mayor número de ellos que otras de igual tamaño. Simplemente dividir el presupuesto de modo que al primer riesgo le toca más, menos al segundo y así sucesivamente no cumple con el objetivo de usar el esfuerzo de la mejor manera posible. Veamos un ejemplo:

ID Probabilidad Pérdida Exposición

1 0.8 90 72

2 0.8 84 67.2

3 0.8 69 55.2

4 0.8 66 52.8

5 0.6 64 38.4

6 0.5 71 35.5

7 0.5 40 20

8 0.5 32 16

Boria et al.

Capítulo 9 139

ID Probabilidad Pérdida Exposición

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 están muy próximos entre sí. Como los números han sido estimados para la pérdida y la probabilidad en cada caso sin contar con un razonamiento demasiado sólido por detrás es difícil asegurar que el riesgo 1 es mayor en exposición que el 2. Una técnica que se puede aplicar es el análisis de sensibilidad, que veremos luego, para entender mejor las variables en juego. La mejor estrategia es considerarlos de la misma categoría 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 categorías y simplemente monitorear los restantes. En qué proporción se reparten los recursos queda librado a la discreción de cada equipo.

Marcela introduce a los gemelos en los vericuetos del MPS y recluta su ayuda para establecer la brecha con la Gestión de Riesgos. Los gemelos concuerdan con ella en que el alcance de la gerencia de riesgos está bien

establecido en la política de calidad, y que se aplica universalmente en T2. Colocan GRI 1 del lado de los resultados

alcanzados. La Guía de riesgos describe las fuentes y categorías de los riesgos, así como los parámetros 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 método y la documentación acorde se discute en las reuniones mensuales del comité de gestión estratégica. (GRI 4, GRI 5, GRI 6). Se los revisa cada semana, cada quincena o cada mes, según dictamine la estrategia fijada, utilizando la plantilla a ese efecto. (GRI 7 y GRI 8). Las acciones correspondientes, sean de eliminación, mitigación, transferencia o contingencia, se documentan y monitorean para asegurar su efectividad. Marcela está satisfecha, la Guía de Gestión de Riesgos está de acuerdo con el MPS.

QUE HA PASADO HASTA AHORA

78. Tras un período de seis meses de estabilidad, Marcela anuncia los planes para pasar al Nivel C en una evaluación conjunta.

79. Jessica introduce una nueva herramienta de decisiones, el árbol de decisión.

80. Basándose en las presentaciones de Marcela y los resultados del árbol de decisión, el Comité de Gestión aprueba de manera unánime la inversión para alcanzar el Nivel C del MPS en una evaluación conjunta con un SCAMPI de Nivel Definido (3).

81. La primera implementación del Nivel C es la del proceso de gestión de riesgos, que se construye e implanta en tiempo récord.

82. Una vez difundido el uso de la Guía de Gestión 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 están llenos de ejemplos, incluyendo la peste negra y la ocupación de América por los europeos en el Siglo XVI, de sucesos que parecían imposibles a la generación que los vivía y que cambiaron las vidas de las personas y las trayectorias de las naciones. Esta visión del azar, compartida en otras ciencias

120, 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 deberían 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 próximo cisne negro las destruirá y deben segmentarse, dividirse y multiplicarse sin endurecer sus canales de información.

120

Es la tesis dominante en el neo-Darwinismo, ver por ejemplo, Dinosaur in a Haystack: Reflections in Natural History, [GOULD S., 1996].

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

140 Capítulo 9

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 especiales que se hacen, cuando corresponde, sobre la base de métodos formales

121. El propósito de usar métodos

formales al tomar decisiones, es que siguiendo un estándar formal se pueden almacenar, comparar, analizar y

reutilizarse las decisiones basándose en los resultados que arrojan. Al principio, T2 tenía sólo métodos muy

básicos, basados en matrices de Pugh con pesos entre alternativas, pero la importancia de las decisiones ha hecho clara la necesidad de herramientas más potentes, incluyendo árboles de decisión, simulaciones, modelos y

correlaciones simples. T2 se ha iniciado correctamente en el camino de la alta madurez en sus procesos

estratégicos.

Veamos como lo ha hecho. Nuevamente Marcela con su bagaje de la Maestría en Administración ha acudido a un profesor suyo, el Dr. Zito, quien le ha recomendado varias lecturas

122, de las cuáles extrajo Marcela poderosas

ideas que transformó en una Guía de Aplicación de Decisiones.

La Guía es parte del material que se usa en la inducción de ingreso de nuevo personal. La justificación reside en que en todo proyecto de software a menudo se enfrenta el equipo con la necesidad de tomar una decisión. En casi todas esas ocasiones las alternativas están claras y las variables que las diferencian son claramente observables y fáciles de comparar. Seleccionar entre las alternativas resulta sencillo y justificar la decisión tampoco implica un costo extra para el equipo: Las características de la solución son obvias, la generación de alternativas sencilla y la decisión es una consecuencia lógica de aplicar bien los pasos anteriores. En esos casos, la aplicación documentada de un proceso formal es innecesaria. Pero en ocasiones la decisión importa un riesgo muy alto para el proyecto y resulta poco aconsejable tomarla de manera informal. Las decisiones “difíciles” no dejarán de serlo por ser tomadas formalmente, pero si se ejecuta el procedimiento formal paso a paso, la organización 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 Guía formaliza el proceso de toma de decisiones para garantizar que se genera y captura toda la información necesaria de modo de que si la decisión es acertada se pueda repetir y si no lo es, que se pueda analizar lo que se decidió para mejorar esa decisión en futuros proyectos.

El Procedimiento de Análisis de Alternativas y Toma de Decisiones (PAyTDD) permite a la organización tomar decisiones de manera consistente. En particular, el PAyTDD ayuda a los participantes en una decisión a tomar decisiones difíciles, aquellas que entrañan riesgo a bienes o personas. El PAyTDD es un procedimiento sistemático que describe paso a paso las actividades a realizar para poder formalizar la generación, documentación, evaluación y selección de alternativas entre el espacio de soluciones de un problema. Consiste en identificar claramente el problema a resolver, plantear objetivos de la solución (sus atributos), generar (identificar) alternativas, descomponer el problema y modelarlo, medir las alternativas contra el método de evaluación y seleccionar la mejor entre ellas. El Procedimiento de Análisis de Alternativas y Toma de Decisiones (PAyTDD) no fue construido con el propósito de ser aplicado a todas las decisiones que se toman en un equipo. La lista que sigue pretende ser una guía de la aplicación del procedimiento, no necesariamente exhaustiva. El PAyTDD puede ser utilizado en múltiples ocasiones, según sea útil a criterio del equipo o de la gerencia de la organización.

Para la aplicación del PAyTDD la Guía establece claros parámetros: El PAyTDD debe ser utilizado cuando el equipo se enfrente a decisiones que tienen una o más de las siguientes características: (a) La decisión está relacionada con un tópico que se considera de alto riesgo que está siendo monitoreado formalmente, o (b) La decisión afecta el plan de trabajo de modo que se impacta en más de un 5% la línea base, o (c) La decisión afecta el plan de trabajo de modo que se impacta en más de un 5% el presupuesto, o (d) La decisión afecta el plan de trabajo de modo que se impacta en más de un 5% la fecha de entrega del producto, o (e) La decisión afecta el plan de trabajo de modo que se impacta en más de un 5% la calidad final del producto, o (f) El cliente requiere que la toma de decisiones quede integralmente documentada para la decisión en cuestión, o (g) El impacto estimado de la decisión supera en más de un 100% el costo esperado de aplicar el procedimiento PAyTDD. El PAyTDD contiene los siguientes pasos:

121

De hecho en la literatura hay muchas publicaciones que hablan a la vez de riegos y decisiones formales. 122

En particular el Dr. Zito recomendó el libro de CLEMEN, 1997, pero Marcela también encontró útil un libro mucho más sencillo, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, de [Schuyler 1996].

Boria et al.

Capítulo 9 141

1. Definir correctamente al problema a resolver. 2. Establecer atributos deseables de la solución. 3. Definir métodos de medición de los atributos seleccionados. 4. Diseñar métodos de evaluación de las soluciones. 5. Generar o descubrir selecciones alternativas. 6. Aplicar a cada solución generada la medición de los atributos deseables. 7. Evaluar mediante los métodos seleccionados las soluciones generadas. 8. Seleccionar la mejor alternativa.

Tabla 9.4: Definición de los Pasos del PAyTDD

Desarrollaremos cada uno de los pasos con un poco más de detalle. Comenzamos por el paso 1, Definición del Problema. El propósito 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 organización e identificar las causas principales del problema, para usarlas como entrada al paso de selección de soluciones alternativas. Las tareas Involucradas son Fijar los objetivos de Resolución del Problema; Identificar y listar diferentes puntos de vista sobre que constituye el problema; Reducir por agrupamiento el número de temas a una cantidad manejable; Rankear los temas en orden de importancia para el objetivo del proyecto; Realizar un análisis 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 categorías: inmediatas, mediatas, a considerar alguna vez. Los pasos requieren que los participantes estén capacitados para realizar tormenta de ideas, agrupamiento de temas y el uso de herramientas como el diagrama de causa-efecto, jerarquía de objetivos, diagrama de Ishikawa o diagrama de espina de pescado. También deben ser suficientemente responsables para poder realizar un triage de los problemas.

El paso 2, Atributos de la Solución tiene como propósito establecer los objetivos que tienen que ser cumplidos por una solución, es decir, definir los atributos de una solución aceptable en términos de los objetivos. La única tarea es identificar los atributos de una buena solución.

El paso 3, Métodos de Medición tiene como propósito fijar mediciones objetivas de los atributos que deben pertenecer a la solución elegida. Las tareas involucradas son las que siguen: Definir el indicador adecuado para el atributo en cuestión, Describir los criterios de análisis involucrados en el modelo de medición, Listar las mediciones derivadas de las mediciones básicas y las funciones de composición requeridas, Listar las mediciones básicas y su método de medición, y Definir claramente las unidades de cada medición en cada nivel.

El paso 4, Métodos de Evaluación tiene como propósito describir el o los métodos 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 través de los indicadores para poder comparar entre soluciones. En principio los atributos elegidos para representar una buena solución son independientes unos de los otros. Las diferentes soluciones exigen que se realice un análisis 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 propósito definir un conjunto de soluciones que puedan resolver el problema. Las tareas involucradas son las que siguen: Revisar la lista de causas profundas de realización 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 identificación del problema, es aconsejable postergar su realización hasta que haya un conocimiento más profundo de la naturaleza de la solución, cosa que las actividades listadas antes que esta pueden proveer. Por otra parte, es posible que durante la realización de la actividad “1. Definición del Problema” sea natural la identificación de posibles soluciones como colofón de la tarea “Identificar causas profundas”. Cada equipo y cada circunstancia deben indicar cuál de las dos opciones es la correcta para la ocasión.

El paso 6, Mediciones de las Alternativas tiene como propósito obtener indicadores para cada solución alternativa definida a partir de la medición de los atributos pre-definidos para poder evaluarlas. Hay una sola tarea involucrada: Aplicar las mediciones definidas en 3 (Métodos de Medición) a las alternativas identificadas en 5. (Soluciones Alternativas).

El paso 7, Evaluación de las Alternativas tiene como propósito generar la tabla final de resultados para poder seleccionar la solución a adoptar. Las tareas involucradas son: Calcular el “valor” de cada una de las alternativas

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

142 Capítulo 9

utilizando los valores obtenidos en la medición de los atributos y la función de evaluación 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 común. Llegado este punto es bueno revisar lo actuado a lo largo de todo el proceso, juzgándolo a partir de la tabla generada. Si los resultados contradicen el sentido común 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 construcción del valor de la solución individual.

El paso 8, Selección de la Mejor Alternativa tiene como propósito el que dice el título, 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 precisión el impacto de la alternativa en términos de planes y tareas, y Obtener consenso en adoptar la solución de mejor valor para la organización. Un rasgo de madurez organizacional es la implementación inteligente de soluciones elegidas a través de métodos objetivos. En este punto la solución debe ser desplegada con detalle para que la conducción tome la decisión de manera consciente y responsable.

Marcela se propone agregar además los métodos al repertorio de toma de decisiones de T2. Primero redacta

instrucciones para construir una jerarquía 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. ¿Cuál es el objetivo? Habrá quizás muchos, de modo que entender cuál es el más importante es crucial para la decisión. 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 elección surge clara de cuál es el que se elija. Eso puede paralizar la decisión completamente, de modo que es necesario encontrar un objetivo de orden mayor que los contenga. En este caso podría 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). ¿Cuántos recursos serán distraídos para realizar enmiendas en el producto que entregamos con defectos conocidos? Esto lleva rápidamente a otra herramienta de pensamiento, el árbol de decisión. Cuándo 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 capítulo, en la Figura 9.1, introducida por Jessica para analizar la decisión de ir o no a la evaluación de Nivel C y de hacerla o no conjunta.

Figura 9.4: Árbol de Objetivos

Cuando aparece la probabilidad en el análisis, y a menudo ese es el caso en la toma de decisiones, puesto que

se está planteando el problema en un ambiente de relativa incertidumbre, la herramienta que se considera en T2

es el árbol de decisión. El árbol nace de un nodo raíz 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 adaptación (las decisiones no son independientes, una de las ramas quedará vacía porque la decisión de adaptación solo aplica en un caso). Esta versatilidad para adaptarse a decisiones complejas es el rasgo más destacado del árbol de decisión. 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 acompaña al árbol de decisión ejemplifica más claramente la obtención de resultados.

Boria et al.

Capítulo 9 143

Para completar el ejemplo, veamos como se puede refinar el Árbol para un análisis de distintas posibilidades en el caso de optarse por el Nivel C del MR-MPS-SW (Figura 9.5)

Figura 9.5: Árbol de Decisión 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 Decisión Refinado

Marcela añade otra técnica al repertorio, el diagrama de dependencias o diagrama de influencias. Un diagrama de influencia es una representación visual simple en forma de grafo de un problema de decisión. 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 decisión), variables aleatorias (nodos ovalados, llamados nodos estocásticos) 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 jerarquía de objetivos con decisiones de inversión en marketing podemos obtener un diagrama de dominio como el que se muestra en la Figura 9.7.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

144 Capítulo 9

Figura 9.7: Diagrama de Influencias con Inclusión de Otras Inversiones

En el diagrama de la Figura 9.7 se asume que el tamaño del mercado es una variable aleatoria que no puede ser influenciada por las decisiones que se tomen. Esto podría ser revisado, si la inversión en marketing pudiera alterar esto, por ejemplo, incluyendo clientes de otros países. También pudiera ser que haya otras decisiones que influyan en esa variable. De todos modos, en aquellas variables donde opera el azar mantendremos nodos estocásticos en el diagrama aunque sean dependientes, como es el caso de costos. También se puede notar que la calidad del producto influye en la cuota de mercado y en los costos. El nodo ‘número de licencias vendidas’ es redundante, puesto que se desprende su valor de ‘cuota de mercado’ y ‘tamaño de mercado’, pero el propósito de un diagrama de influencias es mostrar las relaciones, por lo que su inclusión no vulnera los objetivos. El diagrama de influencias es una herramienta para la discusión de ideas, no un objetivo en sí mismo. Una vez que se entienden las relaciones entre las variables se utilizan otras técnicas como apoyo a la decisión.

Uno de los problemas de la estimación es la inseguridad sobre los valores estimados. La variación de los mismos es importante en función de comprender el impacto de una decisión. Supongamos que el tamaño del mercado es de varios millones de licencias posibles. Por fijar un número, digamos que se trata de 10.000.000 de licencias. Ahora bien, si cada licencia representa un ingreso de 1.000 dólares anuales, estamos hablando de un mercado de 10.000.000.000 de dólares. Una variación de un punto en la cuota de mercado representa entonces 100.000.000 de dólares. Parece razonable entonces que se utilicen los medios más 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 análisis, el de entender para entender hasta qué punto la incertidumbre asociada a sus parámetros numéricos podría hacer variar la utilidad esperada afectando las decisiones, o en otras palabras, donde hay que invertir en conocimiento para disminuir la incertidumbre, se denomina ‘análisis de sensibilidad’ y la herramienta más común para realizarla es el diagrama de tornado.

Estos diagramas muestran gráficamente los cambios que se producen en la utilidad esperada cuando varía una cantidad o valor específico. Si vamos cambiando una a una las variables manteniendo las demás en su valor original obtendremos un rango de utilidades esperadas por cada una de ellas. Estos rangos se representan como barras en un gráfico. Estas barras se ordenan de arriba a abajo y de más larga a menos larga, de modo que el gráfico se parece a un tornado. Las más 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 más grande cuanto más grande sea la barra correspondiente en el diagrama de tornado. Generalmente se hacen variar los valores entre dos extremos, el mínimo probable y el máximo 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 función de ello tampoco lo es.

El diagrama de la Figura 9.8 ha sido construido sin ninguna base de fórmulas al solo efecto de ilustrar la forma que tienen los diagramas de tornado. Si las fórmulas que produjeron ese diagrama existieran, del diagrama se lee que el tamaño del mercado es la variable que más influye en el objetivo de márgenes. Invertir para tener mejor conocimiento de ese tamaño es sensato. Por lo contrario, nuestro objetivo de aumentar los márgenes parece ser inelástico relativamente al presupuesto de Marketing. Sería mejor transferir ese presupuesto a mejorar la calidad del producto, que está bajo nuestro control, para aumentar así los márgenes.

Boria et al.

Capítulo 9 145

Figura 9.8: Diagrama de Tornado

Para construir el diagrama de tornado una herramienta útil es conocer la dependencia estadística entre las variables. Este conocimiento se expresa en una ecuación llamada de ‘regresión’ que modela la relación entre una variable llamada ‘dependiente’, en nuestro caso ‘Márgenes”, y un conjunto de variables ‘independientes’ que influyen en el comportamiento de la variable dependiente. Este modelo asume la forma de una ecuación Y = c0 + 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 comparación a los demás permite suponer que el impacto de la variación de la variable independiente correspondiente es mayor que el de las demás. Esto, por supuesto, está limitado a que dicha variación 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 término

aleatorio y solo existe para que se cumpla la igualdad. Si se conoce ese valor entonces se puede conocer el ‘ajuste’ de la ecuación.

El problema de la regresión consiste en elegir unos valores determinados para los parámetros desconocidos cj, de modo que la ecuación quede completamente especificada. Para ello se necesita un conjunto de observaciones. En una observación cualquiera i-ésima (i=1,... n) se registra el comportamiento simultáneo de la variable dependiente y las variables explicativas (las perturbaciones aleatorias se suponen no observables). Mediante el uso de técnicas estadísticas se obtienen dichos coeficientes. Dada la existencia de múltiples herramientas de cálculo de dichos coeficientes (empezando por Excel) y la naturaleza de este libro dispensaremos al lector de los detalles matemáticos y remitimos a los interesados a la literatura clásica

123. El uso que se le da a la

ecuación de regresión en T2 es el de poder calcular los valores dependientes para un árbol de decisión, pero

veremos que de este modesto inicio surge una aplicación muy madura, en el Capítulo siguiente.

QUE HA PASADO HASTA AHORA

83. Marcela sigue consejos de su profesor e implementa una Guía 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 difusión.

85. Marcela agrega una Guía de Métodos para que las decisiones no se limiten tan solo a matrices de Pugh.

9.10 La Fábrica de Componentes

Mariano llega muy excitado a las oficinas de T2 un martes por la mañana. Acaba de bajar del avión que lo

trajo de Toronto y llama a una reunión urgente del comité de gestión. Sentado en la sala de reuniones espera a que lleguen los demás. Uno a uno van saludando, se sirven su primer cafecito del día y preguntan el motivo de tanta urgencia a Mariano, que sonríe enigmáticamente y desvía la conversación hacia otros tópicos, 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 guardería. Mariano se para, respira hondo y comienza sin ahorra detalles:

123

[SPIEGEL, M., 2011] es nuestro libro de cabecera para Estadística Elemental.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

146 Capítulo 9

- “Colegas de T2, bienvenidos a la gran empresa. Ayer firmamos con TransKND un acuerdo de

entendimiento para que financien la reingeniería de nuestro producto central para hospitales y farmacias. Su financiación cubre la creación de una arquitectura de línea de producto orientada a los servicios, SOA. La inversión les da derechos de comercialización exclusivos en mercados internacionales, pero no les da

ningún privilegio técnico ni participación alguna en decisiones financieras internas a T2. 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 discusión se aprueba el acuerdo y se encomienda a Mariano y Claudio la firma del contrato. Ana también va a participar por la parte técnica. Alcanzado el resultado Mariano disca el número de su contraparte en TransKND y los empresarios se saludan, se llegó al mismo resultado positivo en el hemisferio norte, hay alianza. La reunión se disuelve antes que los gemelos tengan tiempo de ir a buscar más Mumm.

Ni bien salen al pasillo, Ana se pega a Marcela y solicita su ayuda. Entre las dos y con apoyo de los demás deben dar forma al proceso que se utilizará para la reingeniería y en lo sucesivo, para que todos los proyectos se aprovechen de SOA.

9.11 Service Oriented Architecture (SOA) para Principiantes124

SOA es un concepto que aplica en la construcción 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 código legado, porque nadie puede parar las máquinas y volver atrás la historia cuando los sistemas pasan los millones de líneas de código. De entrada un proyecto de SOA es entonces más parecido a un proyecto de reingeniería 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 están brindando para volcarlos en un formato que permite construir fácilmente a partir de las partes resultantes.

Los servicios son unidades de funcionalidad no asociadas, débilmente acopladas que no tienen llamadas entre ellas. Cada servicio se refiere a una acción, como llenar una solicitud en línea para una cuenta, o ver un extracto de cuenta en línea, o la colocación de una reserva online o comprar billetes de avión.

Los desarrolladores que utilizan SOA asocian objetos individuales (servicios) de SOA mediante el uso de la orquestación. En el proceso de orquestación de la funcionalidad el desarrollador de software asocia (servicios) en una disposición no jerárquica con una herramienta de software que contiene una lista completa de todos los servicios disponibles, sus características, así como los medios para construir una aplicación que utiliza estas fuentes. Tiene entonces que existir un sistema de comunicación heterogéneo para que se puedan compatibilizar

arquitecturas de décadas anteriores con los últimos avances tecnológicos. Veamos el producto estrella de T2, el

sistema que vincula el estado de cada paciente con su historia clínica, la medicación y la farmacia del hospital, así como las farmacias proveedoras de los mismos. Ya tiene tres años de desarrollo y ha crecido a más de un millón y medio de líneas de código. 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.

Pero ahora imaginemos el nuevo gran producto de T2, el sistema hospitalario, hoy colgado de la nube, pero

conectando a los enfermeros, médicos, pacientes, familiares de los pacientes, médicos de cabecera, sistemas de ambulancia y todos los otros integrantes de la gran familia de la industria de la salud. Hay que desacoplar el código de las interfaces y generar un protocolo para que los teléfonos, las Blackberry, las tabletas, las laptop, y toda otra futura invención que aproveche corrientes de bits se puedan aprovechar de esas reglas de negocio y aumentar la capacidad y velocidad de la decisión de los interesados. En lugar de llamarse los servicios entre sí por métodos o rutinas de su código fuente, utilizan protocolos definidos que describen cómo los servicios se pasan y analizan mensajes mediante metadatos de descripción.

Detrás de esto y para permitir que funcione se requieren que estos metadatos tengan el suficiente detalle para describir no sólo las características de estos servicios, sino también 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]

Boria et al.

Capítulo 9 147

envoltorio casi exhaustivo de la descripción del contenido. Análogamente, el lenguaje de descripción de servicios Web (WSDL) por lo general describe los servicios en sí, mientras que en el protocolo SOAP se describen los protocolos de comunicación. Si estos lenguajes de descripción son las mejores posibles para el trabajo, y si se convertirá en o seguirán 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. Los metadatos deben venir en forma tal que los sistemas de software los pueden utilizar para configurarse dinámicamente mediante el descubrimiento y la incorporación de servicios definidos, manteniendo coherencia y integridad. Por ejemplo, los metadatos pueden ser utilizados por otras aplicaciones, como un catálogo, para realizar la detección automática de los servicios sin necesidad de modificar el contrato funcional de un servicio.

2. Los metadatos deben venir en una forma que los diseñadores 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. Cuánto más 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 fácilmente. Cada interface lleva consigo una cierta cantidad de ‘gravamen’ de proceso, por lo que la granularidad de los servicios es una consideración de rendimiento, tanto para el servicio como para futuros usos del mismo. Demasiado pequeño sobrecarga las interfaces, demasiado grande reduce el reuso. Esta característica hace que sea muy rentable el uso de SOA en dominios específicos, en vez de dominios muy generales.

Los servicios SOA están más débilmente acoplados que las funciones de biblioteca conectadas para formar un ejecutable. Los servicios SOA también se ejecutan en wrappers "seguros" (como Java o .NET) y en otros lenguajes de programación que gestionan la asignación de memoria y recuperación, permiten enlace ad hoc y tardío, y proporcionan un cierto grado indeterminado de tipo de datos (data typing).

SOA como arquitectura se basa en la orientación a servicios como principio fundamental de diseño. 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 creación de la enésima aplicación es bajo, puesto que todo el software necesario ya existe porque ha sido creado para satisfacer los requisitos de otras aplicaciones anteriores. Idealmente, uno sólo necesita orquestación para producir una nueva aplicación.

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 programación que proporcionan la base para la integración entre aplicaciones en diferentes plataformas a través de un protocolo de comunicación. Un ejemplo de dicha comunicación es el concepto de mensajes. El uso de mensajes a través de canales definidos disminuye la complejidad de la aplicación final, permitiendo de este modo al programador de la aplicación concentrarse en la funcionalidad en lugar de las complejidades de un protocolo de comunicación.

• El deseo de crear una federación de recursos. Establecer y mantener el flujo de datos a un sistema de base de datos distribuída. Esto permite nuevas funcionalidades desarrolladas para hacer referencia a un modelo de negocio común para cada elemento de datos.

Estos requisitos son centrales para T2 en cuánto son esenciales a la visión de interoperabilidad e

independencia de la configuración hardware y software del cliente. El primer paso es construir la arquitectura de referencia SOA, que provee un plan del diseño de servicios de una implementación a lo largo de una organización. 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

convenientemente empaquetadas. En el caso de T2 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 solución SOA, principalmente Procesos de Negocio y Servicios, además muestra como interactúan estos componentes con los usuarios de negocio, y con los sistemas existentes en la Empresa (sistemas legados). Generalmente orientada a capas por la

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

148 Capítulo 9

independencia que este modelo arquitectónico provee y el poquísimo acoplamiento que produce, hay grandes parecidos con el diseño de Sistemas Operativos moderno

125. Hay definiciones bien documentadas

126 de todo lo

que es necesario describir y como crear un registro de metadatos127

.

SOA es menos una arquitectura que lo que es un paradigma para la construcción y mantenimiento de procesos de negocios que abarcan sistemas distribuidos de gran porte

128. 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 supervisión y guía para gobernar el registro y la orquestación.

Figura 9.9: Ilustración de la Arquitectura SOA

9.12 Armando la Fábrica

Para el proceso de reingeniería dentro de T2 Ana propone contratar un ayudante que trabaja ya con ella en la

cátedra y que cumple con las condiciones y tiene las competencias necesarias. Pasadas las entrevistas y los chequeos de antecedentes, el nuevo ingeniero pasa a ser arquitecto del proyecto

129. Junto con Ana y los gemelos

elaboran la arquitectura de alto nivel, aplicando JMC130

. Después de ese ejercicio comienza a funcionar la fábrica de Software: Dependiendo del dominio en particular de la componente a convertir en servicio, los gemelos recomiendan un experto que asume el papel de programador jefe del equipo

131. Será él quién se encargue de los

detalles de la envoltura132

y la definición de metadatos para el registro. Para la escritura de la envoltura armará su equipo y lo conducirá. En suma, una aplicación clásica de FDD a SOA.

QUE HA PASADO HASTA AHORA

86. Una empresa canadiense establece una alianza con T2 para rehacer la arquitectura del producto

de salud llevándola a SOA.

87. Marcela y Ana arman un proceso para fabricar los servicios a partir del código existente, aplicando FDD.

125

[BORIA, J. 1989] 126

http://www.soa.com/solutions/metadata_federation/ 127

Una búsqueda en Google devuelve más de un millón de sitios 128

[JOSUTTIS, N. 2009]. SOA in Practice: The Art of Distributed System Design. 129

¡Una de esas cosas que ocurren solo en software! 130

Ver capítulo 8, Java Modeling in Color. 131

Ver capítulo 3, Feature Driven Development. 132

En la tecnología de la información, 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 programación, una envoltura es un programa o script que establece las bases y hace posible el funcionamiento de otro programa más importante.

Boria et al.

Capítulo 9 149

9.13 El nivel C del MPS

Revisando lo actuado con Máximo, una vez más invocado para realizar un análisis 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 institucionalización de los procesos.

Dado el nuevo convenio con la empresa de Canadá, el resultado DRU 1: Los dominios de aplicación en los que serán investigadas las oportunidades de reuso de activos o en los cuáles se pretende practicar reuso se identifican, detectando los potenciales de reuso respectivos, está claramente cubierto. El segundo resultado, DRU 2: La capacidad de reuso sistemática de la organización es evaluada y las acciones correctivas son tomadas, en el caso de que sean necesarias, es evidenciado en la incorporación de un arquitecto para SOA y la instalación del proyecto basada en FDD. El tercer resultado, DRU 3: Un programa de reuso, cubriendo propósitos, alcance, metas y objetivos, es planificado con el fin de atender a las necesidades de reuso de dominios, también es evidenciada por este proyecto. El cuarto resultado, DRU 4, que pide que el programa de reuso sea implantado, monitoreado y

evaluado decanta de los mismos preceptos de gobierno que se usa en todos los proyectos de T2. DRU 5 dice: Las

propuestas de reuso son evaluadas de forma de garantizar que el resultado del reuso sea apropiado para la aplicación objetivo, y se aplica en el mecanismo de evaluación de cada sprint del proyecto SOA, mientras que DRU 6, Las formas de representación 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 más alto de especificación del proyecto, realizado por Ana y los gemelos. DRU 7, Un modelo de dominio es desarrollado y sus límites 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 características, capacidades, conceptos y funciones comunes, variantes, opcionales y obligatorias. También la elección de SOA permite fácilmente 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 corazón del nuevo proyecto. El proceso DRU no constituye un problema.

Respecto de los resultados de los atributos de proceso, o RAP, la revisión alcanza hasta aquellos que aplican hasta el Nivel C y no han sido remplazados por otros en el proceso de maduración. Estos son: RAP 1, el más básico, que hace referencia a el grado en que el proceso alcanza sus resultados definidos. Esto es el motivo de que se realice la revisión de los resultados de los procesos, de modo que no es una preocupación para Marcela y su equipo. Tampoco surgen muchas dudas de los siguientes resultados esperados: RAP 2. Existe una política organizacional establecida y mantenida para el proceso; RAP 3. La ejecución del proceso es planificada; RAP 4. Las mediciones son planificadas y recolectadas para monitorear la ejecución del proceso y los ajustes son realizados; RAP 5. Las informaciones y los recursos necesarios para la ejecución del proceso son identificados y puestos a disposición de los interesados; RAP 6. Los roles requeridos, las responsabilidades y la autoridad para la ejecución del proceso definido son asignados y comunicados; RAP 7. Las personas que ejecutan el proceso son competentes en términos de formación, entrenamiento y experiencia; RAP 8. La comunicación entre las partes interesadas em el proceso es planificada y ejecutada de forma de garantizar su involucramiento; RAP 9. Los métodos adecuados para monitorear la eficacia y adecuación del proceso son determinados y los resultados del proceso son revistos con la gerencia de alto nivel para darles visibilidad sobre su situación en la organización. Todas estas forman parte de la planificación normal de proyectos, programas, y sprints, o de la estructura de control de calidad y el mecanismo de

gobierno encarnado en las reuniones mensuales del comité de gestión de T2. 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 implementación de la buena gerencia de configuración 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 documentación 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 relación a los estándares, procedimientos y requisitos aplicables y son tratadas las no conformidades.

Más trabajo le ha dado a Máximo 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 estándar es descripto, incluyendo directrices para su adaptación; RAP 16, la secuencia e interacción del proceso estándar con otros procesos son determinadas; RAP 17, los roles y competencias

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

150 Capítulo 9

requeridos para ejecutar el proceso son identificados como parte del proceso estándar; y finalmente de RAP 18, la infra-estructura y el ambiente de trabajo requeridos para ejecutar el proceso son identificados como parte del proceso estándar. Todo esto lo encuentra Máximo en la BiPro cuando compara los planes de los proyectos con los procesos que les dan origen.

En ese análisis, Máximo se apoya en el proceso definido que cada proyecto elige, siguiendo las guías de adaptación, lo que le permite observar evidencia de RAP 19, un proceso definido es implementado basado en las guías para selección y/o adaptación del proceso estándar; RAP 20, la infra-estructura y el ambiente de trabajo requeridos para ejecutar el proceso definido son puestos a disposición, gestionados y mantenidos; y finalmente RAP 21, los datos apropiados son recolectados y analizados, constituyendo una base para la comprensión del comportamiento del proceso, para demostrar la adecuación y la eficacia del proceso, y evaluar donde pueden ser realizadas mejoras continuas del proceso.

Máximo concluye que T2 está preparada para la evaluación de Nivel C, y en consecuencia, dada la fuerza del

modelo MPS, para hacerla conjuntamente con un SCAMPI de Nivel 3, Definido, del CMMI.

QUE HA PASADO HASTA AHORA

88. Máximo concluye que T2 está preparada para la evaluación de Nivel C, y en consecuencia, dada

la fuerza del modelo MPS, para hacerla conjuntamente con un SCAMPI de Nivel 3.

Boria et al.

Capítulo 10 151

Parte IV – Apogeo

CAPÍTULO 10 - ESTABILIZAR PARA LA MEJORA CONTINUA (NIVELES B Y A DE MPS-SW)

“No es la especie más fuerte la que sobrevive, ni la más inteligente, sino aquella que mejor se adapta a los cambios”

Charles M. Darwin

Han pasado veinte meses desde que visitáramos a nuestros amigos de T2 y ha corrido bastante agua bajo el

puente. Cuando los dejamos estaban preparando su evaluación conjunta de nivel C del MPS con el nivel Definido del CMMI, evaluación que se produjo sin sobresaltos y con éxito a los pocos meses. El desarrollo de la fábrica de software basada en arquitectura SOA era incipiente, y el despegue estaba acentuándose en el convenio con la empresa de Canadá. Casi dos años más tarde todos los aspectos de T

2 se han acentuado positivamente. La

empresa tiene tres líneas 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 está en la ciudad de T

2. Los fundadores son caras conocidas en los programas de televisión locales e invitados

frecuentes a seminarios y charlas. Son todavía jóvenes, algunos han cambiado de estado civil, Adolfo y Ana ya tienen tres niñas, los gemelos siguen siendo más 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 mastín con San Bernardo, que ocupa sus días más que su novio. La vida es buena.

10.1 Estabilidad

En todos los aspectos de nuestras vidas la estabilidad nos ofrece una sensación de tranquilidad. Cuando los sucesos son estables y las sorpresas son mínimas 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 circulación porque nos presentan un panorama donde el provenir es incierto, no se puede hacer predicciones y en consecuencia, los mejores planes salen mal.

Nuestros amigos de T2 dedujeron lo mismo de una experiencia particular en los primeros intentos de

planificar sus sprints para el proyecto SOA. La estimación del esfuerzo y duración de las tareas se realiza en T2,

desde el nivel E, tomando un primer valor asociado al tamaño. En los Scrum este valor fue el punto-historia primero, y a partir del nivel D, puntos casos de uso, dada la introducción de los mismos como parte de la definición 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 técnicas de duración media, no hay un método tan preciso. A partir de esta estimación del tamaño se toma como punto inicial del esfuerzo el valor resultante de aplicar la ecuación de regresión para tareas de ese tipo, tomando los valores históricos 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 ecuación pueda ser usada con el mismo efecto. Durante tres meses las estimaciones se hacían a ojo y se fueron ajustando los parámetros de estimación 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 fábrica. Las predicciones erraban por varios días, hasta por semanas en una ocasión. Armados con las herramientas de análisis se pusieron a trabajar. ¿Porqué un proceso, el de estimación, que había sido suficientemente bueno hasta entonces, ya no servía 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 históricos para tareas semejantes (análisis, construcción, prueba) y los cargaron en la herramienta de software de análisis estadístico

133 en uso y con su ayuda produjeron las curvas normales para ambas poblaciones.

Esperaban que los valores medios fueran distintos, pero no creían que en lo demás las distribuciones fueran muy distintas.

133

Hay muchas herramientas de software para análisis estadístico, incluyendo open source y extensiones a Excel. De mucha difusión es Mini Tab y para las simulaciones de Monte Carlo, Crystal Ball. Para una lista ver http://alternativeto.net/software/minitab/

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

152 Capítulo 10

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 población (a la derecha en los gráficos de la Figura 10.1) pero la mayor diferencia la constituye la dispersión

134. Los gemelos acudieron a Claudio, para abrevar en sus recientemente adquiridos

profundos conocimientos de estadística135

. Claudio se muestra casi sorprendido de la pregunta de los gemelos, que quieren saber por qué las estimaciones son tan erráticas 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 exposición para los líderes técnicos que dirigen las estimaciones.

Claudio se dirige por primera vez a un auditorio dentro de T2, pero no es la primera vez que expone en

público. Él también es ‘víctima’ del éxito de T2 y es a menudo invitado a exponer sobre el análisis financiero

aplicado al análisis de cartera, como lo viene haciendo en T2 desde hace años. Por lo tanto, está preparado, aunque

presentar sobre el tema de estadística es nuevo para él. Su exposición, basada en transparencias, se intitula “Estimación y Dispersión”. Su argumento central es que la precisión de la estimación no es un problema del método de estimación, sino del comportamiento del proceso estimado. Para ilustrar esto elige el siguiente ejemplo:

- “Supongamos que estamos intentando estimar el error de un reloj, para lo cuál 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 día, veinticuatro horas, tendremos 72 observaciones. Ahora bien, imaginemos que observamos un cronómetro. En ese caso las desviaciones estarán, posiblemente, debajo del límite de tolerancia de nuestras mediciones, es decir, si comparamos las mediciones en segundos, es posible que la diferencia entre la computadora y el cronómetro sea menor de un segundo. Aun si fuera de alrededor de un segundo, la dispersión de los datos es mínima. Por contraste, observamos un reloj de pared que se ha quedado sin baterías, por lo tanto, siempre marca la misma hora. Dado que el reloj solo marca doce horas, cada medición 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, quizás si alguno no es cero es el del cronómetro. 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 información que radica en la dispersión y que el valor medio no captura. Si usamos la media del error para ajustar nuestra estimación el reloj de pared nos dará sorpresas: Cada observación dista mucho de la realidad, sin embargo el promedio se compensa. El método es el mismo, el error totalmente diferente. Luego el error no proviene del método, sino de la distribución subyacente de la variable que mide el comportamiento del proceso. Si no nos gustan nuestras estimaciones es inútil castigar a los estimadores, hay que mejorar la estabilidad del suceso que se intenta estimar”.

134

Las medidas de dispersión, también llamadas medidas de variabilidad, muestran la variabilidad de una distribución, indicando por medio de un número, si las diferentes puntuaciones de una variable están muy alejadas de la mediana media. Cuanto mayor sea ese valor, mayor será la variabilidad, cuanto menor sea, más homogénea será a la mediana media. Así se sabe si todos los casos son parecidos o varían mucho entre ellos. http://es.wikipedia.org/wiki/Medidas_de_dispersi%C3%B3n

135 Claudio ha iniciado cursos de doctorado en análisis financiero para empresas. De paso, se ha recibido de Actuario.

Boria et al.

Capítulo 10 153

Figura 10.2: Distribución del Error en Dos Relojes

10.2 Eliminando Aleatoriedad

La resultante es que los procesos de SOA no son estables. Buscando la causa raíz se encuentran varias candidatas: Los procedimientos no están definidos con suficiente precisión, 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 guía han sido mal hechos y esto ha pasado desapercibido por calidad; al ser un proceso nuevo las mediciones están mal automatizadas y la granularidad es mayor que en los casos de Scrum, donde las tareas están claramente separadas y la captura de datos es limpia.

El primer paso para controlar el problema es clarificar el proceso inicial de definición del sprint, que antes era bien descripto por el juego de planificación, pero como este no aplica en SOA, se lo remplaza por un procedimiento centrado en la estimación individual del volumen, realizada por el programador jefe. Esta estimación no es revisada y es parte de la fuente de error. Marcela se encarga de precisar el procedimiento de conteo, construyendo un método semejante a los puntos caso de uso que ya utilizan, pero basado en la densidad y extensión de los metadatos que requiere el servicio o la componente en cuestión. Puesto en práctica, los resultados son prometedores, la dispersión baja significativamente en pocas aplicaciones, pero deciden continuar con el experimento hasta que las herramientas estadísticas señalen que el resultado es significativo al 10%

136. Esto

no los detiene en la mejora continua, puesto que Marcela añade auditorías y revisiones que en el apuro por comenzar el proyecto SOA fueron dejadas de lado. Sea esto una lección: 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 análisis estadísticos sólo 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 confíe en las estimaciones y la estabilidad resultante induce una feliz sensación de estar en control. Hasta que un acontecimiento inusual sacude a todos. Jessica recuerda sus lecturas de Taleb

137 y los “cisnes negros”. Un proyecto nuevo de SOA marchaba normalmente, es

decir de acuerdo con las expectativas, hasta que en el Sprint de estabilización se desplomó el cielo: Los errores no solo estaban fuera de toda predicción sino que cada corrección agregaba nuevos. La cuenta de errores abiertos conocidos subía de ciclo de prueba en ciclo de prueba. Un típico escenario de proyecto fuera de control

138. En vez

de disminuir, los defectos aumentan a cada intento de eliminar uno de ellos. El comité de gestión “tira de la perilla de emergencia” y detiene la línea de producción. En una reunión de los programadores jefe se realiza un análisis de causas profundas que no llega a ninguna conclusión. Por primera vez en su historia, T

2 está perpleja y sin

respuesta. Marcela acude, como siempre, a la literatura existente y sus buenos contactos académicos. El Dr. Zito, que ha consultado para empresas internacionales de software en encarnaciones anteriores de su profesión, sonríe beatíficamente al escuchar su narración, como corresponde a los profesores titulares que ya saben lo que tiene que contestar.

136 En las pruebas estadísticas, se considera un resultado estadísticamente significativo si es tan extremo que tal resultado se espera que surja por casualidad sólo en raras circunstancias. El porcentaje expresa qué tan raro es: 10% significa que una de cada nueve veces el resultado es fruto de la elección 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 Capítulo 9. 138

[GLASS R., 1997]: Un proyecto de software se clasifica como ‘fuera de control’ cuando excede en más del 30% sus estimaciones presupuestarias. En el caso que citamos el indicador de gestión que apunta a esto es el crecimiento permanente de los defectos conocidos y abiertos en cada ciclo de prueba.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

154 Capítulo 10

- “Marcela”, le dice, “estamos hablando del problema de complejidad de las interfaces. Es típico que el acoplamiento bajo produzca, en un sistema lo suficientemente grande, un caos de interpretación. La parte del software de ustedes que interpreta los metadatos se ha vuelto más volátil y compleja que las ganancias que obtienen del bajo acoplamiento. Ya era conocido el problema en la época del análisis estructurado, Constantine hablaba de esto, en 1979

139. La pregunta clave es: ¿Cuánto un módulo debe

conocer de otro para entenderlo y comunicarse con él? Cuanto más debemos saber del módulo B para entender del módulo A, más acoplados están A y B. Puesto que tenemos que saber algo acerca de otro módulo es una prueba a priori de un cierto grado de interconexión, incluso si la forma de la interconexión 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 están 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, están 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, ¿Cómo se arregla esto ahora? Claro que por otro lado también su costado de mejora continua le acucia: ¿Se podría haber prevenido?

El comité de gestión está reunido en junta de emergencia. Marcela expone el caso como lo vio junto al Doctor Zito. En el viaje de la Facultad a las oficinas ha tenido un ‘Eureka’

140 y lo transmite al comité. Utiliza un método de

Ford que se conoce como “las ocho disciplinas141

”, por el cuál se define correctamente el problema igual que en el caso del análisis de causas raíces, pero se le agrega un elemento importante, la contención del problema antes de preocuparse de solucionar las causas raíces.

Con esto en mente, Marcela hace su presentación: 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 crítico 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 código 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 había seleccionado y comunicado su necesidad de estar preparados para esta reunión, a la que llama una retrospectiva acelerada. Ingresan en la sala y Ana, quién ya fue puesta en antecedentes por Marcela sobre el sesgo que quiere darle a la reunión, toma la posta y conduce la discusión sobre los arreglos arquitectónicos que habrá que efectuar para contar con un producto dentro de plazos razonables. Los programadores se sienten muy incómodos, puesto que las reuniones de comité de gestión se han vuelto legendarias en T

2, material de muchas leyendas nacidas al abrigo de la decisiones

tomadas en ella por aquellos que los más jóvenes consideran los popes de T2.

139

[YOURDON, E., CONSTANTINE, L. 1979]. Muchos atribuyen gran parte del material a Constantine, de ahí la cita a medias del Doctor.

140 ¡Eureka! o Heureka en griego “¡Lo he encontrado!”, es una famosa exclamación atribuida al matemático griego Arquímedes,

quién según 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 habría realizado mientras se encontraba sumergido en la bañera. Tal fue su alegría que salió a las calles de Siracusa desnudo y gritando ¡Eureka! Marcela tuvo su Eureka en el automóvil y vestida, por suerte.

141 http://es.wikipedia.org/wiki/Ocho_disciplinas_para_la_resoluci%C3%B3n_de_problemas

Boria et al.

Capítulo 10 155

Figura 10.3: El Método de las Ocho Disciplinas

Tímidamente exponen sus quejas, casi todas justificadas: La conducción sobrestimó la capacidad de adquirir conocimientos por parte de los equipos, así como la capacidad de expresarse con precisión y completitud de los clientes. Los métodos de Denney no sirvieron porque las definiciones iniciales no contenían 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 síntoma, como que el tiempo invertido en al análisis 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 más sombrío 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, confundiéndolo con su hermano, “No hay nada que objetar, la percepción es la realidad en este caso. No importa si pensamos que fue de otra manera, para poder arreglar este desastre necesitamos ponernos en la visión 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, quién 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 más jóvenes, que ha sido alumno de Ana, sugiere empezar de nuevo pero con diferentes métodos y achicar el tiempo reusando el código ya escrito. En parte tratar al código como un legado pero empezar con un modelo más 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 máximo 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 técnicas, “Podemos aplicar JAD y salvar esto en ese plazo”.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

156 Capítulo 10

10.4 Contención

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 método allá por los años en que ambos compartían las aulas del ‘Poli’.

JAD es la abreviatura que se usa para Joint Application Development142

, un método integral de construcción de software basado fuertemente en la participación de todos los interesados en la construcción del modelo del sistema previamente a escribir el código. En cierto modo es uno de los precursores de ágil, porque el equipo es autónomo y elige sus procesos hasta cierto punto y los períodos están prefijados. El método se basa en una investigación inicial, en esencia la recolección de los requisitos, para construir un modelo del sistema en cuestión. Esta etapa, según opina Mariano, puede ser realizada sin intervención del cliente porque los equipos ya tienen el conocimiento necesario. La segunda fase constituye la identificación de un equipo y su convocatoria para revisar y actualizar el modelo. En esta etapa hay dos resultados críticos: La elección de los participantes y el respaldo de la alta gerencia. Los participantes deben ser usuarios CRACK

143 es decir, ser personas reconocidas en el ambiente del

cliente, contar con capacidad de decisión, contar con conocimiento de dominio y ponerse a disposición del equipo. El auspicio de la alta gerencia es necesario por dos cosas: La convocatoria a la reunión debe surgir de la alta gerencia, de otro modo es poco posible que atiendan los usuarios CRACK, y la otra razón es que al hacer la convocatoria el auspiciante debe comprometer a todos con el resultado. Nadie puede decir “esto no es lo que yo quería, pero para terminar la discusión preferí aceptarlo”. El compromiso con el resultado obliga a todos tanto a participar como a negociar, puesto que el proyecto tiene duración fija. La tercera fase es la junta de análisis en sí, donde se propone el modelo, se lo analiza y mejora. Las objeciones que se levantan en la reunión son incorporadas al modelo durante la noche y presentadas de nuevo al día siguiente. Esto y la presencia de personas con conocimiento y poder de decisión genera una dinámica muy rápida y en tres a cinco días se puede cubrir lo que habitualmente lleva dos o tres meses. Quedarán algunos puntos sin cerrar pero los responsables por cerrarlos tendrán un plazo perentorio para hacerlo. En cuanto se cierran las últimas acciones se escribe el código, 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 opción. Mariano queda encargado de hablar con el cliente y facilitar las actividades de JAD futuras.

10.5 Causas Raíces

Hasta cierto punto la reunión ha atacado las causas raíces, pero no todavía de forma sistemática. Marcela utiliza datos del fracaso para mostrar los resultados e iniciar una discusión de análisis. Jessica, que está oficiando de escriba y ha recogido los comentarios de los programadores jefe, propone hacer el análisis a partir de ellos.

riesgo o problema: causa(s) raíz (ces): mitigación:

1 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 auditoría de proceso a la actual auditoría de producto y hacer una revisión por colegas del producto

2 Se sobrestimó la capacidad de los clientes de expresarse con precisión y completitud

Añadir a los riesgos en preventa el conocimiento del negocio del punto de contacto

3 Las definiciones iniciales no contenían reglas de negocio suficientemente claras ni completas.

Los procesos de negocio estaban sufriendo reingeniería al mismo tiempo que se los intentaba describir para construir el sistema

Colocar una claúsula en el contrato que hace responsable al cliente de las demoras relacionadas con requisitos incompletos

4

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

No hay una plantilla única, no hay guías de ajuste ni de uso

Contruir la plantilla estándar para metadatos y los artefactos necesarios para su uso productivo en BiPro

142

[WOOD, S. e SILVER, D., 1995] 143

Ver Capítulo 3.

Boria et al.

Capítulo 10 157

riesgo o problema: causa(s) raíz (ces): mitigación:

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 revisión por inspección y crear la lista de ítems de control para poder realizarlas objetivamente

5 El atraso en el sprint de arquitectura fue tomado como un buen síntoma, como que el tiempo invertido en al análisis 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

¿?

Tabla 10.1: Los Problemas del Proyecto Fuera de Control

La reunión 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 pusiéramos en cambio…” que tampoco prospera.

Jessica finalmente decide intervenir.

- “Esto nos pasa porque somos buenos haciendo autopsias pero no sabemos hacer diagnósticos tempranos,” dice, decidida.

- “¿Cómo, cómo, cómo?”, pregunta con sincera curiosidad Alfredo.

- “Si, somos forenses pero no somos clínicos. No sabemos medir la glucosa en sangre, los triglicéridos, la cantidad de glóbulos rojos, de leucocitos, de calcio. No lo sabemos, y lo que es peor, si tuviéramos los números no sabríamos interpretarlos”, insiste Jessica, a quién le gusta hablar con parábolas e hipérboles.

Ana comienza a entender:

- “No somos clínicos, no hacemos prevención, no hacemos análisis, no medimos… ¿Es eso?”, pregunta Ana.

- “Pero sí medimos”, dice Alberto.

- “Y sí hacemos análisis”, 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 más Jessica, que tiene cierta afinidad por el drama de los países bálticos.

La discusión 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 Predicción 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 cuántos defectos vamos a encontrar, qué número de veces hemos de ejecutar cada caso de prueba o cuando vamos a entregar con la calidad prevista, pero todas estas estimaciones están imbuidas de error y no se ingresa ese error en el cálculo. Recordando

la ecuación de regresión debemos considerar el , porque si este valor es muy grande no podemos poner mucha confianza en la estimación. En cierto modo, es la misma discusión acerca de la estabilidad trasladada a las ecuaciones de regresión. Si los procesos son estables debiera ser posible establecer la correlación 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 podríamos afirmar cosas como que el proyecto está dentro de los límites esperados, en vez de poner valores arbitrarios de 15% por encima y por debajo del valor medio.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

158 Capítulo 10

En términos de las teorías 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 dispersión, mayor es la estabilidad.

10.7 Predicción y Análisis

Nuestra especie basa su conocimiento en una ley: Como el ayer es el hoy. La repetitividad de un fenómeno es el parámetro por el cuál medimos su calidad científica. Las leyes científicas establecen las relaciones entre eventos y objetos, miden los resultados y se las enuncia como ecuaciones matemáticas. Kepler y las órbitas planetarias, o Galileo y el plano inclinado, primero observaron los fenómenos y luego postularon relaciones matemáticas que los explican.

Del mismo modo y basados en los mismos principios pensamos que si nuestra fábrica 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 términos de los procesos, los datos que se han venido juntando sobre las características de los mismos (además de los datos catastrales de las tareas que implementan un procedimiento se lleva la cuenta de la duración de la tarea, el costo, el esfuerzo que demanda, el tamaño 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 más instructivo conocer la distribución de los valores históricos. El punto de Jessica es que si invertimos en conocer la distribución de una variable aleatoria relacionada con nuestros proyectos podemos aplicar control estadístico de procesos

144,

abreviado SPC por sus iniciales en inglés.

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 construcción de casos de prueba por unidad de tamaño del caso de uso en los que se basan. Derivando el histograma vemos que afecta una forma parecida a una distribución normal, quizás un poco más volcada a la derecha que a la izquierda. Revisando en la literatura de

estadística la forma más parecida es la 2, una distribución derivada de la curva normal de Gauss. Siguiendo

nuestra búsqueda vemos que hay una familia completa de curvas semejantes, la familia Weibull (ver Fig. 10.4), y que Putnam

145 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 duración de ciertas actividades estaba fuera de sus límites normales. Esto implica que conocemos cuáles son esos límites. 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 distribución que se produce al mezclar y dar cartas de un mazo, la probabilidad de que ocurra esa exacta distribución 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 términos estadísticos. Si sobre la campana de Gauss, que es la representación de la curva normal, dibujamos zonas correspondientes a la

144

[SHEWHART, 1939] 145

[PUTNAM, L. H. e MYERS, W., 2003]

Boria et al.

Capítulo 10 159

distancia de la media a una, dos, y tres desvíos estándares146

, y llamamos a esas zonas A, B, y C, como en la Figura 10.5, encontraremos que las dos “colas” señaladas con flechas tienen muy baja probabilidad de ser parte de una muestra pequeña 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 esperaríamos 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 adag io es ‘hay que escuchar la voz del proceso’.

Figura 10.5: Zonas de SPC Bajo la Distribución Normal

Si se lo hubiera hecho en las primeras etapas del proyecto fuera de control se hubieran detectado las anomalías y se podrían haber tomado medidas paliativas o correctivas.

Las zonas A, B y C sirven además para otros usos. Dada la característica aleatoria de las variables los valores obtenidos del mismo proceso no son siempre idénticos. La variación 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 desvíos estándares) y a veces musita. Las reglas complementarias a la del punto más allá de la zona de control son múltiples 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 línea ascendente o descendente, puesto que esto también 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 línea 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 fenómeno cíclico 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 precisión y una menor desviación estándar asociada. Otra vez, en general es una buena noticia.

• 4 de 5 puntos consecutivos en la zona B o más allá. • 8 puntos consecutivos por encima y por debajo de la zona C indica que tenemos dos poblaciones

diferentes.

En definitiva, prestar atención 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 El atraso en el sprint de arquitectura fue tomado como un buen síntoma, como que el tiempo invertido en al análisis 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

No hay un conocimiento profundo del comportamiento de los procesos y en consecuencia la superstición se impone a la realidad

Aplicar SPC a los procesos críticos.

Tabla 10.2: La Última Fila del Análisis una Vez Completo

146

Medida de la dispersión de una variable alrededor de la media de su distribución.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

160 Capítulo 10

10.8 Correlación y Regresión

Si T2 hubiera utilizado SPC podría haber detectado las anomalías muy temprano en el proyecto. Ese uso ya

justifica el análisis, pero una vez que poseemos ese conocimiento es tentador poder usarlo más extensamente. Considerando que en los años en que se llevan datos en T

2 la masa de ellos es sumamente interesante Jessica

propone que se identifiquen tendencias y se las analice. Claudio se ha familiarizado con las técnicas de inteligencia de negocios

147 y propone contratar a un doctorando con quién comparte cursos y sabe un experto en el tema. Así

es como, temporariamente, Damián se incorpora al equipo de T2.

Damián segmenta los datos en poblaciones diferentes y produce un análisis detallado de cada una. Arma lo que se llama ‘hipercubos’ de datos que va a someter a métodos estadísticos. 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 análisis, por lo que hay un proceso de extracción que separa los datos y arma una super-tabla, el cubo en cuestión. Sobre ese cubo hace diversas operaciones: limpia los datos, analiza correlaciones y factores mediante análisis de la varianza y análisis factorial; y construye ecuaciones de regresión 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 médico recomienda.

10.9 Identificación de procesos críticos

Dada la gran masa de datos que posee T2 es posible sacar conclusiones de los mismos usando minería de

datos, como hizo Damián, 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 exceso de información, que puede ser tan paralizante como su falta

148. Como dijera Stephen Covey, lo principal es

asegurarse que lo principal es lo principal149

. ¿Pero como?

Si recordamos el modelo de Kano (Figura 10.6) que vimos en el Capítulo 7 la satisfacción del cliente es el principal objetivo de la empresa. En primer lugar debiéramos 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, más allá de las que son verbalizadas en los requisitos, como ya vimos en el Capítulo 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 todavía 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 “críticos”. Un evento “crítico” es un instante en el que el usuario de un producto o servicio se forma una opinión sobre la calidad o el valor del mismo. Por ejemplo, un restaurant de comida rápida en una ruta es elegido para parar a comer por un viajero atraído por la publicidad en el camino, pero al acercarse al el cliente tiene varios eventos críticos, 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 percepción de la seguridad en el estacionamiento, puesto que va a dejar su automóvil 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 análisis de decisiones formal.

147

Se denomina inteligencia empresarial, inteligencia de negocios o BI (del inglés business intelligence) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa. http://es.wikipedia.org/wiki/Inteligencia_empresarial

148 http://www.thedailybeast.com/newsweek/2011/02/27/i-can-t-think.html en Newsweek y su traducción 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)

149 [COVEY, S., 1996], First Things First.

Boria et al.

Capítulo 10 161

Figura 10.6: Diagrama del Modelo de Kano

En productos y servicios de software el equivalente a estos eventos críticos pueden ser diferentes de cliente en cliente, pero hay que considerar los defectos, como las diferencias con los requisitos, en su severidad y número; la adecuación 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, quizás no solo el tiempo acumulado de las demoras sino también la cantidad de veces que se prometió entregar y no se cumplió; la facilidad de instalación (transición de la vieja versión o el producto anterior); el volumen de cambio en los procesos; la migración 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, también 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 percepción de calidad del cliente. Esto constituye lo que se denominan CTCs (Critical to Customer).

El próximo paso es identificar características medibles de un producto, servicio o proceso que son clave, de modo que los límites de especificación o estándares de performance deben cumplirse para obtener la satisfacción 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 crítico y queremos resolverlo. Debemos primero identificar la variable CTQ, en este caso el tiempo de respuesta a pedidos de cambio. La medición que debemos usar o crear es el tiempo de respuesta a un pedido de cambio, medido en días 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 días hábiles. Ahora dispondremos de una señal para medir cuando un pedido de cambio tiene un tiempo de respuesta que excede los tres días. En este punto debemos identificar que lleva a los procesos a demorar más de tres días. La Figura 10.7 muestra una gráfica que ejemplifica nuestro análisis.

Figura 10.7: Barreras a la Calidad

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

162 Capítulo 10

Desde una necesidad genérica expresada por el cliente identificamos los procesos que están haciendo de barrera para la satisfacción del cliente y los procesos relacionados CTQs que específicamente hay que mejorar para eliminar los obstáculos. 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 análisis 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; también 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 análisis podría dar el siguiente resultado (Figura 10.8).

Figura 10.8: Análisis de Factores CTQ

Los rectángulos representan procesos, los óvalos objetivos de negocio traducidos a objetivos de proceso, y las flechas cambios sugeridos. Nótese que “Trato Amable Según Proceso” ha sido traducido en una serie de objetivos que no cubren las necesidades del cliente. Esto es típico de una inhabilidad para traducir en objetivos medibles ciertos comportamientos. Ya hemos recomendado el libro de Mager en Capítulos anteriores y lo volvemos a hacer acá. Están faltando dos objetivos observables: Mira a los ojos del cliente cuando se dirige a ella, y Sonríe 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 gestión 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 asociación 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 número de defectos entregados, acelerar el procesamiento de ciertos datos, mejorar el tiempo de descarga e instalación, etc. etc.

Estos objetivos se pueden asociar fácilmente con procesos, posiblemente más de uno, y para cada uno de ellos podemos a su vez identificar objetivos. Por ejemplo, podríamos asociar la cantidad de defectos entregados con el proceso de inspecciones, y colocar un objetivo de eliminar, o disminuir significativamente la porosidad

150 de

las inspecciones. Esto llevaría a la exploración de varias alternativas para detectar más defectos en cada inspección, ya sea mejorar las listas de chequeo, entrenar mejor al personal o involucrar personal con más experiencia. Conocida la distribución de los valores asociados al proceso, como la densidad de defectos encontrados, se pueden fijar objetivos que expresen las mejoras como modificaciones a los parámetros de la distribución, como disminuir el valor medio, o disminuir el valor de la desviación estándar, lo que significa un aumento en la precisión de la estimación.

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.

Boria et al.

Capítulo 10 163

Figura 10.9: BSC Aplicado a Identificar Procesos Críticos

Por último, una técnica para identificar procesos críticos es construir modelos de regresión con las variables conocidas y analizar la sensibilidad del modelo usando diagramas de tornado. Aquéllos que demuestren mayor sensibilidad son críticos 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 variación ya no podemos enunciar objetivos en términos de un solo número, debemos especificar los límites 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 función (PPF), más o menos 0,001 defecto PPF”. Por supuesto, los números elegidos son arbitrarios y sumamente ambiciosos, pero de nada vale fijar objetivos que no lo sean. Por ejemplo un objetivo de 10 defectos PPF más 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 variación es aceptable para los propósitos del negocio. Por supuesto, somos conscientes que esta no es una definición operativa y que es demasiado subjetiva para aparecer útil. Sin embargo, dado que todos los procesos muestran variación, cualquier definición que fije valores es arbitraria y el único juicio que podemos proponer es el de la adecuación. Visto desde la perspectiva de SPC un proceso estable es uno que se observa dentro de los límites de control. Un concepto afín, 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 límites al proceso, no de control sino de especificación. Ya hemos hablado de la voz del proceso, estos límites ahora se asocian a la voz del cliente. En realidad hay una gran cantidad de vías para identificar los procesos críticos. La Figura 10.10 ilustra muchos de ellos.

Figura 10.10: Factores En la Elección de Procesos Críticos

No solo son importantes las necesidades de los clientes, hay otras variables, como costos y ocupación de recursos que pueden determinar procesos críticos. 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 aquél que es capaz y estable. De hecho podemos poner en duda que un proceso no estable sea capaz porque sería imposible de demostrar. La Figura 10.11 muestra la relación entre ambas características. En la figura UCL significa Límite de Control Superior, del inglés Upper Control Limit. LCL es el Límite de Control Inferior, por Lower Control Limit, USL el

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

164 Capítulo 10

Límite de Especificación Superior y LSL el Límite de Especificación Inferior. En la mitad derecha se muestra un proceso capaz y estable, porque los límites de control están comprendidos por los límites de especificación, 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 límites de control se reduzcan.

Figura 10.11: Procesos Capaces y Procesos Estables

10.11 Líneas Base

Los procesos críticos tienen que ser controlados más 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 límites de control naturales de los procesos, en particular los críticos. A esa caracterización se la llama “línea base de desempeño” 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, Damián 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 línea base de desempeño de todo lo que sirve para la gestión cuantitativa de los procesos críticos.

10.12 Indicadores Líderes

Dada la relación entre los procesos tempranos que se exploran con diferentes medios, Damián ha encontrado que varios procesos sirven de alerta temprana para saber si un proyecto está orientado a alcanzar sus objetivos. La noción de un indicador que permite anticipar resultados de un proceso posterior es fundamental para la gestión cuantitativa de un proyecto. Digamos que hemos decidido que para aumentar nuestra participación 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 más 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 Líderes

Los modelos de regresión que ha construido Damián a partir de los datos son los que nos permiten establecer estas hipótesis. Un indicador es siempre un indicador de resultado

151: mide lo que pasó, ninguno puede medir lo

que va a pasar. Pero algunos indicadores pueden ser indicadores de causa152

porque sus valores sirven para predecir el resultado de las acciones que se encuentran más adelante en el flujo del proceso. Justamente esos

151

También se les llama indicadores de efecto, y en inglés, lag indicators u outcome measures. 152

También se llaman indicadores inductores, y en inglés, lead indicators o performance drivers.

Boria et al.

Capítulo 10 165

modelos de regresión permiten establecer intervalos dentro de los cuáles se encontrará una variable futura a partir del conocimiento del valor actual de un indicador de desempeño. Esto nos permite corregir el rumbo si es necesario. Por ejemplo, Damián ha encontrado en sus datos una relación que modela la duración de la construcción de un requerimiento como predictor de la duración del período 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 Composición del Proceso Definido del Proyecto

Mientras que T2 usaba sus herramientas del BiPro cualitativamente, las guías de ajuste cumplían con creces el

propósito de adaptar el proceso estándar a las necesidades del proyecto en particular. Pero la introducción de las herramientas cuantitativas, las líneas base y los modelos, hacen necesario que se revise el proceso de selección de las componentes. Lo que antes era cualitativo ahora debe ser seleccionado con atención a los objetivos de la empresa. Los objetivos fijados en la reunión mensual se traducen uno a uno para cada sprint, y Damián a partir de sus modelos y las líneas base de desempeño que se les aplica corre simulaciones que le permiten ofrecer a los equipos las alternativas posibles, una o más, 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 Composición del Proceso

Imaginemos que hay tres diferentes métodos para capturar requisitos, las Entrevistas Individuales, JAD y RAD, y que cada uno tiene su línea base de desempeño a nivel del requisito individual, con su distribución para costo, duración y calidad. Lo mismo ocurre para los dos métodos de Diseño, los cuatro de Codificación 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 más costoso que RAD o las Entrevistas. Damián tiene entonces de donde sacar datos para correr sus simulaciones de Montecarlo y generar resultados alternativos que le permitan al equipo interesado hacer la elección que mejor se aviene a sus necesidades.

Si no hubiera ninguna alternativa que permita alcanzar los objetivos cómodamente 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 añaden a los riesgos los procesos que tienen más impacto en el resultado y se buscan alternativas que permitan mitigar esos riesgos.

10.14 Gestión Cuantitativa

Armados con un proceso que debe funcionar en la mayoría de los casos los equipos simplemente tienen que hacer las tareas, medir los resultados y controlarlos mediante SPC para que la gestión se lleve adelante. No hay más necesidad de nada y el proyecto se controla solo mientras los datos no muestren anomalías. 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 Damián, para estimar el efecto de sus decisiones. Esto es así porque los modelos poseen variables que están 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 ejecución a través de modificaciones al proceso.

10.15 La Mejora Continua Como Estrategia de Negocio

Para T2 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 afán de superación 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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

166 Capítulo 10

El conocimiento profundo que ha adquirido de su funcionamiento no solo le permite predecir con mayor precisión que sus competidores los resultados, sino que le permite también elegir los clientes. Aquellos que no le ofrecen seguridad en los márgenes se los pasa graciosamente a los “perseguidores de cuota de mercado”, como los llama Claudio. Este conocimiento y su versatilidad con los métodos ágiles son el fruto directo de decisiones estratégicas que permiten diseñar nuevas líneas de producto con alta probabilidad de éxito. Los riesgos de territorios desconocidos y dominios sin dueño le son conocidos y ha aprendido a navegarlos. Sus análisis de cartera han pasado a ser verdaderos análisis financieros con profusión de datos de mercado, probabilidades y simulaciones.

10.16 Costo de Competir

Todavía más importante para T2 es que sus competidores tienen serios problemas para poder entrar en los

mercados de T2. Sus métodos ágiles y su perfecta posición en el mercado hacen que constantemente arriesguen

márgenes, con las consiguientes pérdidas ocasionales y los dolores de cabeza consiguientes. La calidad de T2 ha

subido el costo de entrada para sus competidores.

Además de eso, T2 puede conseguir los mejores recursos humanos en el mercado porque su mito tiene

mucho arraigo. Trabajar para T2 es un orgullo para los profesionales y es considerada una excelente escuela de

negocios. Si alguien recibe una oferta de T2 es poco probable que la rechace.

10.17 Innovación tecnológica

Sin embargo T2 tiene claro que no se puede dormir en los laureles. Como parte de su programa de inducción a

la empresa los ingresantes reciben instrucción en el proyecto de Escucha Tecnológica. Ese proyecto, hijo de Mariano y Alfredo, quiénes lo comparan al SETI

153, consiste en la búsqueda constante de nuevas ideas y

tecnologías de aplicación. Cada ingeniero de T2 elige una publicación académica, científica o de divulgación, como

Scientific American, CACM, IEEE Computer, IEEE Software, o Discover, y la empresa le paga la suscripción y las cuotas sociales si aplican. A cambio el ingeniero tiene que contribuir al menos una nota al mes sobre lo que ha leído en la revista de T

2, llamada SPI

154 Glass. Al principio del programa cuando los ingenieros se contaban por

unidades todo lo que se enviaba se publicaba. Hoy, con los números acercándose a los mil en las tres plantas, hay un comité de selección 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 técnica en BiPro. La incorporación de estos cambios a los procesos ha sufrido cambios en sí misma también. 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 estadísticos gobiernan las decisiones. El comité de gestión ya no pregunta “¿Cómo va el proyecto?” o “¿Cómo podemos aprovechar eso?” sino que es mucho más preciso: “¿Cuál es la probabilidad de cumplir sus compromisos que tiene este proyecto?” y espera una respuesta numérica con un grafico que lo acompañe. Para el caso de procesos, lo que pregunta es “¿Cómo se modifican nuestros márgenes en el futuro, adoptando ese cambio?” y “¿Cuál es el valor presente de esa inversión?”. Marcela no lleva nada ante el comité que no vaya acompañado del plan piloto, los datos financieros que preparó con Claudio sobre las simulaciones que corrió Damián. En casos en que así se justifique presenta un árbol de decisiones.

153

http://www.seti.org/, SETI es un proyecto de búsqueda de vida extraterrestre. 154

Software Process Improvement, Spy Glass es el nombre del catalejo en inglés.

Boria et al.

Capítulo 10 167

Figura 10.14: Definición de Adyacencias y Espacio en Blanco Según 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 días en que los fundadores se reunían alrededor de una mesa de enchapado vinílico para ordenar sus ideas de diseño y rematar las tareas. La automación gobierna los procesos, pero las ideas gobiernan la automación. T

2 ha aprendido a reconocer su núcleo pero también a explorar “el espacio

en blanco”155

, 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 estén definidas o dirigidas por el modelo de negocios de la empresa actual, es decir, las oportunidades fuera de su núcleo y más 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

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

168 Capítulo 10

de Eric Ries, The Lean Startup156

. Ries llama a su ciclo de retroalimentación Construir-Medir-Aprender. (Ver Figura 10.15). El objetivo es acelerar el aprendizaje pasando tan rápido 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 diseño de nuevas funciones en software. Las reacciones de los usuarios sugieren cambios, ajustes, continuar por el camino y ampliarlo o simplemente suspender el proyecto. Sea cuál fuera el resultado, T

2 cree justificado el experimento porque la organización

aprendió.

A veces los usuarios hacen comentarios que identifican errores gruesos pero no exactamente como resolverlos. Para ello se aplican las mismas técnicas de análisis 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 estadísticos. Ya vimos varias técnicas de uso común, empezando en ‘la noche de los tiempos’ con el diagrama de espina de pescado, y el método de las ocho disciplinas. En dos oportunidades hemos mencionado la Ley de Pareto

157, pero no hemos mostrado una aplicación particular que se

hace en el análisis de causas profundas. Cuando un acontecimiento lo merece, por ejemplo un ‘cisne negro’, el análisis de causa sigue el método habitual de analizar las causas profundas con los expertos, identificar soluciones, estimar su impacto, ‘venderlas’ a la dirección, implementarlas y medir el resultado. Pero en dos ocasiones al año el grupo de Marcela analiza las mejoras a implementar para el semestre. Las fuentes de iniciativas son los grupos de estudio, las sugerencias a través del SPI Glass y los cambios a los objetivos de negocio. Estos últimos sugieren mejoras en términos de márgenes a alcanzar, para lo cuál 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 más esfuerzo demandan son candidatos a seguir el proceso de análisis de causa. La Figura 10.16 muestra un diagrama usado en este análisis.

Figura 10.16: Diagrama de Pareto de Defectos de Código

Los defectos de cada categoría se contabilizan sumando el esfuerzo de corrección individual en días de trabajo. ‘Salida Incorrecta’ acumula 53 días, que representa un 52,5% del total del esfuerzo invertido en correcciones. Entre esta categoría y la que le sigue en importancia acumulan 81,2% del total, un ejemplo de la ley del 80-20. Es fácil sacar conclusiones a partir del diagrama. Por ejemplo, si consiguiéramos disminuir a la mitad el número de defectos de la primera categoría reduciríamos en promedio 26,5 días de esfuerzo de corrección. Esto es traducible a dinero contante y sonante de modo inmediato, por lo que se puede rápidamente 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 análisis.

156

[RIES, E., 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

157 Capítulos 2, en la discusión de Lean, y 8, aplicándolo al análisis de perfil operativo.

Boria et al.

Capítulo 10 169

Este método de experimentar nuevas ideas ha dado frutos muy interesantes. T2 ha generado dos spin-offs:

Una línea de producto nuevo es ya una empresa propia, fabricando ambientes de desarrollo para aplicaciones para telefonía 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 inspección por mes. Una de las aplicaciones desarrolladas por la fábrica de apps es una visión 3-D de un objeto a partir de una filmación de 360º. Las empresas tienen sinergia…

Pero más 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 estudio, a cambio de una participación en la nueva empresa. T

2 está preocupada por la enfermedad del

crecimiento: El anquilosamiento, y lo combate de todas las maneras posibles.

QUE HA PASADO HASTA AHORA

89. Los valores típicos del proyecto de SOA no corresponden a la historia de los proyectos de T2.

90. Un proyecto SOA nuevo entra en crisis y se sale de control.

91. Jessica introduce SPC a T2.

92. Damián ingresa al equipo para realizar análisis de datos con herramientas de inteligencia de negocios.

93. Damián segmenta los datos en poblaciones diferentes y produce la línea base de desempeño de cada una.

94. Con la ayuda de diversas técnicas se identifican los procesos críticos para T2.

95. Definidos los procesos críticos T2 se asegura de que sean estables y tengan ya su línea base.

96. Para los procesos críticos Damián genera modelos estadísticos de predicción para utilizarlos en el análisis de objetivos.

97. El sistema de medición se extiende para incluir indicadores líderes e intervalos de confianza.

98. La composición del proceso definido del proyecto pasa a ser cuantitativa, basada en simulaciones Monte Carlo de su desempeño.

99. La persecución constante de la excelencia sube el costo de entrada para la competencia de T2.

100.La innovación sistemática da frutos dulces.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

170 Capítulo 11

CAPÍTULO 11 - CONCLUSIONES

La no-ya-tan-pequeña Tahini Tahini

Nuestra historia termina aquí. Nuestra amable T2 está considerando una oferta de compra astronómica de dos de sus líneas de negocio, hecha por una empresa gigante de los EE.UU. Los gerentes, aún muy jóvenes, evalúan ideas acerca de su retiro en las islas del Pacífico 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 método de identificación de mejoras de proceso

El uso de una metodología para la identificación de oportunidades basadas en la reducción del fracaso y de los tiempos de entrega, hizo que la compañía se centrase en los negocios antes que en los procesos. Si bien mientras mejoraban los procesos, el objetivo siempre ha sido mejorar la competitividad de T

2. El precio nunca fue

tan alto de manera que los resultados siempre justifican la inversión. En resumen, el resultado es una compañía de clase mundial que justifica su importancia en los hechos.

Métodos Ágiles como una herramienta para mejorar

Uno de los factores que aceleraron la maduración de T2 como empresa, fue la elección de métodos ágiles al

comienzo de su vida. La iteración continua aumentó el conocimiento de los procesos y su aplicación. Con muchos datos en la mano, las decisiones fueron más simples y más exitosas. Aun cuando la creciente complejidad de los sistemas que se desarrollaron eliminaron el uso de Scrum y Kanban, la compañía continúa con su adhesión a los métodos ágiles, eligiendo FDD para atacarlos nuevos retos.

El MR-MPS-SW como marco de crecimiento organizacional

Uno de los aspectos más 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 reacción es frecuente y los errores son muchos, hasta los reinados de calidad donde los clientes están plenamente satisfechos, el MR-MPS acompaña a las organizaciones que lo adoptan. El resultado no siempre es tan exitoso como el de T

2, pero aquellos que no tratan de llegar a la

cima no disfrutarán del paisaje!

Boria et al.

Referencias Bibliográficas 171

REFERENCIAS BIBLIOGRÁFICAS

ABNT, 2012, ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 29110-4-1: Engenharia de Software Perfis de ciclo de vida para microorganizações (VSEs) Parte 4-1: Especificações de perfil: Grupo Perfil Genérico, 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, Ingeniería de Software, Kapelusz (II EBAI).

BORIA, J., 1989 Construcción de Sistemas Operativos, Kapeluz (IV EBAI).

BORIA, J., 2010, Don’t 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-and-productivity/

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.

CHRISSIS, M. B.; KONRAD M. & SHRUM S., 2011 (3rd

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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

172 Referencias Bibliográficas

CRISPIN, L. & GREGORY, J., 2009, Agile Testing. A Practical Guide for Testers and Agile Teams, Addison-Wesley.

CSIKSZENTMIHALYI’S 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/200203-Diaz.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), Addison-Wesley.

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 Alliance’s 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.

Boria et al.

Referencias Bibliográficas 173

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.

McFEELEY, B., 1996, IDEALSM

: A User’s 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, versión 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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

174 Referencias Bibliográficas

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. Zürich: 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 CEO’s 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): 1–9

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, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX, MPS.BR – Guia de Aquisição:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011b, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011c, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível F do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011d, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 3: Fundamentação para Implementação do Nível E do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011e, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 4: Fundamentação para Implementação do Nível D do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011f, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 5: Fundamentação para Implementação do Nível C do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011g, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 6: Fundamentação para Implementação do Nível B do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011h, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 7: Fundamentação para Implementação do Nível A do MR-MPS:2011, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011i, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 8: Implementação do MR-MPS:2011 em organizações que adquirem software, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011j, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 9: Implementação do MR-MPS:2011 em organizações do tipo Fábrica de Software, junho 2011. Se encuentra en: http://www.softex.br.

Boria et al.

Referencias Bibliográficas 175

SOFTEX, 2011k, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 10: Implementação do MR-MPS:2011 em organizações do tipo Fábrica de Teste, junho 2011. Se encuentra en: http://www.softex.br.

SOFTEX, 2011l, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Curso de Introdução ao MPS-Software (C1-MPS-SW), setembro 2011.

SOFTEX, 2012a, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia Geral MPS de Software:2012, agosto 2012. Se encuentra en: http://www.softex.br.

SOFTEX, 2012b, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia Geral MPS de Serviços:2012, agosto 2012. Se encuentra en: http://www.softex.br.

SOFTEX, 2012c, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Avaliação:2012, maio 2012. Se encuentra en: http://www.softex.br.

SOFTEX, 2012d, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 11: Implementação e Avaliação do MR-MPS-SW:2012 em Conjunto com o CMMI-DEV v1.3, agosto 2012. Se encuentra en: http://www.softex.br.

SOFTEX, 2012e, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 12: Análise da Aderência do MRMPS-SW:2012 em relação à NBR ISO/IEC 29110-4-1:2012 -Engenharia de Software Perfis de ciclo de vida para microorganizações (VSEs) Parte 4-1: Especificações de perfil: Grupo Perfil Genérico, setembro 2012. Se encuentra en: http://www.softex.br.

SOFTEX, 2012f, ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX., MPS.BR – Guia de Implementação – Parte 13: Mapeamento e Sistemas de Equivalências 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.

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

176 Referencias Bibliográficas

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

Boria et al.

Sumario 177

Sumário

Prefacio ............................................................................................................................................................ iii

Prólogo - Consultoría en Mejora de Procesos ................................................................................................... iv

El Origen del Libro ................................................................................................................................................ iv El Propósito del Libro ........................................................................................................................................... iv Las Vertientes del Libro. ....................................................................................................................................... iv Nota de Cautela .................................................................................................................................................... v Nota Sobre los Autores ......................................................................................................................................... v Autores ................................................................................................................................................................. vi

PARTE I – Introducción

Capítulo 1 - Introducción ................................................................................................................................... 7

1.1 El propósito del libro ....................................................................................................................................... 7 1.2 Definición de método ágil para este libro ....................................................................................................... 7 1.3 Si la mejora de procesos de software es la respuesta, ¿Cuál es la pregunta? ................................................ 7 1.4 El caso de estudio: La empresa Tahini-Tahini ................................................................................................. 8

Capítulo 2 - El Método de Mejora Continua ..................................................................................................... 12

2.1 Mejora de procesos....................................................................................................................................... 12 2.2 Plan-Do-Check-Act ........................................................................................................................................ 14 2.3 El Método IDEAL ............................................................................................................................................ 15 2.4 Focus-Improve-Sustain-Honor ...................................................................................................................... 17 2.5 Lean Simplified .............................................................................................................................................. 18

Capítulo 3 - Los Métodos Ágiles: Kanban, Scrum, XP y FDD.............................................................................. 22

3.1 ¿Qué son los métodos ágiles? ....................................................................................................................... 22 3.2 Kanban: Midiendo el flujo ............................................................................................................................. 23 3.3 Scrum: Organizando el sistema para un estado de equilibrio orgánico ........................................................ 26

Momentos de Verdad en Un Scrum .............................................................................................................. 27 3.4 XP: Inspecciones, Diseño, Cooperación, y Muchas Pruebas ......................................................................... 28

El Juego de la Planificación. ........................................................................................................................... 29 Entregas Rápidas ........................................................................................................................................... 29 Metáfora ........................................................................................................................................................ 29 Diseño Simple ................................................................................................................................................ 29 Prueba Dirigiendo el Desarrollo..................................................................................................................... 30 Refactoreo ..................................................................................................................................................... 30 Programación en Parejas (o de a Pares) ........................................................................................................ 30 Propiedad Colectiva (de los productos por el equipo) .................................................................................. 31 Integración Continua ..................................................................................................................................... 31 Semana de 40 Horas (hoy llamada Paso Sostenible) ..................................................................................... 31 Cliente Presente ............................................................................................................................................ 31 Estándares de Código .................................................................................................................................... 31 Escalamiento ................................................................................................................................................. 32

3.5 Feature Driven Development ........................................................................................................................ 32 3.6 Resumen........................................................................................................................................................ 36

Capítulo 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 Evaluación del Estado de Madurez ............................................................................................................... 47

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

178 Sumario

PARTE II – Primeros Pasos

Capítulo 5 - Una Organización con Problemas (Nivel G de MPS-SW) ................................................................ 48

5.1 La Pequeña Historia de Tahini-Tahini ............................................................................................................ 48 5.2 ¿Quién Está A Cargo? .................................................................................................................................... 49 5.3 Mostrando la Carga de Trabajo y el Estado de las Tareas ............................................................................. 51 5.4 Planificación, Monitoreo y Control del Proyecto en Dosis Homeopática ..................................................... 54 5.5 El Cliente quiere Cambios ............................................................................................................................. 55 5.6 Avances en la Implementación del MPS ....................................................................................................... 58 5.7 Preparando la Evaluación .............................................................................................................................. 60

Capítulo 6 - Una Organización 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é deberíamos 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 pequeña fábrica de software con Scrum .................................................................................................. 79

Parte III – Evolución

Capítulo 7 - Organizando la Organización (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 Disminución de costos por reuso de componentes ...................................................................................... 94 7.5 Utilizando el conocimiento histórico en los proyectos ................................................................................. 95

Capítulo 8 - Eliminando los Defectos (Nivel D de MPS-SW) .............................................................................. 98

8.1 Determinando el Problema ........................................................................................................................... 98 8.2 Búsqueda de la Solución .............................................................................................................................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 Verificación ..................................................................................................................114 8.8 Revisiones....................................................................................................................................................116 8.9 Actividades del Proceso de Inspección .......................................................................................................116

Junta de Instrucción.....................................................................................................................................117 Inspección Individual del Producto..............................................................................................................117 Junta de Unificación ....................................................................................................................................117 Disposición del Producto .............................................................................................................................118 Retrabajo y Conclusión ................................................................................................................................118 Informe Final ...............................................................................................................................................118

8.10 Factores Críticos 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 Diseño y Construcción ...............................................................................................................................127 8.18 Integración ................................................................................................................................................130

Capítulo 9 - Ampliando la Capacidad de Decisión (Nivel C de MPS-sw) .......................................................... 132

9.1 Una Gestión Ambiciosa ...............................................................................................................................132 9.2 Líder en Acción ............................................................................................................................................132

Boria et al.

Sumario 179

9.3 Visión Estratégica de los Riesgos .................................................................................................................133 9.4 Definición 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 Fábrica de Componentes ......................................................................................................................145 9.11 Service Oriented Architecture (SOA) para Principiantes ...........................................................................146 9.12 Armando la Fábrica ...................................................................................................................................148 9.13 El nivel C del MPS ......................................................................................................................................149

Parte IV – Apogeo

Capítulo 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 Contención ................................................................................................................................................156 10.5 Causas Raíces ............................................................................................................................................156 10.6 La Predicción Como Herramienta .............................................................................................................157 10.7 Predicción y Análisis ..................................................................................................................................158 10.8 Correlación y Regresión ............................................................................................................................160 10.9 Identificación de procesos críticos ............................................................................................................160 10.10 Procesos Capaces ....................................................................................................................................163 10.11 Líneas Base ..............................................................................................................................................164 10.12 Indicadores Líderes .................................................................................................................................164 10.13 Composición del Proceso Definido del Proyecto ....................................................................................165 10.14 Gestión Cuantitativa................................................................................................................................165 10.15 La Mejora Continua Como Estrategia de Negocio ..................................................................................165 10.16 Costo de Competir ..................................................................................................................................166 10.17 Innovación tecnológica ...........................................................................................................................166

Capítulo 11 - Conclusiones ............................................................................................................................. 170

Referencias Bibliográficas .............................................................................................................................. 171

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

180 Lista de Figuras

Lista de Figuras

Figura 1.1: Relación entre herramientas y competencia de personas..................................................................... 8 Figura 2.1: El Método IDEAL [McFEELEY, 1996] .................................................................................................... 15 Figura 2.2: Visión de Mejora de Procesos de IDEAL [McFEELEY, 1996] ................................................................. 17 Figura 3.1: Tablero kanban .................................................................................................................................. 24 Figura 3.2: Nota pósit 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: Relación del Retrabajoo vs. Nivel de CMM [DIAZ & KING, 2002] ........................................................ 37 Figura 4.2: Organización 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 Transición Ilusoria (1) ....................................................................................................... 43 Figura 4.8: Modelo de Transición Ilusoria (2) ....................................................................................................... 44 Figura 4.9: Modelo de Transición Administrada ................................................................................................... 44 Figura 4.10: Modelo de Transición 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 histórias -2- .......................................................................... 55 Figura 5.6: Plantilla para Definición de Historias .................................................................................................. 56 Figura 5.7: Plantilla para Definición y Análisis 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. Información ......................................................................................................................... 72 Figura 6.5: Gráfico sobre Precios Futuros del Petróleo ......................................................................................... 72 Figura 6.6: Proceso de Auditoría 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 Misión y Función .............................................................................................................. 85 Figura 7.2: Análisis de Opciones sobre Reuso ....................................................................................................... 95 Figura 8.1: Estructura Típica 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 Postergación de Actividades de Remoción ........................................................... 115 Figura 8.10: Modelo en V con Revisiones entre Actividades de Traducción ....................................................... 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 Abstraída ............................................................ 124 Figura 8.13: Secuencia de Selección de Caminos para Cubrirlos Todos ............................................................... 125

Boria et al.

Lista de Figuras 181

Figura 8.14: Probabilidad de Cada Transición del Grafo ..................................................................................... 126 Figura 9.1: Árbol de Decisión ............................................................................................................................. 132 Figura 9.2: Planilla de Definición, 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 Decisión Refinado .............................................................................................................. 143 Figura 9.6: Tabla de Pagos Correspondiente al Árbol de Decisión Refinado ....................................................... 143 Figura 9.7: Diagrama de Influencias con Inclusión de Otras Inversiones ............................................................. 144 Figura 9.8: Diagrama de Tornado ....................................................................................................................... 145 Figura 9.9: Ilustración de la Arquitectura SOA .................................................................................................... 148 Figura 10.1: Distribuciones de Esfuerzo de Tareas Semejantes en Dos Poblaciones ........................................... 152 Figura 10.2: Distribución del Error en Dos Relojes .............................................................................................. 153 Figura 10.3: El Método de las Ocho Disciplinas .................................................................................................. 155 Figura 10.4: Curvas de la Familia Weibull ........................................................................................................... 158 Figura 10.5: Zonas de SPC Bajo la Distribución Normal ...................................................................................... 159 Figura 10.6: Diagrama del Modelo de Kano ....................................................................................................... 161 Figura 10.7: Barreras a la Calidad ....................................................................................................................... 161 Figura 10.8: Análisis de Factores CTQ ................................................................................................................. 162 Figura 10.9: BSC Aplicado a Identificar Procesos Críticos.................................................................................... 163 Figura 10.10: Factores En la Elección de Procesos Críticos .................................................................................. 163 Figura 10.11: Procesos Capaces y Procesos Estables .......................................................................................... 164 Figura 10.12: Indicadores Líderes ....................................................................................................................... 164 Figura 10.13: Distintas Posibilidades de Composición del Proceso ..................................................................... 165 Figura 10.14: Definición de Adyacencias y Espacio en Blanco Según Johnson .................................................... 167 Figura 10.15: Construir-Medir-Aprender ............................................................................................................ 167 Figura 10.16: Diagrama de Pareto de Defectos de Código .................................................................................. 168

Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

182 Lista de Tablas

Lista de Tablas

Tabla 2.1: Selección del Método de Mejora de Procesos...................................................................................... 13 Tabla 2.2: Selección del Método de Mejora de Procesos...................................................................................... 20 Tabla 5.1: Tamaños de Tareas .............................................................................................................................. 53 Tabla 5.2 Proceso GESTIÓN DE PROYECTOS en el Nivel G [SOFTEX, 2012a] .......................................................... 59 Tabla 5.3 Proceso GESTIÓN DE REQUISITOS [SOFTEX, 2012a] .............................................................................. 60 Tabla 6.1: Pensamientos Negativos sobre el Cambio ........................................................................................... 65 Tabla 6.2: Preparándonos para Crecer ................................................................................................................. 66 Tabla 6.3: Proceso ADQUISICIÓN [SOFTEX, 2012a] ............................................................................................... 67 Tabla 6.4: Matriz de Pugh sobre Propuestas ........................................................................................................ 68 Tabla 6.5: Riesgos del Crecimiento ....................................................................................................................... 70 Tabla 6.6: Proceso GESTIÓN DE PORTFOLIO DE PROYETOS [SOFTEX, 2012a] ........................................................ 70 Tabla 6.7: Misión y Funciones .............................................................................................................................. 71 Tabla 6.8: Riesgos Asociados ................................................................................................................................ 73 Tabla 6.9: Proceso MEDICIÓN [SOFTEX, 2012a] .................................................................................................... 74 Tabla 6.10: Definición de Mediciones .................................................................................................................. 74 Tabla 6.11: Definición 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 Configuración ......................................................................... 76 Tabla 6.14: Proceso GESTIÓN DE CONFIGURACIÓN [SOFTEX, 2012a] ................................................................... 77 Tabla 6.15: Riesgos de no Auditar ........................................................................................................................ 78 Tabla 6.16: Severidad de Inconsistencias en Auditorías ....................................................................................... 78 Tabla 6.17: Proceso ASEGURAMIENT DE LA CALIDAD [SOFTEX, 2012a] ................................................................ 79 Tabla 7.1: Actividades de Reclutamiento e Incorporación de Personal ................................................................ 86 Tabla 7.2: Porcentaje de Éxito en Actividades Seleccionadas por Tipo de Cargo .................................................. 87 Tabla 7.3: Riesgos a T

2 Derivados de Políticas 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 GESTIÓN DE RECURSOS HUMANOS [SOFTEX, 2012a] ............................................................. 89 Tabla 7.7: Orientación Sugerida por Perfil de Sprint ............................................................................................ 92 Tabla 7.8: Proceso DEFINICIÓN DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a]............................................ 92 Tabla 7.9: Proceso EVALUACIÓN Y MEJORA DEL PROCESO ORGANIZACIONAL [SOFTEXT, 2012a] ........................ 94 Tabla 7.10: Proceso GESTIÓN DE REUTILIZACIÓN [SOFTEX, 2012a] ...................................................................... 95 Tabla 7.11: Proceso GESTIÓN DE PROYECTOS (A partir del nivel E) [SOFTEX, 2012a]............................................ 97 Tabla 8.1: Problemas de Requisitos ................................................................................................................... 101 Tabla 8.2: Comparación entre Métodos de Desarrollo por su Beneficio ............................................................. 104 Tabla 8.3: Comparación entre Métodos 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 Mitigación de Riesgos en Requisitos .................................................................... 111 Tabla 8.10: Implementación de DRE en T2 ......................................................................................................... 112 Tabla 8.11: Problemas de Validación ................................................................................................................. 113 Tabla 8.12: Problemas de Verificación ............................................................................................................... 113 Tabla 8.13: Comparación 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 Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T

2 .............................................................. 126

Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T2 .............................................................. 127

Tabla 8.18: Proceso DISENO Y CONSTRUCCIÓN DEL PRODUCTO [SOFTEX, 2012a] .............................................. 127 Tabla 8.19: Problemas de Diseño ....................................................................................................................... 128 Tabla 8.20: Análisis de Opciones sobre Diseño ................................................................................................... 129 Tabla 8.21: Cobertura de Resultados Esperados de PCP ..................................................................................... 129 Tabla 8.22: Acciones Relacionadas con Integración Derivadas de Retrospectivas .............................................. 130

Boria et al.

Lista de Tablas 183

Tabla 9.1: Tabla de Pagos del Árbol de Decisión ................................................................................................ 133 Tabla 9.2: Estrategia de Riesgos de Alto Nivel, Fuentes y Categorías ................................................................. 135 Tabla 9.3: Ejemplo de Tabla (Parcial) de Riesgos ................................................................................................ 139 Tabla 9.4: Definición de los Pasos del PAyTDD ................................................................................................... 141 Tabla 10.1: Los Problemas del Proyecto Fuera de Control .................................................................................. 157 Tabla 10.2: La Última Fila del Análisis una Vez Completo ................................................................................... 159