Si sos programador, o estudiante de programación (o sea, un programador en gestación), es muy probable que estés pensando, "por qué debería interesarme por las metodologías ágiles?". Y sí, es algo bastante común... y lo peor va a ser cuando tedes cuenta que estoy hablando de Ingeniería de Software... sí, esa materia súper aburrida... sí, en esa que no te podías mantener concentrado, y casi que no podías soportar...La verdad que te re entiendo. Yo cuando la cursé tampoco me gustó, y también me preguntaba "el por qué de aprender ingeniería de software". Yo, en ese momento quería aprender a programar, estaba descubriendo el mundo de la programación orientada a objetos, (algo que me cambió la cabeza, la forma de pensar), y mientras tanto, me hablaban de ingeniería de requerimientos, de tablas de decisión, redes de petri, diagramas de flujo de datos, modelos de proceso... La verdad que es algo que a uno no le parece muy interesante cuando en la materia que tenés dos horas antes te enseñan a hacer un sistema que funciona.
Sin embargo, ahora me doy cuenta que la forma que tenía de pensar se debía a que no estaba viendo todo el panorama. Y cuando uno toma conciencia de eso, se pone a pensar. Y llegar a la conclusión de que la "famosa" crisis del software realmente existe. ¿Cómo fue que me di cuenta de eso? Simple, traté de pensar cómo llevar adelante un proyecto de software muy simple. Ahí fue cuando se me ocurrió pensar... "¿Cómo voy a hacer para llevar adelante esto?" Y ahí es cuando te acordás de los modelos de procesos, porque hacer las cosas sin un proceso definido es suicida, uno no puede vivir de la improvisación, no por lo menos cuando dinero en juego, entre otras cosas. No poder cumplir con los requerimientos de los clientes, no poder cumplir con sus necesidades y expectativas, es lo que nos llevaría al fracaso. Así que, por más que seamos los mejores programadores del mundo, no podés andar por la vida programando sin tener en cuenta todas las cosas que trascienden a la programación en sí misma.
Y así fue como me empecé a interesar en todo esto, porque como programador, uno vive en un ambiente y debería entender por lo menos las cuestiones básicas sobre procesos, y cómo lograr llevar a cabo nuestro objetivo con éxito.. y cuál es nuestro objetivo? Entregar software que funcione, en tiempo y forma, y más importante aún, que sea el software que el cliente quiere, espera, y necesita.
Después de esta larga introducción al artículo, si todavía siguen leyendo... voy a empezar con el tema que nos convoca.
¿Cuáles son los motivos por los cuales los proyectos de desarrollo de software fallan? Sí, porque tienen que ser conscientes que muchos proyectos no terminar, son cancelados, o fallan en su cometido... Todo el tiempo, todos los días, a toda hora hay proyectos fallando, que no pueden cumplir con su objetivo. Los motivos a rasgos generales son los siguientes:
- Los proyectos terminan muy tarde, o cuesta demasiado terminarlo: este debe ser uno de los mayores problemas que tenemos al desarrollar software.
- La aplicación, el sistema a entregar, no hace lo que debería hacer: muchas veces pasa que la aplicación se termina, se la entregamos al cliente, y qué nos dice? "Esto no es lo que yo quería"... fuck!
- El sistema es inestable en producción: somos desarrolladores de software profesionales, y creo que es obvio que los sistemas que desarrollamos deberían ser estables, no fallar, no tener pantallas azules de la muerte.. ah, ese era Microsoft, no nosotros... jaja.
- Es imposible trabajar con el código de la aplicación: esto es muy común. Y es lo que nos puede llegar a decir: "no va a haber un segundo release de la aplicación porque no tenemos ni idea de cómo es que funciona el primer release."
El primer intento para paliar la crisis, fue aplicar un proceso de desarrollo, tomado de la ingeniería. Este modelo de proceso es el archi conocido Modelo en Cascada... seguro que se cansaron de verlo... pero vamos a echarle una mirada.
La idea es bastante lógica. Obtenemos todos los requerimientos de nuestro sistema. Después, hacemos el análisis, diseño, codificación, integración, el deploy, y para finalizar mantenimiento. Todas las fases evidentemente son secuenciales. Es una buena idea, y una aproximación mejor que la de no tener ningún plan en absoluto.
Sin embargo, qué podemos cuando nos encontramos con la realidad, y vemos que el cliente no puede definir de antemano las especificaciones del sistema, más que nada porque solamente sabe que "quiere un programita que lo ayude en lo que hace", pero no dispone de la capacidad para describirnos lo que realmente quiere o necesita. Pero bueno, supongamos que tenemos enfrente a un tipo que sabe lo que quiere (existirá alguno?), nos define los requerimientos, entonces nosotros empezamos con el análisis, diseño, codificación y... recibimos un llamado, aparentemente, hay cambios en el mercado, y a la especificación del sistema le tenemos que sumar requerimientos nuevos... oh, shit! qué hacemos ahora? Tenemos que volver a empezar... Todo desde el principio, tomar los requerimientos nuevos, analizar, diseñar, codificar, etc.. todo nuevamente...
Ahí es cuando encontramos el primer problema del modelo en cascada: no tolera cambio en los requerimientos. Cosa que en esta época es imperdonable, con tantas aplicaciones web dando vuelta... piensen en Google... GMail por ejemplo, cambia todos los días practicamente, adaptándose a lo que el mercado necesita... requerimientos dinámicos constantes. "Que quiero tener mail con etiquetas, tener la posibilidad de arrepentirme de mandar un correo, integración con GTalk, video desde el mail, etc..." Eso es el software de hoy, software que se tiene que adaptar a lo que los clientes necesiten, con la mayor velocidad y facilidad posible. Y evidentemente, el mejor plan que teníamos, para esto no nos sirve...
Otro problema que tenemos en este enfoque, es que las distintas fases están aisladas. Cada fase recibe sus entradas, y manda sus salidas. Una vez que mandó las salidas, listo, ya terminó su trabajo. ¿Y qué sucede si los de diseño le pasan algo imposible de implementar a los de codificación? Los de codificación mandarían para atrás el diseño, se volvería para atrás, tal vez los diseño tengan que devolver para atrás hasta análisis... y así sucesivamente... Evidentemente tenemos un problema... un caos... Al parecer, con el modelo en cascada, tenemos problemas serios... uno de ellos es la falta de copromiso... el otro puede ser un overhead innecesario al emplear la división de trabajo en extremo... En ningún momento nadie, excepto el manager del proyecto, tiene una visión total de lo que se está haciendo...
Otro punto que si uno lo piensa bien y que parece ridículo, es la necesidad que nos impone de realizar estimaciones, y planificar todo el proyecto, antes de comenzarlo. ¿Parece lógico planificar qué es lo que se va a hacer de acá a seis meses, por ejemplo? Más cuando uno no puede determinar realmente, qué es lo que va a estar haciendo la semana próxima.
Y acá es cuando uno se da cuenta que el desarrollo de software no es algo simple, y que no es simple porque depende las personas casi totalmente. Y es acá cuando aparecen unas ideas o valores:
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Valorar más el software que funciona que la documentación exhaustiva
Valorar más la colaboración con el cliente que la negociación contractual
Valorar más la respuesta al cambio que el seguimiento de un plan
Nota: Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
Esto es lo que se denomina el Manifiesto Ágil. Según cuenta la leyenda, en el año 2001 se juntó un grupo de profesionales, más que profesionales diría dioses de la informática (Kent Beck, Martin Fowler, Jeff Sutherland, Ken Shwaber, entre otros), y acuñaron la definición de "Metodologías Ágiles" para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales, a las que se consieraban (como vimos en el principio del post) como excesivamente pesadas y rígidas, por su carácter normativos y fuertes dependencias de planificaciones detalladas previas al desarrollo.
Para cerrar esta primer entrega de Intro a ágiles, voy a comentar brevemente qué quiere decir cada uno de los valores del manifiesto.
Valorar más a los individuos y su interacción que a los procesos y las herramientas: es bastante explícito, quiere resaltar que el desarrollo de software lo realizan personas. Las personas, los seres humanos, no somos máquinas. Somos malos realizando trabajos repetitivos. Sin embargo, tenemos la ventaja de ser flexibles, y podemos realizar distintas tareas. Es por eso que se valora a las personas y cómo éstas interactúan.
Los procesos son importantes también, al igual que las herramientas. Pero la clave es que las personas no se tienen que adaptar a los procesos, ni tampoco las organizaciones, si no más bien todo lo contrario.
Valorar más el software que funciona que la documentación exhaustiva: poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un feedback muy estimulante y enriquecedor, lo que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá consegui un documento que contenga requisitos detallados antes de comenzar el proyecto.
Valorar más la colaboración con el cliente que la negociación contractual: las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detaller al principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con feedback continuo durante el desarrollo. También para los casos en los que los requisitos van ser muy inestables por la velocidad del entorno de negocio (o sea, para todos los casos prácticamente... si tenés que hacer un ABM, ya fue... hacelo como quieras, pero para software de verdad, hay que meterle a lo ágil...).
Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija referentes para posibles disputas contractuales entre cliente y proveedor... es decir que no es más que para proteger el "trasero" de los firmantes...
Es por esto que las metodologías ágiles promueven la participación de los clientes en el proyecto de manera activa. Tanto como para refinar requerimientos a lo largo del proceso como para descubrir nuevos o eliminar algunos que en la realidad no sirven. Hay que acordarse que el software es para el cliente, así que cuanto más participe, más posibilidades hay de cumplir con sus expectativas y necesidades.
Valorar más la respuesta al cambio que el seguimiento de un plan: para un modelo de desarrollo que surge de entornos inestables (como GMail o Facebook, como para poner ejemplos...), que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Para resumir:
Y como decimos acá: Google All The Fucking Time. En internet está todo. En la próxima entrega, nos metemos de lleno.
Ahí van links a páginas interesantes:
Los procesos son importantes también, al igual que las herramientas. Pero la clave es que las personas no se tienen que adaptar a los procesos, ni tampoco las organizaciones, si no más bien todo lo contrario.
Valorar más el software que funciona que la documentación exhaustiva: poder ver anticipadamente cómo se comportan las funcionalidades esperadas sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un feedback muy estimulante y enriquecedor, lo que genera ideas imposibles de concebir en un primer momento; difícilmente se podrá consegui un documento que contenga requisitos detallados antes de comenzar el proyecto.
Valorar más la colaboración con el cliente que la negociación contractual: las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detaller al principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con feedback continuo durante el desarrollo. También para los casos en los que los requisitos van ser muy inestables por la velocidad del entorno de negocio (o sea, para todos los casos prácticamente... si tenés que hacer un ABM, ya fue... hacelo como quieras, pero para software de verdad, hay que meterle a lo ágil...).
Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija referentes para posibles disputas contractuales entre cliente y proveedor... es decir que no es más que para proteger el "trasero" de los firmantes...
Es por esto que las metodologías ágiles promueven la participación de los clientes en el proyecto de manera activa. Tanto como para refinar requerimientos a lo largo del proceso como para descubrir nuevos o eliminar algunos que en la realidad no sirven. Hay que acordarse que el software es para el cliente, así que cuanto más participe, más posibilidades hay de cumplir con sus expectativas y necesidades.
Valorar más la respuesta al cambio que el seguimiento de un plan: para un modelo de desarrollo que surge de entornos inestables (como GMail o Facebook, como para poner ejemplos...), que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.
Para resumir:
- La ingeniería de software es buena, aunque les parezca aburrida.
- Tener un plan, por más malo que sea, es mejor que no tener ninguno.
- Tener el mejor plan, es lo mejor. Por eso estamos viendo metodologías ágiles.
Y como decimos acá: Google All The Fucking Time. En internet está todo. En la próxima entrega, nos metemos de lleno.
Ahí van links a páginas interesantes:
No hay comentarios:
Publicar un comentario