Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Mitos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Mitos. Mostrar todas las entradas

lunes, octubre 26, 2020

Mitos y verdades ágiles

 


Mitos, Monstruos, Leyendas urbanas y otros desvaríos de Ágil y de Scrum

Los mitos son una parte esencial de toda cultura. Y la cultura ágil no es una excepción. De hecho, los mitos sobre agilidad y sobre marcos de trabajo como Scrum son una de las razones de las tantas malas prácticas en las que incurren las personas, equipos y organizaciones que intentan hacer las cosas de la manera ágil. En esta sesión hablaremos un poco de las “invenciones” más comunes cuando de pensamiento ágil y Scrum se trata, y de cómo podemos despojarnos de estas aprehensiones.

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.

Puedes ver y descargar la presentación aquí.



Esta presentación se basa en un artículo de 2013 que puedes encontrar en:


domingo, octubre 26, 2014

#Agiles2014: Ágil es algo que eres, CMMI es algo que usas

Ser ágil significa reemplazar la predictibilidad falsa por la eficiencia
ser ágil significa reemplazar la predictibilidad falsa por la eficiencia
Con una actualización debido al cambio de audiencia, presenté en #Agiles2014 mi disertación sobre Ágil y CMMI. Como en la versión 1.0, durante la SEPG LA 2014 en Manizales, mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se habló en el resto de #Agiles2014.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Para descargar la presentación

Puedes descargar las memorias de esta conferencia de: http://goo.gl/rhNMcf


martes, junio 11, 2013

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

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