Los orígenes de Agile
Aunque tu equipo de desarrollo aún no haya hecho la transición a métodos ágiles como Scrum o Extreme Programming, es muy probable que al menos lo estén considerando. "Agile" realmente aborda algunos de los mayores problemas que han afectado a los equipos de software durante décadas. Sin embargo, muchos product managers, diseñadores y también personas de aseguramiento de calidad están inicialmente desconcertados por Agile, porque aún no están familiarizados con sus roles en los métodos ágiles. Estos métodos definitivamente requieren estos roles, pero atribuyo la confusión a los orígenes de los métodos ágiles. Para iluminar los problemas que "Agile" pretende resolver y para descubrir qué desafíos persisten, es útil que explique los orígenes de Agile.
Muchas personas se sorprenden cuando descubren cuánto tiempo lleva existiendo Scrum, el método ágil más conocido. Surgió en 1986 en Japón. (Un ejemplo de cuánto puede tardar una nueva idea en lograr finalmente su avance.)
Los orígenes de Agile están en el software a medida
Lo más importante es que estos métodos provienen del mundo del software a medida (Custom Software).
Desarrollar software a medida, es decir, software para un propósito específico y para un cliente específico, fue durante mucho tiempo un tipo de desarrollo de software extremadamente difícil. En parte esto se debe a que los clientes notoriamente no saben lo que quieren exactamente. Sin embargo, tienen la necesidad de algo y así firman un contrato con una empresa de software a medida o se sientan con sus equipos internos de TI para que trabajen en ello. Pero cuando se les entrega algo, los clientes básicamente dicen que eso no es lo que querían y todo comienza de nuevo, con la frustración creciendo naturalmente cada vez más. Sin embargo, la necesidad básica sigue existiendo y esto ha asegurado el empleo de innumerables desarrolladores de software, empresas y proveedores de servicios.
Además, en el desarrollo de software a medida durante mucho tiempo se llevó la peor parte cuando se trataba de contratar y asegurar los mejores talentos de software. Esto se debe probablemente en parte a que los profesionales prefieren trabajar en empresas que desarrollan software para miles o incluso millones de clientes. La razón es, entre otras cosas, que los profesionales reciben un salario más alto en las empresas donde el equipo de producto debe desarrollar productos de software que muchas personas quieren, porque de lo contrario no ganan dinero. Estas empresas saben que necesitan contratar buenas personas para crear productos exitosos y, en consecuencia, la remuneración también es acorde. Sin embargo, solo un pequeño porcentaje de desarrolladores de software trabaja en software estándar; la mayoría desarrolla software a medida.
¿La ventaja de Agile?
Dado que en el caso del software a medida el cliente asume que sabe lo que quiere, rara vez se encuentra allí el rol del product manager. Igualmente, casi nunca se encuentran diseñadores de User Experience. Las razones son bastante complejas e incluyen cierto grado de desconocimiento (muy pocos en el mundo del software a medida saben lo que hacen los diseñadores UX y para qué se les necesita) y sensibilidad a los costos (reducir costos dejando que los desarrolladores hagan el diseño). Para ser justos, hay que decir que los pocos diseñadores que hay en nuestra industria son inmediatamente captados por las empresas de productos que han entendido cuán importantes son los diseñadores. Por lo tanto, para los equipos que desarrollan software a medida, apenas quedan diseñadores cuando los líderes finalmente comprenden que los necesitan. Del mismo modo, apenas existe aseguramiento de calidad como disciplina propia en el software a medida y se espera que los desarrolladores también se encarguen de las pruebas.
Otro punto importante para entender el mundo del software a medida es que la mayoría de los proyectos de software a medida son relativamente pequeños y están destinados a apoyar las actividades internas de una empresa, como recursos humanos, facturación, producción, etc. Es decir, todas áreas donde hay un número limitado de usuarios y cosas como la escalabilidad y el rendimiento normalmente no son tan importantes.
El proceso en cascada
Anteriormente, en el software a medida se necesitaba el proceso en cascada porque los diferentes stakeholders necesitaban una forma de seguir el progreso durante el largo proceso de desarrollo de las aplicaciones deseadas. Estrictamente hablando, el método en cascada también tiene su origen aquí.
En el software estándar, que se compra por su rendimiento y sus ventajas, se introdujeron algunos roles. El product manager debe recopilar y representar las necesidades de todos los clientes. Los diseñadores deben crear una experiencia de usuario utilizable y deseable, y los testers de aseguramiento de calidad deben verificar que el software funcione como se prometió al cliente en la publicidad.
La solución a los problemas de cascada llegó con los métodos ágiles
En el software a medida, sin embargo, seguían surgiendo los mismos problemas cuando se trataba de crear algo que satisficiera a los clientes. Especialmente para estos equipos, los métodos ágiles significan una fuerte mejora. La comunicación entre clientes y desarrolladores mejora. El riesgo se reduce considerablemente mediante iteraciones más pequeñas y frecuentes. Los clientes pueden descubrir mucho más rápido si les gusta algo que si tuvieran que seguir esperando al final de un largo proceso. Además, los métodos ágiles ayudan a introducir conceptos modernos para probar software y a ahorrar a los equipos las horas de creación de documentos que de todos modos apenas se leen y rápidamente dejan de estar actualizados.
Agile para software a medida y estándar
Básicamente, estas ventajas también aplican al software estándar, pero siempre enfatizo que entonces se deben adaptar algunas cosas. Otra área donde hubo dificultades es la arquitectura o el diseño de software.
Los métodos ágiles animan a los desarrolladores a no aferrarse demasiado a su forma de implementación, porque todo debe poder revisarse o reestructurarse rápida y fácilmente. Aunque esto funciona frecuentemente bien en el software a medida, este enfoque es demasiado ingenuo para grandes servicios de internet que tienen cientos, miles o millones de usuarios.
Por lo tanto, no es sorprendente que muchos equipos de software estándar hayan tenido problemas con los métodos ágiles, porque los orígenes de los métodos ágiles se encuentran en el software a medida. Los muchos libros, artículos y cursos que no mencionan ni product managers ni diseñadores de User Experience (diseñadores de interacción y diseñadores visuales) no están pensados para el desarrollo de software estándar.
Los equipos que quieran cambiar a métodos ágiles en el desarrollo de software deberían verificar previamente si la empresa que va a ayudar a su organización también comprende lo que se requiere para el software estándar. Esto no siempre es el caso, pero sí con la suficiente frecuencia.
