El Dr. Richard Turner es Director del Systems and Software Consortium en Herndon, Virginia, una organización dedicada a asistir a sus miembros en esfuerzos de mejora de procesos de TI, así como adaptar procesos existentes a necesidades nuevas. Richard es miembro del equipo de autores originales del CMMI, y co-autor de los libros “Balancing Agility and Discipline: A Guide for the Perplexed”, y “CMMI Distilled”.
¿Sobre qué trato tu presentación en el SEPG LA?
El punto principal que intento comunicar es que el ambiente bajo el que ejecutamos los procesos está en cambio constante, así que debemos ser capaces de responder a estos cambios, de adaptarnos. Los procesos deben facilitar esta adaptación, en lugar de ser un limitante. Los procesos se han convertido más en un mecanismo para controlar, que para habilitar el trabajo.
¿Cuál es tu opinión sobre las evaluaciones/certificaciones de procesos?
En un inicio, los niveles de madurez simplemente eran para que las organizaciones pudieran decir “me encuentro en tal punto del camino, y sé qué debo hacer para seguir adelante”. Desafortunadamente, en algún momento a alguien se le ocurrió decir cosas como que para participar en ciertos proyectos se requería ser por lo menos nivel 3. Esto acarrea el siguiente problema: muchas veces, por el afán de lograr la meta del nivel 3, las organizaciones “sobredefinen” sus procesos, haciéndolos demasiado pesados. Es hasta los niveles 4 y 5 donde se eliminan esos excesos. Así que si una organización se queda en el nivel 3, se ha quedado en el nivel más ineficiente de mejora de procesos. Esta es una consecuencia negativa de que la certificación sea la meta, y no la mejora de procesos.
¿Nos puedes comentar sobre el libro “Balancing Agility and Discipline”, que escribiste con Barry Boehm?
Como saben, existe cierto desacuerdo entre las metodologías estructuradas/disciplinadas y las metodologías ágiles. Básicamente lo que hicimos fue analizar los riesgos y beneficios de cada acercamiento, y estudiar cómo se podrían combinar o configurar para aplicarlos en proyectos específicos, dependiendo de sus características. De tal forma que para cada proyecto se pueda balancear la cantidad adecuada de disciplina y de agilidad. Además, durante el libro estudiamos algunos aspectos vitales para el éxito de los proyectos de software, tales como entender el criterio de éxito de los clientes, o conocer el valor (prioridad) de los diferentes requerimientos —ya que acostumbramos tener sistemas con cientos de requerimientos, en algunos casos que chocan entre sí, y todos son tratados igual.
¿Qué factores hay que considerar para decidir qué tipo de proceso utilizar?
Tal vez el aspecto más importante es cuán volátiles o dinámicos son los requerimientos del sistema. Otro factor es la mezcla de gente. ¿La mayoría del equipo puede manipular procesos sin romperlos, o son “talacheros” que requieren un proceso disciplinado y estructurado? Anteriormente el tamaño del proyecto también era un factor a considerar, ya que los métodos ágiles están originalmente diseñados para trabajar con equipos pequeños. Sin embargo, estos métodos ya se han escalado hacia equipos grandes, así que ya no lo veo como un factor tan importante.
Has mencionado que un buen desarrollador de software debe ser capaz de hacer ingeniería de procesos. ¿En las escuelas se enseña esto? Desafortunadamente no. Conozco una maestra que enseña a sus alumnos a comparar procesos y decidir cuál es más adecuado para cierto proyecto, pero desafortunadamente es mucho material que cubrir, y muy poco tiempo, especialmente en cursos a nivel licenciatura.
Hay lugares que aplican algo llamado “just too late training”, donde se ayuda a la gente a aprender de sus errores. Por ejemplo, los ponen en proyectos y hacen algunas de las cosas que pasan en la vida real, como de pronto quitar a tres miembros de un equipo. Así que las personas llegan a conclusiones como “ah, si hubiera priorizado los requerimientos, al menos podría realizar alguna negociación inteligente y cumplir con el proyecto de la mejor manera posible dadas las limitaciones”.
Así que hay formas de enseñar este tipo de cosas. Sin embargo, requieren mucho tiempo, y se necesitaría al menos un curso de un semestre completamente dedicado a esto.
¿Quiénes son los que ponen mayor resistencia a implantar métodos ágiles?
En mi experiencia, han sido los dueños de los procesos existentes. Estamos hablando de los gerentes medios, y desafortunadamente los SEPG. En general, los directivos no están tan conectados como para que esto les importe, simplemente dicen “estos son los objetivos, y hay que lograrlos”. Sin embargo, pudiera ser que les preocupe perder algún estatus que les sirva de marketing, como lo es una acreditación CMMI, o algo por el estilo. Algo más que sucede, es que los métodos ágiles tienden a descubrir los errores más rápidamente. Y desafortunadamente, en algunos casos el equipo de desarrollo no quiere esto.
¿Alguna recomendación para los lectores de SG?
Aprovechen sus habilidades naturales, cualesquiera que sean, y no sigan ciegamente el camino que han tomado otros. Hagan su propio camino, donde aprovechen sus habilidades.
- Log in to post comments