La mitología es un
conjunto de mitos relativamente cohesionados: relatos que forman parte de una
determinada cultura. Los mitos son relatos basados en la tradición y en la
leyenda, creados para explicar el universo, el origen del mundo, los fenómenos
naturales y cualquier cosa para la que no haya una explicación simple [1]. En el bestiario mitológico de la
humanidad encontramos seres fantásticos que nos hacen soñar o morir de miedo:
el Dragón, el Fénix, el Grifo, el Kraken, el Cancerbero, la Hidra, el
Minotauro, la Escila, el Pegaso y la Sirena, para citar algunos de los más
arraigados en nuestros temores y pesadillas.
Se trata de esa necesidad
inherente al ser humano de aferrarse a lo desconocido y a lo sobrehumano para
entender mejor la realidad que lo rodea, o simplemente para escaparse de esta.
En el caso de los métodos de software, por ejemplo, estas aprehensiones tienen
su origen en la falta de conocimiento teórico-práctico sobre algo específico,
en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes
practicamos el desarrollo de software. Lo que haré a continuación es mencionar
brevemente algunos de estos arquetipos quiméricos que pululan en el universo de
los métodos ágiles en general y de Scrum en particular.
Ágil
no necesita documentación
¡Esta
es la madre de todas las entelequias! Su origen está en ese valor expuesto en
el Manifiesto Ágil que reza: “valoramos software funcionando sobre documentación extensiva” [2]. En ninguna parte del
manifiesto dice que no se hace documentación, esta debe elaborarse justo cuando
se necesita y solamente la suficiente y necesaria y en los formatos más
adecuados, que llegue al público interesado, que entregue valor a la organización.
Y siendo consecuentes con el primer valor del manifiesto, esta documentación no
se requiere producir con herramientas sofisticadas.
Ágil
significa “no hay un plan”
De
hecho, ágil no soporta el desarrollo sin planeación. Los métodos ágiles usan
planeación y estimación continua para maximizar el ROI. En realidad, ágil es
sobre manejo de alcance. La planeación continua permite redireccionar el compás
del proyecto de acuerdo con el entorno cambiante del mismo; también, asegura un
foco consistente en las prioridades del negocio teniendo en cuenta las
restricciones impuestas al proyecto. Además, la planeación constante posibilita
tomar mejores decisiones y comunicarlas más efectivamente. Plan sí hay, solo
que es dinámico y flexible.
Podemos
rastrear el origen de este mito a otro
valor del Manifiesto Ágil que invoca: “valorar la respuesta ante el
cambio sobre seguir un plan” [2]. Otra vez, se trata de un malentendido nocivo
para la industria del software. Este artículo es un intento más por remediar
esa situación.
Ágil es la solución
tipo “bala de plata” a todos los problemas de la ingeniería de software (Existe
una solución tipo bala de plata)
De
todos los monstruos que llenan las pesadillas de nuestro folclor, ninguno más
terrorífico que los llamados licántropos. Para ellos buscamos balas de plata
que mágicamente los hacen desaparecer para siempre.
La
industria del software tiene muchos problemas, aquellos que precisamente se
quisieron arbitrar con el manifiesto ágil. Sin embargo, ningún método actual,
por sí solo o combinado, es capaz de enfrentar la enorme cantidad de variables
que se mezclan en el ambiente de los proyectos de software, dada la magnitud y
complejidad de la mayoría de estos. Los métodos ágiles no son la excepción. Si
bien su modelo iterativo y adaptativo de gestión posibilita en gran medida la
resolución de muchos impedimentos, siempre habrá que poner de manifiesto
nuestro sentido común para afrontar escenarios hostiles.
Es
decir, además de recurrir a balas de plata, estacas de madera, ajos o apelaciones
a la mediación divina (léase procesos y herramientas, documentación detallada,
contratos y acuerdos de servicio, planes, etc.), necesitamos encontrar
mecanismos que nos permitan interactuar mejor entre nosotros, construir
productos de software por incrementos, colaborar íntimamente con los usuarios y
reaccionar hábilmente ante los cambios que se presentan todo el tiempo durante
un proyecto. Esto es lo que dice realmente el manifiesto ágil.
Ágil no necesita
diseño previo
Este
quizás es un derivado del primer mito. En la realidad, la pieza funcional de
software que se entrega en cada iteración requiere de diseño, el suficiente y
necesario para construir un producto con calidad. Se trata de un diseño
funcional, tan robusto pero tan flexible como se requiera para que todos los cortes
del software se puedan integrar en uno solo. Si pensamos en “diseñar a medida
que avanzamos”, seguramente fallaremos en el intento y nuestro producto nunca
verá la luz del día. El ciclo convencional del software no desaparece porque lo
hagamos ágil: análisis, diseño,
implementación, pruebas y despliegue. ¡Algunas cosas no cambian!
Ágil siempre usa “Historias
de Usuario"
Esta
leyenda también desciende de la primera. Es que la “no documentación” es el más
arraigado de todos los mitos alrededor de los métodos ágiles. Tanto las
organizaciones como los individuos necesitamos de conocimiento explícito, o sea,
de aquel que tenemos y del que somos plenamente conscientes cuando lo
ejecutamos, que está estructurado y
muchas veces esquematizado para
facilitar su difusión. Esas son las claves: estructurado y esquematizado, es
decir, documentado. Otra cosa es el
formato que usamos para documentar, quizás ese es el que debe cambiar, pero ese
es un problema diferente.
Y
en cuanto a las historias de usuario, rutinarias en los métodos ágiles, hay que
decir que ágil no siempre las usa. Hay que usarlas sí, y solo sí, son
apropiadas. Existen otros instrumentos, unos más efectivos que otros, como los
prototipos, los tableros de historias, los simuladores. ¿Alguien ha intentado “porciones
de caso de uso”? Estas últimas son tan livianas como las historias de usuario y
tienen el poder de los casos de uso. Y otro error muy común es creer que las
historias de usuario siempre son elaboradas por el Dueño de Producto.
Scrum siempre Funciona
Ya
tenemos claro que ágil no es una bala de plata y Scrum es ágil, conclusión…
Primero
debemos saber cuándo implementar Scrum en la organización. Y luego debemos
saber cuándo usar Scrum en un proyecto. ¿Está preparado nuestro
cliente/usuario? ¿Habrá un dueño de producto? Más importante aún, ¿está dispuesto
nuestro equipo para entregar software probado y funcionando que sea
potencialmente distribuible cada periodo corto de tiempo – 2 semanas –? ¿Están
claros los valores y principios del manifiesto ágil? Este artículo es un
síntoma de que no lo están. ¿El equipo es autogestionado y experto? ¿Nuestro
usuario está dispuesto a involucrarse al 100%?
Entre
otras, estas son algunas de las cuestiones que debemos responder y establecer
antes de intentar Scrum en nuestros proyectos. Se requiere de cierta capacidad
y de cierta madurez para enfrentar el reto.
Scrum Master igual
a Gerente de Proyecto
Scrum
Master es un rol de gestión, sí, pero no es un gerente como lo conocemos en los
proyectos tradicionales, mucho menos un gerente tipo PMI o algo parecido. “El
Scrum Master es un líder servil, al
servicio del Equipo Scrum.” [3] Un SM es un facilitador, es alguien que se sitúa
en algún lugar entre el equipo de desarrollo y el cliente. También puede verse
como un “guardián de Scrum”, un custodio, alguien que vigila que el proceso se
esté llevando a cabo como lo indica la guía de Scrum.
El
SM puede venir de una PMO, es cierto, pero también puede llegar desde el equipo
de Analistas o de cualquier otro miembro de la organización que tenga las
habilidades y la empatía requerida. El SM tampoco es un desarrollador líder o
arquitecto, también hay que decirlo.
Podemos hacer Scrum sin un Dueño de
Producto o con muchos dueños de producto
Cuando
no tenemos un dueño de producto que está fuera del equipo o, mejor, fuera de la
jerarquía del equipo, perdemos algo precioso e inherente a ágil: la noción del
cliente. Perdemos a la persona que nos puede ayudar a entender lo que realmente
quiere el cliente. “El dueño de producto es el responsable de maximizar el
valor del producto y del trabajo del Equipo de Desarrollo.” [4] El dueño de
producto es quien establece los criterios reales de aceptación del producto,
esto no lo puede hacer otro rol en el equipo o en la organización. Es un hecho,
sin este personaje, el equipo no sabrá que hacer.
Ahora
bien, el dueño del producto es uno solo, no un equipo o comité de dueños de
productos. El dueño de producto es una sola voz y representa los intereses del cliente, es decir, de
todos los interesados en el producto. Más de un dueño de producto puede “adicionar
ruido” al proyecto, es decir, sumar variables que pueden llevar el proyecto a
la devastación. Finalmente, este mito tiene sus orígenes en que ninguna persona
por sí sola tiene el conocimiento completo de lo que quiere la organización,
pero ello no es necesario, solo es suficiente con que tenga contacto con las
personas apropiadas.
Scrum no funciona con CMMI u otros
modelos de procesos y viceversa
He
visto anuncios en la Web sobre “la gran pelea” entre Scrum y CMMI, seminarios
virtuales, tertulias presenciales, diplomados para expertos, como si se tratara
del campeonato de combate definitivo, la última de las grandes contiendas entre
dos “gigantes” del deporte. Esta leyenda urbana tiene sus raíces en la creencia
de que CMMI es predictivo mientras que Scrum es adaptativo. Pero lo que hay que
saber realmente es que CMMI es un modelo de mejoramiento de procesos, nos
indica qué buenas prácticas dan ventaja a nuestra organización, en tanto que
Scrum aporta precisamente el cómo implementar esas prácticas.
En
la realidad es posible integrar estos dos mundos y ponerlos a funcionar en
beneficio de nuestros clientes y de nosotros mismos: a la vez que CMMI permite
describir todos los procesos de la organización y su interacción, Scrum regula
el procedimiento a seguir en el mero proceso de desarrollo. Quizás el detalle
más oscuro en este análisis es aquel de las estadísticas inherentes a toda
organización de alta madurez, pero la cultura ágil de alguna manera impuesta
por Scrum sirve de fundamento sistemático a los requisitos de un proceso de
control estadístico impuesto por CMMI. Las cosas así, es totalmente viable convivir
con Scrum y CMMI en un mismo plano.
Scrum
produce equipos de súper héroes, tipo los Vengadores o la Liga de la Justicia
Necesitamos
expertos, es cierto. Pero estos no se hacen solos. Scrum no es una caneca de desechos
biológicos o químicos y donde podamos caer y levantarnos con poderes
extrasensoriales que permitan leer la mente de los usuarios o con una memoria
prodigiosa que nos faculte a escribir solo las líneas de código correctas o
realizar diseños perfectos en cuestión de segundos.
Si
seguimos Scrum, si asistimos a las ceremonias propuestas por el marco de
trabajo, seremos capaces de entender los obstáculos que evitan mejorar nuestro
desempeño. Y sin la habilidad o deseo de remover esos impedimentos, apenas si podremos
tener mayor visibilidad de los problemas. Y esto simplemente redundará en el
aumento de nuestra frustración, lo que a su vez dejará notar nuestro
comportamiento negativo y menos productivo. Ya lo he repetido, Scrum no es la solución
definitiva, pero ayuda a ser mejores cada vez. La transparencia y la predictibilidad
son los beneficios inmediatos.
¡El plan de mejoramiento personal y profesional lo
ejecutamos de nuestra cuenta!
Más Mitos y Leyendas
Otros
mitos, no menos perjudiciales, son:
- Estamos haciendo Scrum, así que no
necesitamos otras prácticas ágiles como TDD, Refactoring, Pair Programming,
etcétera
- Ágil es menos disciplinado y más fácil
- Podemos lograr agilidad sin cambio
organizacional e individual
- Ágil es igual a Scrum
- Con Scrum podemos hacer cambio en
cualquier momento
La
lista realmente podría ser interminable.
Conclusiones
Scrum
es una idea sencillamente empaquetada y de esta manera podemos transferirla
rápidamente de una persona a otra y de un equipo a otro. Con todo y ello, es
innegable la gran cantidad de concepciones erróneas que tenemos al respecto.
Para sacar estos monstruos y mitos de nuestras mentes es necesario tener
acompañamiento, no basta con aprender por sí solo, necesitamos entrenamiento de
personas que hayan usado exitosamente el método. Las organizaciones, por su
parte, deben concebir un buen plan de implantación del método: configurar el
proceso, hacer proyectos piloto, medir, analizar los resultados, ajustar,
entrenar a los equipos e institucionalizar.
¡Así lo estamos haciendo!
Referencias Web/Bibliográficas
[1] Colaboradores de
Wikipedia. Mitología [en línea]. Wikipedia, La enciclopedia libre, 2013 [fecha
de consulta: 11 de junio del 2013]. Disponible en http://es.wikipedia.org/w/index.php?title=Mitolog%C3%ADa&oldid=67124850
[2] El Manifiesto Ágil de
Software: http://www.agilemanifesto.org/iso/es/
[3] La Guía de Scrum: http://www.scrum.org/Scrum-Guides
[4] La Guía de Scrum:
http://www.scrum.org/Scrum-Guides
Actualización 20200220
Puedes ver y descargar la presentación asociada a este artículo aquí.
