Metodología ágil

El enfoque ágil para el desarrollo de software busca distribuir de forma permanente sistemas de software en funcionamiento diseñados con
iteraciones rápidas.
Sin embargo, la frase "metodología ágil" es engañosa porque implica que el enfoque ágil es la única forma de abordar el desarrollo de
software. La metodología ágil no hace referencia a una serie de indicaciones sobre qué hacer exactamente durante el desarrollo de software.
Se trata más bien de una forma de pensar en la colaboración y los flujos de trabajo, y define un conjunto de valores que guían nuestras
decisiones con respecto a lo que hacemos y a la manera en que lo hacemos.

En concreto, las metodologías ágiles de desarrollo de software buscan proporcionar en poco tiempo pequeñas piezas de software en
funcionamiento para aumentar la satisfacción del cliente. Estas metodologías utilizan enfoques flexibles y el trabajo en equipo para ofrecer
mejoras constantes. Por lo general, el desarrollo ágil de software implica que pequeños equipos autoorganizados de desarrolladores y
representantes empresariales se reúnan regularmente en persona durante el ciclo de vida del desarrollo de software. La metodología ágil
favorece un enfoque sencillo de la documentación de software y acepta los cambios que puedan surgir en las diferentes etapas del ciclo de
vida, en lugar de resistirse a ellos.

METODOLOGAS CONCEPTO VENTAJAS DESVENTAJAS

Scrum

 Permite al equipo dividir el  Al inicio del proyecto, es

Agiles El desarrollo ágil de software proyecto en etapas y así
envuelve un enfoque para la toma centrarse en cada una de
de decisiones en los proyectos de forma individual. Esto
software, que se refiere a métodos permite trabajar más rápido.
de ingeniería del software basados  Las metodologías ágiles
en el desarrollo iterativo e permiten adaptar el
difícil determinar con
precisión la cantidad de
tiempo y dinero que se
necesitará para completarlo,
debido a los requisitos en
constante cambio.

incremental, donde los requisitos y
soluciones evolucionan con el
tiempo según la necesidad del
proyecto.
proyecto a medida que
avanza. Así, ante cualquier
cambio que surja, es muy
sencillo volver a organizar el
equipo en relación con los
nuevos objetivos.
 El equipo necesita tener una
base sólida y habilidades.
 Se requiere un alto nivel de
interacción entre el cliente y
los desarrolladores.
 La falta de atención a la
documentación puede
dificultar que los nuevos
miembros del equipo
accedan a la misma.
Empresas y sus metodologías
Amazon
Método Scrum
Una de las principales prácticas que le permitió a Amazon adoptar Scrum, y que fue clave para el éxito de este, fue la Autonomía en los
equipos de trabajo.
Sin entrar en detalles del proceso de adopción (que abordaremos en otras entradas), veamos algunas prácticas que han influido en el éxito de
Amazon aplicando Scrum.

Arquitectura orientada a servicios

Sí, por lo general nos centramos solo en aspectos administrativos, organizativos o de gestión y dejamos a un lado las decisiones técnicas. Sin
embargo, este es un aspecto clave para lograr equipos y desarrollos modulares.
Cómo creamos un entorno interdependiente, donde cada equipo desarrolle soluciones íntegras pero que inevitablemente afectan o se ven
afectadas por desarrollos de otros equipos. No son independientes porque es prácticamente (una de las pocas veces que me permito decir
esta palabra) imposible. Tampoco son totalmente dependientes, porque sería el caos.
La arquitectura orientada a servicios es una de las soluciones para el problema anterior. Esta permite construir componentes de software de
forma rápida e “independiente”. Además, con la gestión y las técnicas adecuadas, permite a los equipos mantenerse sincronizados y salvar los
conflictos de dependencias entre soluciones.

Equipos de dos pizzas

Los equipos de trabajo son pequeños y están organizados en función de los servicios de aplicación. Estos equipos, llamados “equipos de dos
pizzas” porque es la cantidad de personas que pueden alimentarse con dos pizzas, es lo más parecido a un Scrum Team (3 - 8 integrantes),
que es ampliamente aceptado como el tamaño óptimo de un equipo de trabajo.
Estos equipos en Amazon tienen una rotación muy baja, lo que les permite un acoplamiento efectivo y autoconocimiento para estimar mejor los
tiempos y capacidades de desarrollo.

Autonomía y Empowerment
Dentro de Scrum es una de las claves para la Agilidad. Un equipo autónomo, que pueda tomar sus propias decisiones basadas en su
experiencia, sus capacidades, la situación actual, en fin, que pueda ser pragmático, es esencial para lograr motivación, compromiso,
colaboración y sobre todo… Agilidad.
En Amazon, estas prácticas estuvieron presentes desde el principio.

Qué permitió esto:

Al tener autonomía no tienen que esperar por decisiones de la administración o externas al propio equipo, por lo que pueden ir a su ritmo.
Se les otorgó el poder de resolver los problemas con sus propias herramientas, ideas y recursos. No se les imponen mecanismos o formas de
hacer de otros equipos o jefes.
Si hay prácticas a la que Scrum deba dar las gracias en Amazon, son precisamente a la Autonomía y al Empowerment. ¿Por qué digo esto?
Como los equipos tenían autonomía para buscar soluciones a los problemas, una de las soluciones que surgieron en un momento fue Scrum.
Scrum comenzó en un equipo que se interesó por los principios ágiles y lo aplicaron por decisión propia y simplemente “porque quisieron
hacerlo”. Nadie lo impuso. De hecho, la administración no respaldó la adopción de Scrum, sino que cuando comenzaron a tener éxito, se fue
expandiendo de forma orgánica hacia otros equipos.
El cambio y el éxito fueron evidentes a partir de ahí. Hay anécdotas de estas evidencias que les recomiendo leer.
Scrum de Scrums
Cuando tienes varios equipos trabajando en sus soluciones puede parecer que todo está resuelto. Pero la cruda verdad es que no, eso
simplemente trae mayor complejidad para gestionar los proyectos.
¿Cómo se mantienen sincronizados los equipos? ¿Cómo se toman las decisiones que afectan de manera horizontal a los proyectos? ¿Cómo
unir las fuerzas de los distintos líderes? ¿Cómo escalar Scrum a nivel corporativo?
“Simple”: Scrum de Scrums.
Enfoque Pull por encima de Push
Cuando analizamos las causas de fracasos de cualquier proceso de cambio en las organizaciones, es muy común encontrar lo que casi se ha
convertido en un cliché: resistencia al cambio. Esto tiene muchas causas, pero las principales son las siguientes:
La propia naturaleza del ser humano, que quiere seguir como está. Cambiar requiere energía y nosotros no queremos gastarla, como dice
Jürgen Klaric.
Poca o ninguna comprensión de los beneficios que aporta la nueva propuesta.
La nueva propuesta es impuesta por los jefes sin preocuparse lo suficiente en convencer a los que (realmente) la van a hacer posible.
“Pragmatismo cero”. No se analiza la situación actual/real y por tanto lejos de solucionar, se rompe más: se aplica el popular “copy & paste”.
El enfoque Pull se refiere a involucrar a las personas, convencerlas, demostrarles y sobre todo escucharlas. Hacerles ver la necesidad, que
ellos mismos descubran “el dolor” de manera que sientan el deseo de cambiar y de solucionar. Si lo traducimos: halar, atraer, enamorar.