Tahini tahini sp-final_(cover_-_a4)
3 recomendaciones2,532 vistas
El libro 'La historia de tahini-tahini' aborda la integración de métodos ágiles y modelos de madurez en el desarrollo de software, argumentando que no son incompatibles y que, en cambio, pueden coexistir para mejorar la calidad y madurez de los procesos. A través de una narrativa centrada en una empresa ficticia, los autores exploran técnicas como Kanban, Scrum, XP y FDD, presentando un enfoque práctico y lleno de humor sobre la consultoría en mejora de procesos. Este texto, resultado de una iniciativa del Ministerio de Ciencia, Tecnología e Innovación de Brasil, está dirigido a profesionales del software e ingenieros interesados en la mejora continua de sus procesos.
![Boria et al.
PARTE I – Introducción
CAPÍTULO 1 - INTRODUCCIÓN
1.1 El propósito del libro
Este libro está dirigido a (en orden de interés creciente):
•
implementadores de mejora de procesos de software que quieran conocer mejor los métodos
ágiles para implantarlos en organizaciones de software;
• gerentes de proyecto interesados en conocer mejor los métodos ágiles para desarrollo de
software, sea para adoptarlos o para evaluar su adopción;
• ingenieros de software que intentan trabajar em un proyecto ágil;
• profesores de grado en Computación;
• estudiantes de grado en Computación;
• profesores de postgrado en Ingeniería de Software;
• estudiantes de postgrado en Ingeniería de Software.
En la medida en que los métodos ágiles y los modelos de madurez han sido considerados términos opuestos
en las disciplinas de desarrollo y mantenimiento de software, es difícil concebir un texto que busque alzar un
puente entre los dos mundos. Ya fue hecho, sin embargo, con gran suceso, en el moderno clásico [BOEHM &
TURNER, 2003]. El modelo de referencia para ellos es el CMMI, siendo fácil de imaginar la conversión para el MRMPS-SW, dada la intencional compatibilidad entre los dos.
1.2 Definición de método ágil para este libro
1
Este libro está principalmente enfocado en cuatro métodos ágiles : Kanban, Scrum, XP y FDD (Feature Driven
Development). Esta elección no es por azar. Esos cuatro métodos cubren la mayoría de las implementaciones
ágiles realizadas en el mundo. Además, cubren casi todas, sino todas, las necesidades de uso de métodos ágiles.
Cada uno de estos métodos será debidamente explicado en el capítulo 3, donde se los introduce al lector.
Obviamente, esto ocurrirá en orden creciente de complejidad: Primero el más sencillo y el que tiene el mayor
retorno de la inversión, Kanban. Kanban tiene alto retorno porque al organizar las tareas y detectar los problemas
rápidamente permite al equipo que lo utiliza aumentar el tiempo disponible para mejorar sus procesos e intentar
nuevas mejoras. Scrum, que frecuentemente es el método que se elige desde un principio, acá se ve sólo cuando la
empresa ha conseguido estabilizarse lo suficiente como para tener el tiempo de conseguir que las actividades de
Scrum puedan ser seguidas con la correspondiente disciplina. Las otras dos técnicas se suman a las ya vistas a
medida que la empresa gana en definición de sus procesos y en el número de su personal.
1.3 Si la mejora de procesos de software es la respuesta, ¿Cuál es la pregunta?
El principal enemigo de una empresa desarrolladora de software es la baja calidad. Hasta ahora, nadie tiene
una propuesta válida para mejorar la calidad, salvo la mejora de procesos, que pasa a ser entonces la cuestión
principal. Se puede argumentar que las personas y las herramientas (de software, como CASE) son importantes en
su impulso a la mejora de la productividad. Esto es cierto, pero solo cuando los procesos están en su lugar para
conseguir que se aprovechen las condiciones de los individuos y las herramientas de software. Es común el caso de
2
empresas y organizaciones que desaprovechan sus recursos humanos y tienen licencias que no se usan, por lo que
se deduce que si bien las herramientas y las capacidades de las personas son importantes, son los procesos los que
habilitan realmente el aumento de productividad.
En la Figura 1.1 simbolizamos esto con íconos. En la primera “ecuación” el personal capacitado sumado a
herramientas de software, sumado a procesos bien definidos culmina (después del signo de igualdad) en éxito y
1
2
Las principales referencias de cada uno de los métodos están indicados cuando se describe cada uno en los capítulos
siguientes.
En este libro utilizaremos en lo que sigue el término “organización” para referirnos a todo tipo de grupo humano organizado
para la realización de tareas con un propósito común, sea con o sin fines de lucro.
Capítulo 1
7](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-7-320.jpg)
![Boria et al.
de las organizaciones y de la relación multicausal de los eventos. De este modo preparamos al lector para que
entienda porque una sola acción puede resolver muchos problemas y como a veces es necesario aplicar múltiples
acciones (y esperar) para obtener resultados. El libro de [POPPENDIECK et al., 2010], Leading Lean Software
Development, es nuestra guía por este territorio. También, donde es útil, citamos material del clásico de
[MEADOWS, 2008] Thinking in Systems, A Primer. Los dos libros revolucionan el pensamiento clásico, lineal, de los
gerentes tradicionales, y abren la puerta a una gerencia más ágil, más integrada y con más posibilidades de éxito.
En el Capítulo 3 introducimos los métodos ágiles propiamente dichos. Si bien Lean es un método ágil según
3
sus creadores y es reconocido como tal por la comunidad ágil , su uso exige mucho conocimiento y está más allá
de los objetivos de este libro. En cambio, las técnicas que proponen Kanban, Scrum, XP (Extreme Programming) y
Feature Driven Development (FDD) son del mismo modo exitosas y mucho más fáciles de adoptar, sobre todo si se
lo hace en el orden en que las proponemos en este libro. Esta es una introducción a los métodos y en ningún
momento pretende remplazar la lectura de los textos clásicos del tema, que se citan en la bibliografía y que
recomendamos fuertemente al lector.
El Capítulo 4 se dedica al eje central de este libro, el modelo de Mejoría de Procesos de Software (MPS). Otra
vez, el libro es incapaz de contener todo el conocimiento necesario para hacer buen uso del modelo, de modo que
referimos al lector a las guías que Softex ha publicado y que se encuentran accesibles en el sitio web de esa
4
organización . Las guías son un material indispensable para el lector que pretenda seguir nuestras sugerencias e
implementar siguiendo el MPS. Lo que sí exploraremos en detalle son las grandes pinceladas que es necesario
comprender para que el modelo tenga sentido y no se pierda en los detalles que, necesariamente, hay que aplicar.
Discurriremos sobre la evolución de la cultura imperante en la empresa que fuera inducida por la maduración de
los procesos, manifiesta en el cambio de los niveles de madurez del modelo, concepto en el que nos detendremos
en este capítulo, así como en la arquitectura del modelo que permite encontrar en él las herramientas para su
implementación. Para concluir el capítulo explicamos el concepto de evaluación y como una organización puede
aplicarlo a sí misma, para entender dónde se encuentra y qué camino le falta recorrer.
2
El Capítulo 5 introduce en detalle los problemas iniciales de T . Utilizando ejemplos que han encontrado en su
actividad como consultores y evaluadores de procesos, los autores introducen al lector a los problemas típicos de
una empresa que funciona bien cuando todas las cosas están en su cauce. Los pequeños problemas cotidianos (un
embarazo, una zona sin recepción telefónica, un cliente apurado) pueden desencadenar una “tormenta perfecta”
2
que arruine la mejor reputación. Es ahí cuando los amigos de T deciden introducir métodos de control y
aconsejados correctamente comienzan a utilizar Kanban. Al mismo tiempo consiguen implantar, sin demasiado
esfuerzo extra, procesos del modelo MPS. Tentados por la facilidad con que implementaron los procesos del Nivel
G, los socios deciden realizar una evaluación formal con un evaluador líder y pasan con éxito. La adopción del MPS
2
por la empresa T es ahora un hecho.
En el Capítulo 6 los autores cuentan como los socios, alentados por el éxito obtenido por sus mejoras de
proceso, deciden profundizar el camino y utilizan el modelo MPS para hacerlo. Los controles establecidos hacen
lugar a la gerencia de configuración, que en germen ya comenzaran a implementar en el nivel G; la medición, que
la formación profesional de los socios hace que sea considerada una actividad fundamental para controlar y dirigir
la empresa; y el control de la calidad, impuesto por la realidad.
La llegada de nuevos clientes con pedidos de proyectos que son a veces de adaptación, a veces nuevos
desarrollos, hace que los procesos de la gerencia de portafolio de proyectos les resulten valiosos para entender
cómo organizar el crecimiento de la demanda. Este crecimiento les lleva a plantearse uno de dos caminos: crecer
internamente, lo que significaría ampliar el espacio físico para admitir más desarrolladores, con la consecuente
inversión fija; o subcontratar parte del trabajo. Para tomar la decisión, los socios se apoyan en los procesos de
adquisición y deciden a favor, lo que les lleva a implementarlos. Aun así, su pequeño equipo inicial debe dividirse
para atender el nuevo volumen de trabajo, e incorporan un número pequeño de desarrolladores. Para organizar
los proyectos, los socios deciden utilizar prácticas de Scrum, que les resultan compatibles con el MPS. Para
2
demostrárselo a sí mismos, la T pasa por una nueva evaluación y alcanza el Nivel F.
En el Capítulo 7 comienza la tercera parte, que desarrolla los procesos intermedios del modelo MPS. A
medida que se expanden los negocios y se abren nuevas oportunidades, los socios se ven obligados a expandir
3
4
La comunidad ágil se reconoce en el sitio web: http://www.agilemanifesto.org/
http://www.softex.br/mpsbr/_guias/default.asp
Capítulo 1
9](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-9-320.jpg)
![Boria et al.
la excelencia madurando como organización usando métodos ágiles, para lo cual usaremos un caso de ejemplo y
un modelo.
Es el modelo MPS, en nuestro caso, aquél que orienta la secuencia de acciones en lo que hace al crecimiento
de la madurez organizacional. El modelo MPS, que explicaremos con más detalle en el capítulo 4, es un modelo de
desarrollo organizacional por niveles, que define los procesos que la organización debe implementar en su seno y
los resultados esperados de ese accionar, para ir avanzando de nivel a nivel. Aun cuando es la intención de todos
seguir el modelo, es imposible implementar todos los cientos de procesos a la vez, inclusive si nos restringimos a
tomar los niveles de a uno, cosa por otra parte muy saludable, porque los hábitos que se construyen en uno se
aplican en el que le sigue.
Hay necesidad, por lo tanto, de encontrar un método que nos ayude a organizar el crecimiento en términos
más concretos de lo que hace el MPS, y que a su vez se compadezca de las necesidades de la organización en
cuánto a sus negocios. Como se puede imaginar el lector, no hay una única manera de hacer esto. Por ello, hemos
decidido anticipar la presentación de un proceso del MPS, no en detalle, pero si mostrando su uso. Tomando
prestadas técnicas del MPS en su proceso Gerencia de Desiciones (GDE), comenzaremos por definir el problema
que intentamos resolver.
Problema: Si bien en un marco ‘macro’ los niveles del MPS alcanzan para definir las pautas de la mejora
continua, en cada caso es necesario atender a las necesidades de la organización que pretende mejorar sus
5
procesos, teniendo en cuenta el ‘negocio’ de la misma.
Atributos deseables de una Solución: La solución debe de proveer un mecanismo de mejora continua que
permita identificar cada paso sucesivo de un programa de mejora y este debe tener suficiente detalle como para
que sea posible ejecutarlo sin demasiada ambigüedad, pero no tanto que implique una planificación detallada para
cada selección (DETALLE). Debe proveer un marco teórico reconocible que ayude a medir el impacto de las
decisiones sobre el sistema en conjunto, no solo la optimización local (MARCO). Debe permitir deducir las acciones
derivadas que optimicen el sistema (SISTEMA). Debe retroalimentar el mecanismo que permita introducir mejoras
a buen ritmo, sin que interfieran con el trabajo ni con el desarrollo personal de los empleados (NEGOCIOS). Estos
atributos deseables constituyen los criterios bajo los cuales evaluaremos las alternativas de solución. El orden de
su importancia relativa se muestra en la siguiente tabla:
atributos
peso
NEGOCIO
5
DETALLE
4
SISTEMA
3
MARCO
2
suma
Tabla 2.1: Selección del Método de Mejora de Procesos
Alternativas de Solución: La literatura tiene muchos ejemplos de estos métodos. Los siguientes fueron
incluidos en nuestro conjunto de soluciones: Plan-Do-Check-Act [SHEWHART, 1939], IDEAL [McFEELEY, 1996],
Focus-Improve-Sustain-Honor [ARTHUR, 2004], y Lean Simplified [ARTHUR, 2006].
Método de Evaluación: Utilizaremos una matriz de Pugh [PUGH, 1991] para evaluar alternativas cuando los
atributos son múltiples. Usado por Pugh en General Motors y descripto por él en su libro ya citado y previamente
en un artículo [PUGH, 1981], es uno de los métodos de análisis de alternativas más difundidos entre ingenieros.
Cada columna representa una solución y cada fila un atributo. Cada fila tiene un peso específico que representa el
valor relativo de ese atributo frente a los otros. En cada intersección fila/columna se evalúa el aporte que la
solución de esa columna hace al criterio de esa fila. Previamente se ha establecido un mecanismo de evaluación
que permite ajustar la objetividad al respecto de la medición de cada atributo.
5
La referencia a un negocio está entre comillas porque se trata de los motivos de existencia de la organización. Si esa
organización es un hospital público que mide su impacto en la comunidad en la cantidad de curaciones que realiza o el
estado general de salud de la población que atiende, entonces a esos efectos ese es su ‘negocio’. No se debe entender
como que solo aplica a organizaciones con fines de lucro.
Capítulo 2
13](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-13-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
Criterios de Evaluación por Atributo: DETALLE es medible como 3 (detalle adecuado), 2 (detalle un poco
excesivo o no suficiente), 1 (detalle bastante excesivo, algo así como treinta páginas para entenderlo, o muy
superficial, algo que permite muchas interpretaciones) o 0 (no tiene ninguna explicación clara asociada). MARCO
se mide como 3 (se reconoce en el sistema qué otras cosas hay que atender), 2 (no se analiza el sistema de manera
total, pero es bastante comprehensivo), 1 (hay algunas pistas para analizar acciones derivadas) o 0 (no se apoya
para nada al cambio sistémico. SISTEMA se mide como 3 (las acciones derivadas que impactan al sistemas se
reconocen mediante el método), 2 (hay una visión periférica pero el foco de las acciones es idéntico al foco de la
mejora), 1 (se evalúan resultados globales a nivel sistema aunque no se los prevea en el análisis de impacto), o 0
(ninguna actividad relacionada con el efecto global forma parte del método). NEGOCIOS se mide como 3 (cuando
se enfoca sobre todo en las necesidades del cliente como punto de partida), 2 (hay un alineamiento con el negocio
pero es externo al método), 1 (se puede alinear al negocio pero el método es agnóstico y no lo menciona) o 0 (no
hay ninguna relación evidente entre el método y el negocio).
Describiremos ahora las cuatro opciones, tratando de que el lector mismo pueda juzgar la calificación de cada
una con respecto a cada atributo.
2.2 Plan-Do-Check-Act
Plan-Do-Check-Act (PDCA) es original de [SHEWHART, 1939], y difundido sobre todo por Deming en varias
6
ocasiones . Deming se refería a este procedimiento basado en el método científico como el ‘Ciclo de Shewhart’. La
posteridad lo recuerda a menudo como el ‘Ciclo de Deming’, una de las consecuencias de la notoriedad de este
que es todavía mayor que la de aquél. Hacia el final de su vida Deming cambió el “Check” (validar) por “Study”
(estudiar) para enfatizar que el paso debe ser de análisis más que de inspección.
Puede justificadamente considerarse a Shewhart como el padre de la calidad industrial. Fue él quien
introdujo los diagramas de control estadístico para el análisis de la estabilidad de un proceso a través de la
medición de un atributo. Dada su fecha de origen, es difícil encontrar el material original, pero en la mayoría de las
7
citas el primer paso es identificar el problema y luego analizarlo. No hay una mención explícita de los objetivos de
negocios, aunque es difícil imaginar que Shewhart los haya eludido, leyendo sus otros materiales. Posiblemente se
ha sacado (una vez más) del contexto al método y al hacerlo se perdió parte de su valor sistémico. Por lo tanto, sin
juzgar al método en sí pero si juzgando su uso habitual, podemos decir que PDCA es sencillo, fácil de aplicar pero
es factible de ser usado sin tener en cuenta el impacto en el negocio. Hay en varias versiones del método
referencias a un proceso desarrollado por Deming para la mejora continua, lo que daría una mejor versión
sistémica del mismo, así como un posible vínculo con los objetivos de negocios. A continuación describimos los
pasos de PDCA.
PLAN (Planificar) Paso 1: Identificar el Problema. Actividades: Seleccionar el problema a ser analizado; definir
claramente el problema y redactar un enunciado preciso del mismo; fijar un objetivo medible para el esfuerzo de
resolución del problema; establecer un proceso para la coordinación con, y conseguir la aprobación de, la alta
dirección.
PLAN (Planificar) Paso 2: Analizar el Problema. Actividades: Identificar los procesos que impactan en el
problema y elegir uno; listar los pasos del proceso tal como se ejecutan en este momento; construir un mapa del
proceso; validar el mapa del proceso; identificar posibles causas del problema; juntar y analizar datos relacionados
con el problema; verificar o revisar el enunciado original del problema; identificar las causas raíces del problema;
juntar datos adicionales si es necesario para verificar las causas raíces
DO (Hacer) Paso 3: Desarrollar Soluciones. Actividades: Establecer criterios para elegir una solución; generar
soluciones potenciales que ataquen las causas raíces del problema; elegir una solución; conseguir aprobación y
soporte para la solución escogida; planificar la solución.
DO (Hacer) Paso 4: Implementar la Solución. Actividades: Implementar la solución escogida en un piloto o
ensayo. Si el proceso PDCA está siendo utilizado dentro del Proceso de Mejora Continua, pasar al Paso 6 de ese
proceso. Si se lo está utilizando por separado, continuar con el Paso 5.
CHECK (Verificar) Paso 5: Evaluar los Resultados. Actividades: Juntar datos de la solución; analizar los datos.
¿Se alcanzó el objetivo buscado? Si es así, pasar al Paso 6. Si no es así, volver al Paso 1.
6
7
El libro [SHEWHART W., 1939] fue compilado por Deming con un prefacio de su autoría.
Véase por ejemplo http://quality.enr.state.nc.us/tools/pdca.htm
14
Capítulo 2](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-14-320.jpg)
![Boria et al.
ACT (Actuar) Paso 6: Estandarizar la Solución (y Capitalizar Nuevas Oportunidades). Actividades: Identificar
cambios sistémicos y necesidades de entrenamiento necesarias para un implementación completa; adoptar la
solución; planificar y monitorear permanentemente la solución; continuar buscando oportunidades incrementales
para refinar la solución; buscar nuevas oportunidades de mejora.
El método PDCA es sólido, pero su edad ha hecho que varios de los detalles que su autor predicaba hayan
sido dejados de lado en su implementación corriente, que es lo que un buen evaluador juzga: Su uso por encima
de su definición. Eso no quita que para el lector avisado los pasos de PDCA no sigan teniendo utilidad. De hecho,
como veremos en lo que sigue, el ciclo de Shewhart sigue siendo utilizado en diferentes variantes. Tampoco es
frecuente que los usuarios de PDCA lo coloquen en el marco adecuado, simplemente es utilizado como un ciclo
cuya repetición produce los resultados esperados. Recordemos que para Shewhart, y en consecuencia para
Deming, hay un proceso de mejora continua en el que PDCA encaja. De otra manera se pierde parte de su impacto.
Es en ese proceso marco que varias de las iniciativas sistémicas y el vínculo con los objetivos de negocios están
inmersos, de modo que cambiar ese proceso como fuera definido y colocar otro en su lugar puede tener como
consecuencia la pérdida de ese entorno y en consecuencia la desmejora del proceso de mejora. Veamos ahora
como McFeeley lidia con ese problema, incorporando a su método el detalle necesario (en exceso, según nuestro
punto de vista).
2.3 El Método IDEAL
Debido a la enorme influencia que Deming, y en consecuencia Shewhart, a quién aquél citaba
constantemente, tienen sobre la comunidad de mejora de procesos, este método y los que describiremos más
tarde están fuertemente influenciados por PDCA. La Figura 2.1 muestra una descripción gráfica del método IDEAL.
Tiene cinco fases que se corresponden con etapas importantes de una iniciativa de mejora de procesos. Puesto
que la mejora es continua, se espera que se continúe el ciclo una vez alcanzada la 5ª fase. Si bien el autor de IDEAL
[McFEELEY, 1996] aclara que los límites entre fases son más borrosos que los que se describe en la referencia, es
usual que las recomendaciones de éste no se sigan y se ejecute como una secuencia de actividades en un proyecto,
así como otras desviaciones de alto impacto.
Figura 2.1: El Método IDEAL [McFEELEY, 1996]
La primera fase se denomina, con lógica, ‘Initiating,’ que traducido quiere decir Comenzando. Tiene tres
bloques, pero en la descripción detallada no se las considera, siendo descriptas en cambio 10 tareas que se
detallan, algunas hasta el nivel de subtareas. La misma situación de desacople entre la gráfica y la descripción
textual se repite para todas las fases. La fase ‘Initiating’ culmina cuando la infraestructura para la mejora de
procesos se ha construido, se han vinculado los objetivos de negocios al programa de mejoras de proceso, hay un
sistema de recompensas alineado con las mejoras y un plan inicial para el proyecto de mejoras, que contiene el
plan de comunicación de los avances.
La fase que sigue se denomina ‘Diagnosing’ y tiene seis tareas. Se traduce fácilmente, dada la similitud de los
vocablos, por Diagnosticando. En efecto, es la fase en la que se realiza el análisis de la brecha existente entre las
Capítulo 2
15](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-15-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
necesidades de proceso y los procesos en uso, tal como se usan. El criterio de entrada de la fase no coincide
totalmente con el criterio de salida de la primera fase, por lo que es difícil entender como se consigue llegar a su
ejecución. La fase tiene como criterio de finalización que se hayan entregado las brechas halladas y las
recomendaciones al comité de gestión y hayan sido aceptado, así como que ya haya un boceto del plan estratégico
de acción.
La tercera fase de IDEAL se denomina ‘Establishing’, que quiere decir Estableciendo, pero se refiere acá al
plan y no a los procesos. Si bien es confuso, da una linda sigla (IDEAL) que un nombre más lógico (Planificar, o
Detallar) no conformaría. En esta fase se ajustan prioridades y se forman los equipos que llevarán adelante la
definición y difusión de los cambios y mejoras a los procesos. Notablemente, el método recomienda que la
planificación la realice el comité de gestión, es decir los gerentes que realizan la supervisión estratégica del plan de
mejoras, y no el grupo de procesos. Este excelente consejo es ignorado en la práctica. La fase tiene 14 actividades.
El criterio de finalización es que el plan estratégico se haya completado y aprobado, y que la visión organizacional,
el plan de negocios y el plan estratégico de mejora de procesos tengan sinergia entre sí.
La fase que sigue se denomina ‘Acting,’ que se traduce por Actuando. Esta fase es la más interesante, aunque
el modelo tiene muchas componentes útiles, porque ésta enfoca muy directamente en el negocio. Es cuando las
mejoras se identifican, construyen, despliegan y se ponen práctica. Tiene diez pasos, de los cuales destacaremos
una subtarea del paso 2, Desarrollar Soluciones: Analizar y Arreglar el Problema. Nos interesa porque en muchas
formas anticipa y se parece a Lean, en que el planteamiento es puramente enfocado en el dolor y no en la mejora
de procesos en sí. Se modifican procesos porque los procesos actuales toleran defectos y demoras que no se
deben tolerar, se ataca sus causas, pero se enfoca en los síntomas. Esta fase tiene como criterio de éxito que la
estrategia de despliegue y el plan se han ejecutado plenamente, o están en camino de serlo. Las soluciones que se
han adoptado (o piloteado) se han documentado correctamente y están bajo control del grupo de procesos, y se
tiene claro cómo se las va a mantener. La mejora de procesos ha comenzado a estar institucionalizada en la
organización. Esta fase hace referencia a muchas pequeñas mejoras realizadas en paralelo, bajo un único plan
estratégico y múltiples planes tácticos. Sin embargo, la gran mayoría de las implementaciones de IDEAL adolecen
del mismo defecto: Un enorme plan táctico que nunca termina de ejecutarse y que sufre del síndrome del correo:
las cartas (pedidos de nuevos cambios) siguen llegando y la tarea de planificar nunca se concluye.
La fase final, o si se quiere la que inicia una nueva iteración del ciclo IDEAL, se denomina ‘Leveraging’, que
significa Aprovechando, o Sacando Provecho, en realidad es la variante de la primera fase, puesto que tendría poco
sentido empezar de nuevo sin tener en cuenta lo que ya se avanzó. Se denomina así porque ante la alta gerencia
se afirma el auspicio mediante la muestra del avance. Cuando las organizaciones caen en los errores que
marcamos antes, el resultado es que el proyecto de mejoras tiene poco que mostrar. El ejemplo más común es que
se definen soluciones pero no se las implementa ni en pilotos, lo que se justifica por el síndrome del correo: ya que
se han aceptado nuevos pedidos de cambio, el grupo de mejoras se enfocará en la definición de soluciones y no en
su implementación. Como consecuencia una larga lista de cambios es lanzada simultáneamente sin suficiente
preparación, por la demanda de capacitación que eso conlleva, y el proyecto fracasa. IDEAL no es un mal método,
pero es muy detallado (se describe en un documento de 236 páginas) lo que hace que mucha gente lo haya
8
implementado sin haber leído esos detalles con la consiguiente pérdida de varios elementos fundamentales,
9
como el vínculo con los objetivos de negocios, el paralelismo en la implementación y la visión sistémica
(multicausal, con lazos de retroalimentación y demoras entre causa y efecto visible) que son indispensables para
establecer un programa de mejora continua.
Lo mejor de IDEAL es su visión de la mejora de procesos (Figura 2.2) basada en los objetivos de la
organización y soportada en la visibilidad del proyecto, la comunicación horizontal y vertical entre las partes, la
captura, retención y aprovechamiento de la experiencia (lecciones aprendidas), y una red de soporte de todo el
proyecto. De ese modo se sostiene el plan táctico y el estratégico para culminarlos con éxito.
8
9
Si el lector no se siente cómodo con la afirmación de que un número muy grande de personas no lee los detalles antes de
implementar un modelo, los autores querrían remitirlo al trabajo de Royce, Managing the Development of Large
Software Systems [ROYCE, W., 1970], a quién se considera el padre del ciclo de vida en cascada por ese mismo artículo, y
que lamentablemente está mal citado: Lo que Royce dice en ese trabajo es que esa visión del proceso de desarrollo es
infantil y llena de problemas.
Los usuarios de IDEAL tienden a desarrollar un proyecto secuencial con muchas iniciativas que demoran la fase de aplicación,
una de las maneras de resistir el cambio.
16
Capítulo 2](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-16-320.jpg)
![Boria et al.
Figura 2.2: Visión de Mejora de Procesos de IDEAL [McFEELEY, 1996]
2.4 Focus-Improve-Sustain-Honor
Focus-Improve-Sustain-Honor (FISH) de [ARTHUR, 2004] es una variante más de PDCA, con énfasis en las
10.
herramientas de Six-Sigma El ciclo de Arthur se basa en la medición. El uso de los datos disponibles y la
búsqueda tipo “inteligencia de negocios” es el fundamento del análisis, en vez de los defectos o la brecha respecto
de algún ideal. Esto por supuesto no está contra los preceptos de PDCA, pero si influye mucho en el impacto que
tiene cada uno, porque en FISH es indispensable comenzar por el análisis de los datos antes de entrar en el ciclo.
El ciclo tiene cuatro fases, Focus, enfocar, la primera, está basado en un hecho estadísticamente demostrable
por la distribución de los defectos: Unos pocos procesos son responsables de la mayoría de los mismos. Encontrar
esas “fábricas de defectos” enfoca el proceso de mejora en donde más rendimiento tiene. Para Arthur, la
11
aplicación de la ley de Pareto predice grandes ganancias. Su razonamiento es que si el 80% de los defectos son
producidos por el 20% de los procesos, volviendo a aplicar la regla se tiene que el 64% (80% del 80%) de los
defectos proviene del 4% (20% del 20%) de los procesos. De ese modo un minúsculo grupo de procesos permite
eliminar un número sumamente grande de defectos, de donde enfocar es necesario.
La segunda fase, Improve, mejorar, es donde el defecto encontrado se elimina. Esta es la fase donde se
identifican las causas profundas, se eligen las soluciones posibles y se define y lleva adelante su implementación. El
MPS (ver el Capítulo 4) contiene resultados esperados de procesos que ayudan a entender la implementación de
los pasos de mejora por identificación de las causas raíces. Utilizaremos a lo largo del libro esta capacidad de
12
identificar las causas de las cosas para poder mejorarlas o difundirlas . Utilizar el análisis de causa raíz de forma
sistemática es una de las herramientas más poderosas de la mejora de proceso, y una de las tres herramientas
intelectuales (junto con el análisis y gestión de riesgos y la visión sistémica del proceso) que más rendimiento
tienen en los procesos intelectuales que acompañan, o deben acompañar, a la mejora de procesos.
La tercera fase, Sustain, sostener, es donde la mejora se intenta consolidar y mantener, para lo cual Arthur
propone utilizar herramientas de “conocimiento profundo” como fueran introducidas por Shewhart y difundidas
por Deming. Para comenzar, Arthur indica desarrollar el mapa del proceso, utilizando siempre herramientas
10
11
12
Six Sigma es una estrategia de gestión originada en Motorola en 1986 SPC and TQM in Manufacturing and Services
[TENNANT, G., 2001] y usada mundialmente. Trata de mejorar la calidad de los resultados de los procesos identificando y
eliminando las causas de los defectos. Utiliza una variedad de métodos, fundamentalmente estadísticos. El término surgió
del análisis estadístico de la ocurrencia de defectos en manufactura. La madurez de un proceso de fabricación puede
expresarse como la cantidad de desvíos estándar () que se aleja de la media de la población total, o por el porcentaje de
piezas sin defectos que produce. Un proceso seis es uno que produce 99.99966% de las piezas sin defectos, que fue el
objetivo fijado por Motorola y que dio nombre a los métodos que se conjuntaron en un proceso para alcanzarlo.
Pareto fue un estadígrafo francés del siglo XX que se destacó en el estudio de la distribución de la renta. En 1906 él hizo la
famosa observación de que el veinte por ciento de la población poseía el ochenta por ciento de la propiedad en Italia,
posteriormente generalizada por Joseph M. Juran en el principio de Pareto (también conocida como la regla del 80-20).
Si el evento es un problema o un defecto, intentaremos ubicar su origen para desterrarlo, pero si el evento es un resultado
positivo no planificado, intentaremos entender qué lo provocó para reproducirlo en otros ambientes.
Capítulo 2
17](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-17-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
simples. En todos los casos, Arthur se inclina por la simplicidad, dedicándole tiempo al proceso intelectual y
utilizando la herramienta que mejor se adapta al menor costo de aprendizaje posible. Por ejemplo, en este caso
13
sugiere utilizar un diagrama de flujo, siendo que hay otras herramientas posibles que son más poderosas e
igualmente difundidas.
Para poder afirmar que los resultados se han alcanzado es necesario saber que el proceso está normalizado,
porque si no es así es imposible establecer comparaciones. Supongamos que el problema es que una receta
culinaria viene dando resultados desparejos. Al analizar la causa profunda nos damos cuenta que diferentes
cocineros le dan diferente interpretación a las instrucciones y que algunos pasos están faltando, porque el autor de
la receta asumió que los que la intentarían ejecutar tenían conocimientos culinarios en grado suficiente, lo que no
resultó una predicción verdadera. Además, hay un error en la receta que sugiere usar un tipo de harina que no es
el correcto, digamos que dice “harina” a secas, que en el contexto de los cocineros que tienen problemas con la
receta se entiende por “harina de trigo,” cuando el que diseñó la receta quería que fuera “harina de maíz”. El
análisis de causa ha detectado estos defectos y se ha sugerido que se hagan cambios a la receta, definiendo con
precisión los pasos para que no haya diferentes interpretaciones, y corrigiendo los errores y ambigüedades.
Un grupo de procesos sin la suficiente experiencia consideraría que ha cumplido su cometido: El proceso, de
ejecutarse correctamente, “debería” funcionar. Jay Arthur (y los autores) no se conforman con esa definición,
incompleta, de la responsabilidad del grupo de proceso: ¿Y si no funciona? Lamentablemente la resultante en esos
casos es que el grupo de procesos le arroja la responsabilidad a los que debiendo ejecutar correctamente el
proceso no lo hacen, sin constatar que, necesariamente, son ellos y no los cambios los que llevan a perpetuar el
problema o introducir otros nuevos.
Por lo tanto, ‘sostener’ implica medir y analizar los resultados. Esto lleva a tener que entender cuándo, dónde
y qué medir. Uno de los pasos más importantes en la definición de procesos y el cambio para la mejora es
identificar los procesos clave y los atributos a medir. Esta capacidad es exigida por el MPS en los niveles más altos
de madurez, a partir del Nivel B, pero es una de las cualidades más valiosas de un gerente. Por ejemplo, si nos
preocupa que la mayoría de los proyectos termina después de su fecha de entrega y hemos hecho cambios en
consecuencia para adelantar la producción de resultados, medir las demoras que se producen en aquellos puntos
es de suma importancia. Medir solo el resultado final, el desvío en la fecha de entrega, es solo parcialmente útil
porque una vez que hemos entregado tarde no se puede modificar el resultado. Arthur introduce acá herramientas
de 6 que el MPS no requiere sino hasta el Nivel B, como ya hemos dicho, y por lo tanto complica un poco más de
lo necesario el análisis de resultados.
La última fase del ciclo es Honor, honrar. Arthur se refiere acá a la necesidad de respetar y premiar los
compromisos con el cambio, con la mejora (no todo cambio es una mejora, pero toda mejora es un cambio). Gran
parte del mensaje sobre la mejora de procesos está contenido en la manera que la organización resalta y
recompensa los esfuerzos de su personal en relación a los cambios y las mejoras. Es importante destacar que no
todos los intentos de mejora, sobre todo en las etapas tempranas del proceso de mejora continua, han de resultar
igualmente exitosos. Algunos serán hasta negativos, pero es indispensable rescatarlos como esfuerzos válidos
porque la organización aprende.
2.5 Lean Simplified
El último método es Lean Simplified [ARTHUR, 2006]. Jay Arthur desarrolló ese método como una extensión
de su anterior FISH que vimos más arriba con el propósito de hacer más clara la aplicación del mismo, enfatizando
la cadena de valor que lleva desde el pedido del cliente a su satisfacción por la entrega del producto. La palabra
inglesa Lean significa delgado, sin peso demás. Arthur elige llamarlo Simplified, simplificado, porque ha reducido la
demanda estadística que su método FISH tiene. Llamaremos a este método LS, para evitar usar términos en inglés.
LS, como lo explica Jay Arthur en [ARTHUR, 2006] es un método para la empresa manufacturera. Sin
embargo, modificando o dejando de lado lo que no aplica para el desarrollo de software, es un método poderoso
para identificar y resolver problemas con vista a la mejora continua. Presentamos acá nuestra versión de LS
adaptada a la producción de software.
13
18
Los diagramas SADT, o IDEF0 en su versión norma internacional, son más detallados y de uso difundido. También los
diagramas de flujo con andariveles que permiten discernir responsabilidades. Asimismo sería posible diseñar el proceso
siguiendo técnicas de flujo de datos del Análisis Estructurado o con herramientas de UML.
Capítulo 2](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-18-320.jpg)
![Boria et al.
14
En el corazón de LS está el tema de la velocidad de producción . La velocidad no es apuro, es hacerlo mejor y
sin interrupciones, no es trabajar los fines de semana o hasta altas horas de la noche. La velocidad es
productividad puesta al servicio del producto. En un mundo conectado globalmente por la Internet los clientes
esperan servicios casi inmediatos sin pérdida de calidad ni aumento de los precios. El libro de [RODIN, 2010] es una
visión de cómo la demanda por servicios gratuitos entregados en el momento y sin costo alguno está
revolucionando los negocios. Para las organizaciones que fabrican software el desafío está lanzado: Hay que
eliminar los defectos y todas las demoras para entregar más que a tiempo y con bajos costos.
Las demoras no son justificables. El producto de software puede ser único e irrepetible, pero los procesos por
los cuáles se lo produce no lo son. Cada proyecto se compone de las mismas fases, que realizan las mismas
actividades. La resistencia a ese concepto es notable en empresas de baja madurez, y sin embargo vemos una y
otra vez que la resistencia a hacer las cosas de otra manera es tan arraigada como la necesidad de sostener que
siempre son diferentes. Lo único que se demora en cambiar es la creencia de que la organización está justificada
en actuar como lo hace.
En cada empresa hay dos fábricas, la principal que diseña, vende, factura y entrega el producto, cuya fórmula
es Velocidad con Calidad + Ganancias = Beneficio. La segunda es la fábrica de arreglos, que corrige todos los
errores que se van cometiendo a medida que se diseña, vende y factura el producto. Hay siempre una fábrica de
arreglos visible que se mide y se controla, pero hay otra que es oculta que hace que los errores se corrijan sin que
haya atribución ni contabilización. Esa fábrica tiene otra fórmula: Defectos + Demoras = Pérdidas.
En el fondo, LS se centra en la velocidad de producción. La relación entre las etapas de un proceso es
fundamental. Las etapas y actividades que no agregan valor deben ser eliminadas del proceso. Por eso la primera
actividad en LS es hacer un mapa de la “cadena de valor”, la secuencia de actividades que van desde la recepción
15
del pedido del cliente a la satisfacción de sus necesidades . Una vez más, el mapa tiene que ser sencillo, pero no
tanto que resulte fácil de malinterpretar. Además, puesto que se trata de un sistema de tracción donde la salida
fuerza al proceso anterior y así sucesivamente, este método atiende principalmente la voz del cliente. Hecho
correctamente, esto genera valor para el cliente y en consecuencia, la organización.
Foco en los Defectos
Al intentar reducir la “fricción” que demora los procesos, Toyota descubrió que hay muchas formas de
desperdicio (“muda”).
1.
2.
3.
4.
5.
6.
7.
Exceso de producción (en software, incluir código que no fue solicitado “por si lo vamos a necesitar”)
Inventario excesivo (en software, los procesos que se generan alrededor de la funcionalidad no
requerida, como testeo extra, volumen de manuales, etc.)
Esperas (en software se manifiesta en particular cuando hay que esperar por otro rol a que el personal
esté disponible, o las instalaciones, o cuando el cliente tiene que dar respuesta)
Movimientos innecesarios del producto (en software la ubicuidad de los productos en formato
electrónico hace de esto un problema inexistente, pero si se mantienen planos en papel o en
pizarrones puede llegar a ocurrir)
Movimientos innecesarios del personal (típicamente en la instalación o en la validación, a menudo en la
etapa de generar requisitos)
Procesamiento innecesario o inadecuado (no es muy común, pero en ciertas organizaciones
burocráticas hay ocurrencias de esto)
Defectos que obligan a reparaciones y retrabajo (no hay porqué explicar esto en nuestra profesión)
Si la organización trabaja con plazos cortos y se concentra em mantener la flexibilidad se obtienen beneficios
en calidad y satisfacción del cliente. En el capítulo 3 veremos cómo un grupo de desarrolladores de software
14
15
La empresa Toyota inventó el método de "producción esbelta" (lean production) tomando como referencia los
supermercados de los EEUU, donde percibieron que cuando los anaqueles de los supermercados alcanzan el punto mínimo
del inventario son reabastecidas tan rápidamente como los clientes "quitan" los productos de la góndola. En un sistema de
tracción, el proceso anterior debe siempre hacer lo que el proceso subsecuente le pide. Para ver que el stock está bajo y,
como consecuencia, reponerlo, se coloca una tarjeta que señala el punto exacto. El nombre en japonés de esa tarjeta es
Kanban, palabra que hoy identifica tanto a la tarjeta como al sistema.
No es lo mismo oír y reaccionar que escuchar y satisfacer.
Capítulo 2
19](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-19-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
CAPÍTULO 3 - LOS MÉTODOS ÁGILES: KANBAN, SCRUM, XP Y FDD
3.1 ¿Qué son los métodos ágiles?
En el capítulo anterior presentamos la mejora continua de procesos y decidimos tomar como referente a LS.
Las ventajas de un método liviano, desprovisto de burocracia, que enfoca directamente en las necesidades de
negocio no pasaron desapercibidas para los “metodólogos” de Ingeniería de Software. Ya en el siglo pasado habían
nacido varios métodos de desarrollo que se apoyaban en las ideas de producción de Toyota, notablemente
Extreme Programming [BECK, 2000], Scrum [SCHWABER, 2002], DSDM [STAPLETON, 1997], Adaptive Software
Development [HIGHSMITH, 1999], Crystal [COCKBURN, 2005], Feature-Driven Development [COAD, 1999],
Pragmatic Programming [HUNT, 1999] y otros más. En un intento de encontrar formas comunes se reunieron
diecisiete de estos creadores en Febrero del 2001 en un centro de esquí en Utah. Lo que surgió fue un manifiesto
18
que marcó la ingeniería de software de modo único, el Agile Software Development Manifesto .
El contenido del manifiesto se puede leer en línea, pero consideramos que su influencia es tan importante, y
sus coincidencias con el método de Toyota TPS son tantas que lo incluimos acá.
Manifiesto para el Desarrollo de Software Ágil
Estamos descubriendo mejores métodos para desarrollar software ejercitándolos y ayudando a
otros a usarlos. A través de este devenir apreciamos:
Los individuos y las interacciones
por sobre los procesos y las herramientas
Software que funciona
por sobre una documentación completa
Colaboración con el cliente
por sobre la negociación del contrato
Responder a cambios
por sobre seguir un plan
Es decir, aunque hay valor en los ítems de la derecha, valoramos los ítems de la izquierda aun
más.
(firman) Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.
Aunque el manifiesto describe las ideas más básicas, hay entre los autores más acuerdos que los allí
expuestos. Muchas de las coincidencias provienen de la misma fuente: El foco en la calidad, con las reglas de
Toyota que mencionáramos ya en el capítulo anterior en la sección “Foco en los Defectos”. Así como Toyota tiene
su método TPS que es una forma de “Kaizen”, los métodos ágiles se apoyan en períodos de producción cortos y
mucha colaboración dentro del equipo de proyecto, apoyado en la sinergia que genera el trabajo en equipo de la
estructura formada para alcanzar las metas establecidas por la dirección de la compañía. En gran parte, su
popularidad entre el personal de desarrollo se deriva de la independencia que los equipos sienten al tomar sus
decisiones en conjunto y en alto grado libres de las redes burocráticas que se tejen en las grandes empresas, lo
que trae consigo resultados concretos, tanto cualitativos como cuantitativos.
Al dejar que el equipo de trabajo tome las decisiones para el próximo período de trabajo, llamado en la jerga
19
20
de los agilistas un “Sprint” , los métodos ágiles consiguen motivar al personal de los proyectos y
comprometerlos con el resultado al permitirles tomar decisiones de peso. Dada la corta duración de un Sprint,
usualmente nunca más de cuatro semanas, los equipos pueden ver sus resultados de inmediato. También es
importante la participación del cliente. Junto con un representante del cliente que esté comprometido a su vez con
18
19
http://agilemanifesto.org/
Usaremos este neologismo para designar a aquellos que adhieren a los métodos ágiles y los practican.
20
22
Los diccionarios definen ‘Sprint’ como la mayor velocidad alcanzada por un corredor en una carrera, especialmente en el
final. Las carreras de hasta 200 metros se consideran todas Sprints, de principio a fin. Por analogía, cada tramo de un
proyecto ágil se considera un Sprint.
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-22-320.jpg)
![Boria et al.
el resultado, se define el alcance de cada Sprint. Es un deber de los equipos ágiles definir una parte del producto
que en sí misma tenga valor para la organización del cliente. De ese modo el producto parcial es concreto y
mantiene la concentración y el foco en el negocio.
Los métodos ágiles nacieron como respuesta a las burocracias que ignoran las particularidades del desarrollo
de software y en su ignorancia presionan a los equipos a llevar adelante proyectos con compromisos irracionales
realizados por los que no saben. Al poner metas cortas y priorizar la participación del cliente en las decisiones de
negocio, además de poner un freno concreto a los cambios caprichosos, los métodos ágiles rescatan el valor de la
ingeniería de software ante los embates burocráticos de ciertos niveles en las corporaciones. Entre otras virtudes,
la decisión por el equipo es visible para todos, DEBE ser visible para todos. En consecuencia la transparencia de los
proyectos ágiles es uno de sus atributos más valiosos y más revolucionarios.
Los agilistas se consideran un movimiento pro-métodos. Los que creen que la agilidad es contraria a los
procesos y las herramientas, a la documentación o los planes se equivocan. Lo que buscan es que estas entidades
estén al servicio de las actividades del equipo y no a la inversa. Si el lector cree que ser ágil es no planificar, no
seguir procesos por ligeros que estos sean, no tener más herramientas que el ambiente de desarrollo interactivo y
un par de lenguajes, no documentar las decisiones, se equivoca de plano. El que así piensa es un hacker, no un
agilista. Los agilistas piensan que la planificación de detalle no puede llevar más que unas pocas horas y debe
involucrar al equipo, que los procesos son flexibles pero deben de ser acordados por los que los llevan a la práctica,
que la documentación debe ser fácil de mantener y responder a una necesidad orgánica del proyecto y debe ser
hecha cuando esa necesidad se manifiesta y no como una condición contractual después de que el producto se
haya concluido. En cuanto a herramientas, baste recordar que la integración continua, uno de los baluartes de los
métodos ágiles, requiere excelentes herramientas de gestión de configuración con testeo integrado por lo tanto es
claro que los agilistas trabajan en pro de la eficiencia y no en contra de la misma.
21,22
Los cuatro métodos ágiles que encontramos más útiles en diferentes etapas de una empresa son Kanban
,
23
24
25
Scrum , XP y FDD . El orden en que los describiremos va del más sencillo (Kanban) al más complejo (FDD).
Scrum y XP se apoyan en Kanban y en particular describiremos XP en su versión XBREED, que mezcla los conceptos
de XP con las prácticas de Scrum para obtener un proceso más sólido y confiable.
3.2 Kanban: Midiendo el flujo
Quién introdujera Kanban como método ágil fue [ANDERSON, 2011]. El método Kanban es parte de una
familia de sistemas que se denominan “pull”, o de arranque, contra el enfoque tradicional de sistemas “push” o de
empuje. Otra manera de ver la diferencia entre unos y otros sistemas es que el sistema de arranque es guiado por
la demanda mientras que el sistema de empuje es guiado por la producción. En un sistema “pull” el proceso espera
que haya demanda de su producto para producirlo, tratando de que se llegue justo a tiempo con el mismo, de
26
manera de que no haya inventario . El inventario es característico de los sistemas “push” puesto que es el
amortiguador que permite el desacoplamiento entre procesos consecutivos. El problema es que el inventario
consume mucho capital y tiene un alto costo, siendo que además no se sabe si el producto final tiene comprador o
no. De ese modo se desperdicia trabajo y materiales.
El método Kanban permite alcanzar un ritmo de producción sostenible e introducir cambios a los procesos
con muy baja resistencia. Es por eso que lo usamos de preferencia con aquellas organizaciones de muy baja
27
madurez institucional. Como vimos, el método Kanban es uno de los mecanismos que subyace el TPS pero la
adaptación para ingeniería de software es del 2004 y fue realizada por Anderson en Microsoft. Anderson lo
presentó en la conferencia Agile 2007 de Washington y comenzó el entusiasmo por el método, puesto que los
resultados eran muy alentadores.
21
22
23
24
25
26
27
KNIBERG, H. e SKARIN, M., 2010
Cuando usamos Kanban con mayúsculas nos referimos al método Kanban desarrollado por Anderson, cuando se lo usa en
minúsculas, kanban, hace referencia a cualquier otro uso, como el sistema kanban de Toyota o el tablero kanban que
veremos más adelante.
KNIBERG, H., 2007
KNIBERG, H., 2007
PALMER, S. R. e FELSING, J. M., 2002
Esto también es conocido como sistema “Just in Time”, o con las siglas JIT.
Toyota Production System.
Capítulo 3
23](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-23-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
El método es en sí muy simple, pero al usarlo de determinada manera trae consigo múltiples ventajas que
señalaremos al explicarlo. Si bien el texto [ANDERSON, 2011] es la base que permite entenderlo profundamente,
para el lector que aspira a un manejo más pragmático aconsejamos [KNIBERG & SKARIN, 2010] que se remite a lo
esencial de la implementación, sin por ello dejar de lado lo anecdótico que permite la comprensión, o como se dice
en México, el “aterrizaje” del material.
Un elemento central en el método es el uso del tablero kanban. No se debe confundir el uso del tablero con
la aplicación del método; es posible usar el tablero sin seguirlo, como de hecho se hace en muchas adaptaciones
de Scrum y XP, porque el tablero es un excelente medio para comunicar el progreso de un proyecto.
El tablero kanban es simplemente un registro del avance del proyecto materializado según le convenga al
28
equipo. Lo más frecuente es usar un tablero donde se puedan pegar notas autoadhesivas que llamaremos pósit ,
como en la Figura 3.1, dividido en columnas verticales. Cada columna indica un estado de las tareas. Las pósit
contienen los nombres de las tareas. La primera columna de la izquierda típicamente contiene lo “pendiente”, es
decir la lista de las tareas a realizar que aún no se han comenzado. Cuando un miembro del equipo tiene
disponibilidad para comenzar una tarea, toma de esa columna la tarea que corresponda, ya sea por prioridad
prestablecida o por alguna otra razón que se haya convenido en el equipo, y la corre a la columna siguiente hacia
la derecha. En algunos métodos que usan el tablero kanban el miembro del equipo que hace esto coloca la fecha y
hora del comienzo, su nombre y la fecha estimada de finalización en los rincones del pósit, diseñados para ese uso,
29
como se muestra en la Figura 3.2 . Cuando termina de realizar su tarea, toma el pósit de donde lo colocó y lo
mueve una columna más a la derecha, de donde a su vez lo tomará alguien más para continuar con el proceso
hasta que la tarea alcance el punto donde se acordó se la considerará completa, punto en el cuál alcanza la
columna de la extrema derecha del tablero.
Figura 3.1: Tablero kanban
No hay ningún motivo especial para utilizar tarjetas autoadhesivas o los tableros en sí. Pueden utilizarse
planchas de cartón a las que se pinchan con chinches tarjetas de cartulina, pueden usarse filas horizontales en vez
de columnas o puede utilizarse un tablero virtual de los muchos que se ofrecen por la Internet. El objetivo es el
mismo, dar claridad a las tareas pendientes de resolución y entender tanto el estado actual del proyecto como la
ocupación del personal.
Figura 3.2: Nota pósit del Tablero kanban
28
Pósit es un artículo nuevo en el diccionario de la Real Academia Española, avance de la vigésimatercera edición. Su definición
es (Del ingl. Post-it, marca reg.). 1. m. Hoja pequeña de papel, empleada generalmente para escribir notas, con una franja
autoadhesiva en el reverso, que permite pegarla y despegarla con facilidad.
29
24
En el ejemplo mostrado el rincón superior izquierdo contiene el nombre de la persona responsable, el superior derecho la
fecha y hora de apertura del ítem, el inferior derecho la estimada de finalización y el inferior izquierdo (sin llenar en el
ejemplo) la fecha real de finalización. Cuando se usa esta convención a menudo los pósit se copian y se pegan unos sobre
otros para tener la historia de su desarrollo.
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-24-320.jpg)
![Boria et al.
En el método Kanban se limita el número de tareas en cada columna. El objetivo es identificar claramente la
capacidad del sistema y balancear la demanda contra la capacidad del equipo. El método Kanban permite
comprender el tiempo de tránsito de cada tarea, desde que ingresa al sistema por la izquierda hasta que culmina
en la columna de la derecha. (Hay algo de satisfacción personal para cada miembro del equipo en mover la tarea
hacia la columna “completado” que motiva a usar kanban). Una vez que se han ajustado los parámetros de
producción, el equipo alcanza un ritmo sustentable, es decir, que puede mantenerse indefinidamente,
consiguiendo en efecto predictibilidad que otros métodos tardan mucho en alcanzar.
Puesto que esa regularidad se hace presente muy rápidamente, toda obstrucción a esa regularidad es
rápidamente visible, potenciando al equipo para detectarlos y, en consecuencia, resolverlos. El impacto que tienen
en la regularidad los defectos, las demoras, los cuellos de botella y la mala estimación del tamaño y la complejidad
del producto aparecen muy pronto en el tablero. Es fácil relacionar estos problemas con el costo del proyecto,
dado que al restringir el número de tareas en cada columna las personas tienen que atender los cuellos de botella
para ayudar a resolverlos. De esta manera el método Kanban vincula rápidamente los problemas técnicos del
proyecto a los resultados de negocio, sin tener que establecer complicados mecanismos de análisis. Este es un
resultado que no se anticipaba al introducir el método pero que es uno de los puntales de su adopción.
Una de las ventajas de Kanban es que al producir con calidad y a tiempo se genera confianza en los clientes,
que reciben productos con regularidad y con la calidad esperada. Otra ventaja es que, al hacer que el equipo
mejore constantemente sus procesos para evitar demoras, las entregas se hacen más frecuentes y con mayor
funcionalidad. A su vez, esta situación hace que el equipo se sienta más a gusto y ponga más ahínco en mejorar el
flujo de trabajo.
Para implementar Kanban el primer paso es identificar el flujo de trabajo, lo que se conoce como la “cadena
de valor” que ya viéramos en el Capítulo anterior en las discusiones sobre el método de mejora de procesos a
seguir. Dado el origen común de esos métodos (las diferentes versiones de calidad total) y el hecho de que el
método Kanban es una adaptación al desarrollo de software de una técnica con el mismo nombre (kanban)
derivada del TPS, a su vez del mismo origen que los anteriores, las coincidencias no deben sorprendernos. Kanban
usa cinco principios para crear comportamientos en las organizaciones donde se lo aplica: Visualizar el Flujo de
Trabajo; Limitar el Trabajo en Realización; Medir y Manejar el Flujo; Explicitar Políticas de Proceso; y Utilizar
30
Modelos para Reconocer Oportunidades de Mejoras.
El primer punto saliente en la construcción de un tablero kanban para el flujo de trabajo es que la columna de
la derecha corresponde al estado de tarea completada. Antes de que se pueda proseguir con la implementación
del método es imprescindible que el equipo, junto con el proveedor de información (más adelante llamaremos a
este rol ‘Dueño del Producto’ siguiendo la costumbre introducida por [SCHWABER & BEEDLE, 2002]) defina los
atributos necesarios de una tarea para que se la considere completada. Por ejemplo, la densidad de defectos
remanentes conocidos, o los estados por los que ha debido pasar (inspecciones, pruebas unitarias, etcétera).
La columna de la derecha está así bien identificada y su sentido es claro. La columna de la izquierda es donde
se colocan los pendientes. Entre medio hay tantas columnas como el equipo quiera y que tengan significado para
ellos. Por ejemplo puede que la siguiente columna a la derecha de “Pendientes” sea “En Análisis”, la que le sigue a
esta sea “Analizado”, la siguiente “En Desarrollo”, la siguiente “Listo para Prueba”, la siguiente “Listo para
Integración”, y así sucesivamente. Por otra parte puede que un equipo determine que todo lo que necesitan saber
se contiene en tres columnas: “Pendiente”, “En Desarrollo”, “Listo para Entregar”. Las decisiones que así se toman
tienen repercusiones muy grandes. Por ejemplo, la primera elección sugiere que dentro del equipo hay
especialidades que van pasando la tarea de una a otra. La abren los analistas que la pasan a los desarrolladores
que la pasan a los testers. La segunda sugiere que el equipo trabaja en células integradas donde todos esos roles se
cumplen dentro de la célula. Un caso extremo poco recomendable es el de la célula unipersonal.
Recomendamos la adopción del tablero más complejo con divisiones técnicas del trabajo, por lo menos
mientras no se incorporen técnicas especiales como programación por pares y diseño dirigido por las pruebas. El
motivo es que las diferentes etapas dentro del proceso permiten avizorar mejor estados intermedios, de modo
que los atrasos potenciales y los cuellos de botella puedan ser rápidamente detectados y la duración de las tareas
mejor estimadas. Además, este esquema de trabajo es muy flexible y permite crecer con facilidad hacia otros
30
Los modelos a que hace referencia Anderson son más generales que los que presentaremos en el próximo Capítulo, pero
dada la apertura que sugiere el texto ya citado, los autores no encontramos contradictorio utilizar el MPS para introducir
mejoras de proceso compatibles con Kanban.
Capítulo 3
25](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-25-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
métodos, en particular Feature Driven Development, que recomendamos más adelante como un método
ventajoso para proyectos grandes con equipos de mucha personas. Por si estas dos características no fueran
31
suficientes, otra ventaja consiste en que los estados intermedios de pase permiten al proyecto contar con el
apoyo de grupos organizacionales, como Aseguramiento de la Calidad, que puedan tomar esos traspasos como
referencias e intervenir sin violencia en la calidad del proceso.
Hasta acá lo descripto constituye generalidades del uso de un tablero kanban. Para que sea una aplicación del
método Kanban, es necesario limitar el número de pósit en cada columna. Si en una columna hay tantos pósit
como indica el límite, generalmente anotado en el tope de la columna junto a su nombre, no se puede pasar un
pósit más a esa columna. Esto implica que aunque se haya terminado el paso anterior para una tarea la columna
está bloqueada y no se puede hacer avanzar el pósit correspondiente. Claramente las personas que quedan
ociosas notan esto, las personas que están trabajando en las actividades de la columna saturada notan esto y la
cadena de producción se detiene. En esta situación se detecta un cuello de botella, que debe ser resuelto por los
mismos miembros del equipo. A diferencia de la gran mayoría de los métodos existentes, Kanban no es
prescriptivo. En eso lo sigue Scrum, pero Kanban es todavía menos prescriptivo que Scrum. El equipo elige, adapta
y adopta sus procesos según su necesidad.
Lo que diferencia notablemente a Kanban de los otros métodos ágiles es su flexibilidad, pero sobre todo es la
limitación del volumen de trabajo en cada etapa. Es esta restricción la que pone en juego los mecanismos de
adaptación, y en consecuencia los mecanismos de mejora, que en otros métodos quedan a cargo de reuniones
especiales llamadas “retrospectivas”. Lo que en los demás es una visión de lo que pasó, en Kanban es la necesidad
lógica de operar sobre lo que está pasando.
Siguiendo nuestra opción de mejora de procesos que definiéramos en el Capítulo anterior, utilizaremos los
mismos preceptos que usa Anderson para Kanban puesto que son compatibles: Foco en Calidad, Reducción del
Trabajo en Desarrollo, Entregas Frecuentes, Balanceo de la Demanda contra la Producción, Fijación de Prioridades,
y Atacar las Fuentes de Variación para Mejorar la Predictibilidad. La receta de Anderson no sólo es compatible con
la de LS que eligiéramos antes, ¡Es totalmente compatible con el MPS! En el Capítulo 5 expandiremos las técnicas
de Kanban utilizando el ejemplo de Tahini-Tahini.
3.3 Scrum: Organizando el sistema para un estado de equilibrio orgánico
Scrum no debe ser considerado un método, a pesar de que tiene reglas claras que se deben seguir, porque
deja muchas resoluciones abiertas para que el equipo del proyecto las resuelva. Al describir Kanban dijimos que
después del mismo, Scrum es el enfoque ágil menos prescriptivo. Esto es cierto, pero la gran diferencia entre el
número de reglas de uno y otro (3 contra más de 10) hace que estén cerca pero no demasiado.
Para implementar Scrum en una organización hay que hacer cambios profundos antes. Con Kanban los
cambios originales son solo tres: reflejar el flujo en un tablero Kanban, limitar el número de tareas por etapa y
mejorar el flujo total haciendo las alteraciones que demande el proceso. Kanban se adapta fácilmente a cualquier
proceso subyacente, porque las entregas rápidas pueden ser internas al equipo y la participación de los
involucrados externos al mismo es deseable pero no indispensable. En cambio, en Scrum es indispensable
restructurar la organización en varios sentidos: Primero se tiene que contar con una persona que conozca el
producto, o tenga la visión del producto, y que esté disponible para trabajar con el equipo durante la duración del
proyecto. La dedicación que se requiere no es de tiempo completo, pero esta persona debe permanecer accesible
para que el equipo pueda tomar decisiones de negocios conjuntamente con ella. Asimismo, está persona debe
32
poseer la suficiente autoridad para que sus decisiones no se revean . En el lenguaje de Scrum esta persona se
conoce como el “Dueño del Producto”.
En segundo lugar, el personal debe ser dividido en equipos interdisciplinarios pequeños, auto-organizados,
que cuentan con la supervisión y colaboración para allanar problemas de parte de un especialista, llamado en
Scrum el Scrum Master. El Scrum Master se encarga de que se sigan los procesos de Scrum y de mantener la
relación del equipo con el medio que lo rodea. En ese sentido, es mucho más un perro pastor que cuida del ganado
que un gerente que dirige las operaciones. La auto-organización del equipo es fundamental en Scrum. El Scrum
31
En inglés, “hand-off” entre un rol y el otro.
32
26
Esto es lo que [BOEHM, B. e TURNER, R., 2003] llaman un usuario ‘CRACK’ (collaborative, representative, authorized,
committed and knowledgeable) que traducido es colaborativo, representativo, autorizado, comprometido y con
conocimiento.
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-26-320.jpg)
![Boria et al.
Master no dicta lo que debe de hacerse, sino que allana el camino para que se lo pueda hacer. De ese modo es el
propio equipo 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:
33
“momentos de verdad”, por analogía con el mismo concepto en Marketing .
33
[CARLZON, 1989] Moments of Truth.
Capítulo 3
27](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-27-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
34
Producto. Esto tiene inmediatas consecuencias. Al no tener la guía de un usuario CRACK , 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
35
de desarrollo. De hecho, Kent Beck , el pionero de XP, fue de los primeros en sugerir iteraciones cortas con
34
35
Usuario “CRACK” (collaborative, representative, authorized, committed and knowledgeable) que traducido es colaborativo,
representativo, autorizado, comprometido y con conocimiento [BOEHM e TURNER, 2003].
BECK, K., 2000, Extreme Programming Explained, Addison-Wesley.
28
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-28-320.jpg)
![Boria et al.
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
36
escuchando indefinidamente” . 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.
Capítulo 3
29](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-29-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
37
citada en las referencias .
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
38, 39
productividad de su técnica particular de programación por pares
. 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
39
30
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.
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.
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-30-320.jpg)
![Boria et al.
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.
Capítulo 3
31](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-31-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
Escalamiento
Casi desde el principio de su existencia, la ingeniería de software se ocupa de dos problemas ligados entre sí:
40
“Programming in the Large” y “Programming in the Many” . El primer problema es el de atacar proyectos
grandes. El concepto de ‘grande’ es relativo a la media que produce la 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]
32
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-32-320.jpg)
![Boria et al.
Figura 3.5: Ciclo de Desarrollo de FDD
Entremos en un poco de detalle en los cinco procesos.
El primer proceso comienza cuando se han determinado los principales actores para todos los roles
requeridos. Los roles que resultan clave en FDD son seis. El principal rol es el de Gerente de Proyecto. Es
responsable administrativo del proyecto y debe mantener el ‘sistema’ proyecto andando. Muy a la manera del
Scrum Master, el Gerente de Proyecto FDD se ocupa de que se siga el proceso y que su equipo pueda funcionar
libe de interrupciones. A diferencia del Scrum Master, el Gerente de Proyectos FDD tiene la última palabra en
alcance, presupuestos mensuales y 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
41
nombre es Programador en Jefe . 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.
Capítulo 3
33](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-33-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
42
proceso, construir la lista de funciones . 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”.
34
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-34-320.jpg)
![Boria et al.
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
43
invariante que resulta de la ejecución de los métodos de la clase . 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
44
fase .
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
44
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]
Usamos indistintamente fase, paso y proceso para referirnos a las cinco fases de FDD.
Capítulo 3
35](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-35-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
45
para los autores el formato ideal para encajar con los modelos de madurez inspirados en CMM , tales como el
MPS o el CMMI.
45
[PAULK, M., WEBER, C., CURTIS, B., 1994] siguiendo a [HUMPHREY, W., 1989]
36
Capítulo 3](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-36-320.jpg)
![Boria et al.
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.
Tabla 1: Desempeño de Proyectos de los Sistemas de Decisión de
General Dynamics Contra el Nivel CMM
Nivel Porciento Efectividad
CMM
de
de la
Retrabajo Contención
en Fase
2
3
4
5
23.2%
14.3%
9.5%
6.8%
25.5%
41.5%
62.3%
87.3%
Densidad de Productividad (x
Defectos
factor relativo
Únicos
al nivel 2)
Reportados
por el Cliente
por KSLOC
3.20
0.90
0.22
0.19
1x
2x
1.9 x
2.9 x
Figura 4.1: 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
46
[HUMPHREY, 1989] consiste en la creación de un modelo de estados que ofrecen precisamente esa guía .
47
De hecho, los modelos de estado son anteriores al trabajo de Humphrey. En un trabajo eminente , Richard
Nolan introduce un modelo de estados para la 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
48
referencia a dos criterios para la ‘buena formación’ de modelos de estados, descriptos por Simon Kuznets : 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
47
48
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.
[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.
[KUZNETS, S., 1966]
Capítulo 4
37](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-37-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
49
internacionales para definición, evaluación y mejora de procesos de software” .
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
50
Software, MR-MPS-SW [SOFTEX, 2012a], ya citada, cuya lectura es indispensable para entender la génesis , 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
50
[SOFTEX, 2012a], página 6
[SOFTEX, 2012a], página 15, Apartado 7, Base técnica para a definição do modelo MPS
38
Capítulo 4](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-38-320.jpg)
![Boria et al.
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.
Capítulo 4
39](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-39-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
40
Capítulo 4](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-40-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
51
cambio, esto no es equivalente a decir que estén de acuerdo con la dirección que se le quiere dar al cambio .
Lo desconocido causa temor, o al menos, resquemor. Esperar que todos entiendan el cambio de entrada y lo
adopten por sus ventajas es iluso, la 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
42
"... 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).
Capítulo 4](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-42-320.jpg)
![Boria et al.
Figura 4.6: Secuencia de Resistencia al Cambio [KUBLER-ROSS, 1997]
En lo que sigue evitaremos discutir cambios culturales profundos, para lo que hemos reservado una 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
52
un objeto, sino un proceso, un devenir , 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.
Capítulo 4
43](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-43-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
53
momento que se lo necesita y con los procesos reales .
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
54
individual no alcanza para conseguir el cambio de la organización. Como dice Peter Senge en [SENGE, 2006],
“Cuando pensamos en la organización que aprende, son los equipos los que aprenden”. Dicho de otra manera, no
53
54
En TeraQuest llamábamos a esto por las siglas JIT, OTJ, JET, (Just in Time, On The Job, Just Enough Training)
When we think of a learning organization, it is the teams that learn. Peter Senge, “The fifth Discipline”
44
Capítulo 4](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-44-320.jpg)
![Boria et al.
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
Capítulo 4
45](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-45-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
cultura, encontramos que son cuatro dimensiones, como muestra la Figura 4.12, derivadas de los dos ejes sobre
55
los que se apoya una organización :
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.
46
Capítulo 4](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-46-320.jpg)
![Boria et al.
satisfacer al cliente. En un mercado no hay privilegios para amigos y la competencia lo es todo, de ahí el nombre.
Las empresas financieras suelen mostrar ejemplos de esta cultura.
Por último, una ‘Ad-hocracia’ es una cultura que favorece la diferenciación de su personal. En una Adhocracia 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
56
organizacional ; 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
57
organizacionales de cualquier tamaño” . 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 autoevaluació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
57
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.
SOFTEX, 2012i
Capítulo 4
47](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-47-320.jpg)
![Boria et al.
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
2
definen un proceso que solucione la causa y evita que se repita. Nuestro hombre en T parte por definir, siguiendo
el método, las características deseables del proceso:
•
•
•
Evitar que se repita el problema en el futuro
2
Ser muy fácil de implementar (dos o tres días en T )
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
2
buscar en la red herramientas de software que se ajusten a las necesidades de T para llevar el tablero Kanban en
la nube o en servidores locales, gratuitamente. Hay suficientes como para que Mariano se entretenga por varios
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
2
no hubiera respuesta de ninguna de las dos. Todo está bien en el universo de T . 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.
Capítulo 5
51](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-51-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
prácticas. Además, ni ha sacado el tema del MPS con T , 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
2
una cita acá y otra allá, por la tarde del viernes está de nuevo en la sala de diseño de T 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
2
pero utiliza esta vez la herramienta de software (sprint.er) que instalaron en T . La secuencia de pasos es la misma:
identificar el Backlog, hacer la 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,
2
revisar y cerrar. Pero esta es la primera propuesta con desarrollo a medida que T va a firmar; hasta aquí solo han
vendido servicios de un producto relativamente estable con modificaciones que no alteraban el esquema de
trabajo, basado sobre todo en correcciones al 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.
PLANTILLA DE DEFINICION DE HISTORIAS
ID NOMBRE
IMPORTANCIA TAMAÑO VALIDACION
1
RIESGOS ASOCIADOS
CAPACIDADES REQUERIDAS
2
3
4
5
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
59
sobre lo que hacen usando otras facultades además de su capacidad de construir .
Planilla de Definición y Control de Riesgos
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 Exp - Exposición - producto entre prob y perd
100)
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
Descripción del Riesgo
Prob Perd Exp
ID
Condición
Prioridad Prioridad # Veces
en este la última
en la
análisis
vez
lista
Acción
Quién
Cuando
Consecuencia
1
2
3
4
5
6
7
8
9
10
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
56
[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í.
Capítulo 5](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-56-320.jpg)
![Boria et al.
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).
2
De las tareas de planificación solo faltan GPR 8 y GPR 9. Máximo y el equipo de T 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
Capítulo 5
59](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-59-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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:
60
Capítulo 5](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-60-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
61
nombre de retrospectivas, y T las adopta bajo la preparación y supervisión 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
62
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.
Capítulo 5](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-62-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
62
definición de nuevas competencias necesarias y delimitación de nuevas responsabilidades” .
QUE HA PASADO HASTA AHORA
2
26. T 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
2
prontamente por el personal de T y la organización recibió su diploma en el congreso anual del Simpósio Brasileiro
2
de Qualidade de Software (SBQS). La noticia circuló rápidamente en los medios locales y T tuvo sus quince
2
minutos de notoriedad. Por breve que haya sido esa notoriedad los amigos de T , como el Doctor Molar, se
sintieron obligados a compartir el orgullo que les trajo la noticia. La consecuencia inmediata es que otros clientes
2
se acercaron a T para inquirir sobre sus servicios.
Una oferta muy tentadora llegó desde el Consejo Profesional de Contadores 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.
2
Tras unas breves charlas iniciales con CoProCoP se hace una reunión plenaria de T 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
2
Dos días más tarde, Máximo facilita la reunión plenaria de T 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
64
Capítulo 6](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-64-320.jpg)
![Boria et al.
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
63
la propiedad y si la decisión aumenta o disminuye los riesgos. Máximo propone crear una matriz de Pugh 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
2
a las oficinas de T 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
2
un sistema nuevo, en la nube, por lo que la experiencia de T les es sumamente apetecible, y un proveedor de
servicios a agentes de seguros que 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.
-
63
“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?”.
Ver Capítulo 2.
Capítulo 6
67](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-67-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
dirige a la pizarra y escribe: ‘Visión para T : 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:
1 sistema
completo
software para
farmacias
1 sistema migración a
SaaS
Asociación servicios de
salud
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
atributo
contadores
Esfuerzo
mercado pot.
Enorme
hospitales, farmacias,
muy ampilo
Farmacias
médicos
Tabla 6.4: Matriz de Pugh sobre Propuestas
servicios a
agentes de seguros
????????
Los signos de pregunta los escribieron los mellizos Galarraga, que de repente se levantaron al unísono y se
disputaron el marcador.
-
68
“¿Qué pasa si”, dijo Alberto,
Capítulo 6](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-68-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
comunicar la visión y el estado de los proyectos
estratégicas
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).
70
Capítulo 6](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-70-320.jpg)
![Boria et al.
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
2
defectos relacionados con el producto, y duración, esfuerzo y costo de la tarea. Con esto en mente, T 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
64
una posible mala definición del sistema de decisión 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 que se usan en los proyectos son
decididas en conjunto por la gerencia del proyecto y la
PMO
se especifica claramente el procedimiento de
medición con responsabilidades y controles
las mediciones e indicadores que se utilizan en los
proyectos son decididos sin consideración a las
necesidades organizacionales
cada proyecto tiene una versión distinta del sistem de
decisión
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
no todos los interesados entienden el porqué de las
decisiones
se guardan los datos y los resultados de los análisis de
manera de que puedan ser recuperados
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
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
64
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;
Los datos requeridos son recolectados y analizados;
2
T 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.
Capítulo 6
73](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-73-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
liquidez para mantener a T funcionando. Se buscará una alianza con la empresa de SaaS para servicios de salud. A
cambio de poner el know-how de SaaS y la arquitectura se espera participación en el negocio y las patentes que
2
puedan surgir. Con la empresa que quiere fundir su software para farmacias con el existente de T se llevará
adelante un convenio por el 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
Planilla de construcción de
El plan está aprobado y
Programa
programas del líder técnico de
bajo control de
proyecto
configuración
Fecha Real de finalización del
Subversion
La fecha de ingreso es
programa
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
Programas Acumulados Planificados
para la Semana
Programas Acumulados Realizados en
la Semana
Cálculos utilizados
Cuenta; el número de programas cuya fecha de finalización
según el plan cae dentro de la semana en cuestión.
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.
74
Capítulo 6](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-74-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
riesgo:
mitigación:
si no sabemos donde se almacenan los productos y los
resultados, perdemos tiempo y posiblemente trabajo
si "no se puede encontrar una hoja en particular en el
bosque" se pierde mucho tiempo identificando cada
parte
si los documentos se actualizan sin que los interesados
se enteren pueden haber “choques” entre cambios
se adopta un sistema de gestión de documentación
se adopta un sistema de clasificación de los ítems
almacenados
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
se lleva la historia de los cambios de línea base
se sigue un proceso estricto para cambiar un producto
si no sabemos quién cambió qué ni cuando puede ser
difícil reproducir los motivos y decisiones alrededor de
un cambio
si las personas no respetan las reglas y los activos se
se controla que los productos de trabajo sean
almacenan en cualquier parte y cualquiera los accede y
almacenados, leídos y liberados al uso siguiendo las
modifica se puede introducir mucho retrabajo
formas del proceso
Tabla 6.12: Riesgos Derivados de la Falta de Control de Activos
65
Máximo introduce al grupo la noción de línea base de productos . 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
2
cuestión. Para T 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.
76
Capítulo 6](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-76-320.jpg)
![Boria et al.
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
2
trabajando en T y la sala de diseño ha pasado a ser la sala de uno de los dos equipos de Scrum. Media calle más
2
hacia el rio se abrió la sucursal de T , 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.
2
Cuando Máximo explicó la escritura de procesos a T 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
66
computadora, encontró un webinar que bajó de SlideShare . 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
Capítulo 6
77](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-77-320.jpg)
![Boria et al.
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,
2
poniendo a buen uso la inversión de T 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.
Capítulo 6
79](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-79-320.jpg)
![Boria et al.
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
reunión inicial
la
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 TahiniTahini.
Capítulo 7
89](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-89-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
2
que una empresa pequeña como T 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
el tamaño de la funcionalidad excede la
capacidad del sprint
la funcionalidad es nueva y tiene muchas aristas
inexploradas
la funcionalidad es totalmente central al
funcionamiento del producto (control)
el dueño del producto tiene dudas sobre la
funcionalidad que sugiere
el equipo no tiene miembros con experiencia
la arquitectura es crucial en el desempeño
futuro del producto
elección sugerida
Kanban con un mini-equipo dedicado
mini-espiral de Boëhm dentro del sprint o partir el
sprint a partir del análisis para hacer demos más
frecuentes
usar TDD a full e inspecciones además de
programación de a dos
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
usar inspecciones y programación de a dos con el
scrum master en uno de los roles
usar un sprint para definir la arquitectura, a la
manera de FDD, y decidir después sobre Kanban,
Scrum o Scrumban
Tabla 7.7: Orientación Sugerida por Perfil de Sprint
2
Cuatro semanas después de contar con la presencia del consultor en las oficinas de T , 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 TahiniTahini.
44. Marcela define una arquitectura para organizar los activos de proceso.
92
Capítulo 7](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-92-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
Pero antes de alcanzar el nivel E, T 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 autoorganizació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.
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.
94
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.
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.
Capítulo 7](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-94-320.jpg)
![Boria et al.
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
74
75
organizacionales , como la indentación , 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
2
necesidades de T .
74
75
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.
Se consigue fácilmente con herramientas de “Pretty Printing”
Capítulo 7
95](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-95-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
76
objetiva, es un atributo de la relación entre un objeto y el sujeto que evalúa la calidad . No existe la calidad
“absoluta”, siempre es calidad “para” y en un contexto. Por lo mismo, la calidad está ligada a las expectativas de
77
los clientes. En el modelo de Kano se puede ver que hay tres tipos de requisitos: los llamados Indispensables,
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.
b.
c.
d.
e.
76
77
78
utilizar la historia de los sprints en el juego de planificación para tener una mejor aproximación
al esfuerzo real
78
fijar el uso del estándar de recursos necesarios en los planes de proyecto para poder comenzar
su provisión anticipadamente (escritorio, PC, SW, etc.)
establecer normas de comportamiento de los equipos y hacerlas respetar, con las variantes
necesarias
darle a las experiencias el lugar importante que merecen y almacenar juiciosamente los
resultados para aprovecharlos en futuros proyectos
establecer procesos estándar y mecanismos de elección entre ellos, con criterios para elegirlos y
adaptarlos.
[PIRSIG, 1974], Zen y el arte del Mantenimiento de la Motocicleta. Puede decirse que es uno de los ensayos 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.
http://kanomodel.com/
De poco vale tener una guía si no se la sigue!
96
Capítulo 7](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-96-320.jpg)
![Boria et al.
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
2
continúan disminuyendo la capacidad de T , 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.
2
57. T se encamina a una evaluación del Nivel E.
Capítulo 7
97](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-97-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
competencias de T y de perfeccionar la base de conocimientos y su uso por los empleados de la misma. Jessica se
consigue integrar perfectamente con el equipo de 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
79
itera sobre un proceso que Jessica introdujo al grupo, conocido como la hoja de resultados balanceados , 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
2
80
en T es simplemente revisada en cada oportunidad , se analizan los resultados, se fijan objetivos y se discuten las
2
inversiones en diferentes categorías. T 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
98
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”.
Capítulo 8](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-98-320.jpg)
![Boria et al.
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
2
su vez, para analizar como estas metas financieras se traducen en metas con los clientes, en T se usan tres temas
para (1) expandir (que ellos compren 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
2
81
2
de defectos producida por los equipos de T con las medias históricas en la literatura la conducción de T 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
Capítulo 8
99](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-99-320.jpg)
![Boria et al.
riesgo o problema:
mitigación:
suelen quedar funciones sin especificar y los requisitos
no funcionales son demasiado frecuentemente
añadidos hacia el final del proyecto resultando en
mucho retrabajo
hay mucho impacto en los compromisos por la
cantidad de requisitos derivados que surgen después
del juego de planificación
la especificación de los requisitos debe permitir
identificar funciones así como los atributos de
calidad no funcionales del producto
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
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
aun en aquellos casos en los que se construyen
modelos del producto estos son pocas veces
discutidos con el dueño del producto
como parte del mecanismo de entendimiento de
los requerimientos es necesario construir historias
de usuario, narrativas y/o casos de uso que
expliquen el uso esperado del producto
la 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
durante el juego de planificación los requisitos
menos comunes serán validados usando modelos y
los casos de uso o historias de usuario
3
4
8
antes de encarar un sprint se deben definir los
detalles de la porción de funcionalidad que se va a
incluir
Tabla 8.1: Problemas de Requisitos
Este es el punto de partida de la futura tabla de decisiones. La columna de la derecha, ‘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
84
System Modeling Language, ASML , 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
85
sistema si se construye un modelo del mismo, puesto que ese modelo obra como ‘objeto de frontera ’ entre el
cliente y el ingeniero de software. El modelo, entonces, es factible de 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
85
[WARD, P., e MELLOR, S., 1986], Structured Development for Real-Time Systems, Volume I: Introduction and Tools
Un “objeto de frontera” se define como una entidad que tiene uso plástico, que varía de una comunidad a la otra. De ese
modo su interpretación permite detectar discrepancias entre las comunidades.
Capítulo 8
101](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-101-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
86
87
Modeling in Color’ (JMC). En JMC se utiliza notación de UML , 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
87
[COAD, P. et al, 1999], Java Modeling In Color With UML: Enterprise Components and Process. Actualmente se modificó el
nombre a Visual Paradigm, abreviado VP UML.
[FOWLER, M., 2003], UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)
102
Capítulo 8](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-102-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
89
90
publicación en StickyMinds , y encuentran su último libro sumamente útil. Presentan entonces una propuesta
alternativa: Usar historias de usuario para mantenerse dentro de eXtreme Programming, elaborar con ellas un
91
diagrama de casos de uso, identificar casos faltantes usando una matriz CRUD , y desenvolver un perfil de
92
operaciones siguiendo las técnicas del libro de Denney y para aquellos casos que lo ameriten , desarrollar casos
93
de uso completos siguiendo los parámetros del libro de Allistair Cockburn . 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
94
Development o TDD ). De ese modo, opinan, solucionarán la mayoría de los problemas sin modificar demasiado el
tratamiento actual de los requerimientos.
2
Como T 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:
los clientes nos dan información
incompleta sobre las necesidades y
requerimientos del producto dando
lugar a mucho retrabajo
información incompleta sobre
necesidades y requerimientos
especificaciones incompletas
mitigación:
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
proceso sistemático de identificación
JMC
XP + TST
A
M
documento donde priorizar requisitos y
especificarlos
identificar funciones así como atributos
de calidad
definir detalles de la porción de
funcionalidad en el sprint
especificar interfaces internas y externas
construir historias de usuario, narrativas
y/o casos de uso
balancear requisitos y necesidades del
cliente contra restricciones del equipo
M
A
funciones y requisitos no funcionales
B
sin especificar
demasiados requisitos derivados
M
después del juego de planificación
no hay clara definición de las interfaces
A
no hay contexto donde situar las
A
especificaciones
se pasa a la estimación sin hacer un
M
análisis más profundo de la
funcionalidad
los modelos no son discutidos con el
validar requisitos menos comunes
A
dueño del producto
temprano
Tabla 8.2: Comparación entre Métodos de Desarrollo por su Beneficio
89
90
91
92
93
94
M
M
A
A
A
A
http://www.stickyminds.com/
[DENNEY, R., 2012], Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test
Design.
CRUD es la secuencia de iniciales de las palabras inglesas CREATE, READ, UPDATE, DELETE. Estas actividades surgen del uso
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.
Siguiendo a Denney, los casos que tengan mayor frecuencia de uso se desarrollan primero.
[COCKBURN, A., 2000], Writing Effective Use Cases.
Fundamental en XP, el TDD se basa en un ciclo corto de repeticiones: primero el desarrollador escribe un caso de prueba
automatizado que define una mejora deseada o nuevas funcionalidades. El 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”.
104
Capítulo 8](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-104-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
98
incomparables. En este caso Marcela se inclina por el formato propuesto por Allistair Cockburn en su libro . A
menudo se propone la siguiente estructura en el 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:
los clientes nos dan información incompleta sobre las
necesidades y requerimientos del producto dando lugar a
mucho retrabajo
98
XP + TST
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
[COCKBURN, A., 2000], Writing Effective Use Cases.
110
Capítulo 8](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-110-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
99
Máximo, utiliza las interpretaciones que de ellos hace Barry Boëhm en su obra . Para ellos entonces, verificar es
comparar si lo que se realiza cumple con lo especificado, mientras que validar es garantizar que el producto
satisface las necesidades del cliente.
2
100
Para verificar sus productos, T utiliza múltiples herramientas. Las revisiones , ya sean inspecciones por
101
102
pares, recorridas , revisiones estructuradas o revisiones continuas ; 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
103
caídas o fallas del sistema con el propósito de detectar errores en el producto , pero también como herramienta
104
de diseño 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.
105
Para validar sus productos T2 hace uso de actividades en las que participa el DP . Al planificar el Sprint el
equipo crea el modelo que representa la funcionalidad deseada y lo “ejecuta” frente al DP. Esto permite validar la
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
101
102
103
104
105
Véase para mayor detalle [FREEDMAN e WEINBERG, 1990].
N. del A. Hemos traducido walkthroughs como “recorridas”, manteniendo la consistencia histórica con [BORIA, J., 1987].
Siguiendo a [BECK, K., 2000] consideramos a la programación de a dos una forma extrema de revisión continua.
Probar el programa para “asegurarse que funciona” es un error de enfoque que disminuye la efectividad de la prueba.
Test Driven Design en [BECK, K., 2000]
Dueño del Producto, Capítulo 3.
114
Capítulo 8](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-114-320.jpg)
![Boria et al.
Figura 8.8: Modelo V de Desarrollo de Software
La rama derecha del modelo en V define la correspondencia entre las actividades de 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
106
que la reparación introduce nuevos errores con mayor probabilidad de la que tendría repararlo con tiempo . 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],
Capítulo 8
115](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-115-320.jpg)
![Boria et al.
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
108
capacidad de encontrar defectos, la recorrida. Hay un libro de Yourdon 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:
Objetivos
108
Recorridas
Obtener
retroalimentación
temprana sobre la
manera de avanzar con el
Revisiones Estructuradas
Mostrar que el producto
tiene la calidad esperada
Inspecciones
Ubicar todos los errores
posibles y corregirlos hasta
alcanzar un nivel de calidad
prefijado
YOURDON, Edward, 1989, Structured Walkthroughs. Prentice-Hall.
Capítulo 8
119](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-119-320.jpg)
![Boria et al.
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.
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
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
2
elección de entrenamiento anual pago por T . 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.
2.
3.
4.
Capítulo 8
El conjunto de casos de prueba que se tiene que usar
Los datos que tienen ser utilizados cada vez que se corran los casos
Los ambientes en los que tienen que correr las pruebas
Las pruebas de regresión incluidas en las pruebas de dicho tipo
121](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-121-320.jpg)
![Boria et al.
Resultados Esperados de VAL en el MPS
Atividades Internas en Tahini-Tahini
VAL 1 Los productos de trabajo a ser validados son
identificados
acordar con el cliente y el equipo la estrategia de
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
2
Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T
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.
Capítulo 8
127](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-127-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
CAPÍTULO 9 - AMPLIANDO LA CAPACIDAD DE DECISIÓN (NIVEL C de MPS-SW)
9.1 Una Gestión Ambiciosa
2
Hasta acá la gestión de T 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
111
who do the right thing"
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
132
Capítulo 9](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-132-320.jpg)
![Boria et al.
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
2
establecido en la política de calidad, y que se aplica universalmente en T . 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
120
naciones. Esta visión del azar, compartida en otras ciencias , fuerza a las organizaciones a repensar su estructura
y el manejo de riesgo. Puesto que un ‘cisne negro’ no se puede prever, es imprescindible organizarse para que la
llegada del mismo no sea destructiva en el corto, mediano y largo plazo. En el corto plazo las empresas y
organizaciones 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].
Capítulo 9
139](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-139-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
9.9 Decisiones Formales
Del mismo modo en que los riesgos son analizados siguiendo procedimientos bien definidos para agregar
valor, recogiendo nuevos riesgos y las soluciones correspondientes que se deben considerar, hay decisiones
121
especiales que se hacen, cuando corresponde, sobre la base de métodos formales . El propósito de usar métodos
formales al tomar decisiones, es que siguiendo un estándar formal se pueden almacenar, comparar, analizar y
2
reutilizarse las decisiones basándose en los resultados que arrojan. Al principio, T 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
2
correlaciones simples. T 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
122
a un profesor suyo, el Dr. Zito, quien le ha recomendado varias lecturas , 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
122
De hecho en la literatura hay muchas publicaciones que hablan a la vez de riegos y decisiones formales.
En particular el Dr. Zito recomendó el libro de CLEMEN, 1997, pero Marcela también encontró útil un libro mucho más
sencillo, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, de [Schuyler 1996].
140
Capítulo 9](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-140-320.jpg)
![Boria et al.
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 = c 0 + c1
X1 + c2 X2 + … + cn Xn + . Los coeficientes cj son los que determinan la variabilidad correspondiente en el diagrama
de tornado. Un coeficiente muy grande en 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
123
al lector de los detalles matemáticos y remitimos a los interesados a la literatura clásica . El uso que se le da a la
2
ecuación de regresión en T 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
2
Mariano llega muy excitado a las oficinas de T 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.
Capítulo 9
145](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-145-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
-
2
“Colegas de T , 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
2
ningún privilegio técnico ni participación alguna en decisiones financieras internas a T . En este momento
está reunido el Board de TransKND en Toronto para ratificar o rechazar el acuerdo, del mismo modo que
nosotros lo estamos haciendo acá. Revisemos el acuerdo”.
Acto seguido distribuye copias a cada uno, previamente marcadas con resaltador las partes importantes. El
Comité discute varias horas, pero al finalizar la 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 Principiantes
124
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
2
arquitecturas de décadas anteriores con los últimos avances tecnológicos. Veamos el producto estrella de T , 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.
2
Pero ahora imaginemos el nuevo gran producto de T , 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]
146
Capítulo 9](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-146-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
independencia que este modelo arquitectónico provee y el poquísimo acoplamiento que produce, hay grandes
125
126
parecidos con el diseño de Sistemas Operativos moderno . Hay definiciones bien documentadas de todo lo
127
que es necesario describir y como crear un registro de metadatos .
SOA es menos una arquitectura que lo que es un paradigma para la construcción y mantenimiento de
128
procesos de negocios que abarcan sistemas distribuidos de gran porte . Una componente esencial de una
arquitectura SOA es el bus. El bus es el gran unificador, permite eliminar la necesidad de conocer detalles de
interfaces entre servicios. A cambio exige la existencia de un registro de los metadatos que cada uno espera recibir
y la capacidad de cada uno de interpretar metadatos. Esto puede llevar a un gran caos, por lo que todos los
autores recomiendan incorporar un nivel de 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
2
Para el proceso de reingeniería dentro de T 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
129
chequeos de antecedentes, el nuevo ingeniero pasa a ser arquitecto del proyecto . Junto con Ana y los gemelos
130
elaboran la arquitectura de alto nivel, aplicando JMC . 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
131
recomiendan un experto que asume el papel de programador jefe del equipo . Será él quién se encargue de los
132
detalles de la envoltura 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
2
86. Una empresa canadiense establece una alianza con T 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
126
127
128
129
130
131
132
[BORIA, J. 1989]
http://www.soa.com/solutions/metadata_federation/
Una búsqueda en Google devuelve más de un millón de sitios
[JOSUTTIS, N. 2009]. SOA in Practice: The Art of Distributed System Design.
¡Una de esas cosas que ocurren solo en software!
Ver capítulo 8, Java Modeling in Color.
Ver capítulo 3, Feature Driven Development.
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.
148
Capítulo 9](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-148-320.jpg)
![Boria et al.
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
136
con el experimento hasta que las herramientas estadísticas señalen que el resultado es significativo al 10% . 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
137
recuerda sus lecturas de Taleb y los “cisnes negros”. Un proyecto nuevo de SOA marchaba normalmente, es
decir de acuerdo con las expectativas, hasta que en el Sprint de 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
138
conocidos subía de ciclo de prueba en ciclo de prueba. Un típico escenario de proyecto fuera de control . 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
2
de causas profundas que no llega a ninguna conclusión. Por primera vez en su historia, T 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.
Capítulo 10
153](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-153-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
-
“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
139
estructurado, Constantine hablaba de esto, en 1979 . 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
140
Zito. En el viaje de la Facultad a las oficinas ha tenido un ‘Eureka’ y lo transmite al comité. Utiliza un método de
141
Ford que se conoce como “las ocho disciplinas ”, 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é
2
de gestión se han vuelto legendarias en T , material de muchas leyendas nacidas al abrigo de la decisiones
2
tomadas en ella por aquellos que los más jóvenes consideran los popes de T .
139
140
141
[YOURDON, E., CONSTANTINE, L. 1979]. Muchos atribuyen gran parte del material a Constantine, de ahí la cita a medias del
Doctor.
¡Eureka! o Heureka en griego “¡Lo he encontrado!”, es una famosa 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.
http://es.wikipedia.org/wiki/Ocho_disciplinas_para_la_resoluci%C3%B3n_de_problemas
154
Capítulo 10](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-154-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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’.
142
JAD es la abreviatura que se usa para Joint Application Development , 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
143
alta gerencia. Los participantes deben ser usuarios CRACK 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
Las definiciones iniciales no contenían
reglas de negocio suficientemente
claras ni completas.
3
4
142
143
Los metadatos no fueron definidos
con una plantilla única a la vista, sino
que cada uno adaptó la suya a las
necesidades que iban surgiendo
Los procesos de negocio
estaban sufriendo reingeniería
al mismo tiempo que se los
intentaba describir para
construir el sistema
No hay una plantilla única, no
hay guías de ajuste ni de uso
Añadir a los riesgos en preventa el
conocimiento del negocio del
punto de contacto
Colocar una claúsula en el
contrato que hace responsable al
cliente de las demoras
relacionadas con requisitos
incompletos
Contruir la plantilla estándar para
metadatos y los artefactos
necesarios para su uso productivo
en BiPro
[WOOD, S. e SILVER, D., 1995]
Ver Capítulo 3.
156
Capítulo 10](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-156-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
144
variable aleatoria relacionada con nuestros proyectos podemos aplicar control estadístico de procesos ,
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
2
estadística la forma más parecida es la , 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
145
que Putnam las ha utilizado en sus investigaciones sobre los procesos de software.
Figura 10.4: Curvas de la Familia Weibull
Aplicar SPC hubiera resultado útil en el proyecto fuera de control, porque nos hubiera dicho que la 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
145
[SHEWHART, 1939]
[PUTNAM, L. H. e MYERS, W., 2003]
158
Capítulo 10](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-158-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
10.8 Correlación y Regresión
2
Si T 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.
2
Considerando que en los años en que se llevan datos en T la masa de ellos es sumamente interesante Jessica
propone que se identifiquen tendencias y se las analice. Claudio se ha familiarizado con las técnicas de inteligencia
147
de negocios y propone contratar a un doctorando con quién comparte cursos y sabe un experto en el tema. Así
2
es como, temporariamente, Damián se incorpora al equipo de T .
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
2
Dada la gran masa de datos que posee T 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
148
exceso de información, que puede ser tan paralizante como su falta . Como dijera Stephen Covey, lo principal es
149
asegurarse que lo principal es lo principal . ¿Pero como?
Si recordamos el modelo de Kano (Figura 10.6) que vimos en el 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
149
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)
[COVEY, S., 1996], First Things First.
160
Capítulo 10](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-160-320.jpg)
![Boria et al.
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,
2
pero las ideas gobiernan la automación. T ha aprendido a reconocer su núcleo pero también a explorar “el espacio
155
en blanco” , aquellas oportunidades que no encajan con sus modelos de negocios o con sus clientes habituales.
Johnson define al “espacio en blanco” como: “la gama de posibles actividades que no 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
Capítulo 10
167](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-167-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
156
de Eric Ries, The Lean Startup . 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
2
suspender el proyecto. Sea cuál fuera el resultado, T 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
157
oportunidades hemos mencionado la Ley de Pareto , 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
157
[RIES, E., 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful
Businesses
Capítulos 2, en la discusión de Lean, y 8, aplicándolo al análisis de perfil operativo.
168
Capítulo 10](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-168-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
180
Lista de Figuras](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-180-320.jpg)
![Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
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
2
Tabla 7.3: Riesgos a T 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
2
Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T .............................................................. 126
2
Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T .............................................................. 127
Tabla 8.18: Proceso DISENO Y 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
182
Lista de Tablas](https://image.slidesharecdn.com/tahini-tahinispfinalcover-a4-131115081722-phpapp01/85/Tahini-tahini-sp-final_-cover_-_a4-182-320.jpg)
Tahini tahini sp-final_(cover_-_a4)
- 2. Jorge Luis Boria Viviana Leonor Rubinstein Andrés Rubinstein La Historia de Tahini-Tahini: Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS
- 3. Boria et al. PREFACIO La discusión sobre la posibilidad o no de utilización de métodos ágiles en conjunto con modelos de madurez de procesos de software es frecuente y actual. Algunos consideran que las exigencias de los modelos de madurez no pueden ser implementadas en organizaciones con desarrollo ágil. Otros consideran que la implantación de estos modelos va a lastimar la agilidad de desarrollo. Esta incompatibilidad es discutida, por lo tanto, por defensores del uso de métodos ágiles y por defensores de los modelos de madurez. En este contexto se sitúa el libro “La Historia de Tahini-Tahini: Mejora de Procesos de Software con Métodos Ágiles y Modelo MPS” de Jorge Boria, Viviana Rubinstein y Andrés Rubinstein. El libro tuvo origen en una llamada realizada en diciembre de 2011 por la Secretaria de Política de Informática – SEPIN, del Ministério de Ciência, Tecnologia e Inovação – MCTI, responsable por la conducción del Programa Brasileiro de Qualidade e Produtividade em Software – PBQP Software, para el Ciclo 2012 del Programa “Série de Livros do PBQP Software”. Entre varios competidores resultó el texto seleccionado para publicación. Y fue, sin duda, una excelente elección. En él, los autores, a partir de su riquísima experiencia como consultores, evaluadores MPS y lead appraisers CMMI, nos muestran que no existen contradicciones entre modelos de madurez, mejora de procesos y métodos ágiles. Existe, por el contrario, un excelente camino que puede ser recorrido con éxito por las organizaciones hasta que sean alcanzados niveles muy altos de calidad y madurez en los procesos de software. De acuerdo con los autores, el libro tiene como objetivo mostrar cómo se inter-relacionan las técnicas de consultoría, con los métodos ágiles para alcanzar los resultados esperados del MR-MPS-SW. Para esto utilizan cuatro métodos ágiles, Kanban, Scrum, XP y FDD (Feature Driven Development), y la historia de Tahini-Tahini, una empresa ficticia que ciertamente a todos nos gustaría que existiese. Es un libro técnico, más fascinante y de lectura muy agradable. A veces nos hace reír, tal el buen humor de los autores al tratar el tema. Ciertamente será un caso de éxito, en esta excelente iniciativa del MCTI. Agradezco a los autores la invitación a escribir el prefacio de un libro tan interesante y con contribuciones tan importantes para la calidad y la Ingeniería de Software. Abril, 2013 Ana Regina Cavalcanti da Rocha Universidade Federal do Rio de Janeiro COPPE/UFRJ Prefacio iii
- 4. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS PRÓLOGO - CONSULTORÍA EN MEJORA DE PROCESOS El Origen del Libro Este libro se originó en un llamado realizado en Diciembre de 2011 de la Secretaria de Política de Informática – SEPIN, del Ministerio de Ciencia, Tecnología e Innovación - MCTI, responsable por la conducción del Programa Brasilero de la Calidad y Productividad en Software - PBQP Software, para su Ciclo 2012 del Programa "Serie de Libros de PBQP Software". Entre los temas para los cuáles había que presentar propuestas uno nos parecía sumamente útil a la población de ingeniería de software, la Mejora de Procesos de Software con Métodos Ágiles y el Modelo MPS. Sobre los otros temas, igualmente de importancia, hay literatura básica y avanzada. Tampoco es un valor agregado, en un mundo globalizado, escribir un libro en Castellano o Portugués; el Inglés es la nueva Lingua Franca y los principales cultores de esto son los informáticos. Nos atrajo el desafío de conciliar tres vertientes, tal la complejidad del tema. Estamos agradecidos a todos los que intervinieron en el proceso que llevó a la selección, edición y publicación de este libro. El Propósito del Libro Este libro se plantea como un libro de cuentos para profesionales. La empresa que se usa como caso de éxito no existe ni existió, ojalá exista alguna vez. Los personajes surgieron de amigos, conocidos y situaciones que alguna vez nos tocó vivir, como empleados, consultores o patronal de empresas de software. Su propósito es ilustrar como se interrelacionan las técnicas de consultoría, siempre una buena facilitación cuando está bien hecha, a veces enseñanza-aprendizaje, nunca dictadura; con los métodos ágiles, que son muchos más que Scrum; para cumplir con los resultados esperados del MPS. Este libro no es un recetario, no hay en él un algoritmo, ni siquiera una heurística que permita a otros recorrer el mismo camino que el de los protagonistas de nuestra historia. Sin embargo, abrevar en él para identificar problemas y avizorar soluciones es lo que nos propusimos que fuera su utilización. Esperamos que los lectores aprecien la historia, porque está ahí para hacerlos pensar en las situaciones que ocurren a diario en la industria de software. Por último, este libro no es auto contenido. Requiere que el lector utilice las pautas bibliográficas que les dejamos, ocho páginas en total de materiales superlativos. Si algo destacamos de este libro es que la bibliografía de por sí vale la pena. Las Vertientes del Libro. El título de este libro mezcla tres ideas poderosas. Habla de mejora de procesos con métodos ágiles y el modelo de mejora MPS. Cualquiera de las tres ideas merece un libro de por sí, de manera que escribir uno solo, y en el corto plazo con que contamos los autores, implica una elección de contenidos. Este es un libro sobre las actividades que se llevan a cabo en consultorías de mejora de procesos. Aunque el principal personaje es una mujer, Marcela, que trabaja en relación de dependencia con la empresa que nos permite crear el hilo conductor de la historia, sus actividades son las de un consultor de primer nivel. Marcela encarna la heroína de la novela romántica Inglesa del siglo XVIII en que es inteligente, sabe lo que quiere y sabe cómo conseguirlo. Es el ejemplo de liderazgo de este libro, aun cuando los demás socios y compañeros de ruta son buenos gerentes y excelentes profesionales, cada uno con su vena técnica, es Marcela la que guía con el ejemplo, la que cuestiona el statu quo, la que, en definitiva, lleva la empresa Tahini-Tahini a la cima de la calidad. Cuando escribíamos el libro era con Marcela que preferíamos identificarnos, al fin y al cabo es el personaje más exitoso. Las lecciones que debieran recogerse de este libro se deben a Marcela. No es un libro de consultoría, los hay, y muy buenos, escritos por consultores mejores que nosotros. Sin embargo, hay muchos consejos sobre cómo realizar las cosas que importan, las que llevan a los cambios serios, que están contenidos en las acciones de los personajes. También hay muchísimas técnicas que solemos introducir, de un modo u otro, en nuestras consultorías. El Capítulo 2 inicia el camino mostrando variantes de métodos de mejora continua, culminando con el método Lean. Recomendamos lecturas extras para poder entenderlo y aprovecharlo. No es un libro sobre el MPS, preferimos que el lector aprenda acerca de este robusto modelo en las guías del mismo y en los cursos autorizados que se dictan. Sin embargo no hay nada en el libro que no haya sido escrito con el MPS en mente. Toda la historia de Tahini-Tahini, los vaivenes con las técnicas, a menudo presentadas para su discusión antes de que puedan ser aprovechadas, ilustra nuestro punto de vista sobre los modelos de madurez, iv Prólogo
- 5. Boria et al. centrado en el MPS: Hay que tener la visión global del destino para que el camino se pueda transitar con comodidad. Tampoco es un curso de métodos ágiles. El lector avisado debe entender que para introducir un método ágil en una organización hace falta un entrenador o un mentor que guíe la implementación día a día. Producir una organización ágil a partir de una que no lo es requiere experiencia y adaptación a las necesidades de la organización. Y aunque no es un libro sobre cambio organizacional, de esta disciplina sí que toma muchos conceptos prestados. De todos modos, la literatura de cambio organizacional es muy vasta y muy rica, y le haríamos muy poca justicia si intentáramos resumirla en estas pocas páginas. El libro intenta describir las actividades de consultoría que tienen lugar en muchas organizaciones. Los autores hemos elegido un mecanismo de presentación de los materiales que está a mitad de camino del libro de texto y la narración de una historia que nos permite divertirnos con los personajes. Esperamos que se entretengan con su lectura. Nota de Cautela Ningún libro de calidad puede dejar de citar a Deming. Este superhombre de la calidad nos dejó decenas de pensamientos e ideas para andar con mayor comodidad tras sus huellas. En este Prólogo queremos rendirle un pequeño homenaje a la vez que usar sus palabras para advertir al lector del error que muchas veces se comete en aras de contener los gastos: “El Obstáculo de Deming, La esperanza de postre instantáneo --- la suposición de que una o dos consultas con un estadístico competente pondrá a la empresa en el camino a la calidad y la productividad – postre instantáneo. No es tan simple, siempre será necesario estudiar y ponerse a trabajar.” No somos estadísticos expertos, pero hemos visto el mismo síntoma en muchas empresas traducido a una invitación a almorzar a cambio de un consejo gratuito que después se intenta llevar a la práctica sin los conocimientos necesarios. Los consultores no son irremplazables, pero el conocimiento que traen a las organizaciones si lo es. Nota Sobre los Autores Siempre un libro es una creación colectiva. Tolkien hablaba del ‘humus’ que el autor junta para plantar sus ideas, humus que le debe a sus lecturas y experiencias. Las musas inspiradoras solo trabajan en mentes abiertas que han pasado por las experiencias que enriquecen la vida, tantas veces dolorosas. Pero además de la herencia, los autores siempre están obligados con muchas personas que hicieron lo imposible posible. Queremos agradecer muy especialmente a Ana Regina Cavalcanti da Rocha por su confianza y amistad, a Kival Chaves Weber, Nelson Henrique Franco de Oliveira y José Antonio Antonioni por el apoyo y las oportunidades brindadas y a Richard Denney por prestarnos el material de su autoría usado en algunas partes de este libro. Prólogo v
- 6. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS Autores Jorge Luis Boria Master of Engineering in Computer Science por Cornell University, Estados Unidos. Senior Advisor del Modelo MPS. Evaluador Líder Experimentado MPS. SCAMPI Lead Appraiser para alta madurez. Instructor certificado de los cursos del modelo CMMI. Fue Visiting Scientist del Software Engineer Institute de Carnegie-Mellon University. Fue Professor Titular de las Universidades UBA, UNICEN, UNSL, USal, UB y otras en Argentina. Es autor de otros dos libros relacionados con la industria del software. Jorge quiere agradecerle particularmente a Joyce Statz por la formación que recibió trabajando para ella en TeraQuest Metrics. Joyce fue a la vez amiga, formadora, orientadora y entrenadora. Viviana Leonor Rubinstein Licenciada en Computación Científica por la UBA. Certified Project Manager, UT-SQI. Evaluadora Líder Experimentada MPS. SCAMPI Lead Appraiser DEV y SVC para alta madurez. Instructora certificada de los cursos del modelo CMMI. Fue Profesora Titular en las Universidades UNS en Ushuaia, UBA, UNICEN y otras en Argentina. Es autora de tres volúmenes para la enseñanza de computación en colegios secundarios. Viviana quiere agradecerle a Regina, su mamá, con la que compartió la escritura de su primer libro. Andrés Oscar Rubinstein Programador y Analista de Sistemas de la Pontifícia Universidade Católica do Rio de Janeiro. Evaluador Líder Intermedio MPS. SCAMPI Lead Appraiser DEV y SVC. Sócio de TecnoVoz S.A. Argentina. Fue profesor y auxiliar docente en la PUC-Rio y en la Universidad de Belgrano y el Colegio Nacional de Buenos Aires en Argentina. Andrés quiere agradecerle a Viviana y a Jorge por la confianza, a Adri y a los amigos de siempre por el aguante, y a Male y a Nico por estar. Finalmente, Jorge y Viviana quieren agradecer a Alma, Beto y Franca por darle un nuevo sentido a sus vidas. Y Viviana y Andrés agradecen a Jorge por su liderazgo en la confección de este libro, sin el que tendría sido imposible su realización. vi Prólogo
- 7. Boria et al. PARTE I – Introducción CAPÍTULO 1 - INTRODUCCIÓN 1.1 El propósito del libro Este libro está dirigido a (en orden de interés creciente): • implementadores de mejora de procesos de software que quieran conocer mejor los métodos ágiles para implantarlos en organizaciones de software; • gerentes de proyecto interesados en conocer mejor los métodos ágiles para desarrollo de software, sea para adoptarlos o para evaluar su adopción; • ingenieros de software que intentan trabajar em un proyecto ágil; • profesores de grado en Computación; • estudiantes de grado en Computación; • profesores de postgrado en Ingeniería de Software; • estudiantes de postgrado en Ingeniería de Software. En la medida en que los métodos ágiles y los modelos de madurez han sido considerados términos opuestos en las disciplinas de desarrollo y mantenimiento de software, es difícil concebir un texto que busque alzar un puente entre los dos mundos. Ya fue hecho, sin embargo, con gran suceso, en el moderno clásico [BOEHM & TURNER, 2003]. El modelo de referencia para ellos es el CMMI, siendo fácil de imaginar la conversión para el MRMPS-SW, dada la intencional compatibilidad entre los dos. 1.2 Definición de método ágil para este libro 1 Este libro está principalmente enfocado en cuatro métodos ágiles : Kanban, Scrum, XP y FDD (Feature Driven Development). Esta elección no es por azar. Esos cuatro métodos cubren la mayoría de las implementaciones ágiles realizadas en el mundo. Además, cubren casi todas, sino todas, las necesidades de uso de métodos ágiles. Cada uno de estos métodos será debidamente explicado en el capítulo 3, donde se los introduce al lector. Obviamente, esto ocurrirá en orden creciente de complejidad: Primero el más sencillo y el que tiene el mayor retorno de la inversión, Kanban. Kanban tiene alto retorno porque al organizar las tareas y detectar los problemas rápidamente permite al equipo que lo utiliza aumentar el tiempo disponible para mejorar sus procesos e intentar nuevas mejoras. Scrum, que frecuentemente es el método que se elige desde un principio, acá se ve sólo cuando la empresa ha conseguido estabilizarse lo suficiente como para tener el tiempo de conseguir que las actividades de Scrum puedan ser seguidas con la correspondiente disciplina. Las otras dos técnicas se suman a las ya vistas a medida que la empresa gana en definición de sus procesos y en el número de su personal. 1.3 Si la mejora de procesos de software es la respuesta, ¿Cuál es la pregunta? El principal enemigo de una empresa desarrolladora de software es la baja calidad. Hasta ahora, nadie tiene una propuesta válida para mejorar la calidad, salvo la mejora de procesos, que pasa a ser entonces la cuestión principal. Se puede argumentar que las personas y las herramientas (de software, como CASE) son importantes en su impulso a la mejora de la productividad. Esto es cierto, pero solo cuando los procesos están en su lugar para conseguir que se aprovechen las condiciones de los individuos y las herramientas de software. Es común el caso de 2 empresas y organizaciones que desaprovechan sus recursos humanos y tienen licencias que no se usan, por lo que se deduce que si bien las herramientas y las capacidades de las personas son importantes, son los procesos los que habilitan realmente el aumento de productividad. En la Figura 1.1 simbolizamos esto con íconos. En la primera “ecuación” el personal capacitado sumado a herramientas de software, sumado a procesos bien definidos culmina (después del signo de igualdad) en éxito y 1 2 Las principales referencias de cada uno de los métodos están indicados cuando se describe cada uno en los capítulos siguientes. En este libro utilizaremos en lo que sigue el término “organización” para referirnos a todo tipo de grupo humano organizado para la realización de tareas con un propósito común, sea con o sin fines de lucro. Capítulo 1 7
- 8. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS felicidad. En la segunda ecuación la falta de procesos bien definidos incrementa los riesgos y produce frecuentes problemas en los productos resultantes. Figura 1.1: Relación entre herramientas y competencia de personas La disciplina que inducen los procesos es la que permite aprovechar los conocimientos y las herramientas. Sin esta disciplina no es posible reproducir los éxitos que puedan haber alcanzado los proyectos, porque la memoria organizacional se pierde. 1.4 El caso de estudio: La empresa Tahini-Tahini En este libro seguimos el desarrollo de una organización que nace de una idea de estudiantes universitarios. La empresa que crean es pequeña y por hacerse a sí mismos una broma, la han llamado Tahíni-Tahíni. El nombre surgió cuando una de las fundadoras llegó a la reunión de creación un poco retrasada y al mirar el número de personas alrededor de la mesa dijo, “Somos una empresa tiny-tiny”. Sus futuros socios encontraron eso gracioso y le pusieron de nombre Tahíni-Tahíni, haciendo un doble juego de palabras. En el libro a menudo nos referiremos a 2 la misma con las siglas que sus socios usan para referirse a ella: T , T2 o la Doble T. Como toda empresa recién nacida, creada por jóvenes emprendedores, no ha seguido un plan de crecimiento ideal, más bien ha crecido a saltos, y los mares embravecidos que ha tenido que capear la han hecho más fuerte. Los problemas de la empresa no son poco comunes, son los más frecuentes para una organización de ese tamaño y con esa historia en cada etapa de su crecimiento. En cada paso los socios han debido tomar decisiones que afectan los resultados, y en cada oportunidad lo han hecho alterando los procesos que gobiernan el desarrollo del producto. En cada caso apuntaron a mejorar la calidad y el control de los procesos para mejorar la calidad y el control sobre el producto. Durante el desarrollo del caso de estudio utilizaremos la descripción de Kanban para el principio de un proyecto de mejora de procesos; Scrum en relación a las actividades de gerencia de proyectos más comunes; XP (Extreme Programming) para lo que constituye la categoría de las áreas de ingeniería de software tratadas en el nivel D (Ampliamente Definido) del MR MPS SW. Cuando una empresa crece, los métodos anteriores comienzan a mostrar limitaciones. La coordinación de muchos equipos en Scrum de Scrums presenta mayores limitaciones que 2 los métodos tradicionales. XP ya es difícil de controlar en proyectos medianos. Acompañando el crecimiento de T , la propuesta es una metodología conocida como Feature Driven Development (FDD). En torno de la cuestión del cambio organizacional, seguiremos el camino de la metodología Lean, que se concentra principalmente en la resolución de problemas a través de la mejora de procesos. También en este capítulo describimos cada uno de los capítulos restantes. Cada capítulo que hace referencia a un nivel del MR MPS SW explica los resultados requeridos de los procesos siguiendo las exigencias del modelo. El libro se divide en cuatro partes, cada una atendiendo una necesidad diferente. En la primera parte (Capítulos 1 a 4) se sientan las bases para que el lector pueda comprender los métodos y filosofía de trabajo que los autores proponen. La segunda parte (Capítulos 5 y 6) atiende los temas de baja madurez (Niveles G y F del MPS) e 2 introduce en detalle los primeros dolores de crecimiento de T y la resolución encarada por los socios basada en el uso de Kanban y Scrum. La tercera parte (Capítulos 7 a 9) desenvuelve la temática de Madurez Media, los niveles E, D, y C del Modelo MPS, donde aparecen XP y más adelante FDD. Finalmente, la cuarta parte (Capítulos 10 y 11) 2 expone como la madurez definida de T le permite alcanzar un conocimiento profundo del funcionamiento de sus 2 procesos, caracterizándolos cuantitativamente. El libro se cierra con un resumen del viaje de T desde su creación hasta su venta billonaria. En el Capítulo 2 explicaremos nuestra filosofía de mejora de procesos. Para ello utilizaremos el método Lean, palabra inglesa que significa delgado, porque es el que mejor se adapta a nuestras ideas. Adoptando mensajes de diversas fuentes, explicaremos como es mejor hacer lo menos posible para resolver un problema que hacer grandes cambios sin efecto aparente. También aprovecharemos el Capítulo 2 para hablar de una visión sistémica 8 Capítulo 1
- 9. Boria et al. de las organizaciones y de la relación multicausal de los eventos. De este modo preparamos al lector para que entienda porque una sola acción puede resolver muchos problemas y como a veces es necesario aplicar múltiples acciones (y esperar) para obtener resultados. El libro de [POPPENDIECK et al., 2010], Leading Lean Software Development, es nuestra guía por este territorio. También, donde es útil, citamos material del clásico de [MEADOWS, 2008] Thinking in Systems, A Primer. Los dos libros revolucionan el pensamiento clásico, lineal, de los gerentes tradicionales, y abren la puerta a una gerencia más ágil, más integrada y con más posibilidades de éxito. En el Capítulo 3 introducimos los métodos ágiles propiamente dichos. Si bien Lean es un método ágil según 3 sus creadores y es reconocido como tal por la comunidad ágil , su uso exige mucho conocimiento y está más allá de los objetivos de este libro. En cambio, las técnicas que proponen Kanban, Scrum, XP (Extreme Programming) y Feature Driven Development (FDD) son del mismo modo exitosas y mucho más fáciles de adoptar, sobre todo si se lo hace en el orden en que las proponemos en este libro. Esta es una introducción a los métodos y en ningún momento pretende remplazar la lectura de los textos clásicos del tema, que se citan en la bibliografía y que recomendamos fuertemente al lector. El Capítulo 4 se dedica al eje central de este libro, el modelo de Mejoría de Procesos de Software (MPS). Otra vez, el libro es incapaz de contener todo el conocimiento necesario para hacer buen uso del modelo, de modo que referimos al lector a las guías que Softex ha publicado y que se encuentran accesibles en el sitio web de esa 4 organización . Las guías son un material indispensable para el lector que pretenda seguir nuestras sugerencias e implementar siguiendo el MPS. Lo que sí exploraremos en detalle son las grandes pinceladas que es necesario comprender para que el modelo tenga sentido y no se pierda en los detalles que, necesariamente, hay que aplicar. Discurriremos sobre la evolución de la cultura imperante en la empresa que fuera inducida por la maduración de los procesos, manifiesta en el cambio de los niveles de madurez del modelo, concepto en el que nos detendremos en este capítulo, así como en la arquitectura del modelo que permite encontrar en él las herramientas para su implementación. Para concluir el capítulo explicamos el concepto de evaluación y como una organización puede aplicarlo a sí misma, para entender dónde se encuentra y qué camino le falta recorrer. 2 El Capítulo 5 introduce en detalle los problemas iniciales de T . Utilizando ejemplos que han encontrado en su actividad como consultores y evaluadores de procesos, los autores introducen al lector a los problemas típicos de una empresa que funciona bien cuando todas las cosas están en su cauce. Los pequeños problemas cotidianos (un embarazo, una zona sin recepción telefónica, un cliente apurado) pueden desencadenar una “tormenta perfecta” 2 que arruine la mejor reputación. Es ahí cuando los amigos de T deciden introducir métodos de control y aconsejados correctamente comienzan a utilizar Kanban. Al mismo tiempo consiguen implantar, sin demasiado esfuerzo extra, procesos del modelo MPS. Tentados por la facilidad con que implementaron los procesos del Nivel G, los socios deciden realizar una evaluación formal con un evaluador líder y pasan con éxito. La adopción del MPS 2 por la empresa T es ahora un hecho. En el Capítulo 6 los autores cuentan como los socios, alentados por el éxito obtenido por sus mejoras de proceso, deciden profundizar el camino y utilizan el modelo MPS para hacerlo. Los controles establecidos hacen lugar a la gerencia de configuración, que en germen ya comenzaran a implementar en el nivel G; la medición, que la formación profesional de los socios hace que sea considerada una actividad fundamental para controlar y dirigir la empresa; y el control de la calidad, impuesto por la realidad. La llegada de nuevos clientes con pedidos de proyectos que son a veces de adaptación, a veces nuevos desarrollos, hace que los procesos de la gerencia de portafolio de proyectos les resulten valiosos para entender cómo organizar el crecimiento de la demanda. Este crecimiento les lleva a plantearse uno de dos caminos: crecer internamente, lo que significaría ampliar el espacio físico para admitir más desarrolladores, con la consecuente inversión fija; o subcontratar parte del trabajo. Para tomar la decisión, los socios se apoyan en los procesos de adquisición y deciden a favor, lo que les lleva a implementarlos. Aun así, su pequeño equipo inicial debe dividirse para atender el nuevo volumen de trabajo, e incorporan un número pequeño de desarrolladores. Para organizar los proyectos, los socios deciden utilizar prácticas de Scrum, que les resultan compatibles con el MPS. Para 2 demostrárselo a sí mismos, la T pasa por una nueva evaluación y alcanza el Nivel F. En el Capítulo 7 comienza la tercera parte, que desarrolla los procesos intermedios del modelo MPS. A medida que se expanden los negocios y se abren nuevas oportunidades, los socios se ven obligados a expandir 3 4 La comunidad ágil se reconoce en el sitio web: http://www.agilemanifesto.org/ http://www.softex.br/mpsbr/_guias/default.asp Capítulo 1 9
- 10. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 2 asimismo sus oficinas. Una reunión fundamental los pone en la encrucijada: ¿A dónde queremos llevar a T ? Finalmente se resuelve crear una visión ambiciosa: Ser una de las diez mejores fábricas de software del mundo. Preparándose para el crecimiento, los socios entienden que su visión se completa con una base de conocimientos que puedan ser compartidos, usados y expandidos por todos los ingenieros y demás empleados de su empresa. Sus procesos de gestión evolucionan asimismo para aprovecharse de este conocimiento de manera sistemática. De manera normal surge en la base de conocimientos la definición de los procesos organizacionales. Cuando los empleados superan un número considerado crítico de manera arbitraria, las reuniones de proceso se sistematizan y se formalizan en un proyecto para su evaluación y mejoría permanente. Las constantes incorporaciones fuerzan asimismo a organizar la identificación, captación, preparación y retención de los recursos humanos. En todas estas tareas el MPS les resulta fundamental e indispensable, al darles un marco coherente y las pautas culturales para crecer. El resultado es una organización que aprende, con empleados motivados que continuamente hacen propuestas de mejora de sus propios procesos y los ajenos. Una iniciativa brillante resulta de 2 una de estas propuestas, y T incorpora prácticas de reuso para mejorar todavía más la calidad de sus productos y el rendimiento de su personal. En el segundo Capítulo de la tercera parte, el Capítulo 8, introducimos las técnicas y prácticas de Extreme Programming (XP) que no se superponen con las anteriores ya incorporadas. Una discusión en una retrospectiva lleva a identificar la variación en la interpretación de las técnicas de desarrollo en los equipos como la fuente de diferencias entre las estimaciones iniciales, ahora desarrolladas a partir de la historia, y los resultados reales. Discutiendo en la reunión del grupo de procesos organizacionales se vincula asimismo a esa indefinición con un grupo de defectos que están saliendo repetidamente al mercado. Una propuesta de adoptar XP es recibida tibiamente, pero de todos modos se la implementa, cuidando de que al hacerlo se respeten las condiciones para seguir cumpliendo con la implementación de procesos de MPS. Esto lleva a algunas variantes, como por ejemplo que pair programming, la técnica por la cual dos programadores trabajan juntos en un mismo programa, sea implementada con un coach que registra los defectos encontrados para permitir realizar análisis de los mismos. Los equipos incorporan asimismo software de control e introducen variantes a los procesos para continuar avanzando y seguir dentro del marco del MPS. Enfrentados con la realidad de su crecimiento y los riesgos que trae, los socios incorporan una visión estratégica de su negocio y una vez más lo hacen siguiendo el modelo. En el Capítulo 9 se introduce la visión del 2 riesgo como constante. La T no se define a sí misma como una empresa que quiere evitar los riesgos, sino conocerlos y enfrentarlos. De ese modo es capaz de prepararse mejor para afrontar lo que la realidad les coloque en su camino. Los riesgos así analizados son mejor enfrentados y la capacidad desarrollada de mejora de procesos es, en eso, una herramienta. Por ejemplo, en vez de aprovechar oportunistamente el reuso cuando aparece una 2 necesidad que puede reusar partes ya existentes en los proyectos concluidos, la T organiza una fábrica de componentes que se pueden articular rápidamente para formar productos, reduciendo aún más sus defectos por parte y aumentando a niveles muy altos su productividad. Cada decisión tiene un costo y un beneficio, pero hasta 2 este momento en la historia de la T no se aprendía sistemáticamente de las decisiones ya tomadas. Para evitar 2 que ese conocimiento se pierda, la T incorpora métodos de decisión formales que incluyen varias técnicas que aprovechan la historia. Pronto los proyectos las usan para tomar decisiones sobre la velocidad, la calidad esperada, 2 el reuso y la subcontratación a terceros. La T es ya una organización con centenares de empleados y una sólida reputación de calidad. Los llamados por referencias empiezan a ser internacionales. Debido a ese crecimiento y el 2 consecuente alejamiento físico de los clientes, la T añadió a su arsenal el método FDD, que le permite planificar 2 con mayor precisión los sprints. La T decide ser evaluada respecto al Nivel C del modelo MPS y a su vez, en una evaluación conjunta, respecto al Nivel Definido del modelo CMMI-DEV, cosa que logra con singular éxito. 2 Al ingresar en la Cuarta Parte del libro, encontramos a T en su apogeo. Ha abierto oficinas en varios países centrales, tiene centros de desarrollo en todas las regiones de Brasil y de Latinoamérica, y disfruta de un bien ganado prestigio. Sin embargo, los socios no descansan en sus laureles. En el Capítulo 10 vemos cómo se aprovechan de la base de datos históricos que han amasado a lo largo de los años para utilizarlos en su favor. Identifican los procesos críticos que se relacionan con sus objetivos de negocio, analizan su estabilidad relativa, construyen modelos que permiten prever resultados futuros en puntos tempranos de un proyecto y ayudar a corregir problemas. Extienden las técnicas que emplean en la toma de decisiones para incluir factores cuantitativos y mejoran sus análisis de causa raíz para que se considere el costo beneficio de las posibles alternativas. La gerencia de proyectos pasa de ser un arte con partes de ingeniería a ser una ciencia con partes de arte. El Capítulo 11 cierra el libro con los socios discutiendo sobre la compra de dos líneas de negocios por una mega empresa. Para que su historia no sea un caso único, el capítulo hace la contabilidad de los factores que 10 Capítulo 1
- 11. Boria et al. permitieron su éxito. Revisa entonces Lean, Kanban, Scrum, FDD y XP. También, y muy fundamentalmente, el rol del MPS como la herramienta de desarrollo organizacional que le permitió realizar este crecimiento en tiempo récord y con mínimos inconvenientes. Capítulo 1 11
- 12. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS CAPÍTULO 2 - EL MÉTODO DE MEJORA CONTINUA 2.1 Mejora de procesos Si estamos de acuerdo con la literatura existente y la experiencia personal de los autores, la mejora de procesos es la herramienta que permite a las organizaciones entenderse a sí mismas profundamente, yendo de un conocimiento intuitivo a uno cuantitativo, pasando por etapas intermedias que sirven tanto para mejorar los resultados como para apoyar los pasos siguientes. Una anécdota sirve para hacer clara la diferencia entre seguir procesos acordados por las partes y no seguirlos. Los procesos acordados por las partes cambian cuando las partes así lo deciden, mientras que no seguir procesos implica que no hay un patrón reconocible que ha sido pactado por los interesados. En una organización desarrolladora de software, Pedro, uno de los mejores programadores, era un ferviente defensor de los procesos. Rápidamente convenció a sus colegas de equipo de trabajo para que adoptaran procesos en la construcción de diversos documentos y, sobre todo, para definir la secuencia de pases y el criterio de finalización, basado en la calidad objetiva, de cada producto. Los proyectos en los que Pedro participaba eran exitosos con más frecuencia que todos los demás, y los clientes de los mismos elogiaban el producto generado. Finalmente las diferencias llegaron a los oídos de la dirección y nuestro joven programador fue recibiendo sucesivas promociones a cargos de cada vez mayor responsabilidad. No había pasado mucho tiempo cuando finalmente lo promovieron a jefe técnico de desarrollo. Convocó a sus hasta entonces colegas y les hizo ver que su promoción obedecía al reconocimiento que la alta gerencia hacía del trabajo que seguía procesos, por lo que esperaba que todos colaboraran con él para ampliar su utilización y contribuir a su mejora. Hubo muchas cabezas que asintieron y tras algunas preguntas y respuestas la reunión se dio por concluida. Solo Pablo, un programador, que hasta la llegada nuestro héroe era considerado el programador “estrella”, se quedó atrás. - “Pedro”, le dijo. “Yo estoy contento por tu nombramiento, pero tú sabes bien que yo no sigo procesos ajenos y siento que intentar que los demás entiendan mis procesos es una pérdida de tiempo, porque me sirven a mí y solo a mí. Espero que no lo tomes a mal, pero pienso seguir haciendo lo que hice siempre”. - “No esperaba otra cosa”, dijo Pedro. - “Qué suerte que lo tomes así, me da gusto”, contestó Pablo. Satisfecho, tomó sus notas y encaró para la puerta del salón. Pedro lo dejó alcanzar la puerta y lo detuvo: - “Eso sí, no fracases. Nunca fracases. Los que siguen procesos pueden tener problemas, porque los problemas nos enseñan qué partes del proceso hay que cambiar. Pero si tú no sigues procesos, los fracasos no nos enseñan nada y tú cargarás con toda la responsabilidad. Espero que no lo tomes a mal, pero es así como pienso seguir haciendo lo que hice siempre”. Los procesos que se siguen nos permiten identificar defectos tempranamente y detectar su origen. En cierto sentido, seguir un proceso es como comprar una póliza de seguros: uno no quiere que le pase nada de malo, pero invierte un poco para el caso en que algo malo ocurra. Lo mismo es con los procesos: Si todos tuviéramos memoria perfecta, no cometiéramos nunca errores y las especificaciones en lenguaje natural tuvieran un significado único e inamovible, entonces se relativizaría mucho la necesidad de seguir procesos. Todavía resultarían útiles para coordinar el trabajo, pero para personas con memoria total se podrían hacer procesos sumamente cortos. La realidad es bien otra: Los seres humanos erramos, olvidamos y malinterpretamos las comunicaciones en lenguaje natural. En consecuencia, la única manera de aprender como organización es capturar nuestros procesos para entender su funcionamiento (datos del proceso) y la calidad de los productos que generan. No todos los procesos son iguales. Hay procesos administrativos que no nos ocupan en este libro. Hay procesos extra-organización que tampoco nos interesan. Los procesos que queremos resaltar y mejorar son aquellos procesos vinculados con el desarrollo de software en las organizaciones. Aun así, es posible obtener más detalle de lo que plantearemos en este libro en otras fuentes. Los autores nos limitaremos a exhibir el comportamiento mínimo para organizar proyectos que produzcan sistemas de software de buena calidad. Las organizaciones que entienden sus procesos y les sacan provecho se dicen ‘maduras’. Una organización madura persigue sus objetivos con uso de ese conocimiento. Sabe lo que sus equipos son capaces de alcanzar y no hace promesas que no puede cumplir. Los equipos usan el conocimiento para adentrarse en el desarrollo con confianza en sus fuerzas y su capacidad de cumplir con sus compromisos. Las organizaciones inmaduras, entretanto, a veces cumplen con sus compromisos, pero muchas veces no. No conocen su capacidad y hacen promesas que nacen de su deseo de ganar el cliente. Lo que propondremos en este libro es un camino para llegar a 12 Capítulo 2
- 13. Boria et al. la excelencia madurando como organización usando métodos ágiles, para lo cual usaremos un caso de ejemplo y un modelo. Es el modelo MPS, en nuestro caso, aquél que orienta la secuencia de acciones en lo que hace al crecimiento de la madurez organizacional. El modelo MPS, que explicaremos con más detalle en el capítulo 4, es un modelo de desarrollo organizacional por niveles, que define los procesos que la organización debe implementar en su seno y los resultados esperados de ese accionar, para ir avanzando de nivel a nivel. Aun cuando es la intención de todos seguir el modelo, es imposible implementar todos los cientos de procesos a la vez, inclusive si nos restringimos a tomar los niveles de a uno, cosa por otra parte muy saludable, porque los hábitos que se construyen en uno se aplican en el que le sigue. Hay necesidad, por lo tanto, de encontrar un método que nos ayude a organizar el crecimiento en términos más concretos de lo que hace el MPS, y que a su vez se compadezca de las necesidades de la organización en cuánto a sus negocios. Como se puede imaginar el lector, no hay una única manera de hacer esto. Por ello, hemos decidido anticipar la presentación de un proceso del MPS, no en detalle, pero si mostrando su uso. Tomando prestadas técnicas del MPS en su proceso Gerencia de Desiciones (GDE), comenzaremos por definir el problema que intentamos resolver. Problema: Si bien en un marco ‘macro’ los niveles del MPS alcanzan para definir las pautas de la mejora continua, en cada caso es necesario atender a las necesidades de la organización que pretende mejorar sus 5 procesos, teniendo en cuenta el ‘negocio’ de la misma. Atributos deseables de una Solución: La solución debe de proveer un mecanismo de mejora continua que permita identificar cada paso sucesivo de un programa de mejora y este debe tener suficiente detalle como para que sea posible ejecutarlo sin demasiada ambigüedad, pero no tanto que implique una planificación detallada para cada selección (DETALLE). Debe proveer un marco teórico reconocible que ayude a medir el impacto de las decisiones sobre el sistema en conjunto, no solo la optimización local (MARCO). Debe permitir deducir las acciones derivadas que optimicen el sistema (SISTEMA). Debe retroalimentar el mecanismo que permita introducir mejoras a buen ritmo, sin que interfieran con el trabajo ni con el desarrollo personal de los empleados (NEGOCIOS). Estos atributos deseables constituyen los criterios bajo los cuales evaluaremos las alternativas de solución. El orden de su importancia relativa se muestra en la siguiente tabla: atributos peso NEGOCIO 5 DETALLE 4 SISTEMA 3 MARCO 2 suma Tabla 2.1: Selección del Método de Mejora de Procesos Alternativas de Solución: La literatura tiene muchos ejemplos de estos métodos. Los siguientes fueron incluidos en nuestro conjunto de soluciones: Plan-Do-Check-Act [SHEWHART, 1939], IDEAL [McFEELEY, 1996], Focus-Improve-Sustain-Honor [ARTHUR, 2004], y Lean Simplified [ARTHUR, 2006]. Método de Evaluación: Utilizaremos una matriz de Pugh [PUGH, 1991] para evaluar alternativas cuando los atributos son múltiples. Usado por Pugh en General Motors y descripto por él en su libro ya citado y previamente en un artículo [PUGH, 1981], es uno de los métodos de análisis de alternativas más difundidos entre ingenieros. Cada columna representa una solución y cada fila un atributo. Cada fila tiene un peso específico que representa el valor relativo de ese atributo frente a los otros. En cada intersección fila/columna se evalúa el aporte que la solución de esa columna hace al criterio de esa fila. Previamente se ha establecido un mecanismo de evaluación que permite ajustar la objetividad al respecto de la medición de cada atributo. 5 La referencia a un negocio está entre comillas porque se trata de los motivos de existencia de la organización. Si esa organización es un hospital público que mide su impacto en la comunidad en la cantidad de curaciones que realiza o el estado general de salud de la población que atiende, entonces a esos efectos ese es su ‘negocio’. No se debe entender como que solo aplica a organizaciones con fines de lucro. Capítulo 2 13
- 14. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS Criterios de Evaluación por Atributo: DETALLE es medible como 3 (detalle adecuado), 2 (detalle un poco excesivo o no suficiente), 1 (detalle bastante excesivo, algo así como treinta páginas para entenderlo, o muy superficial, algo que permite muchas interpretaciones) o 0 (no tiene ninguna explicación clara asociada). MARCO se mide como 3 (se reconoce en el sistema qué otras cosas hay que atender), 2 (no se analiza el sistema de manera total, pero es bastante comprehensivo), 1 (hay algunas pistas para analizar acciones derivadas) o 0 (no se apoya para nada al cambio sistémico. SISTEMA se mide como 3 (las acciones derivadas que impactan al sistemas se reconocen mediante el método), 2 (hay una visión periférica pero el foco de las acciones es idéntico al foco de la mejora), 1 (se evalúan resultados globales a nivel sistema aunque no se los prevea en el análisis de impacto), o 0 (ninguna actividad relacionada con el efecto global forma parte del método). NEGOCIOS se mide como 3 (cuando se enfoca sobre todo en las necesidades del cliente como punto de partida), 2 (hay un alineamiento con el negocio pero es externo al método), 1 (se puede alinear al negocio pero el método es agnóstico y no lo menciona) o 0 (no hay ninguna relación evidente entre el método y el negocio). Describiremos ahora las cuatro opciones, tratando de que el lector mismo pueda juzgar la calificación de cada una con respecto a cada atributo. 2.2 Plan-Do-Check-Act Plan-Do-Check-Act (PDCA) es original de [SHEWHART, 1939], y difundido sobre todo por Deming en varias 6 ocasiones . Deming se refería a este procedimiento basado en el método científico como el ‘Ciclo de Shewhart’. La posteridad lo recuerda a menudo como el ‘Ciclo de Deming’, una de las consecuencias de la notoriedad de este que es todavía mayor que la de aquél. Hacia el final de su vida Deming cambió el “Check” (validar) por “Study” (estudiar) para enfatizar que el paso debe ser de análisis más que de inspección. Puede justificadamente considerarse a Shewhart como el padre de la calidad industrial. Fue él quien introdujo los diagramas de control estadístico para el análisis de la estabilidad de un proceso a través de la medición de un atributo. Dada su fecha de origen, es difícil encontrar el material original, pero en la mayoría de las 7 citas el primer paso es identificar el problema y luego analizarlo. No hay una mención explícita de los objetivos de negocios, aunque es difícil imaginar que Shewhart los haya eludido, leyendo sus otros materiales. Posiblemente se ha sacado (una vez más) del contexto al método y al hacerlo se perdió parte de su valor sistémico. Por lo tanto, sin juzgar al método en sí pero si juzgando su uso habitual, podemos decir que PDCA es sencillo, fácil de aplicar pero es factible de ser usado sin tener en cuenta el impacto en el negocio. Hay en varias versiones del método referencias a un proceso desarrollado por Deming para la mejora continua, lo que daría una mejor versión sistémica del mismo, así como un posible vínculo con los objetivos de negocios. A continuación describimos los pasos de PDCA. PLAN (Planificar) Paso 1: Identificar el Problema. Actividades: Seleccionar el problema a ser analizado; definir claramente el problema y redactar un enunciado preciso del mismo; fijar un objetivo medible para el esfuerzo de resolución del problema; establecer un proceso para la coordinación con, y conseguir la aprobación de, la alta dirección. PLAN (Planificar) Paso 2: Analizar el Problema. Actividades: Identificar los procesos que impactan en el problema y elegir uno; listar los pasos del proceso tal como se ejecutan en este momento; construir un mapa del proceso; validar el mapa del proceso; identificar posibles causas del problema; juntar y analizar datos relacionados con el problema; verificar o revisar el enunciado original del problema; identificar las causas raíces del problema; juntar datos adicionales si es necesario para verificar las causas raíces DO (Hacer) Paso 3: Desarrollar Soluciones. Actividades: Establecer criterios para elegir una solución; generar soluciones potenciales que ataquen las causas raíces del problema; elegir una solución; conseguir aprobación y soporte para la solución escogida; planificar la solución. DO (Hacer) Paso 4: Implementar la Solución. Actividades: Implementar la solución escogida en un piloto o ensayo. Si el proceso PDCA está siendo utilizado dentro del Proceso de Mejora Continua, pasar al Paso 6 de ese proceso. Si se lo está utilizando por separado, continuar con el Paso 5. CHECK (Verificar) Paso 5: Evaluar los Resultados. Actividades: Juntar datos de la solución; analizar los datos. ¿Se alcanzó el objetivo buscado? Si es así, pasar al Paso 6. Si no es así, volver al Paso 1. 6 7 El libro [SHEWHART W., 1939] fue compilado por Deming con un prefacio de su autoría. Véase por ejemplo http://quality.enr.state.nc.us/tools/pdca.htm 14 Capítulo 2
- 15. Boria et al. ACT (Actuar) Paso 6: Estandarizar la Solución (y Capitalizar Nuevas Oportunidades). Actividades: Identificar cambios sistémicos y necesidades de entrenamiento necesarias para un implementación completa; adoptar la solución; planificar y monitorear permanentemente la solución; continuar buscando oportunidades incrementales para refinar la solución; buscar nuevas oportunidades de mejora. El método PDCA es sólido, pero su edad ha hecho que varios de los detalles que su autor predicaba hayan sido dejados de lado en su implementación corriente, que es lo que un buen evaluador juzga: Su uso por encima de su definición. Eso no quita que para el lector avisado los pasos de PDCA no sigan teniendo utilidad. De hecho, como veremos en lo que sigue, el ciclo de Shewhart sigue siendo utilizado en diferentes variantes. Tampoco es frecuente que los usuarios de PDCA lo coloquen en el marco adecuado, simplemente es utilizado como un ciclo cuya repetición produce los resultados esperados. Recordemos que para Shewhart, y en consecuencia para Deming, hay un proceso de mejora continua en el que PDCA encaja. De otra manera se pierde parte de su impacto. Es en ese proceso marco que varias de las iniciativas sistémicas y el vínculo con los objetivos de negocios están inmersos, de modo que cambiar ese proceso como fuera definido y colocar otro en su lugar puede tener como consecuencia la pérdida de ese entorno y en consecuencia la desmejora del proceso de mejora. Veamos ahora como McFeeley lidia con ese problema, incorporando a su método el detalle necesario (en exceso, según nuestro punto de vista). 2.3 El Método IDEAL Debido a la enorme influencia que Deming, y en consecuencia Shewhart, a quién aquél citaba constantemente, tienen sobre la comunidad de mejora de procesos, este método y los que describiremos más tarde están fuertemente influenciados por PDCA. La Figura 2.1 muestra una descripción gráfica del método IDEAL. Tiene cinco fases que se corresponden con etapas importantes de una iniciativa de mejora de procesos. Puesto que la mejora es continua, se espera que se continúe el ciclo una vez alcanzada la 5ª fase. Si bien el autor de IDEAL [McFEELEY, 1996] aclara que los límites entre fases son más borrosos que los que se describe en la referencia, es usual que las recomendaciones de éste no se sigan y se ejecute como una secuencia de actividades en un proyecto, así como otras desviaciones de alto impacto. Figura 2.1: El Método IDEAL [McFEELEY, 1996] La primera fase se denomina, con lógica, ‘Initiating,’ que traducido quiere decir Comenzando. Tiene tres bloques, pero en la descripción detallada no se las considera, siendo descriptas en cambio 10 tareas que se detallan, algunas hasta el nivel de subtareas. La misma situación de desacople entre la gráfica y la descripción textual se repite para todas las fases. La fase ‘Initiating’ culmina cuando la infraestructura para la mejora de procesos se ha construido, se han vinculado los objetivos de negocios al programa de mejoras de proceso, hay un sistema de recompensas alineado con las mejoras y un plan inicial para el proyecto de mejoras, que contiene el plan de comunicación de los avances. La fase que sigue se denomina ‘Diagnosing’ y tiene seis tareas. Se traduce fácilmente, dada la similitud de los vocablos, por Diagnosticando. En efecto, es la fase en la que se realiza el análisis de la brecha existente entre las Capítulo 2 15
- 16. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS necesidades de proceso y los procesos en uso, tal como se usan. El criterio de entrada de la fase no coincide totalmente con el criterio de salida de la primera fase, por lo que es difícil entender como se consigue llegar a su ejecución. La fase tiene como criterio de finalización que se hayan entregado las brechas halladas y las recomendaciones al comité de gestión y hayan sido aceptado, así como que ya haya un boceto del plan estratégico de acción. La tercera fase de IDEAL se denomina ‘Establishing’, que quiere decir Estableciendo, pero se refiere acá al plan y no a los procesos. Si bien es confuso, da una linda sigla (IDEAL) que un nombre más lógico (Planificar, o Detallar) no conformaría. En esta fase se ajustan prioridades y se forman los equipos que llevarán adelante la definición y difusión de los cambios y mejoras a los procesos. Notablemente, el método recomienda que la planificación la realice el comité de gestión, es decir los gerentes que realizan la supervisión estratégica del plan de mejoras, y no el grupo de procesos. Este excelente consejo es ignorado en la práctica. La fase tiene 14 actividades. El criterio de finalización es que el plan estratégico se haya completado y aprobado, y que la visión organizacional, el plan de negocios y el plan estratégico de mejora de procesos tengan sinergia entre sí. La fase que sigue se denomina ‘Acting,’ que se traduce por Actuando. Esta fase es la más interesante, aunque el modelo tiene muchas componentes útiles, porque ésta enfoca muy directamente en el negocio. Es cuando las mejoras se identifican, construyen, despliegan y se ponen práctica. Tiene diez pasos, de los cuales destacaremos una subtarea del paso 2, Desarrollar Soluciones: Analizar y Arreglar el Problema. Nos interesa porque en muchas formas anticipa y se parece a Lean, en que el planteamiento es puramente enfocado en el dolor y no en la mejora de procesos en sí. Se modifican procesos porque los procesos actuales toleran defectos y demoras que no se deben tolerar, se ataca sus causas, pero se enfoca en los síntomas. Esta fase tiene como criterio de éxito que la estrategia de despliegue y el plan se han ejecutado plenamente, o están en camino de serlo. Las soluciones que se han adoptado (o piloteado) se han documentado correctamente y están bajo control del grupo de procesos, y se tiene claro cómo se las va a mantener. La mejora de procesos ha comenzado a estar institucionalizada en la organización. Esta fase hace referencia a muchas pequeñas mejoras realizadas en paralelo, bajo un único plan estratégico y múltiples planes tácticos. Sin embargo, la gran mayoría de las implementaciones de IDEAL adolecen del mismo defecto: Un enorme plan táctico que nunca termina de ejecutarse y que sufre del síndrome del correo: las cartas (pedidos de nuevos cambios) siguen llegando y la tarea de planificar nunca se concluye. La fase final, o si se quiere la que inicia una nueva iteración del ciclo IDEAL, se denomina ‘Leveraging’, que significa Aprovechando, o Sacando Provecho, en realidad es la variante de la primera fase, puesto que tendría poco sentido empezar de nuevo sin tener en cuenta lo que ya se avanzó. Se denomina así porque ante la alta gerencia se afirma el auspicio mediante la muestra del avance. Cuando las organizaciones caen en los errores que marcamos antes, el resultado es que el proyecto de mejoras tiene poco que mostrar. El ejemplo más común es que se definen soluciones pero no se las implementa ni en pilotos, lo que se justifica por el síndrome del correo: ya que se han aceptado nuevos pedidos de cambio, el grupo de mejoras se enfocará en la definición de soluciones y no en su implementación. Como consecuencia una larga lista de cambios es lanzada simultáneamente sin suficiente preparación, por la demanda de capacitación que eso conlleva, y el proyecto fracasa. IDEAL no es un mal método, pero es muy detallado (se describe en un documento de 236 páginas) lo que hace que mucha gente lo haya 8 implementado sin haber leído esos detalles con la consiguiente pérdida de varios elementos fundamentales, 9 como el vínculo con los objetivos de negocios, el paralelismo en la implementación y la visión sistémica (multicausal, con lazos de retroalimentación y demoras entre causa y efecto visible) que son indispensables para establecer un programa de mejora continua. Lo mejor de IDEAL es su visión de la mejora de procesos (Figura 2.2) basada en los objetivos de la organización y soportada en la visibilidad del proyecto, la comunicación horizontal y vertical entre las partes, la captura, retención y aprovechamiento de la experiencia (lecciones aprendidas), y una red de soporte de todo el proyecto. De ese modo se sostiene el plan táctico y el estratégico para culminarlos con éxito. 8 9 Si el lector no se siente cómodo con la afirmación de que un número muy grande de personas no lee los detalles antes de implementar un modelo, los autores querrían remitirlo al trabajo de Royce, Managing the Development of Large Software Systems [ROYCE, W., 1970], a quién se considera el padre del ciclo de vida en cascada por ese mismo artículo, y que lamentablemente está mal citado: Lo que Royce dice en ese trabajo es que esa visión del proceso de desarrollo es infantil y llena de problemas. Los usuarios de IDEAL tienden a desarrollar un proyecto secuencial con muchas iniciativas que demoran la fase de aplicación, una de las maneras de resistir el cambio. 16 Capítulo 2
- 17. Boria et al. Figura 2.2: Visión de Mejora de Procesos de IDEAL [McFEELEY, 1996] 2.4 Focus-Improve-Sustain-Honor Focus-Improve-Sustain-Honor (FISH) de [ARTHUR, 2004] es una variante más de PDCA, con énfasis en las 10. herramientas de Six-Sigma El ciclo de Arthur se basa en la medición. El uso de los datos disponibles y la búsqueda tipo “inteligencia de negocios” es el fundamento del análisis, en vez de los defectos o la brecha respecto de algún ideal. Esto por supuesto no está contra los preceptos de PDCA, pero si influye mucho en el impacto que tiene cada uno, porque en FISH es indispensable comenzar por el análisis de los datos antes de entrar en el ciclo. El ciclo tiene cuatro fases, Focus, enfocar, la primera, está basado en un hecho estadísticamente demostrable por la distribución de los defectos: Unos pocos procesos son responsables de la mayoría de los mismos. Encontrar esas “fábricas de defectos” enfoca el proceso de mejora en donde más rendimiento tiene. Para Arthur, la 11 aplicación de la ley de Pareto predice grandes ganancias. Su razonamiento es que si el 80% de los defectos son producidos por el 20% de los procesos, volviendo a aplicar la regla se tiene que el 64% (80% del 80%) de los defectos proviene del 4% (20% del 20%) de los procesos. De ese modo un minúsculo grupo de procesos permite eliminar un número sumamente grande de defectos, de donde enfocar es necesario. La segunda fase, Improve, mejorar, es donde el defecto encontrado se elimina. Esta es la fase donde se identifican las causas profundas, se eligen las soluciones posibles y se define y lleva adelante su implementación. El MPS (ver el Capítulo 4) contiene resultados esperados de procesos que ayudan a entender la implementación de los pasos de mejora por identificación de las causas raíces. Utilizaremos a lo largo del libro esta capacidad de 12 identificar las causas de las cosas para poder mejorarlas o difundirlas . Utilizar el análisis de causa raíz de forma sistemática es una de las herramientas más poderosas de la mejora de proceso, y una de las tres herramientas intelectuales (junto con el análisis y gestión de riesgos y la visión sistémica del proceso) que más rendimiento tienen en los procesos intelectuales que acompañan, o deben acompañar, a la mejora de procesos. La tercera fase, Sustain, sostener, es donde la mejora se intenta consolidar y mantener, para lo cual Arthur propone utilizar herramientas de “conocimiento profundo” como fueran introducidas por Shewhart y difundidas por Deming. Para comenzar, Arthur indica desarrollar el mapa del proceso, utilizando siempre herramientas 10 11 12 Six Sigma es una estrategia de gestión originada en Motorola en 1986 SPC and TQM in Manufacturing and Services [TENNANT, G., 2001] y usada mundialmente. Trata de mejorar la calidad de los resultados de los procesos identificando y eliminando las causas de los defectos. Utiliza una variedad de métodos, fundamentalmente estadísticos. El término surgió del análisis estadístico de la ocurrencia de defectos en manufactura. La madurez de un proceso de fabricación puede expresarse como la cantidad de desvíos estándar () que se aleja de la media de la población total, o por el porcentaje de piezas sin defectos que produce. Un proceso seis es uno que produce 99.99966% de las piezas sin defectos, que fue el objetivo fijado por Motorola y que dio nombre a los métodos que se conjuntaron en un proceso para alcanzarlo. Pareto fue un estadígrafo francés del siglo XX que se destacó en el estudio de la distribución de la renta. En 1906 él hizo la famosa observación de que el veinte por ciento de la población poseía el ochenta por ciento de la propiedad en Italia, posteriormente generalizada por Joseph M. Juran en el principio de Pareto (también conocida como la regla del 80-20). Si el evento es un problema o un defecto, intentaremos ubicar su origen para desterrarlo, pero si el evento es un resultado positivo no planificado, intentaremos entender qué lo provocó para reproducirlo en otros ambientes. Capítulo 2 17
- 18. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS simples. En todos los casos, Arthur se inclina por la simplicidad, dedicándole tiempo al proceso intelectual y utilizando la herramienta que mejor se adapta al menor costo de aprendizaje posible. Por ejemplo, en este caso 13 sugiere utilizar un diagrama de flujo, siendo que hay otras herramientas posibles que son más poderosas e igualmente difundidas. Para poder afirmar que los resultados se han alcanzado es necesario saber que el proceso está normalizado, porque si no es así es imposible establecer comparaciones. Supongamos que el problema es que una receta culinaria viene dando resultados desparejos. Al analizar la causa profunda nos damos cuenta que diferentes cocineros le dan diferente interpretación a las instrucciones y que algunos pasos están faltando, porque el autor de la receta asumió que los que la intentarían ejecutar tenían conocimientos culinarios en grado suficiente, lo que no resultó una predicción verdadera. Además, hay un error en la receta que sugiere usar un tipo de harina que no es el correcto, digamos que dice “harina” a secas, que en el contexto de los cocineros que tienen problemas con la receta se entiende por “harina de trigo,” cuando el que diseñó la receta quería que fuera “harina de maíz”. El análisis de causa ha detectado estos defectos y se ha sugerido que se hagan cambios a la receta, definiendo con precisión los pasos para que no haya diferentes interpretaciones, y corrigiendo los errores y ambigüedades. Un grupo de procesos sin la suficiente experiencia consideraría que ha cumplido su cometido: El proceso, de ejecutarse correctamente, “debería” funcionar. Jay Arthur (y los autores) no se conforman con esa definición, incompleta, de la responsabilidad del grupo de proceso: ¿Y si no funciona? Lamentablemente la resultante en esos casos es que el grupo de procesos le arroja la responsabilidad a los que debiendo ejecutar correctamente el proceso no lo hacen, sin constatar que, necesariamente, son ellos y no los cambios los que llevan a perpetuar el problema o introducir otros nuevos. Por lo tanto, ‘sostener’ implica medir y analizar los resultados. Esto lleva a tener que entender cuándo, dónde y qué medir. Uno de los pasos más importantes en la definición de procesos y el cambio para la mejora es identificar los procesos clave y los atributos a medir. Esta capacidad es exigida por el MPS en los niveles más altos de madurez, a partir del Nivel B, pero es una de las cualidades más valiosas de un gerente. Por ejemplo, si nos preocupa que la mayoría de los proyectos termina después de su fecha de entrega y hemos hecho cambios en consecuencia para adelantar la producción de resultados, medir las demoras que se producen en aquellos puntos es de suma importancia. Medir solo el resultado final, el desvío en la fecha de entrega, es solo parcialmente útil porque una vez que hemos entregado tarde no se puede modificar el resultado. Arthur introduce acá herramientas de 6 que el MPS no requiere sino hasta el Nivel B, como ya hemos dicho, y por lo tanto complica un poco más de lo necesario el análisis de resultados. La última fase del ciclo es Honor, honrar. Arthur se refiere acá a la necesidad de respetar y premiar los compromisos con el cambio, con la mejora (no todo cambio es una mejora, pero toda mejora es un cambio). Gran parte del mensaje sobre la mejora de procesos está contenido en la manera que la organización resalta y recompensa los esfuerzos de su personal en relación a los cambios y las mejoras. Es importante destacar que no todos los intentos de mejora, sobre todo en las etapas tempranas del proceso de mejora continua, han de resultar igualmente exitosos. Algunos serán hasta negativos, pero es indispensable rescatarlos como esfuerzos válidos porque la organización aprende. 2.5 Lean Simplified El último método es Lean Simplified [ARTHUR, 2006]. Jay Arthur desarrolló ese método como una extensión de su anterior FISH que vimos más arriba con el propósito de hacer más clara la aplicación del mismo, enfatizando la cadena de valor que lleva desde el pedido del cliente a su satisfacción por la entrega del producto. La palabra inglesa Lean significa delgado, sin peso demás. Arthur elige llamarlo Simplified, simplificado, porque ha reducido la demanda estadística que su método FISH tiene. Llamaremos a este método LS, para evitar usar términos en inglés. LS, como lo explica Jay Arthur en [ARTHUR, 2006] es un método para la empresa manufacturera. Sin embargo, modificando o dejando de lado lo que no aplica para el desarrollo de software, es un método poderoso para identificar y resolver problemas con vista a la mejora continua. Presentamos acá nuestra versión de LS adaptada a la producción de software. 13 18 Los diagramas SADT, o IDEF0 en su versión norma internacional, son más detallados y de uso difundido. También los diagramas de flujo con andariveles que permiten discernir responsabilidades. Asimismo sería posible diseñar el proceso siguiendo técnicas de flujo de datos del Análisis Estructurado o con herramientas de UML. Capítulo 2
- 19. Boria et al. 14 En el corazón de LS está el tema de la velocidad de producción . La velocidad no es apuro, es hacerlo mejor y sin interrupciones, no es trabajar los fines de semana o hasta altas horas de la noche. La velocidad es productividad puesta al servicio del producto. En un mundo conectado globalmente por la Internet los clientes esperan servicios casi inmediatos sin pérdida de calidad ni aumento de los precios. El libro de [RODIN, 2010] es una visión de cómo la demanda por servicios gratuitos entregados en el momento y sin costo alguno está revolucionando los negocios. Para las organizaciones que fabrican software el desafío está lanzado: Hay que eliminar los defectos y todas las demoras para entregar más que a tiempo y con bajos costos. Las demoras no son justificables. El producto de software puede ser único e irrepetible, pero los procesos por los cuáles se lo produce no lo son. Cada proyecto se compone de las mismas fases, que realizan las mismas actividades. La resistencia a ese concepto es notable en empresas de baja madurez, y sin embargo vemos una y otra vez que la resistencia a hacer las cosas de otra manera es tan arraigada como la necesidad de sostener que siempre son diferentes. Lo único que se demora en cambiar es la creencia de que la organización está justificada en actuar como lo hace. En cada empresa hay dos fábricas, la principal que diseña, vende, factura y entrega el producto, cuya fórmula es Velocidad con Calidad + Ganancias = Beneficio. La segunda es la fábrica de arreglos, que corrige todos los errores que se van cometiendo a medida que se diseña, vende y factura el producto. Hay siempre una fábrica de arreglos visible que se mide y se controla, pero hay otra que es oculta que hace que los errores se corrijan sin que haya atribución ni contabilización. Esa fábrica tiene otra fórmula: Defectos + Demoras = Pérdidas. En el fondo, LS se centra en la velocidad de producción. La relación entre las etapas de un proceso es fundamental. Las etapas y actividades que no agregan valor deben ser eliminadas del proceso. Por eso la primera actividad en LS es hacer un mapa de la “cadena de valor”, la secuencia de actividades que van desde la recepción 15 del pedido del cliente a la satisfacción de sus necesidades . Una vez más, el mapa tiene que ser sencillo, pero no tanto que resulte fácil de malinterpretar. Además, puesto que se trata de un sistema de tracción donde la salida fuerza al proceso anterior y así sucesivamente, este método atiende principalmente la voz del cliente. Hecho correctamente, esto genera valor para el cliente y en consecuencia, la organización. Foco en los Defectos Al intentar reducir la “fricción” que demora los procesos, Toyota descubrió que hay muchas formas de desperdicio (“muda”). 1. 2. 3. 4. 5. 6. 7. Exceso de producción (en software, incluir código que no fue solicitado “por si lo vamos a necesitar”) Inventario excesivo (en software, los procesos que se generan alrededor de la funcionalidad no requerida, como testeo extra, volumen de manuales, etc.) Esperas (en software se manifiesta en particular cuando hay que esperar por otro rol a que el personal esté disponible, o las instalaciones, o cuando el cliente tiene que dar respuesta) Movimientos innecesarios del producto (en software la ubicuidad de los productos en formato electrónico hace de esto un problema inexistente, pero si se mantienen planos en papel o en pizarrones puede llegar a ocurrir) Movimientos innecesarios del personal (típicamente en la instalación o en la validación, a menudo en la etapa de generar requisitos) Procesamiento innecesario o inadecuado (no es muy común, pero en ciertas organizaciones burocráticas hay ocurrencias de esto) Defectos que obligan a reparaciones y retrabajo (no hay porqué explicar esto en nuestra profesión) Si la organización trabaja con plazos cortos y se concentra em mantener la flexibilidad se obtienen beneficios en calidad y satisfacción del cliente. En el capítulo 3 veremos cómo un grupo de desarrolladores de software 14 15 La empresa Toyota inventó el método de "producción esbelta" (lean production) tomando como referencia los supermercados de los EEUU, donde percibieron que cuando los anaqueles de los supermercados alcanzan el punto mínimo del inventario son reabastecidas tan rápidamente como los clientes "quitan" los productos de la góndola. En un sistema de tracción, el proceso anterior debe siempre hacer lo que el proceso subsecuente le pide. Para ver que el stock está bajo y, como consecuencia, reponerlo, se coloca una tarjeta que señala el punto exacto. El nombre en japonés de esa tarjeta es Kanban, palabra que hoy identifica tanto a la tarjeta como al sistema. No es lo mismo oír y reaccionar que escuchar y satisfacer. Capítulo 2 19
- 20. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS construyó métodos que permiten aprovecharse de estos conocimientos. El movimiento que iniciaron se conoce 16 como el Agile Manifesto y ha marcado como se desarrolla software desde su aparición. LS sigue con la organización del trabajo para eliminar el desperdicio. Son cinco las tareas a realizar: Sort, ordenar; Straighten, enderezar; Shine, pulir; Standardize, estandarizar; y Sustain, mantener.. Nosotros damos aquí 17 nuestra interpretación de esas tareas en actividades de ingeniería de software . Ordenar significa decidir qué es útil y qué no lo es y eliminarlo. Esto es la tarea de las personas o roles que identifican las mejoras de proceso. A menudo los pedidos de cambio de procesos se originan en los equipos, y un rol en particular, llamado afirmación o aseguramiento de la calidad es quien debiera detectar la necesidad del cambio y transmitirla. Enderezar es colocar cada cosa en su lugar y tener un lugar para cada cosa. Ese es el rol de la gestión de configuración en la ingeniería de software. Pulir es mantener el área limpia para exponer defectos y pérdidas. En software esto se manifiesta en la aplicación de formas y patrones que permiten el análisis y la inspección por terceros, por ejemplo el uso de estándares de programación que ayudan a leer un programa. Estandarizar es definir sistemas, procesos y procedimientos que ayuden a mantener las tres reglas anteriores. Este es nuevamente el rol del área de mejora de procesos. Mantener, por último, es conseguir que el flujo de trabajo sea estable y se respeten las reglas. Entre el área de mejora de procesos y el grupo de afirmación de calidad esto debiera ser alcanzable. Otra de las normas que rigen LS es la preminencia de la demanda por sobre la producción. En vez de producir en anticipación de lo que se demandará se produce a partir de lo que se pide. En nuestra traducción al mundo de procesos esto significa que no intentaremos mejorar lo que no se siente que está roto. El vocablo inglés “pull” que significa halar, tirar, representa este pensamiento, contra el vocablo inglés “push” que significa empujar. Es común en la disciplina de mejora de procesos que se intente ‘empujar’ mejoras desde el centro hacia afuera, o desde arriba hacia abajo. En nuestra experiencia la resistencia así creada demanda mucho esfuerzo y no justifica el retorno de la inversión. Por el contrario, un enfoque de ‘halar’ hace que el cambio se vea como algo positivo ya que, efectivamente, resuelve un problema. Cuando una mejora de procesos se percibe como una eliminación de un obstáculo a la productividad se gana un aliado para los futuros cambios, que además cuenta ahora con tiempo extra para apoyar la creación y difusión de nuevos cambios. LS tiene más para aportar, pero en lo esencial nos alcanza con lo expuesto para entender las ventajas y desventajas del método. Nuestra matriz de Pugh para los cuatro métodos queda así: atributos peso PDCA IDEAL FISH LS NEGOCIO 5 1 3 3 3 DETALLE 4 1 1 2 3 SISTEMA 3 2 1 1 3 MARCO 2 2 0 0 3 19 22 26 42 suma Tabla 2.2: Selección del Método de Mejora de Procesos Con estos valores es claro que nos inclinamos por LS. Por supuesto, se puede criticar esta decisión, porque los valores colocados en la intersección son arbitrarios hasta cierto punto. En una decisión de mayor impacto económico sería deseable que la puntuación estuviera mejor detallada para lograr mayor objetividad. Puesto que vamos a utilizar LS en nuestros análisis y nuestras propuestas para la empresa que hemos tomado como caso de ejemplo, es bueno resaltar algunos valores y creencias que se asocian con LS. 1. 2. 3. 4. 5. 16 17 El proceso exacto producirá los resultados exactos. Desarrollar al personal y a los proveedores agrega valor. La resolución continua de problemas raíces conduce al aprendizaje organizacional. El flujo de una pieza aumenta la productividad, el lucro y la calidad. A los productos no les gusta hacer fila esperando atención. Los materiales, piezas y productos son impacientes. http://www.agilemanifesto.org/ Remitimos al el lector interesado en las definiciones originales en manufactura al sitio http://es.wikipedia.org/wiki/5S 20 Capítulo 2
- 21. Boria et al. 6. 7. 8. Lo único que agrega valor en un proceso es la transformación física o informacional de la materia-prima en algo que el cliente quiere. Los errores son oportunidades para el aprendizaje. La resolución de problemas es un 20% de herramientas y un 80% de aplicar la inteligencia. Nuestro enfoque de mejora de procesos va a adoptar muchas de estas máximas, en lo que aplican a las áreas de desarrollo de software. No vamos a limitarnos a seguir al modelo MPS en su aplicación, vamos a procurar identificar y resolver los problemas que son comunes en las empresas desarrolladoras de software. Capítulo 2 21
- 22. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS CAPÍTULO 3 - LOS MÉTODOS ÁGILES: KANBAN, SCRUM, XP Y FDD 3.1 ¿Qué son los métodos ágiles? En el capítulo anterior presentamos la mejora continua de procesos y decidimos tomar como referente a LS. Las ventajas de un método liviano, desprovisto de burocracia, que enfoca directamente en las necesidades de negocio no pasaron desapercibidas para los “metodólogos” de Ingeniería de Software. Ya en el siglo pasado habían nacido varios métodos de desarrollo que se apoyaban en las ideas de producción de Toyota, notablemente Extreme Programming [BECK, 2000], Scrum [SCHWABER, 2002], DSDM [STAPLETON, 1997], Adaptive Software Development [HIGHSMITH, 1999], Crystal [COCKBURN, 2005], Feature-Driven Development [COAD, 1999], Pragmatic Programming [HUNT, 1999] y otros más. En un intento de encontrar formas comunes se reunieron diecisiete de estos creadores en Febrero del 2001 en un centro de esquí en Utah. Lo que surgió fue un manifiesto 18 que marcó la ingeniería de software de modo único, el Agile Software Development Manifesto . El contenido del manifiesto se puede leer en línea, pero consideramos que su influencia es tan importante, y sus coincidencias con el método de Toyota TPS son tantas que lo incluimos acá. Manifiesto para el Desarrollo de Software Ágil Estamos descubriendo mejores métodos para desarrollar software ejercitándolos y ayudando a otros a usarlos. A través de este devenir apreciamos: Los individuos y las interacciones por sobre los procesos y las herramientas Software que funciona por sobre una documentación completa Colaboración con el cliente por sobre la negociación del contrato Responder a cambios por sobre seguir un plan Es decir, aunque hay valor en los ítems de la derecha, valoramos los ítems de la izquierda aun más. (firman) Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. © 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. Aunque el manifiesto describe las ideas más básicas, hay entre los autores más acuerdos que los allí expuestos. Muchas de las coincidencias provienen de la misma fuente: El foco en la calidad, con las reglas de Toyota que mencionáramos ya en el capítulo anterior en la sección “Foco en los Defectos”. Así como Toyota tiene su método TPS que es una forma de “Kaizen”, los métodos ágiles se apoyan en períodos de producción cortos y mucha colaboración dentro del equipo de proyecto, apoyado en la sinergia que genera el trabajo en equipo de la estructura formada para alcanzar las metas establecidas por la dirección de la compañía. En gran parte, su popularidad entre el personal de desarrollo se deriva de la independencia que los equipos sienten al tomar sus decisiones en conjunto y en alto grado libres de las redes burocráticas que se tejen en las grandes empresas, lo que trae consigo resultados concretos, tanto cualitativos como cuantitativos. Al dejar que el equipo de trabajo tome las decisiones para el próximo período de trabajo, llamado en la jerga 19 20 de los agilistas un “Sprint” , los métodos ágiles consiguen motivar al personal de los proyectos y comprometerlos con el resultado al permitirles tomar decisiones de peso. Dada la corta duración de un Sprint, usualmente nunca más de cuatro semanas, los equipos pueden ver sus resultados de inmediato. También es importante la participación del cliente. Junto con un representante del cliente que esté comprometido a su vez con 18 19 http://agilemanifesto.org/ Usaremos este neologismo para designar a aquellos que adhieren a los métodos ágiles y los practican. 20 22 Los diccionarios definen ‘Sprint’ como la mayor velocidad alcanzada por un corredor en una carrera, especialmente en el final. Las carreras de hasta 200 metros se consideran todas Sprints, de principio a fin. Por analogía, cada tramo de un proyecto ágil se considera un Sprint. Capítulo 3
- 23. Boria et al. el resultado, se define el alcance de cada Sprint. Es un deber de los equipos ágiles definir una parte del producto que en sí misma tenga valor para la organización del cliente. De ese modo el producto parcial es concreto y mantiene la concentración y el foco en el negocio. Los métodos ágiles nacieron como respuesta a las burocracias que ignoran las particularidades del desarrollo de software y en su ignorancia presionan a los equipos a llevar adelante proyectos con compromisos irracionales realizados por los que no saben. Al poner metas cortas y priorizar la participación del cliente en las decisiones de negocio, además de poner un freno concreto a los cambios caprichosos, los métodos ágiles rescatan el valor de la ingeniería de software ante los embates burocráticos de ciertos niveles en las corporaciones. Entre otras virtudes, la decisión por el equipo es visible para todos, DEBE ser visible para todos. En consecuencia la transparencia de los proyectos ágiles es uno de sus atributos más valiosos y más revolucionarios. Los agilistas se consideran un movimiento pro-métodos. Los que creen que la agilidad es contraria a los procesos y las herramientas, a la documentación o los planes se equivocan. Lo que buscan es que estas entidades estén al servicio de las actividades del equipo y no a la inversa. Si el lector cree que ser ágil es no planificar, no seguir procesos por ligeros que estos sean, no tener más herramientas que el ambiente de desarrollo interactivo y un par de lenguajes, no documentar las decisiones, se equivoca de plano. El que así piensa es un hacker, no un agilista. Los agilistas piensan que la planificación de detalle no puede llevar más que unas pocas horas y debe involucrar al equipo, que los procesos son flexibles pero deben de ser acordados por los que los llevan a la práctica, que la documentación debe ser fácil de mantener y responder a una necesidad orgánica del proyecto y debe ser hecha cuando esa necesidad se manifiesta y no como una condición contractual después de que el producto se haya concluido. En cuanto a herramientas, baste recordar que la integración continua, uno de los baluartes de los métodos ágiles, requiere excelentes herramientas de gestión de configuración con testeo integrado por lo tanto es claro que los agilistas trabajan en pro de la eficiencia y no en contra de la misma. 21,22 Los cuatro métodos ágiles que encontramos más útiles en diferentes etapas de una empresa son Kanban , 23 24 25 Scrum , XP y FDD . El orden en que los describiremos va del más sencillo (Kanban) al más complejo (FDD). Scrum y XP se apoyan en Kanban y en particular describiremos XP en su versión XBREED, que mezcla los conceptos de XP con las prácticas de Scrum para obtener un proceso más sólido y confiable. 3.2 Kanban: Midiendo el flujo Quién introdujera Kanban como método ágil fue [ANDERSON, 2011]. El método Kanban es parte de una familia de sistemas que se denominan “pull”, o de arranque, contra el enfoque tradicional de sistemas “push” o de empuje. Otra manera de ver la diferencia entre unos y otros sistemas es que el sistema de arranque es guiado por la demanda mientras que el sistema de empuje es guiado por la producción. En un sistema “pull” el proceso espera que haya demanda de su producto para producirlo, tratando de que se llegue justo a tiempo con el mismo, de 26 manera de que no haya inventario . El inventario es característico de los sistemas “push” puesto que es el amortiguador que permite el desacoplamiento entre procesos consecutivos. El problema es que el inventario consume mucho capital y tiene un alto costo, siendo que además no se sabe si el producto final tiene comprador o no. De ese modo se desperdicia trabajo y materiales. El método Kanban permite alcanzar un ritmo de producción sostenible e introducir cambios a los procesos con muy baja resistencia. Es por eso que lo usamos de preferencia con aquellas organizaciones de muy baja 27 madurez institucional. Como vimos, el método Kanban es uno de los mecanismos que subyace el TPS pero la adaptación para ingeniería de software es del 2004 y fue realizada por Anderson en Microsoft. Anderson lo presentó en la conferencia Agile 2007 de Washington y comenzó el entusiasmo por el método, puesto que los resultados eran muy alentadores. 21 22 23 24 25 26 27 KNIBERG, H. e SKARIN, M., 2010 Cuando usamos Kanban con mayúsculas nos referimos al método Kanban desarrollado por Anderson, cuando se lo usa en minúsculas, kanban, hace referencia a cualquier otro uso, como el sistema kanban de Toyota o el tablero kanban que veremos más adelante. KNIBERG, H., 2007 KNIBERG, H., 2007 PALMER, S. R. e FELSING, J. M., 2002 Esto también es conocido como sistema “Just in Time”, o con las siglas JIT. Toyota Production System. Capítulo 3 23
- 24. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS El método es en sí muy simple, pero al usarlo de determinada manera trae consigo múltiples ventajas que señalaremos al explicarlo. Si bien el texto [ANDERSON, 2011] es la base que permite entenderlo profundamente, para el lector que aspira a un manejo más pragmático aconsejamos [KNIBERG & SKARIN, 2010] que se remite a lo esencial de la implementación, sin por ello dejar de lado lo anecdótico que permite la comprensión, o como se dice en México, el “aterrizaje” del material. Un elemento central en el método es el uso del tablero kanban. No se debe confundir el uso del tablero con la aplicación del método; es posible usar el tablero sin seguirlo, como de hecho se hace en muchas adaptaciones de Scrum y XP, porque el tablero es un excelente medio para comunicar el progreso de un proyecto. El tablero kanban es simplemente un registro del avance del proyecto materializado según le convenga al 28 equipo. Lo más frecuente es usar un tablero donde se puedan pegar notas autoadhesivas que llamaremos pósit , como en la Figura 3.1, dividido en columnas verticales. Cada columna indica un estado de las tareas. Las pósit contienen los nombres de las tareas. La primera columna de la izquierda típicamente contiene lo “pendiente”, es decir la lista de las tareas a realizar que aún no se han comenzado. Cuando un miembro del equipo tiene disponibilidad para comenzar una tarea, toma de esa columna la tarea que corresponda, ya sea por prioridad prestablecida o por alguna otra razón que se haya convenido en el equipo, y la corre a la columna siguiente hacia la derecha. En algunos métodos que usan el tablero kanban el miembro del equipo que hace esto coloca la fecha y hora del comienzo, su nombre y la fecha estimada de finalización en los rincones del pósit, diseñados para ese uso, 29 como se muestra en la Figura 3.2 . Cuando termina de realizar su tarea, toma el pósit de donde lo colocó y lo mueve una columna más a la derecha, de donde a su vez lo tomará alguien más para continuar con el proceso hasta que la tarea alcance el punto donde se acordó se la considerará completa, punto en el cuál alcanza la columna de la extrema derecha del tablero. Figura 3.1: Tablero kanban No hay ningún motivo especial para utilizar tarjetas autoadhesivas o los tableros en sí. Pueden utilizarse planchas de cartón a las que se pinchan con chinches tarjetas de cartulina, pueden usarse filas horizontales en vez de columnas o puede utilizarse un tablero virtual de los muchos que se ofrecen por la Internet. El objetivo es el mismo, dar claridad a las tareas pendientes de resolución y entender tanto el estado actual del proyecto como la ocupación del personal. Figura 3.2: Nota pósit del Tablero kanban 28 Pósit es un artículo nuevo en el diccionario de la Real Academia Española, avance de la vigésimatercera edición. Su definición es (Del ingl. Post-it, marca reg.). 1. m. Hoja pequeña de papel, empleada generalmente para escribir notas, con una franja autoadhesiva en el reverso, que permite pegarla y despegarla con facilidad. 29 24 En el ejemplo mostrado el rincón superior izquierdo contiene el nombre de la persona responsable, el superior derecho la fecha y hora de apertura del ítem, el inferior derecho la estimada de finalización y el inferior izquierdo (sin llenar en el ejemplo) la fecha real de finalización. Cuando se usa esta convención a menudo los pósit se copian y se pegan unos sobre otros para tener la historia de su desarrollo. Capítulo 3
- 25. Boria et al. En el método Kanban se limita el número de tareas en cada columna. El objetivo es identificar claramente la capacidad del sistema y balancear la demanda contra la capacidad del equipo. El método Kanban permite comprender el tiempo de tránsito de cada tarea, desde que ingresa al sistema por la izquierda hasta que culmina en la columna de la derecha. (Hay algo de satisfacción personal para cada miembro del equipo en mover la tarea hacia la columna “completado” que motiva a usar kanban). Una vez que se han ajustado los parámetros de producción, el equipo alcanza un ritmo sustentable, es decir, que puede mantenerse indefinidamente, consiguiendo en efecto predictibilidad que otros métodos tardan mucho en alcanzar. Puesto que esa regularidad se hace presente muy rápidamente, toda obstrucción a esa regularidad es rápidamente visible, potenciando al equipo para detectarlos y, en consecuencia, resolverlos. El impacto que tienen en la regularidad los defectos, las demoras, los cuellos de botella y la mala estimación del tamaño y la complejidad del producto aparecen muy pronto en el tablero. Es fácil relacionar estos problemas con el costo del proyecto, dado que al restringir el número de tareas en cada columna las personas tienen que atender los cuellos de botella para ayudar a resolverlos. De esta manera el método Kanban vincula rápidamente los problemas técnicos del proyecto a los resultados de negocio, sin tener que establecer complicados mecanismos de análisis. Este es un resultado que no se anticipaba al introducir el método pero que es uno de los puntales de su adopción. Una de las ventajas de Kanban es que al producir con calidad y a tiempo se genera confianza en los clientes, que reciben productos con regularidad y con la calidad esperada. Otra ventaja es que, al hacer que el equipo mejore constantemente sus procesos para evitar demoras, las entregas se hacen más frecuentes y con mayor funcionalidad. A su vez, esta situación hace que el equipo se sienta más a gusto y ponga más ahínco en mejorar el flujo de trabajo. Para implementar Kanban el primer paso es identificar el flujo de trabajo, lo que se conoce como la “cadena de valor” que ya viéramos en el Capítulo anterior en las discusiones sobre el método de mejora de procesos a seguir. Dado el origen común de esos métodos (las diferentes versiones de calidad total) y el hecho de que el método Kanban es una adaptación al desarrollo de software de una técnica con el mismo nombre (kanban) derivada del TPS, a su vez del mismo origen que los anteriores, las coincidencias no deben sorprendernos. Kanban usa cinco principios para crear comportamientos en las organizaciones donde se lo aplica: Visualizar el Flujo de Trabajo; Limitar el Trabajo en Realización; Medir y Manejar el Flujo; Explicitar Políticas de Proceso; y Utilizar 30 Modelos para Reconocer Oportunidades de Mejoras. El primer punto saliente en la construcción de un tablero kanban para el flujo de trabajo es que la columna de la derecha corresponde al estado de tarea completada. Antes de que se pueda proseguir con la implementación del método es imprescindible que el equipo, junto con el proveedor de información (más adelante llamaremos a este rol ‘Dueño del Producto’ siguiendo la costumbre introducida por [SCHWABER & BEEDLE, 2002]) defina los atributos necesarios de una tarea para que se la considere completada. Por ejemplo, la densidad de defectos remanentes conocidos, o los estados por los que ha debido pasar (inspecciones, pruebas unitarias, etcétera). La columna de la derecha está así bien identificada y su sentido es claro. La columna de la izquierda es donde se colocan los pendientes. Entre medio hay tantas columnas como el equipo quiera y que tengan significado para ellos. Por ejemplo puede que la siguiente columna a la derecha de “Pendientes” sea “En Análisis”, la que le sigue a esta sea “Analizado”, la siguiente “En Desarrollo”, la siguiente “Listo para Prueba”, la siguiente “Listo para Integración”, y así sucesivamente. Por otra parte puede que un equipo determine que todo lo que necesitan saber se contiene en tres columnas: “Pendiente”, “En Desarrollo”, “Listo para Entregar”. Las decisiones que así se toman tienen repercusiones muy grandes. Por ejemplo, la primera elección sugiere que dentro del equipo hay especialidades que van pasando la tarea de una a otra. La abren los analistas que la pasan a los desarrolladores que la pasan a los testers. La segunda sugiere que el equipo trabaja en células integradas donde todos esos roles se cumplen dentro de la célula. Un caso extremo poco recomendable es el de la célula unipersonal. Recomendamos la adopción del tablero más complejo con divisiones técnicas del trabajo, por lo menos mientras no se incorporen técnicas especiales como programación por pares y diseño dirigido por las pruebas. El motivo es que las diferentes etapas dentro del proceso permiten avizorar mejor estados intermedios, de modo que los atrasos potenciales y los cuellos de botella puedan ser rápidamente detectados y la duración de las tareas mejor estimadas. Además, este esquema de trabajo es muy flexible y permite crecer con facilidad hacia otros 30 Los modelos a que hace referencia Anderson son más generales que los que presentaremos en el próximo Capítulo, pero dada la apertura que sugiere el texto ya citado, los autores no encontramos contradictorio utilizar el MPS para introducir mejoras de proceso compatibles con Kanban. Capítulo 3 25
- 26. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS métodos, en particular Feature Driven Development, que recomendamos más adelante como un método ventajoso para proyectos grandes con equipos de mucha personas. Por si estas dos características no fueran 31 suficientes, otra ventaja consiste en que los estados intermedios de pase permiten al proyecto contar con el apoyo de grupos organizacionales, como Aseguramiento de la Calidad, que puedan tomar esos traspasos como referencias e intervenir sin violencia en la calidad del proceso. Hasta acá lo descripto constituye generalidades del uso de un tablero kanban. Para que sea una aplicación del método Kanban, es necesario limitar el número de pósit en cada columna. Si en una columna hay tantos pósit como indica el límite, generalmente anotado en el tope de la columna junto a su nombre, no se puede pasar un pósit más a esa columna. Esto implica que aunque se haya terminado el paso anterior para una tarea la columna está bloqueada y no se puede hacer avanzar el pósit correspondiente. Claramente las personas que quedan ociosas notan esto, las personas que están trabajando en las actividades de la columna saturada notan esto y la cadena de producción se detiene. En esta situación se detecta un cuello de botella, que debe ser resuelto por los mismos miembros del equipo. A diferencia de la gran mayoría de los métodos existentes, Kanban no es prescriptivo. En eso lo sigue Scrum, pero Kanban es todavía menos prescriptivo que Scrum. El equipo elige, adapta y adopta sus procesos según su necesidad. Lo que diferencia notablemente a Kanban de los otros métodos ágiles es su flexibilidad, pero sobre todo es la limitación del volumen de trabajo en cada etapa. Es esta restricción la que pone en juego los mecanismos de adaptación, y en consecuencia los mecanismos de mejora, que en otros métodos quedan a cargo de reuniones especiales llamadas “retrospectivas”. Lo que en los demás es una visión de lo que pasó, en Kanban es la necesidad lógica de operar sobre lo que está pasando. Siguiendo nuestra opción de mejora de procesos que definiéramos en el Capítulo anterior, utilizaremos los mismos preceptos que usa Anderson para Kanban puesto que son compatibles: Foco en Calidad, Reducción del Trabajo en Desarrollo, Entregas Frecuentes, Balanceo de la Demanda contra la Producción, Fijación de Prioridades, y Atacar las Fuentes de Variación para Mejorar la Predictibilidad. La receta de Anderson no sólo es compatible con la de LS que eligiéramos antes, ¡Es totalmente compatible con el MPS! En el Capítulo 5 expandiremos las técnicas de Kanban utilizando el ejemplo de Tahini-Tahini. 3.3 Scrum: Organizando el sistema para un estado de equilibrio orgánico Scrum no debe ser considerado un método, a pesar de que tiene reglas claras que se deben seguir, porque deja muchas resoluciones abiertas para que el equipo del proyecto las resuelva. Al describir Kanban dijimos que después del mismo, Scrum es el enfoque ágil menos prescriptivo. Esto es cierto, pero la gran diferencia entre el número de reglas de uno y otro (3 contra más de 10) hace que estén cerca pero no demasiado. Para implementar Scrum en una organización hay que hacer cambios profundos antes. Con Kanban los cambios originales son solo tres: reflejar el flujo en un tablero Kanban, limitar el número de tareas por etapa y mejorar el flujo total haciendo las alteraciones que demande el proceso. Kanban se adapta fácilmente a cualquier proceso subyacente, porque las entregas rápidas pueden ser internas al equipo y la participación de los involucrados externos al mismo es deseable pero no indispensable. En cambio, en Scrum es indispensable restructurar la organización en varios sentidos: Primero se tiene que contar con una persona que conozca el producto, o tenga la visión del producto, y que esté disponible para trabajar con el equipo durante la duración del proyecto. La dedicación que se requiere no es de tiempo completo, pero esta persona debe permanecer accesible para que el equipo pueda tomar decisiones de negocios conjuntamente con ella. Asimismo, está persona debe 32 poseer la suficiente autoridad para que sus decisiones no se revean . En el lenguaje de Scrum esta persona se conoce como el “Dueño del Producto”. En segundo lugar, el personal debe ser dividido en equipos interdisciplinarios pequeños, auto-organizados, que cuentan con la supervisión y colaboración para allanar problemas de parte de un especialista, llamado en Scrum el Scrum Master. El Scrum Master se encarga de que se sigan los procesos de Scrum y de mantener la relación del equipo con el medio que lo rodea. En ese sentido, es mucho más un perro pastor que cuida del ganado que un gerente que dirige las operaciones. La auto-organización del equipo es fundamental en Scrum. El Scrum 31 En inglés, “hand-off” entre un rol y el otro. 32 26 Esto es lo que [BOEHM, B. e TURNER, R., 2003] llaman un usuario ‘CRACK’ (collaborative, representative, authorized, committed and knowledgeable) que traducido es colaborativo, representativo, autorizado, comprometido y con conocimiento. Capítulo 3
- 27. Boria et al. Master no dicta lo que debe de hacerse, sino que allana el camino para que se lo pueda hacer. De ese modo es el propio equipo 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: 33 “momentos de verdad”, por analogía con el mismo concepto en Marketing . 33 [CARLZON, 1989] Moments of Truth. Capítulo 3 27
- 28. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 34 Producto. Esto tiene inmediatas consecuencias. Al no tener la guía de un usuario CRACK , 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 35 de desarrollo. De hecho, Kent Beck , el pionero de XP, fue de los primeros en sugerir iteraciones cortas con 34 35 Usuario “CRACK” (collaborative, representative, authorized, committed and knowledgeable) que traducido es colaborativo, representativo, autorizado, comprometido y con conocimiento [BOEHM e TURNER, 2003]. BECK, K., 2000, Extreme Programming Explained, Addison-Wesley. 28 Capítulo 3
- 29. Boria et al. 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 36 escuchando indefinidamente” . 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. Capítulo 3 29
- 30. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 37 citada en las referencias . 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 38, 39 productividad de su técnica particular de programación por pares . 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 39 30 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. 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. Capítulo 3
- 31. Boria et al. 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. Capítulo 3 31
- 32. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS Escalamiento Casi desde el principio de su existencia, la ingeniería de software se ocupa de dos problemas ligados entre sí: 40 “Programming in the Large” y “Programming in the Many” . El primer problema es el de atacar proyectos grandes. El concepto de ‘grande’ es relativo a la media que produce la 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] 32 Capítulo 3
- 33. Boria et al. Figura 3.5: Ciclo de Desarrollo de FDD Entremos en un poco de detalle en los cinco procesos. El primer proceso comienza cuando se han determinado los principales actores para todos los roles requeridos. Los roles que resultan clave en FDD son seis. El principal rol es el de Gerente de Proyecto. Es responsable administrativo del proyecto y debe mantener el ‘sistema’ proyecto andando. Muy a la manera del Scrum Master, el Gerente de Proyecto FDD se ocupa de que se siga el proceso y que su equipo pueda funcionar libe de interrupciones. A diferencia del Scrum Master, el Gerente de Proyectos FDD tiene la última palabra en alcance, presupuestos mensuales y 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 41 nombre es Programador en Jefe . 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. Capítulo 3 33
- 34. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 42 proceso, construir la lista de funciones . 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”. 34 Capítulo 3
- 35. Boria et al. 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 43 invariante que resulta de la ejecución de los métodos de la clase . 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 44 fase . 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 44 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] Usamos indistintamente fase, paso y proceso para referirnos a las cinco fases de FDD. Capítulo 3 35
- 36. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 45 para los autores el formato ideal para encajar con los modelos de madurez inspirados en CMM , tales como el MPS o el CMMI. 45 [PAULK, M., WEBER, C., CURTIS, B., 1994] siguiendo a [HUMPHREY, W., 1989] 36 Capítulo 3
- 37. Boria et al. 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. Tabla 1: Desempeño de Proyectos de los Sistemas de Decisión de General Dynamics Contra el Nivel CMM Nivel Porciento Efectividad CMM de de la Retrabajo Contención en Fase 2 3 4 5 23.2% 14.3% 9.5% 6.8% 25.5% 41.5% 62.3% 87.3% Densidad de Productividad (x Defectos factor relativo Únicos al nivel 2) Reportados por el Cliente por KSLOC 3.20 0.90 0.22 0.19 1x 2x 1.9 x 2.9 x Figura 4.1: 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 46 [HUMPHREY, 1989] consiste en la creación de un modelo de estados que ofrecen precisamente esa guía . 47 De hecho, los modelos de estado son anteriores al trabajo de Humphrey. En un trabajo eminente , Richard Nolan introduce un modelo de estados para la 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 48 referencia a dos criterios para la ‘buena formación’ de modelos de estados, descriptos por Simon Kuznets : 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 47 48 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. [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. [KUZNETS, S., 1966] Capítulo 4 37
- 38. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 49 internacionales para definición, evaluación y mejora de procesos de software” . 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 50 Software, MR-MPS-SW [SOFTEX, 2012a], ya citada, cuya lectura es indispensable para entender la génesis , 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 50 [SOFTEX, 2012a], página 6 [SOFTEX, 2012a], página 15, Apartado 7, Base técnica para a definição do modelo MPS 38 Capítulo 4
- 39. Boria et al. 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. Capítulo 4 39
- 40. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 40 Capítulo 4
- 41. Boria et al. 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. Capítulo 4 41
- 42. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 51 cambio, esto no es equivalente a decir que estén de acuerdo con la dirección que se le quiere dar al cambio . Lo desconocido causa temor, o al menos, resquemor. Esperar que todos entiendan el cambio de entrada y lo adopten por sus ventajas es iluso, la 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 42 "... 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). Capítulo 4
- 43. Boria et al. Figura 4.6: Secuencia de Resistencia al Cambio [KUBLER-ROSS, 1997] En lo que sigue evitaremos discutir cambios culturales profundos, para lo que hemos reservado una 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 52 un objeto, sino un proceso, un devenir , 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. Capítulo 4 43
- 44. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 53 momento que se lo necesita y con los procesos reales . 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 54 individual no alcanza para conseguir el cambio de la organización. Como dice Peter Senge en [SENGE, 2006], “Cuando pensamos en la organización que aprende, son los equipos los que aprenden”. Dicho de otra manera, no 53 54 En TeraQuest llamábamos a esto por las siglas JIT, OTJ, JET, (Just in Time, On The Job, Just Enough Training) When we think of a learning organization, it is the teams that learn. Peter Senge, “The fifth Discipline” 44 Capítulo 4
- 45. Boria et al. 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 Capítulo 4 45
- 46. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS cultura, encontramos que son cuatro dimensiones, como muestra la Figura 4.12, derivadas de los dos ejes sobre 55 los que se apoya una organización : 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. 46 Capítulo 4
- 47. Boria et al. satisfacer al cliente. En un mercado no hay privilegios para amigos y la competencia lo es todo, de ahí el nombre. Las empresas financieras suelen mostrar ejemplos de esta cultura. Por último, una ‘Ad-hocracia’ es una cultura que favorece la diferenciación de su personal. En una Adhocracia 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 56 organizacional ; 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 57 organizacionales de cualquier tamaño” . 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 autoevaluació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 57 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. SOFTEX, 2012i Capítulo 4 47
- 48. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 La empresa Tahini-Tahini, internamente conocida como T , 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 2 fueron compañeros de clase. Al momento en que los encontramos T está alcanzando sus veinte meses de funcionamiento continuo y los gemelos están por dar su último examen para graduarse. 2 En un principio T 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 2 lo que en T 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 2 pruebas ad-hoc. Cuando no encuentra fallas, libera el producto, subiéndolo al sitio de T , de donde el cliente puede hacer uso del mismo. 48 Capítulo 5
- 49. Boria et al. En el momento en que nuestro equipo es llamado a colaborar con ellos para realizar mejoras a sus procesos, 2 T está a punto de concretar un lanzamiento importante en el área de los dentistas. 5.2 ¿Quién Está A Cargo? 2 Hoy es un gran día en T . 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 2 dispuesto a conceder ante la presión de algunos de sus miembros para cancelar el contrato con T pero necesita de nuestra ayuda para resistir los embates. La consultora está haciendo promesas de entrega en tiempos imposibles, ignorando la necesidad de adaptación del ERP en cuestión, lo que además seguramente obligará a algunos cambios 2 importantes en las interfaces de los futuros clientes. Por todo eso, el Doctor Molar le pide a T que: 1. 2. Indique el estado actual del proyecto de adaptación de ISP a los problemas de los odontólogos; Dedique un par de horas, hacia mediados de semana, a hacer una demostración del producto cómo sea 2 que esté, al efecto de convencer a los asociados a que esperen el lanzamiento antes de cortar con T ; 3. Estime que porcentaje del producto va a estar listo para la 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. Capítulo 5 49
- 50. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 50 Capítulo 5
- 51. Boria et al. 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 2 definen un proceso que solucione la causa y evita que se repita. Nuestro hombre en T parte por definir, siguiendo el método, las características deseables del proceso: • • • Evitar que se repita el problema en el futuro 2 Ser muy fácil de implementar (dos o tres días en T ) 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 2 buscar en la red herramientas de software que se ajusten a las necesidades de T para llevar el tablero Kanban en la nube o en servidores locales, gratuitamente. Hay suficientes como para que Mariano se entretenga por varios 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 2 no hubiera respuesta de ninguna de las dos. Todo está bien en el universo de T . 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. Capítulo 5 51
- 52. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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- 52 Capítulo 5
- 53. Boria et al. - “¿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 5a6 7 a 10 más de 10 1a2 2a4 más de 4 Días en el día 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 Capítulo 5 53
- 54. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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”. 58 - “¡Ahora tenemos una épica !”, 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 2 La reunión continúa a pedido de Máximo, por media hora más. Antes de dejar a T 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 54 Capítulo 5
- 55. Boria et al. 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 2 todos, y la simpatía y juventud de los profesionales hacen el resto y se firma un memorándum de acuerdo entre T y la SOPA. Lo que piden algunos de los menos entusiastas es que se demuestre la capacidad de modificar el servicio, para lo cuál han encargado algunos cambios, la mayoría cosméticos, pero algunos que afectan los 2 módulos de cálculo. T tiene una semana para responder con un plan y una propuesta de honorarios. Establecida 2 ya una buena relación entre T y Máximo, lo llaman directamente para que facilite otra reunión para dar la respuesta. Capítulo 5 55
- 56. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 prácticas. Además, ni ha sacado el tema del MPS con T , 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 2 una cita acá y otra allá, por la tarde del viernes está de nuevo en la sala de diseño de T 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 2 pero utiliza esta vez la herramienta de software (sprint.er) que instalaron en T . La secuencia de pasos es la misma: identificar el Backlog, hacer la 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, 2 revisar y cerrar. Pero esta es la primera propuesta con desarrollo a medida que T va a firmar; hasta aquí solo han vendido servicios de un producto relativamente estable con modificaciones que no alteraban el esquema de trabajo, basado sobre todo en correcciones al 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. PLANTILLA DE DEFINICION DE HISTORIAS ID NOMBRE IMPORTANCIA TAMAÑO VALIDACION 1 RIESGOS ASOCIADOS CAPACIDADES REQUERIDAS 2 3 4 5 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 59 sobre lo que hacen usando otras facultades además de su capacidad de construir . Planilla de Definición y Control de Riesgos 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 Exp - Exposición - producto entre prob y perd 100) 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 Descripción del Riesgo Prob Perd Exp ID Condición Prioridad Prioridad # Veces en este la última en la análisis vez lista Acción Quién Cuando Consecuencia 1 2 3 4 5 6 7 8 9 10 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 56 [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í. Capítulo 5
- 57. Boria et al. • 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. Capítulo 5 57
- 58. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS - “Justamente de eso quería que habláramos”, dice. “Hay un programa recibir fondos del estado para hacerlo”. 60 que permite invertir en calidad y 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 2 empresas como T 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 2 como evaluaciones, evidencia directa y otros términos que hoy son nuevos en T pero que se van a convertir, con el paso del tiempo, en moneda corriente. Claudio queda con la tarea de contar el resumen de lo acá hablado a 2 todos los socios, mientras que Máximo tiene que hablar en Vitalería para que se ingrese a T en la lista de empresas que aspiran al soporte para implementación. 5.6 Avances en la Implementación del MPS 2 Unas semanas después T 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 2 en T : Gestión de Proyectos (GPR) en el Nivel G GPR 1 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 60 El alcance del trabajo para el proyecto está definido; La participación de las partes interesadas en el proyecto es planificada, supervisada y mantenida; 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. 58 Capítulo 5
- 59. Boria et al. 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). 2 De las tareas de planificación solo faltan GPR 8 y GPR 9. Máximo y el equipo de T 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 Capítulo 5 59
- 60. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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: 60 Capítulo 5
- 61. Boria et al. 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 2 procesos de T . 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 2 las actividades de generar el plan, definiendo los roles y funciones de cada actor e interesado. Cuando T 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 2 generar la propuesta, cómo se adjudica la responsabilidad y que recursos le dan soporte. De este modo T atiende a los resultados esperados de los Atributos de Proceso. Capítulo 5 61
- 62. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 61 nombre de retrospectivas, y T las adopta bajo la preparación y supervisión 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 62 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. Capítulo 5
- 63. Boria et al. 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 2 de lo que se espera del personal de T . 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. 2 Dejamos a Máximo y T organizando la evaluación formal de Nivel G del modelo MPS. Capítulo 5 63
- 64. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 62 definición de nuevas competencias necesarias y delimitación de nuevas responsabilidades” . QUE HA PASADO HASTA AHORA 2 26. T 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 2 prontamente por el personal de T y la organización recibió su diploma en el congreso anual del Simpósio Brasileiro 2 de Qualidade de Software (SBQS). La noticia circuló rápidamente en los medios locales y T tuvo sus quince 2 minutos de notoriedad. Por breve que haya sido esa notoriedad los amigos de T , como el Doctor Molar, se sintieron obligados a compartir el orgullo que les trajo la noticia. La consecuencia inmediata es que otros clientes 2 se acercaron a T para inquirir sobre sus servicios. Una oferta muy tentadora llegó desde el Consejo Profesional de Contadores 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. 2 Tras unas breves charlas iniciales con CoProCoP se hace una reunión plenaria de T 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 2 Dos días más tarde, Máximo facilita la reunión plenaria de T 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 64 Capítulo 6
- 65. Boria et al. tome el sombrero que corresponde a lo que quiere expresar antes de decirlo, de modo que todos sepan que está haciendo esa 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 implica contratar servicios externos rápido Muchas líneas de producto implica contar con gestión de configuración implica seleccionar entre opciones de inversión Capítulo 6 65
- 66. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 AQU 2 Los criterios de selección del proveedor son establecidos y usados para evaluar los proveedores en potencial; AQU 3 66 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; El proveedor es seleccionado con base en la evaluación de las propuestas y de los criterios establecidos; Capítulo 6
- 67. Boria et al. 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 63 la propiedad y si la decisión aumenta o disminuye los riesgos. Máximo propone crear una matriz de Pugh 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 2 a las oficinas de T 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 2 un sistema nuevo, en la nube, por lo que la experiencia de T les es sumamente apetecible, y un proveedor de servicios a agentes de seguros que 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. - 63 “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?”. Ver Capítulo 2. Capítulo 6 67
- 68. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 dirige a la pizarra y escribe: ‘Visión para T : 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: 1 sistema completo software para farmacias 1 sistema migración a SaaS Asociación servicios de salud 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 atributo contadores Esfuerzo mercado pot. Enorme hospitales, farmacias, muy ampilo Farmacias médicos Tabla 6.4: Matriz de Pugh sobre Propuestas servicios a agentes de seguros ???????? Los signos de pregunta los escribieron los mellizos Galarraga, que de repente se levantaron al unísono y se disputaron el marcador. - 68 “¿Qué pasa si”, dijo Alberto, Capítulo 6
- 69. Boria et al. - “… 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 la escasez de recursos implica desbalances entre líneas Capítulo 6 cuando hay desvíos de la estrategia implementamos acciones correctivas utilizamos la visión estratégica para resolver conflictos de recursos y dependencias críticas 69
- 70. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 comunicar la visión y el estado de los proyectos estratégicas 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). 70 Capítulo 6
- 71. Boria et al. 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. Nombre del cargo Nombre del cargo al cual reporta Experiencia Funciones del cargo Que hace Como lo hace Formacion Contactos dentro profesional de la organizacion deseable o requerida Contactos fuera de la organizacion Mision del cargo Con quien lo hace Indicadores de gestion Habilidades requeridas Tabla 6.7: 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. Capítulo 6 71
- 72. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 72 Capítulo 6
- 73. Boria et al. 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 2 defectos relacionados con el producto, y duración, esfuerzo y costo de la tarea. Con esto en mente, T 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 64 una posible mala definición del sistema de decisión 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 que se usan en los proyectos son decididas en conjunto por la gerencia del proyecto y la PMO se especifica claramente el procedimiento de medición con responsabilidades y controles las mediciones e indicadores que se utilizan en los proyectos son decididos sin consideración a las necesidades organizacionales cada proyecto tiene una versión distinta del sistem de decisión 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 no todos los interesados entienden el porqué de las decisiones se guardan los datos y los resultados de los análisis de manera de que puedan ser recuperados 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 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 64 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; Los datos requeridos son recolectados y analizados; 2 T 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. Capítulo 6 73
- 74. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 liquidez para mantener a T funcionando. Se buscará una alianza con la empresa de SaaS para servicios de salud. A cambio de poner el know-how de SaaS y la arquitectura se espera participación en el negocio y las patentes que 2 puedan surgir. Con la empresa que quiere fundir su software para farmacias con el existente de T se llevará adelante un convenio por el 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 Planilla de construcción de El plan está aprobado y Programa programas del líder técnico de bajo control de proyecto configuración Fecha Real de finalización del Subversion La fecha de ingreso es programa 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 Programas Acumulados Planificados para la Semana Programas Acumulados Realizados en la Semana Cálculos utilizados Cuenta; el número de programas cuya fecha de finalización según el plan cae dentro de la semana en cuestión. 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. 74 Capítulo 6
- 75. Boria et al. El trabajo es intenso pero prolífico. La nueva estructura comienza a dar frutos en forma de acciones paralelas. 2 El ambiente se electrifica y T comienza a preparar su despegue. Claudio inicia acciones que 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 2 continuidad con los clientes. Prácticamente, él solo sintetiza lo que T era hasta una semana antes. Ana ocupa sus últimas semanas antes de ser madre en dejar todas las decisiones arquitectónicas bien documentadas. Fecha de creación Especificación del Indicador Para <fecha> <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: Capítulo 6 75
- 76. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS riesgo: mitigación: si no sabemos donde se almacenan los productos y los resultados, perdemos tiempo y posiblemente trabajo si "no se puede encontrar una hoja en particular en el bosque" se pierde mucho tiempo identificando cada parte si los documentos se actualizan sin que los interesados se enteren pueden haber “choques” entre cambios se adopta un sistema de gestión de documentación se adopta un sistema de clasificación de los ítems almacenados 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 se lleva la historia de los cambios de línea base se sigue un proceso estricto para cambiar un producto si no sabemos quién cambió qué ni cuando puede ser difícil reproducir los motivos y decisiones alrededor de un cambio si las personas no respetan las reglas y los activos se se controla que los productos de trabajo sean almacenan en cualquier parte y cualquiera los accede y almacenados, leídos y liberados al uso siguiendo las modifica se puede introducir mucho retrabajo formas del proceso Tabla 6.12: Riesgos Derivados de la Falta de Control de Activos 65 Máximo introduce al grupo la noción de línea base de productos . 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 2 cuestión. Para T 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. 76 Capítulo 6
- 77. Boria et al. 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 2 trabajando en T y la sala de diseño ha pasado a ser la sala de uno de los dos equipos de Scrum. Media calle más 2 hacia el rio se abrió la sucursal de T , 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. 2 Cuando Máximo explicó la escritura de procesos a T 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 66 computadora, encontró un webinar que bajó de SlideShare . 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 Capítulo 6 77
- 78. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS pasos que han elegido para el proceso. En ese momento se pueden modificar decisiones, otorgar dispensas y revisar lo actuado. Por supuesto, Marcela participará en todas las retrospectivas. 2 Puesto que el Dueño del Producto es interno a T , 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 verificar que los productos se adhieren a las reglas diferentes formatos es posible que cometamos muchos que son políticas de la organización errores involuntarios si las personas no siguen los procesos que hemos verificar que las personas siguen las reglas y los establecido no es posible asegurar que lo que sucede es procesos que son política de la organización lo que se espera y además de no aprender de los errores es probable que cometamos muchos si detectamos problemas pero no los comunicamos no comunicar los problemas y las disconformidades para van a resolverse solos y es posible que todos les pierdan que se puedan resolver el respeto a los procesos si no nos ponemos de acuerdo con las acciones a seguir cuando haya disconformidades o problemas hay que para arreglar disconformidades o las que se acuerdan no acordar un plan de acción para que se mantengan las se controlan es posible que se abandonen las buenas buenas prácticas o se corrija el proceso prácticas 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. 2. 3. 4. 5. 6. 7. revisar los riesgos revisar el plan seleccionar procesos críticos seleccionar productos críticos planificar auditorías realizar auditorías 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. 78 Capítulo 6
- 79. Boria et al. 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, 2 poniendo a buen uso la inversión de T 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. Capítulo 6 79
- 80. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 GPR 1 GPR 2 GPR 3 GPR 4 GPR 5 GPR 6 GPR 7 GPR 8 GPR 9 GPR 10 GPR 11 GPR 12 GPR 13 GPR 14 GPR 15 GPR 16 GPR 17 GPR 18 GPR 19 El alcance del trabajo para el proyecto está definido Las tareas y los productos de trabajo del proyecto son dimensionados, utilizando métodos apropiados El modelo y las fases del ciclo de vida del proyecto son definidos El esfuerzo y el costo para la ejecución de las tareas y de los productos de trabajo son estimados con base en El presupuesto y el cronograma del proyecto, incluyendo la definición de hitos (marcos) y puntos de Los riesgos del proyecto son identificados y su impacto, probabilidad de ocurrencia y prioridad de Los recursos humanos para el proyecto son planificados considerando el perfil y el conocimiento necesarios Los recursos y el entorno de trabajo necesarios para llevar a cabo el proyecto son planificados Los datos relevantes del proyecto son identificados y planificados respecto a la forma de recolección, Un plan general para la ejecución del proyecto es establecido con la integración de planes específicos La viabilidad de lograr las metas del proyecto es explícitamente evaluada considerando restricciones y El Plan del Proyecto es revisado con todos los interesados y el compromiso con él es obtenido y mantenido El alcance, las tareas, las estimativas, el presupuesto y el cronograma del proyecto son supervisados con Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados con Los riesgos son supervisados con relación a lo planificado La participación de las partes interesadas en el proyecto es planificada, supervisada y mantenidao Revisiones son realizadas en hitos (marcos) del proyecto y conforme lo establecido en los planes Registros de problemas identificados y el resultado del análisis de cuestiones pertinentes, incluyendo Acciones para corregir desvíos de lo planificado y para prevenir la repetición de los problemas identificados a a a a a a o D ia ri Demo a a a a a a a a Scr um da d H istóri ca Ta sa de "Q u ema do" Retr o spect iva Juego de Pla nif. Veloci Ka nb an Gerencia de Proyectos en los Niveles G y F Ba cklo g Tomando en cuenta las técnicas que han incorporado, los gemelos realizan una autoevaluación del grado de 2 cobertura que tienen los resultados esperados del MPS-SW en T . Revisan los resultados con Máximo y con 2 satisfacción reafirman que el camino elegido es el correcto. (Figura 6.8). T comienza a preparar su evaluación nivel F. a a a a a a a a a a a a a a a Figura 6.8: Cobertura de los Resultados Esperados con Scrum y Kanban 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. 80 Capítulo 6
- 81. Boria et al. 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 2 de lo que se espera del personal de T . 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. 2 26. T 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). Capítulo 6 81
- 82. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 82 Capítulo 6
- 83. Boria et al. 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. 2. No se tiene bien definido el perfil de empleado que se solicita No hay un repositorio de conocimientos que ayude a minimizar el aprendizaje individual de 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” 2 4. No hay una inducción a los procesos de T 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 67 un modelo de competencias 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 2 organización. Comienza utilizando el formulario de misión y funciones de T 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 Capítulo 7 83
- 84. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 2. 3. 4. Fallas detectadas por el usuario (previo a y en los primeros seis meses tras el lanzamiento) Satisfacción de los ingenieros de software con los informes recibidos Efectividad de los casos de prueba diseñados (rendimiento en errores por caso sobre total de errores) 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. 2. 3. 4. 5. 6. 7. 8. 9. Número de errores no previamente detectados que se encontraron en el test de aceptación Número de errores detectados por los usuarios en los primeros seis meses de uso que no fueron previamente detectados Número de errores informados no reproducibles a partir del informe Número de informes rechazados por los ingenieros de software Número de defectos que pasan de ‘abierto’ a ‘cerrado’ sin pasos intermedios después del informe Rendimiento promedio de los casos de prueba diseñados Número total de informes no rechazados por los ingenieros de software Número de casos corridos por unidad de tiempo Número de defectos reportados por unidad de tiempo Funciones (Qué hace el ocupante del cargo para cumplir con la misión) 1. 2. Interpreta el Plan de Pruebas de Software 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 • • • • • 84 Con los ingenieros de software, para expandir lo realizado en pruebas ejecutadas y los respectivos informes Con el gerente de pruebas, para recibir instrucciones acerca de las tareas a realizar e informar actividades realizadas y situaciones excepcionales Con los analistas de negocios, para desarrollar requerimientos verificables por pruebas y recibir sugerencias para el desarrollo de casos de prueba Con los analistas de negocios, para expandir sobre lo informado de los documentos de requisitos Con el Scrum master y el equipo del Scrum, para priorizar y clasificar los defectos encontrados (leve, serio, fatal, etc.) Capítulo 7
- 85. Boria et al. 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 2 actuar correctamente como personal efectivo de T . 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 2 pruebas. Las competencias específicas de un cargo son aquellas que son distintivas de los procesos de T , por ejemplo un Scrum Master debe poseer las competencias que le permitan hacer funcionar a su equipo pero además 2 debe hacerlo de la manera que se espera en T , 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 2 indispensables para trabajar en T , 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. Capítulo 7 85
- 86. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 86 Capítulo 7
- 87. Boria et al. 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 2 aquí sus argumentos, nuevamente analizados como riesgos a T : 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 2 período de aprendizaje y ajuste a las necesidades de T 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 2 Tabla 7.3: Riesgos a T 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 Capítulo 7 87
- 88. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 68 God we trust, all the others bring data” (En Dios confíamos, los demás vengan con datos) . Fase Tarea Apoyo a la Venta Participa de la reunión inicial COMPETENCIA POR NIVELES DE UN GERENTE DE CUENTAS COMPETENCIA 1 2 3 4 Lego Principiante Junior Senior No tiene idea sobre qué se espera de él o ella Toma apuntes y hace preguntas de seguimiento Toma apuntes, hace preguntas de seguimiento y desambiguación 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 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í Toma apuntes, hace preguntas de seguimiento y desambiguación; y participa en las discusiones Prepara la presentación, presenta el material sin problemas y conduce los ejercicios Mantiene la integridad de la propuesta sin confrontar al cliente y se asegura que los cambios de impacto se reflejan en el alcance 5 Experto Conduce y facilita la actividad Prepara la presentación, presenta el material con aplomo y conduce los ejercicios Coordina los cambios con todos los interesados y balancea los intereses colectivos para llegar al ganarganar Tabla 7.4: Primera Parte de un Modelo de Competencias Para mostrar que un modelo de competencias es posible, Marcela ofrece un ejemplo parcialmente completo para el cargo de gerente de cuentas, que le envió 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 88 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 Capítulo 7
- 89. Boria et al. 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 reunión inicial la 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 TahiniTahini. Capítulo 7 89
- 90. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 69 entre varias opciones 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 2 que ya hemos descripto, almacenados en la red interna de T . Con el crecimiento organizacional una empresa que alcanzó esto por estar relativamente bien organizada, puede encontrar que en realidad esa 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 2 de procesos habrá siempre lugar para definir ciclos de vida en uso en T y hacerlos adaptables a los procesos. En particular está pensando en algunas ideas que discute con Ana, que sigue trabajando desde su casa desde las últimas semanas de su embarazo mientras cuida del recién nacido, y que tienen que ver con Feature Driven 70 Development . Dada su experiencia con el reclutamiento de nuevos empleados y los objetivos fijados para controlar 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 70 http://bsix12.com/knowledge-sharing-tools/ es un buen punto para empezar la búsqueda. Ver Capítulo 3 90 Capítulo 7
- 91. Boria et al. 71 seguimiento , 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 2 primeros días en T 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 2 en el Proceso Maestro de T , 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 72 aplicaciones para reuso de conocimiento. Desarrolladas en primera instancia para el reuso de software , 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 72 Ver en Capítulo 6 Aseguramiento de la Calidad DECKER, B., et al, 2005. Capítulo 7 91
- 92. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 2 que una empresa pequeña como T 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 el tamaño de la funcionalidad excede la capacidad del sprint la funcionalidad es nueva y tiene muchas aristas inexploradas la funcionalidad es totalmente central al funcionamiento del producto (control) el dueño del producto tiene dudas sobre la funcionalidad que sugiere el equipo no tiene miembros con experiencia la arquitectura es crucial en el desempeño futuro del producto elección sugerida Kanban con un mini-equipo dedicado mini-espiral de Boëhm dentro del sprint o partir el sprint a partir del análisis para hacer demos más frecuentes usar TDD a full e inspecciones además de programación de a dos 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 usar inspecciones y programación de a dos con el scrum master en uno de los roles usar un sprint para definir la arquitectura, a la manera de FDD, y decidir después sobre Kanban, Scrum o Scrumban Tabla 7.7: Orientación Sugerida por Perfil de Sprint 2 Cuatro semanas después de contar con la presencia del consultor en las oficinas de T , 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 TahiniTahini. 44. Marcela define una arquitectura para organizar los activos de proceso. 92 Capítulo 7
- 93. Boria et al. 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 2 proceso de T , 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 73 que se hacen al final de cada sprint, llamadas retrospectivas , donde se discuten tanto nuevas necesidades como mejoras ya realizadas, para seleccionar y adoptar 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 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 73 La descripción de las necesidades y los objetivos de los procesos de la organización son establecidos y mantenidos; Los objetivos de mejora de los procesos son identificados y priorizados; Ver Capítulo 3 Capítulo 7 93
- 94. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 Pero antes de alcanzar el nivel E, T 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 autoorganizació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. 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. 94 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. 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. Capítulo 7
- 95. Boria et al. 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 74 75 organizacionales , como la indentación , 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 2 necesidades de T . 74 75 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. Se consigue fácilmente con herramientas de “Pretty Printing” Capítulo 7 95
- 96. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 76 objetiva, es un atributo de la relación entre un objeto y el sujeto que evalúa la calidad . No existe la calidad “absoluta”, siempre es calidad “para” y en un contexto. Por lo mismo, la calidad está ligada a las expectativas de 77 los clientes. En el modelo de Kano se puede ver que hay tres tipos de requisitos: los llamados Indispensables, 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. b. c. d. e. 76 77 78 utilizar la historia de los sprints en el juego de planificación para tener una mejor aproximación al esfuerzo real 78 fijar el uso del estándar de recursos necesarios en los planes de proyecto para poder comenzar su provisión anticipadamente (escritorio, PC, SW, etc.) establecer normas de comportamiento de los equipos y hacerlas respetar, con las variantes necesarias darle a las experiencias el lugar importante que merecen y almacenar juiciosamente los resultados para aprovecharlos en futuros proyectos establecer procesos estándar y mecanismos de elección entre ellos, con criterios para elegirlos y adaptarlos. [PIRSIG, 1974], Zen y el arte del Mantenimiento de la Motocicleta. Puede decirse que es uno de los ensayos 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. http://kanomodel.com/ De poco vale tener una guía si no se la sigue! 96 Capítulo 7
- 97. Boria et al. 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 2 continúan disminuyendo la capacidad de T , 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. 2 57. T se encamina a una evaluación del Nivel E. Capítulo 7 97
- 98. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 competencias de T y de perfeccionar la base de conocimientos y su uso por los empleados de la misma. Jessica se consigue integrar perfectamente con el equipo de 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 79 itera sobre un proceso que Jessica introdujo al grupo, conocido como la hoja de resultados balanceados , 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 2 80 en T es simplemente revisada en cada oportunidad , se analizan los resultados, se fijan objetivos y se discuten las 2 inversiones en diferentes categorías. T 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 98 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”. Capítulo 8
- 99. Boria et al. 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 2 su vez, para analizar como estas metas financieras se traducen en metas con los clientes, en T se usan tres temas para (1) expandir (que ellos compren 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 2 81 2 de defectos producida por los equipos de T con las medias históricas en la literatura la conducción de T 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 Capítulo 8 99
- 100. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 82 58. Jessica se incorpora al equipo de Marcela e introduce BSC 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 2 La solución pudiera ser armar un método propio y ajustado a las necesidades de negocios específicas de T , 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 83 listan los problemas con la mitigación o solución a la derecha del mismo en la Tabla 8.1, de ese nombre . riesgo o problema: 1 83 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 82 mitigación: 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 Balance Score Card 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. 100 Capítulo 8
- 101. Boria et al. riesgo o problema: mitigación: suelen quedar funciones sin especificar y los requisitos no funcionales son demasiado frecuentemente añadidos hacia el final del proyecto resultando en mucho retrabajo hay mucho impacto en los compromisos por la cantidad de requisitos derivados que surgen después del juego de planificación la especificación de los requisitos debe permitir identificar funciones así como los atributos de calidad no funcionales del producto 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 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 aun en aquellos casos en los que se construyen modelos del producto estos son pocas veces discutidos con el dueño del producto como parte del mecanismo de entendimiento de los requerimientos es necesario construir historias de usuario, narrativas y/o casos de uso que expliquen el uso esperado del producto la 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 durante el juego de planificación los requisitos menos comunes serán validados usando modelos y los casos de uso o historias de usuario 3 4 8 antes de encarar un sprint se deben definir los detalles de la porción de funcionalidad que se va a incluir Tabla 8.1: Problemas de Requisitos Este es el punto de partida de la futura tabla de decisiones. La columna de la derecha, ‘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 84 System Modeling Language, ASML , 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 85 sistema si se construye un modelo del mismo, puesto que ese modelo obra como ‘objeto de frontera ’ entre el cliente y el ingeniero de software. El modelo, entonces, es factible de 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 85 [WARD, P., e MELLOR, S., 1986], Structured Development for Real-Time Systems, Volume I: Introduction and Tools Un “objeto de frontera” se define como una entidad que tiene uso plástico, que varía de una comunidad a la otra. De ese modo su interpretación permite detectar discrepancias entre las comunidades. Capítulo 8 101
- 102. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 86 87 Modeling in Color’ (JMC). En JMC se utiliza notación de UML , 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 87 [COAD, P. et al, 1999], Java Modeling In Color With UML: Enterprise Components and Process. Actualmente se modificó el nombre a Visual Paradigm, abreviado VP UML. [FOWLER, M., 2003], UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) 102 Capítulo 8
- 103. Boria et al. Las clases amarillas denotan <<roles>> y representan una forma de participar en un evento o actividad por una clase de entidad verde. Ejemplos de clases amarillas son Comprador, Vendedor y AgenteDeVentas. El cuarto arquetipo es el azul, denominado <<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 88 entre sí de manera natural, que los autores de JMC llaman “componentes independientes del dominio ”. La Figura 8.4 muestra una componente de este tipo. Como 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. Capítulo 8 103
- 104. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 89 90 publicación en StickyMinds , y encuentran su último libro sumamente útil. Presentan entonces una propuesta alternativa: Usar historias de usuario para mantenerse dentro de eXtreme Programming, elaborar con ellas un 91 diagrama de casos de uso, identificar casos faltantes usando una matriz CRUD , y desenvolver un perfil de 92 operaciones siguiendo las técnicas del libro de Denney y para aquellos casos que lo ameriten , desarrollar casos 93 de uso completos siguiendo los parámetros del libro de Allistair Cockburn . 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 94 Development o TDD ). De ese modo, opinan, solucionarán la mayoría de los problemas sin modificar demasiado el tratamiento actual de los requerimientos. 2 Como T 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: los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo información incompleta sobre necesidades y requerimientos especificaciones incompletas mitigación: 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 proceso sistemático de identificación JMC XP + TST A M documento donde priorizar requisitos y especificarlos identificar funciones así como atributos de calidad definir detalles de la porción de funcionalidad en el sprint especificar interfaces internas y externas construir historias de usuario, narrativas y/o casos de uso balancear requisitos y necesidades del cliente contra restricciones del equipo M A funciones y requisitos no funcionales B sin especificar demasiados requisitos derivados M después del juego de planificación no hay clara definición de las interfaces A no hay contexto donde situar las A especificaciones se pasa a la estimación sin hacer un M análisis más profundo de la funcionalidad los modelos no son discutidos con el validar requisitos menos comunes A dueño del producto temprano Tabla 8.2: Comparación entre Métodos de Desarrollo por su Beneficio 89 90 91 92 93 94 M M A A A A http://www.stickyminds.com/ [DENNEY, R., 2012], Use Cases Levels of Test. A Four-Step Strategy for Budgeting Time and Innovation in Software Test Design. CRUD es la secuencia de iniciales de las palabras inglesas CREATE, READ, UPDATE, DELETE. Estas actividades surgen del uso 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. Siguiendo a Denney, los casos que tengan mayor frecuencia de uso se desarrollan primero. [COCKBURN, A., 2000], Writing Effective Use Cases. Fundamental en XP, el TDD se basa en un ciclo corto de repeticiones: primero el desarrollador escribe un caso de prueba automatizado que define una mejora deseada o nuevas funcionalidades. El 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”. 104 Capítulo 8
- 105. Boria et al. 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 Capítulo 8 105
- 106. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. C Aceptar oferta Realizar contraoferta Rechazar oferta Ingresar Inmueble Cerrar Acuerdo Ofertar Comprar Eliminar propietario Propietario U C Autenticar propietario Cliente Ofertar Alquilar CLASES................................ Buscar inmueble CASOS DE USO Registrarse Luego se listan las clases que surgen de los casos de uso y se analizan para constatar si las cuatro funciones CRUD 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. D U R 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. 106 Capítulo 8
- 107. C Aceptar oferta Realizar contraoferta Rechazar oferta Ingresar Inmueble Cerrar Acuerdo Ofertar Comprar Eliminar propietario Propietario U C Autenticar propietario Cliente Ofertar Alquilar CLASES................................ Registrarse CASOS DE USO Buscar inmueble Boria et al. D U R 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 95 frecuentes y que por lo tanto conllevan poco riesgo. En las palabras de Denney , “es mejor tener una estrategia para utilizar el tiempo sabiamente, y saber cuales 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 96 desconocida. Según Denney , la precisión es despreciable en este momento, basta con conocer un orden de 95 96 Use Case Level of Test, op.cit., página 6. Use Case Level of Test, op.cit., páginas 40 y 41. Capítulo 8 107
- 108. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 97 modo que el intervalo elegido es el mes. En la matriz que estamos generando (llamada QFD por Denney, dada la similitud existente entre su matriz de 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 59 clientes nuevos 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 3830 59 0.01 rechazos acuerdos cerrados autenticaciones de propietario eliminar propietario Tabla 8.6: Estimaciones de Actividad porcentaje de esfuerzo 659 18% 3 20% 0.125 1250 34% 1 38% 0.03 300 8% 5 9% Propietario ranking 1 peso relativo 1000 ejecuciones por mes 10000 Cliente Cantidad Administrador Con esas estimaciones, la matriz de QFD queda con los datos siguientes: Registrarse 0.06 0.059 Buscar inmueble Ofertar Alquilar ACTORES CASOS DE USO................................ 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). 108 Capítulo 8
- 109. 1 766 21% 0.06313 63.13 2% Rechazar oferta 0.002 2 0% Realizar contraoferta 0.02 Ofertar Comprar 0.01 Cerrar Acuerdo 0.0383 Ingresar Inmueble 20 59 59 1 1 110 110 330 330 9% 10% 3% Actualizar Datos 4 0% Limpiar Datos 23% 2% Eliminar propietario 2 1% Autenticar propietario porcentaje de esfuerzo 3% CASOS DE USO................................ ranking 100 0.383 ACTORES Cliente peso relativo 1000 ejecuciones por mes 10000 Administrador Cantidad Propietario Boria et al. 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 Capítulo 8 109
- 110. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 98 incomparables. En este caso Marcela se inclina por el formato propuesto por Allistair Cockburn en su libro . A menudo se propone la siguiente estructura en el 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: los clientes nos dan información incompleta sobre las necesidades y requerimientos del producto dando lugar a mucho retrabajo 98 XP + TST 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 [COCKBURN, A., 2000], Writing Effective Use Cases. 110 Capítulo 8
- 111. Boria et al. 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 aun en aquellos casos en los que se construyen modelos del producto estos son pocas veces discutidos con el dueño del producto Los perfiles operativos se ocupan de establecer ese equilibrio cuando hay presiones de recursos 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 DRE 2 Un conjunto definido de requisitos del cliente es especificado y priorizado a partir de necesidades, expectativas y limitaciones identificadas DRE 3 Un conjunto de requisitos funcionales y nofuncionales, del producto y de las componentes del producto que describen la solución del problema a ser resuelto, es definido y mantenido a partir de los requisitos del cliente DRE 4 Los requisitos funcionales y no-funcionales de cada componente del producto son refinados, elaborados y asignados DRE 5 Interfaces internas y externas del producto y de cada componente del producto son definidas se sigue un proceso sistemático para la identificación de lo que el cliente necesita para que tenga lo que quiere según lo que dice se construye un documento que permite priorizar los requisitos y especificarlos de modo que su revisión y análisis sea posible la especificación de los requisitos debe permitir identificar funciones así como los atributos de calidad no funcionales del producto DRE 6 Conceptos operacionales y escenarios son desarrollados Capítulo 8 antes de encarar un sprint se deben definir los detalles de la porción de funcionalidad que se va a incluir parte de la especificación debe dirigirse expresamente al entorno de funcionamiento del producto, sean interfaces internas o externas como parte del mecanismo de entendimiento de los requerimientos es necesario construir historias de usuario, narrativas y/o casos de uso que expliquen el uso esperado del producto 111
- 112. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 que hasta años antes. T se enfrenta al problema de detectarlos antes que el cliente. Revisando las planillas analizadas en su momento junto con los Problemas de Requisitos, que se conglomeraron en otras cuatro, a saber, ‘Problemas de Diseño’, ‘Problemas de Integración’, ‘Problemas de Verificación’ y ‘Problemas de Validación’, los 2 cuatro protagonistas de nuestra historia en T 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. 112 Capítulo 8
- 113. Boria et al. riesgo o problema: 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 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 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 mitigación: 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 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 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: 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 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 no siempre la densidad que calculamos está basada en datos creíbles debiéramos poder justificar ante el equipo el retorno de la inversión que supone verificar usando inspecciones mitigación: 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 aplicar a rajatabla auditorías de proceso y producto hasta que se fije la conducta de prueba sistemática automatizar todas las pruebas 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 Capítulo 8 113
- 114. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 99 Máximo, utiliza las interpretaciones que de ellos hace Barry Boëhm en su obra . Para ellos entonces, verificar es comparar si lo que se realiza cumple con lo especificado, mientras que validar es garantizar que el producto satisface las necesidades del cliente. 2 100 Para verificar sus productos, T utiliza múltiples herramientas. Las revisiones , ya sean inspecciones por 101 102 pares, recorridas , revisiones estructuradas o revisiones continuas ; 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 103 caídas o fallas del sistema con el propósito de detectar errores en el producto , pero también como herramienta 104 de diseño 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. 105 Para validar sus productos T2 hace uso de actividades en las que participa el DP . Al planificar el Sprint el equipo crea el modelo que representa la funcionalidad deseada y lo “ejecuta” frente al DP. Esto permite validar la 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 101 102 103 104 105 Véase para mayor detalle [FREEDMAN e WEINBERG, 1990]. N. del A. Hemos traducido walkthroughs como “recorridas”, manteniendo la consistencia histórica con [BORIA, J., 1987]. Siguiendo a [BECK, K., 2000] consideramos a la programación de a dos una forma extrema de revisión continua. Probar el programa para “asegurarse que funciona” es un error de enfoque que disminuye la efectividad de la prueba. Test Driven Design en [BECK, K., 2000] Dueño del Producto, Capítulo 3. 114 Capítulo 8
- 115. Boria et al. Figura 8.8: Modelo V de Desarrollo de Software La rama derecha del modelo en V define la correspondencia entre las actividades de 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 106 que la reparación introduce nuevos errores con mayor probabilidad de la que tendría repararlo con tiempo . 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], Capítulo 8 115
- 116. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 116 Capítulo 8
- 117. Boria et al. 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, Capítulo 8 117
- 118. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 107 fanatismo 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. 118 Capítulo 8
- 119. Boria et al. 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 108 capacidad de encontrar defectos, la recorrida. Hay un libro de Yourdon 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: Objetivos 108 Recorridas Obtener retroalimentación temprana sobre la manera de avanzar con el Revisiones Estructuradas Mostrar que el producto tiene la calidad esperada Inspecciones Ubicar todos los errores posibles y corregirlos hasta alcanzar un nivel de calidad prefijado YOURDON, Edward, 1989, Structured Walkthroughs. Prentice-Hall. Capítulo 8 119
- 120. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS Recorridas producto y corregir errores si hubiera Revisiones Estructuradas Inspecciones Criterio de Entrada Se identifica la necesidad en el calendario del proyecto o el autor u otro lo deciden El autor solicita la inspeción y confirma que el producto cumple con los criterios para ser inspeccionado Decisiones Las decisiones las toma el autor Cierre de las Cuestiones Fuera del alcance del procedimiento La gerencia estima que el producto está listo, se han publicado los criterios de calidad, el autor confirma que se puede empezar El equipo de inspección informa y recomienda, la gerencia decide La gerencia controla como parte del proyecto Tamaño Dos o más personas, sin límites Quién esté disponible Composición del Equipo Liderazgo Autor Preparación Opcionalmente se distribuye el material con horas de anticipación Presentador Mediciones Recogidas Usualmente el autor Opcional, raramente se hace Informes Lo emite el autor a su discreción Captura de Datos No es requerida Al menos tres, no más de los Líderes técnicos y colegas del autor Generalmente un líder técnico del proyecto Hay una revisión individual previa siguiendo criterios establecidos en lista de chequeo Autor o lector designado Generalmente se hacen como en inspeciones pero no son requeridas, depende de la empresa Informe con la lista de defectos, cuestiones y acciones realizadas No es requerida El equipo define la disposición del producto y acciones futuras El moderador controla de acuerdo a los criterios del equipo Tres por lo menos, no más de siete Colegas del autor elegidos bajo criterios Moderador capacitado Hay una revisión individual previa siguiendo criterios establecidos en lista de chequeo y con materiales de soporte Lector designado o nadie Requeridas formalmente, esfuerzo, tiempo, tipo y número de cuestiones Informe con detalle de lo detectado, invertido y actuado 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 2 embargo, veamos como las adaptaron Marcela y los gemelos en T . 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 2 adaptado el método de revisiones estructuradas para su uso en sprints. Recordando los inicios de T , cuando se realizaba el “remate” de tareas, cuando un equipo de trabajo termina un producto que amerita ser revisado, lo 2 que se define en el juego de planificación del Sprint, invoca mediante la Intranet de T (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. 120 Capítulo 8
- 121. Boria et al. 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. 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 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 2 elección de entrenamiento anual pago por T . 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. 2. 3. 4. Capítulo 8 El conjunto de casos de prueba que se tiene que usar Los datos que tienen ser utilizados cada vez que se corran los casos Los ambientes en los que tienen que correr las pruebas Las pruebas de regresión incluidas en las pruebas de dicho tipo 121
- 122. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 5. 6. 7. 8. 9. 10. El número de defectos tolerados por categoría de severidad El mínimo de funcionalidad cubierta por las pruebas (cobertura) Objetivos de desempeño de las pruebas a ser alcanzados (performance) Objetivos específicos de volumen (si aplican) Objetivos de confiabilidad (si aplican) 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 FLUJOS ALTERNATIVOS El sistema almacena los datos del nuevo usuario en su base de datos y pasa al CU de Ingresar 7a El sistema encuentra un usuario con la misma identidad (nombre, tipo y 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 122 Capítulo 8
- 123. Boria et al. 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. Capítulo 8 123
- 124. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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). 124 Capítulo 8
- 125. Boria et al. 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. Capítulo 8 125
- 126. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 existente entre los procedimientos en uso por T 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 acordar con el equipo la estrategia de verificación, identificados los productos a evaluar y con qué métodos, el cronograma de las diferentes evaluaciones, los VER 2 Una estrategia de verificación es desarrollada e criterios de entrada, discontinuación y aceptación implementada, estableciendo el cronograma, (garantizando que la cobertura mínima es uno de revisores involucrados, métodos para verificación ellos) y los ambientes de prueba cuando aplican 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 aplicar a rajatabla auditorías de proceso y producto revisiones por pares, son ejecutadas 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 los datos obtenidos de las pruebas y las inspecciones, analizados y puestos a disposición de las partes recorridas y revisiones técnicas, deben ser analizados interesadas y discutidos en la reunión mensual de cartera 2 Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T 126 Capítulo 8
- 127. Boria et al. Resultados Esperados de VAL en el MPS Atividades Internas en Tahini-Tahini VAL 1 Los productos de trabajo a ser validados son identificados acordar con el cliente y el equipo la estrategia de 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 2 Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T 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. Capítulo 8 127
- 128. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS Diseño y Construcción del Producto – PCP riesgo o problema: 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 el sprint de estabilización está teniendo problemas porque el equipo no reconoce algunas decisiones de diseño tomadas que impactan en las pruebas la integración a menudo fracasa en el primer intento, haciendo perder un día de pruebas cada vez hemos intentado reinventar la rueda en varias ocasiones 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 en casos particulares se ha entregado la documentación incompleta o en formato diferente del acordado mitigación: desarrollar criterios universales para iniciar un análisis de alternativas de diseño basados en los objetivos de 2 negocios de T y el proyecto documentar el diseño, sobre todo el porqué de la selección de componentes, apoyado en los requisitos, sobre todo los no funcionales realizar un análisis de causa para identificar acciones aplicar el análisis de reuso ampliándolo con componentes del mercado 109 reforzar el sentimiento de YAGNI utilizando solo pruebas que han sido aprobadas por el equipo en el momento de aprobar el plan del sprint 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 110 análisis de reuso que ya viéramos para incluir entre las opciones componentes que se pueden adquirir fuera de 2 T . Esto de inmediato da frutos porque Mariano mantiene un cuaderno de 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 2 cuáles son los productos que compiten con las líneas de producto de T y orientarlas hacia las necesidades del mercado. De ese modo, los equipos no tienen que cambiar ni un ápice sus procesos, un 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. 2. 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. 110 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. 109 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. Adopción o Diseño de componente, si aplica, se realiza el ajuste de la componente, de acuerdo a las You Ain't Gonna Need It (No vas a necesitarlo) Capítulo 7, Figura 7.2: Análisis de Opciones sobre Reuso, página 22. 128 Capítulo 8
- 129. Boria et al. 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 2 objetivos de negocios de T y el proyecto PCP 2 Las soluciones son seleccionadas para el producto o componentes de producto, con base en escenarios definidos y en criterios identificados PCP 3 El producto y/o componente del producto es 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 rehacer la revisión de la documentación en el sprint criterios definidos de estabilización Tabla 8.21: Cobertura de Resultados Esperados de PCP Capítulo 8 129
- 130. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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: 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) 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 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 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 cediendo a presiones propias los programadores suelen subir código defectuoso al ambiente de integración mitigación: 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 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 asegurar la compatibilidad de las interfaces mediante una mini-inspección antes de subir un módulo a integrar dedicar parte del procedimiento de análisis de impacto al análisis de interfaces 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 orientar a los equipos para que generen sus propias demasiadas pautas, salvo lo que está en scripts de la reglas siempre que incluyan a las normas herramienta organizacionales o reciban dispensa para no hacerlo en el pasado hemos creído haber aprobado una los datos de la integración deben ser cuidadosamente integración cuando en realidad no se había corrido ingresados en la herramienta y los resultados deben todavía ser analizados como parte del scrum diario algunos casos de la base de pruebas de regresión han añadir a la descripción del rol de ingeniero de pruebas dejado de ser útiles y nuevos casos que debieran haber el procedimiento de mantenimiento de la base de sido incluídos no lo han sido regresión no en todos los casos se ha desarrollado la orientar a los scrum master para que revisen el documentación prevista por contrato a la par del backlog y cuestionen la falta de tareas relacionadas producto en sí, lo que a menudo provoca sofocones con documentación contractualmente obligatoria sobre el final 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. 130 Capítulo 8
- 131. Boria et al. 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. Capítulo 8 131
- 132. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS CAPÍTULO 9 - AMPLIANDO LA CAPACIDAD DE DECISIÓN (NIVEL C de MPS-SW) 9.1 Una Gestión Ambiciosa 2 Hasta acá la gestión de T 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 111 who do the right thing" 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 132 Capítulo 9
- 133. Boria et al. Status Quo Nivel C SCAMPI 112 Ingresos Gastos Ingresos Gastos Ingresos Gastos 32.1 25.3 0.8 0.032 1.6 0.069 Probabilidad 0.98 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 2 hacer ingresar el producto de T 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 2 T 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 113 que vimos ya en el Capítulo 8 , Marcela procede a definir con precisión el significado y el uso del término dentro 2 2 de T . Siguiendo el uso de IEEE, el MPS y el CMMI, “Riesgo” en T es un problema potencial, es decir algo que no ha 114 ocurrido aun. Existe riesgo en todas las actividades, porque el futuro es incierto. Se le atribuye a Niels Bohr la frase “Nada es más difícil de prever que el futuro” e ironías aparte, nada es más cierto desde nuestro conocimiento 2 científico. Marcela elige la forma más amplia de definir un riesgo. Su uso en T 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 113 114 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 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. http://www.aps.org/policy/reports/popa-reports/energy/modeling.cfm Capítulo 9 133
- 134. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 115 2 y hasta los métodos de evaluación . Una modificación a la política de calidad de T define el alcance de la aplicación de la gestión de riesgo con precisión. 2 Lo que Marcela se propone es que todos los que trabajan en T , 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 116 siguen los pasos definidos por Boehm : 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 preventa Fuente de riesgos a evaluar cliente dominio tecnología competencia reuso 115 116 117 alto nuevo, procesos débiles, teoría X de 117 gestión desconocido, baja tecnología, alto impacto en clientes del cliente novedosa, nuevas API, nuevas herramientas existen buenos proveedores con mucha experiencia escasísima probabilidad de reuso Categorias medio bajo nuevo, procesos OK, gestión moderna conocido, procesos OK, gestión moderna conocido en parte, tecnología moderna, impacto medio en clientes del cliente conocida, algunas nuevas herramientas existen buenos proveedores con nuestra misma experiencia algo de reuso pero no en ciertos módulos críticos conocido, tecnología de avanzada, impacto manejable en el cliente conocida y compatible 100% dominamos el mercado fundamentalmente adaptaciones a productos nuestros Ya vimos en el Capítulo 8 que se ha eliminado la evaluación anual, remplazada por la evaluación continua. BOEHM, B., 1989, Software Risk Management. http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y 134 Capítulo 9
- 135. Boria et al. Fase kickoff Fuente de riesgos a evaluar tradeoff de sprints con requisitos alto Categorias medio bajo demasiada funcionalidad para el release planificado no entiende el problema y está totalmente impedido de tomar decisiones muy altos, relacionados con la tecnología a incorporar y la curva de aprendizaje se puede modular la funcionalidad para reducir la duración se prefiere calidad en lo entregado a muchas funciones entiende el problema pero está limitado en su capadidad de decisión un poco más alto que lo habitual por su duración operativo, resolutivo, independiente, capaz desarrollo nuevo vs arreglos nunca hay tiempo para arreglar porque lo nuevo siempre tienen mayor prioridad hay que estirarse un poco para poder arreglar lo del sprint anterior, pero es manejable el 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' 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 no hubo mucho tiempo para arreglar y el sprint de estabilización es corto hay presión por incluir siempre 'un poco más' pero hay posibilidad de bajar el ritmo cada dos sprints el dueño del producto duda sobre lo que necesita quedan cosas para arreglar pero entran en el sprint si no surgen algunos defectos enmascarados dueño del producto costos del proyecto sprints estabilización costos de mantenimiento habituales el dueño del producto sabe lo que necesita y sabe explicarlo llegamos con muy poco para arreglar, se puede usar tiempo par refactorear entrega tardía el dueño del el dueño del el dueño del producto producto es producto negocia prefiere un producto terminante respecto calidad por fecha de estable a que se de la fecha de entrega entregue a tiempo entrega y no hay negociación 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 2 almacenado. Por ejemplo, la primera decisión de un proyecto es el método organizativo que se va a dar. En T 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. Capítulo 9 135
- 136. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 de riesgos en T . 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. 136 Capítulo 9
- 137. Boria et al. Planilla de Definición y Control de Riesgos ID - identificador del riesgo Descripción del Riesgo - problema potencial ( condición y consecuencia) Prob - probabilidad de que el riesgo se transforme en un problema Prioridad en este análisis - ranking pro exposición Acción - acciones a llevar a cabo para lidiar con el riesgo Descripción del Riesgo Añada las columnas que sean necesarias para monitorear la evolución de los riesgos. 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 la última vez - muestra el cambio ocurrido # Veces en la lista - resistencia a las acciones Quién - persona responsable por las acciones Cuando - fecha en la que se revisarán las acciones Prob Perd Exp ID Condición Nombre del Proyecto: Fecha: Preparado por: Prioridad Prioridad # Veces en este la última en la análisis vez lista Acción: eliminación, mitigación, transferencia, disminución, o tratamiento de la contingencia Quién Cuando Consecuencia 1 2 3 4 5 6 7 8 9 10 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 2 2 proyecto se resienta por ellos. En primer lugar las estrategias de T (T 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 118 materializa. Si hemos sido nosotros mismos los que hemos tomado la decisión apresuradamente , entonces es abusivo que intentemos hacer esto. Sin embargo, es posible que las ventajas de usar A y B sean tan grandes que podamos negociar 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. 119 Siguiendo con nuestro ejemplo, dada que la situación de incompatibilidad es nuestro ‘gato de Schrödinger , 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 119 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. 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 Capítulo 9 137
- 138. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 procedimiento de T 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 1 2 3 4 5 6 7 8 138 Probabilidad 0.8 0.8 0.8 0.8 0.6 0.5 0.5 0.5 Pérdida 90 84 69 66 64 71 40 32 Exposición 72 67.2 55.2 52.8 38.4 35.5 20 16 Capítulo 9
- 139. Boria et al. 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 2 establecido en la política de calidad, y que se aplica universalmente en T . 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 120 naciones. Esta visión del azar, compartida en otras ciencias , fuerza a las organizaciones a repensar su estructura y el manejo de riesgo. Puesto que un ‘cisne negro’ no se puede prever, es imprescindible organizarse para que la llegada del mismo no sea destructiva en el corto, mediano y largo plazo. En el corto plazo las empresas y organizaciones 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]. Capítulo 9 139
- 140. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 9.9 Decisiones Formales Del mismo modo en que los riesgos son analizados siguiendo procedimientos bien definidos para agregar valor, recogiendo nuevos riesgos y las soluciones correspondientes que se deben considerar, hay decisiones 121 especiales que se hacen, cuando corresponde, sobre la base de métodos formales . El propósito de usar métodos formales al tomar decisiones, es que siguiendo un estándar formal se pueden almacenar, comparar, analizar y 2 reutilizarse las decisiones basándose en los resultados que arrojan. Al principio, T 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 2 correlaciones simples. T 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 122 a un profesor suyo, el Dr. Zito, quien le ha recomendado varias lecturas , 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 122 De hecho en la literatura hay muchas publicaciones que hablan a la vez de riegos y decisiones formales. En particular el Dr. Zito recomendó el libro de CLEMEN, 1997, pero Marcela también encontró útil un libro mucho más sencillo, Decision Analysis in Projects. Learn to Make Faster, More Confident Decisions, de [Schuyler 1996]. 140 Capítulo 9
- 141. Boria et al. 1. 2. 3. 4. 5. 6. 7. 8. Definir correctamente al problema a resolver. Establecer atributos deseables de la solución. Definir métodos de medición de los atributos seleccionados. Diseñar métodos de evaluación de las soluciones. Generar o descubrir selecciones alternativas. Aplicar a cada solución generada la medición de los atributos deseables. Evaluar mediante los métodos seleccionados las soluciones generadas. 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 Capítulo 9 141
- 142. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 2 Marcela se propone agregar además los métodos al repertorio de toma de decisiones de T . 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 2 se está planteando el problema en un ambiente de relativa incertidumbre, la herramienta que se considera en T 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. 142 Capítulo 9
- 143. Boria et al. 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. Capítulo 9 143
- 144. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 144 Capítulo 9
- 145. Boria et al. 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 = c 0 + c1 X1 + c2 X2 + … + cn Xn + . Los coeficientes cj son los que determinan la variabilidad correspondiente en el diagrama de tornado. Un coeficiente muy grande en 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 123 al lector de los detalles matemáticos y remitimos a los interesados a la literatura clásica . El uso que se le da a la 2 ecuación de regresión en T 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 2 Mariano llega muy excitado a las oficinas de T 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. Capítulo 9 145
- 146. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS - 2 “Colegas de T , 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 2 ningún privilegio técnico ni participación alguna en decisiones financieras internas a T . En este momento está reunido el Board de TransKND en Toronto para ratificar o rechazar el acuerdo, del mismo modo que nosotros lo estamos haciendo acá. Revisemos el acuerdo”. Acto seguido distribuye copias a cada uno, previamente marcadas con resaltador las partes importantes. El Comité discute varias horas, pero al finalizar la 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 Principiantes 124 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 2 arquitecturas de décadas anteriores con los últimos avances tecnológicos. Veamos el producto estrella de T , 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. 2 Pero ahora imaginemos el nuevo gran producto de T , 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] 146 Capítulo 9
- 147. Boria et al. 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. 2. 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. 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. 2 Estos requisitos son centrales para T 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 2 convenientemente empaquetadas. En el caso de T esta arquitectura de referencia debe ser documentada, ampliada y refinada, pero el conocimiento del dominio permite avizorar que ese proceso no va a ser doloroso ni largo. La Arquitectura de Referencia SOA plasma los distintos componentes de una 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 Capítulo 9 147
- 148. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS independencia que este modelo arquitectónico provee y el poquísimo acoplamiento que produce, hay grandes 125 126 parecidos con el diseño de Sistemas Operativos moderno . Hay definiciones bien documentadas de todo lo 127 que es necesario describir y como crear un registro de metadatos . SOA es menos una arquitectura que lo que es un paradigma para la construcción y mantenimiento de 128 procesos de negocios que abarcan sistemas distribuidos de gran porte . Una componente esencial de una arquitectura SOA es el bus. El bus es el gran unificador, permite eliminar la necesidad de conocer detalles de interfaces entre servicios. A cambio exige la existencia de un registro de los metadatos que cada uno espera recibir y la capacidad de cada uno de interpretar metadatos. Esto puede llevar a un gran caos, por lo que todos los autores recomiendan incorporar un nivel de 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 2 Para el proceso de reingeniería dentro de T 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 129 chequeos de antecedentes, el nuevo ingeniero pasa a ser arquitecto del proyecto . Junto con Ana y los gemelos 130 elaboran la arquitectura de alto nivel, aplicando JMC . 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 131 recomiendan un experto que asume el papel de programador jefe del equipo . Será él quién se encargue de los 132 detalles de la envoltura 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 2 86. Una empresa canadiense establece una alianza con T 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 126 127 128 129 130 131 132 [BORIA, J. 1989] http://www.soa.com/solutions/metadata_federation/ Una búsqueda en Google devuelve más de un millón de sitios [JOSUTTIS, N. 2009]. SOA in Practice: The Art of Distributed System Design. ¡Una de esas cosas que ocurren solo en software! Ver capítulo 8, Java Modeling in Color. Ver capítulo 3, Feature Driven Development. 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. 148 Capítulo 9
- 149. Boria et al. 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 2 evaluado decanta de los mismos preceptos de gobierno que se usa en todos los proyectos de T . DRU 5 dice: Las propuestas de reuso son evaluadas de forma de garantizar que el resultado del reuso sea apropiado para la 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 2 gobierno encarnado en las reuniones mensuales del comité de gestión de T . Lo mismo acontece con RAP 10, la adherencia de los procesos ejecutados a sus descripciones de proceso, padrones y procedimientos es evaluada objetivamente y son tratadas las no-conformidades. La 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 Capítulo 9 149
- 150. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 2 Máximo concluye que T 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 2 88. Máximo concluye que T 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. 150 Capítulo 9
- 151. Boria et al. 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 2 Han pasado veinte meses desde que visitáramos a nuestros amigos de T 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 2 empresa de Canadá. Casi dos años más tarde todos los aspectos de T 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 2 está en la ciudad de T . 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. 2 Nuestros amigos de T dedujeron lo mismo de una experiencia particular en los primeros intentos de 2 planificar sus sprints para el proyecto SOA. La estimación del esfuerzo y duración de las tareas se realiza en T , 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 133 software de análisis estadístico 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/ Capítulo 10 151
- 152. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 134 constituye la dispersión . Los gemelos acudieron a Claudio, para abrevar en sus recientemente adquiridos 135 profundos conocimientos de estadística . 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. 2 Claudio se dirige por primera vez a un auditorio dentro de T , pero no es la primera vez que expone en 2 público. Él también es ‘víctima’ del éxito de T y es a menudo invitado a exponer sobre el análisis financiero 2 aplicado al análisis de cartera, como lo viene haciendo en T 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: - 134 135 “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”. 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 Claudio ha iniciado cursos de doctorado en análisis financiero para empresas. De paso, se ha recibido de Actuario. 152 Capítulo 10
- 153. Boria et al. 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 136 con el experimento hasta que las herramientas estadísticas señalen que el resultado es significativo al 10% . 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 137 recuerda sus lecturas de Taleb y los “cisnes negros”. Un proyecto nuevo de SOA marchaba normalmente, es decir de acuerdo con las expectativas, hasta que en el Sprint de 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 138 conocidos subía de ciclo de prueba en ciclo de prueba. Un típico escenario de proyecto fuera de control . 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 2 de causas profundas que no llega a ninguna conclusión. Por primera vez en su historia, T 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. Capítulo 10 153
- 154. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS - “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 139 estructurado, Constantine hablaba de esto, en 1979 . 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 140 Zito. En el viaje de la Facultad a las oficinas ha tenido un ‘Eureka’ y lo transmite al comité. Utiliza un método de 141 Ford que se conoce como “las ocho disciplinas ”, 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é 2 de gestión se han vuelto legendarias en T , material de muchas leyendas nacidas al abrigo de la decisiones 2 tomadas en ella por aquellos que los más jóvenes consideran los popes de T . 139 140 141 [YOURDON, E., CONSTANTINE, L. 1979]. Muchos atribuyen gran parte del material a Constantine, de ahí la cita a medias del Doctor. ¡Eureka! o Heureka en griego “¡Lo he encontrado!”, es una famosa 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. http://es.wikipedia.org/wiki/Ocho_disciplinas_para_la_resoluci%C3%B3n_de_problemas 154 Capítulo 10
- 155. Boria et al. 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”. Capítulo 10 155
- 156. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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’. 142 JAD es la abreviatura que se usa para Joint Application Development , 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 143 alta gerencia. Los participantes deben ser usuarios CRACK 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 Las definiciones iniciales no contenían reglas de negocio suficientemente claras ni completas. 3 4 142 143 Los metadatos no fueron definidos con una plantilla única a la vista, sino que cada uno adaptó la suya a las necesidades que iban surgiendo Los procesos de negocio estaban sufriendo reingeniería al mismo tiempo que se los intentaba describir para construir el sistema No hay una plantilla única, no hay guías de ajuste ni de uso Añadir a los riesgos en preventa el conocimiento del negocio del punto de contacto Colocar una claúsula en el contrato que hace responsable al cliente de las demoras relacionadas con requisitos incompletos Contruir la plantilla estándar para metadatos y los artefactos necesarios para su uso productivo en BiPro [WOOD, S. e SILVER, D., 1995] Ver Capítulo 3. 156 Capítulo 10
- 157. Boria et al. riesgo o problema: 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 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 5 causa(s) raíz (ces): 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 ¿? 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. Capítulo 10 157
- 158. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 144 variable aleatoria relacionada con nuestros proyectos podemos aplicar control estadístico de procesos , 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 2 estadística la forma más parecida es la , 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 145 que Putnam las ha utilizado en sus investigaciones sobre los procesos de software. Figura 10.4: Curvas de la Familia Weibull Aplicar SPC hubiera resultado útil en el proyecto fuera de control, porque nos hubiera dicho que la 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 145 [SHEWHART, 1939] [PUTNAM, L. H. e MYERS, W., 2003] 158 Capítulo 10
- 159. Boria et al. 146 distancia de la media a una, dos, y tres desvíos estándares , 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 adagio 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 146 El atraso en el sprint de arquitectura fue tomado No hay un conocimiento como un buen síntoma, como que el tiempo profundo del comportamiento invertido en al análisis iba a pagarse solo en lo de los procesos y en sucesivo, cuando en realidad se cortó consecuencia la superstición se abruptamente porque se sintió que continuar era impone a la realidad mejor que esperar a entender bien el problema del usuario Tabla 10.2: La Última Fila del Análisis una Vez Completo Aplicar SPC a los procesos críticos. Medida de la dispersión de una variable alrededor de la media de su distribución. Capítulo 10 159
- 160. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 10.8 Correlación y Regresión 2 Si T 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. 2 Considerando que en los años en que se llevan datos en T la masa de ellos es sumamente interesante Jessica propone que se identifiquen tendencias y se las analice. Claudio se ha familiarizado con las técnicas de inteligencia 147 de negocios y propone contratar a un doctorando con quién comparte cursos y sabe un experto en el tema. Así 2 es como, temporariamente, Damián se incorpora al equipo de T . 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 2 Dada la gran masa de datos que posee T 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 148 exceso de información, que puede ser tan paralizante como su falta . Como dijera Stephen Covey, lo principal es 149 asegurarse que lo principal es lo principal . ¿Pero como? Si recordamos el modelo de Kano (Figura 10.6) que vimos en el 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 149 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) [COVEY, S., 1996], First Things First. 160 Capítulo 10
- 161. Boria et al. 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 Capítulo 10 161
- 162. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 150 con el proceso de inspecciones, y colocar un objetivo de eliminar, o disminuir significativamente la porosidad 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. 162 Capítulo 10
- 163. Boria et al. 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 Capítulo 10 163
- 164. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 151 estas hipótesis. Un indicador es siempre un indicador de resultado : mide lo que pasó, ninguno puede medir lo 152 que va a pasar. Pero algunos indicadores pueden ser indicadores de causa porque sus valores sirven para predecir el resultado de las acciones que se encuentran más adelante en el flujo del proceso. Justamente esos 151 152 También se les llama indicadores de efecto, y en inglés, lag indicators u outcome measures. También se llaman indicadores inductores, y en inglés, lead indicators o performance drivers. 164 Capítulo 10
- 165. Boria et al. 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 2 Mientras que T 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 2 Para T el objetivo es ser mejor. No solo ser la mejor de todas las empresas en su rubro, sino mejor que ella misma, ayer. Desde su humilde inicio la empresa no há hecho mas que mejorar. La calidad que muestran sus productos y su 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. Capítulo 10 165
- 166. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 Todavía más importante para T es que sus competidores tienen serios problemas para poder entrar en los 2 mercados de T . Sus métodos ágiles y su perfecta posición en el mercado hacen que constantemente arriesguen 2 márgenes, con las consiguientes pérdidas ocasionales y los dolores de cabeza consiguientes. La calidad de T ha subido el costo de entrada para sus competidores. 2 Además de eso, T puede conseguir los mejores recursos humanos en el mercado porque su mito tiene 2 mucho arraigo. Trabajar para T es un orgullo para los profesionales y es considerada una excelente escuela de 2 negocios. Si alguien recibe una oferta de T es poco probable que la rechace. 10.17 Innovación tecnológica 2 Sin embargo T 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 153 Mariano y Alfredo, quiénes lo comparan al SETI , consiste en la búsqueda constante de nuevas ideas y 2 tecnologías de aplicación. Cada ingeniero de T 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 2 154 leído en la revista de T , llamada SPI Glass. Al principio del programa cuando los ingenieros se contaban por unidades todo lo que se enviaba se publicaba. Hoy, con los 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 154 http://www.seti.org/, SETI es un proyecto de búsqueda de vida extraterrestre. Software Process Improvement, Spy Glass es el nombre del catalejo en inglés. 166 Capítulo 10
- 167. Boria et al. 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, 2 pero las ideas gobiernan la automación. T ha aprendido a reconocer su núcleo pero también a explorar “el espacio 155 en blanco” , aquellas oportunidades que no encajan con sus modelos de negocios o con sus clientes habituales. Johnson define al “espacio en blanco” como: “la gama de posibles actividades que no 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 Capítulo 10 167
- 168. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 156 de Eric Ries, The Lean Startup . 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 2 suspender el proyecto. Sea cuál fuera el resultado, T 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 157 oportunidades hemos mencionado la Ley de Pareto , 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 157 [RIES, E., 2011], The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses Capítulos 2, en la discusión de Lean, y 8, aplicándolo al análisis de perfil operativo. 168 Capítulo 10
- 169. Boria et al. 2 Este método de experimentar nuevas ideas ha dado frutos muy interesantes. T 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 2 estudio, a cambio de una participación en la nueva empresa. T está preocupada por la enfermedad del crecimiento: El anquilosamiento, y lo combate de todas las maneras posibles. QUE HA PASADO HASTA AHORA 2 89. Los valores típicos del proyecto de SOA no corresponden a la historia de los proyectos de T . 90. Un proyecto SOA nuevo entra en crisis y se sale de control. 2 91. Jessica introduce SPC a T . 92. 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. 2 94. Con la ayuda de diversas técnicas se identifican los procesos críticos para T . 2 95. Definidos los procesos críticos T 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. 2 99. La persecución constante de la excelencia sube el costo de entrada para la competencia de T . 100.La innovación sistemática da frutos dulces. Capítulo 10 169
- 170. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 mientras mejoraban los procesos, el objetivo siempre ha sido mejorar la competitividad de T . El precio nunca fue tan alto de manera que los resultados siempre justifican la 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 2 Uno de los factores que aceleraron la maduración de T 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 2 que lo adoptan. El resultado no siempre es tan exitoso como el de T , pero aquellos que no tratan de llegar a la cima no disfrutarán del paisaje! 170 Capítulo 11
- 171. Boria et al. 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-andproductivity/ CAMERON, K., QUINN, R., 2011, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, Jossey-Bass. CARL III, W. J., Unpublished paper, Flow A Theory of Optimal Experience: History and Critical Evaluation. CARLZON, J., 1989, Moments Of Truth, Harper Business. rd CHRISSIS, M. B.; KONRAD M. & SHRUM S., 2011 (3 Edition), CMMI for Development®: Guidelines for Process Integration and Product Improvement, Addison-Wesley. CLEMEN, R., 1997, Making Hard Decisions: An Introduction to Decision Analysis, Duxbury. COAD, P., DE LUCA, J., LEFEVRE E., 1999, Java Modeling In Color With UML: Enterprise Components and Process, Prentice-Hall. COCKBURN, A., 2000, Writing Effective Use Cases, Addison-Wesley Professional. COCKBURN, A., 2005, Crystal Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley. COHN, M., 2006, Agile Estimation and Planning, Prentice-Hall. COVEY, S., 1996, First Things First, Free Press. CONNER, D., PATTERSON, R., 1982, Building Commitment to Organizational Change, Training and Development Journal, v36 n4 p18-26,28-30 Apr 1982. CULBERT, S., 2010, Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing-and Focus on What Really Matters, Business Plus. Referencias Bibliográficas 171
- 172. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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/200203Diaz.pdf EBENAU, R. & STRAUSS S., 1994, Software Inspection Process, McGraw-Hill. FLORAC, W. A. & CARLETON, A. D., 1999, Measuring the Software Process, Addison-Wesley. FOWLER, M., 2003, UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), AddisonWesley. FREEDMAN, D. P. & WEINBERG G., 1990, Handbook of Walkthroughs, Inspections, and Technical Reviews. Dorset House, FRIED, J., 2005, An Analysis of the Correlation between System Engineering Defect Phase Containment and System Engineering Hours at General Dynamics C4 Systems. Se encuentra en: http://www.acims.arizona.edu/PUBLICATIONS/PDF/JenniferFriedMCSproject%205-21-05.pdf. GAUSE, D. & WEINBERG G., 1989, Exploring Requirements: Quality Before Design. Dorset House. GILB T. & GRAHAM D., 1994, Software Inspection, Addison-Wesley Professional. GLASS R., 1997, Software Runaways: Monumental Software Disasters, Prentice Hall. GOULD S., 1996, Dinosaur in a Haystack: Reflections in Natural History, Three River Press. GRIES, D., 1987, The Science of Programming, Springer. HALL, E., 1998, Managing Risk: Methods for Software Systems Development, Addison-Wesley Professional. HIGHSMITH, J., 1999, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House. HIGHSMITH, J., 2001, Agile 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. 172 Referencias Bibliográficas
- 173. Boria et al. JOHNSON, M., 2010, Seizing the White Space: Business Model Innovation for Growth and Renewal, Perseus Books Group. JONES, C., 1996 Applied Software Measurement, McGraw-Hill. JONES, C., 1994, Assessment and Control of Software Risks, Prentice-Hall. JONES, C., 1986, Programming Productivity, McGraw-Hill. JOSUTTIS, N.,2009, SOA in Practice: The Art of Distributed System Design, OReilly Media. KAPLAN, R., & NORTON, D., 1996, The Balanced Scorecard: Translating Strategy into Action, Harvard Business Review Press. KAN. S., 2002, Metrics and Models in Software Quality Engineering, 2nd Edition, Addison-Wesley Professional. KERNIGHAN B. W., & PLAUGER P. J., 1974, The Elements of Programming Style, McGraw-Hill. KNIBERG, H., 2007, Scrum and XP from the Trenches. How we do Scrum, C4Media, Publisher of InfoQ.com. KNIBERG, H. & SKARIN, M., 2010, Kanban and Scrummaking the most of both, C4Media, Publisher of InfoQ.com. KUBLER-ROSS, E., 1997, On Death and Dying. Scribner. KUZNETS, S., 1966, Economic Growth and Structure. Selected Essays, Heinemann. LADAS, C., 2008, Scrumban and Other Essays on Kanban Systems for Lean Software Development, Modus Cooperandi Press. LEFFINGWELL, D., 2007, Scaling Software Agility. Best Practices for Large Enterprises, Addison-Wesley. LUCIA, A.D., LEPSINGER, R., 2007, The Art and Science of Competency Models. Pinpointing Critical Success Factors in Organizations, Jossey-Bass Pfeiffer. SM McFEELEY, B., 1996, IDEAL : A 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. Referencias Bibliográficas 173
- 174. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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. 174 Referencias Bibliográficas
- 175. Boria et al. 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. Referencias Bibliográficas 175
- 176. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS WOOD, S. & SILVER, D., 1995, Joint Application Development, Wiley. YOURDON, E., 1989, Structured Walkthroughs, Prentice-Hall. YOURDON, E., e CONSTANTINE, L. 1979, Structured Design: Fundamentals of a Discipline of Computer Program and System Design, Prentice-Hall. ZAHNISER, R., 1995, System Storyboarding Techniques, American Programmer, Sep 1993. Se encuentra en: http://www.belizenorth.com/articles/SST.htm 176 Referencias Bibliográficas
- 177. Boria et al. 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 Sumario 177
- 178. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 178 Sumario
- 179. Boria et al. 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 Sumario 179
- 180. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 180 Lista de Figuras
- 181. Boria et al. 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 Lista de Figuras 181
- 182. Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS 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 2 Tabla 7.3: Riesgos a T 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 2 Tabla 8.16: Resultados Esperados de VER y Actividades Internas en T .............................................................. 126 2 Tabla 8.17: Resultados Esperados de VAL y Actividades Internas en T .............................................................. 127 Tabla 8.18: Proceso DISENO Y 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 182 Lista de Tablas
- 183. Boria et al. 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 Lista de Tablas 183