Jorge Luis Boria
Viviana Leonor Rubinstein
Andrés Rubinstein

La Historia de Tahini-Tahini:
Mejora de Procesos de Software...
Boria et al.

PREFACIO
La discusión sobre la posibilidad o no de utilización de métodos ágiles en conjunto con modelos de ...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

PRÓLOGO - CONSULTORÍA EN MEJORA DE PROCESOS
...
Boria et al.

centrado en el MPS: Hay que tener la visión global del destino para que el camino se pueda transitar con
com...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

Autores


Jorge Luis Boria
Master of Engine...
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 o...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

felicidad. En la segunda ecuación la falta d...
Boria et al.

de las organizaciones y de la relación multicausal de los eventos. De este modo preparamos al lector para qu...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

2

asimismo sus oficinas. Una reunión fundam...
Boria et al.

permitieron su éxito. Revisa entonces Lean, Kanban, Scrum, FDD y XP. También, y muy fundamentalmente, el rol...
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....
Boria et al.

la excelencia madurando como organización usando métodos ágiles, para lo cual usaremos un caso de ejemplo y
...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

Criterios de Evaluación por Atributo: DETALL...
Boria et al.

ACT (Actuar) Paso 6: Estandarizar la Solución (y Capitalizar Nuevas Oportunidades). Actividades: Identificar...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

necesidades de proceso y los procesos en uso...
Boria et al.

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

2.4 Focus-Improve-Sustain-Honor
Focus-Im...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

simples. En todos los casos, Arthur se incli...
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 me...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

construyó métodos que permiten aprovecharse ...
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-...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

CAPÍTULO 3 - LOS MÉTODOS ÁGILES: KANBAN, SCR...
Boria et al.

el resultado, se define el alcance de cada Sprint. Es un deber de los equipos ágiles definir una parte del p...
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 usarl...
Boria et al.

En el método Kanban se limita el número de tareas en cada columna. El objetivo es identificar claramente la
...
Mejora de Procesos de Software con Métodos Ágiles y el Modelo de Madurez MPS

métodos, en particular Feature Driven Develo...
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Tahini tahini sp-final_(cover_-_a4)
Próxima SlideShare
Cargando en…5
×

Tahini tahini sp-final_(cover_-_a4)

1.987 visualizaciones

Publicado el

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

Publicado en: Educación
0 comentarios
3 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
1.987
En SlideShare
0
De insertados
0
Número de insertados
95
Acciones
Compartido
0
Descargas
177
Comentarios
0
Recomendaciones
3
Insertados 0
No insertados

No hay notas en la diapositiva.

Tahini tahini sp-final_(cover_-_a4)

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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

×