Somos una comunidad en constante movimiento, divulgación y aprendizaje.
Te invitamos a estar conectado con nuestros eventos por toda Colombia en
http://www.meetup.com/AgilesColombia/
–
Por: Leonardo Agudelo – @sweepnoise
Las metodologías ágiles de desarrollo de software son, a la fecha, parte importante de la respuesta a los problemas planteados en el fenómeno conocido como la crisis del software.
Estas metodologías proponen dividir cada proyecto en partes más pequeñas, permitiendo hacer entregas de software funcional en periodos cortos de tiempo (inferiores a 1 mes) sin darle tanta importancia a la documentación extensiva, anteponen la flexibilidad al cambio sobre planes rígidos, prefieren la colaboración con el cliente que la negociación contractual y valoran más a las personas que a los procesos.
Es normal que tanto los proveedores de software, como los consumidores de los servicios de desarrollo, acostumbrados a metodologías robustas para el desarrollo de software, tomen precauciones a la hora de emprender un proyecto adoptando metodologías ágiles.
Una de las principales razones para ser cautelosos en la adopción de estas metodologías es la aparente falta de elementos y/o artefactos que apoyen el mantenimiento de las aplicaciones, ya que con las metodologías robustas, el mantenimiento se apoya en gran medida en los artefactos generados en etapas de análisis y diseño, que, como vimos, se hacen menos prioritarios en las nuevas tendencias.
Otros factores importantes que influyen en el proceso de mantenimiento son la complejidad del software, el tamaño del mismo y el conocimiento que tengan de él los desarrolladores. Estos factores son impactados por prácticas de las metodologías ágiles de desarrollo de software, permitiendo reducir el efecto negativo de los mismos en el mantenimiento y conservando la agilidad. En este post presentaré algunas de esas prácticas:
Desarrollo dirigido por pruebas (TDD por sus siglas en inglés): es una técnica de desarrollo en la que no se implementa una funcionalidad hasta que no se haya escrito la prueba para la misma, por lo cual se construyen únicamente funcionalidades que pasen las pruebas escritas. Esta técnica se usa en la metodología ágil eXtreme Programming (XP) y aporta mejorando el mantenimiento preventivo y reduciendo el mantenimiento correctivo del software, ya que cada cambio que se haga en el sistema deberá pasar las pruebas escritas en un comienzo, mejorando la calidad y reduciendo los defectos.
Refactorización: consiste en reorganizar el código para que sea más limpio y por ende más fácil de mantener. Con esta técnica no se pretende cambiar los resultados del código sino la forma en que se obtienen. Esta técnica también es tomada de la metodología XP y aporta a la categoría de mantenimiento perfectivo del software.
Priorización: esta práctica, proveniente de XP y de SCRUM, tiene como objetivo que los stakeholders del negocio decidan cuales son los requisitos que en realidad se deben desarrollar como prioridad. Estadísticas del Standish Group dicen que el 64% de características del software empresarial nunca son usadas y el 16% son usadas algunas veces; esta estadística nos muestra que hacemos software que no se requiere, incrementando el tamaño del software cuando no es realmente necesario. Como vimos anteriormente, el tamaño del software es uno de los factores que afectan el mantenimiento. Con esta práctica se pretende que el software sea tan grande como realmente se requiera, aportando al mantenimiento preventivo del mismo.
Diseño simple: en XP se promueve el diseño simple, en el cual no se tienen en cuenta funcionalidades que podrían requerirse en el futuro, sino únicamente las funcionalidades requeridas en la actualidad. Esta práctica previene el incremento innecesario de la complejidad del software, uno más de los factores que afectan negativamente el mantenimiento del software.
Conocimiento del software: las metodologías ágiles se basan en la interacción cara a cara entre el equipo de desarrollo y los stakeholders del negocio, por lo cual, el conocimiento del proyecto y del software se da de una manera tácita en los miembros del equipo. El conocimiento del software es uno de los más importantes factores que afectan positivamente el mantenimiento. En este punto es importante resaltar que lo ideal es que los miembros del equipo que construyen el software sean los mismos que estén presentes en el proceso de mantenimiento.
Como vemos, las metodologías ágiles de desarrollo de software tienen formas efectivas de mejorar el proceso de mantenimiento del software. El reto más grande es ser lo suficientemente maduros como organización para asumir como propias las prácticas ágiles y evolucionar nuestra forma de trabajo adaptándonos a las exigencias cambiantes del entorno sin descuidar la calidad de nuestra labor.
Por: Jorge Hernán Abad L – @jorge_abad
Recuerdo como le he dicho a mis estudiantes de pregrado y posgrado mi reencarnación anterior, sí cuando fui/soy ingeniero civil, y que luego poco a poco desde los programas para cálculo estructural y matrices inversas, la realización de supermacros en visual basic para excel y la construcción de software para sistemas de información geográfica hizo que llegara al mundo que estaba destinado, el de los sistemas y más precisamente el del software.
Por mucho tiempo he estado en temas de requisitos, casos de uso, java, php, JEE, BPM, SOA, arquitectura empresarial, calidad, pruebas, CMMi, reglas de negocio, pero nunca había encontrado el dinamismo y entusiasmo que he observado con el uso de tanto framework de gestión de proyectos como Scrum, como el uso de las prácticas ágiles de ingeniería.
Son muchas las cosas que se han vuelto satisfactorias desde mis primeros dias usando scrum hace como 8 meses:
- la sonrisa del cliente
- la sonrisa de los desarrolladores
- el nivel de estrés bajo
- el de compromiso super alto
- los reconocimientos
- los bugs en producción cada vez menores
- la confianza entre el cliente y proveedor emergiendo y fortaleciéndose (por fin como aprendí en algun lugar «SIENDO SOCIOS DE NEGOCIO»)
Y por fin hacer software es algo divertido, algo que anima y reta, y no algo que devoraba implacablemente el tiempo de:nuestr@s novi@, espos@, hij@s, amigos y por ende de nuestro merecido descanso (sea cual sea la forma que le queramos dar).
Y recordando mis clases de mecánica de fluidos, recuerdo que el agua siempre elegía el camino (la línea) del menor gasto de energía – o camino óptimo – (no les suena similar a Lean, eliminando el desperdicio) y así se ha vuelto para mi Scrum. La forma de gastar la menor cantidad de energía para llegar al resultado esperado.
Antes nos desgastábamos en tantas cosas, wow, con solo pensar en la desconfianza típica entre cliente y proveedor, a eso súmele:
- las reuniones tediosas de levantamiento de requisitos
- el juego de las estimaciones, que nunca le acertábamos (cosa que si añoraba de mi anterior reencarnación – la ingeniería civil – y que volví a recuperar con Scrum)
- la llenadera de actas, y documentos como evidencia de la desconfianza
- el seguimiento constante al riesgo
- la preocupación con el alcance
- el salir perdiendo siempre como proveedor (pues como vamos a perder ese cliente tan importante, regálenle esas horas)
- las horas exhaustivas de pruebas
- el querer comprimir inútilmente el tiempo de pruebas para luego dolorosamente comprobar que ese tiempo NUNCA lo debimos haber recortado.
- el decirnos mentiras entre todos y prometer con firma de sangre fechas que no íbamos a cumplir nunca (si realmente hubiera puesto mi sangre en esos compromisos no estaría escribiendo este post)
- la amistad e idilio entre cliente y proveedor que termina siendo el peor de los odios, o un matrimonio del cual ambos quieren salir pero muchas veces no encuentran como.
- y uno como gerente de proyecto, consultor, desarrollador, comercial en la mitad viendo como pasa todo eso y día tras día, proyecto tras proyecto, el problema se repite una y otra vez..
Pero afortunadamente surgió el Manifiesto Ágil http://agilemanifesto.org/, y poco a poco los que estábamos enamorados de metodologías como RUP – iterativo, incremental y lógico -(que muy contadas veces la vi aplicar correctamente, por lo general venden RUP como un proyecto con las 4 fases – inicio, elaboración, construcción y transición- cada una de una sola iteración y en especial la de construcción de una sola iteración convirtiéndolo el proyecto en el odiado y reconocido cascada con todas sus consecuencias funestas),vimos como fue creciendo bajo su sombra el arbolito de las metodologías ágiles y hoy más de 12 años después comienza a ser la respuesta a mi pregunta:
¿Por qué si hacer software es tan apasionante, resulta siendo tan frustrante? (últimamente le estaba diciendo PROGRAMACIÓN ORIENTADA A LA FRUSTRACIÓN POF o en inglés FRUSTATION-ORIENTED PROGRAMMING FOP)
o mejor
¿por qué si hacer software es tan apasionante, no es divertido?
Veía y veo iniciativas como CMMi, PSP /TSP tratando de enmarcar cosas que tienen que ver con la creatividad y la imaginación (wow casi no lo reconozco… siempre he sido fiel seguidor de los modelos de calidad, y de apoyar la escritura de código como trabajo de ingeniería, más hoy como una revelación comprendo que hay mucho de arte de libertad-controlada como diria Alan Cyment) y que en su afán de enmarcar y definir todo, terminan haciendo esto que se ve tan divertido o que uno lo imagina así al ver videojuegos en algo digno de señores de corbatas que no aman lo que hacen y que no ven la hora de ser gerentes de proyecto, o hacer un posgrado en administración, finanzas o cualquier otra cosa para cambiar de negocio.
Hoy veo a Scrum junto con las prácticas ágiles de ingeniería como el renacer de la pasión de mi equipo de trabajo, como el renacer de mi pasión por crear y proponer cosas nuevas, como el renacer de la creatividad y de la confianza entre cliente y proveedor.
Y son pequeños hechos, pequeños caos controlados, grandes destellos de creatividad en espacios delimitados de tiempo los que están dando orden a aquello que me atrajo en un principio y que amo tanto:
- los dailys sincronizan al equipo
- los planning nos comprometen
- los review nos enorgullecen o nos hacen sonrojar cuando fallamos (retandonos a ser mejores)
- las retrospectivas nos ayudan a ser mucho mejores
- las reuniones innecesarias no existen
- las reuniones de temas que tenemos que trabajar dentro de un mes o más no existen, por lo tanto tanta complejidad se va perdiendo.
- La verbalización y activación de la comunicación agiliza el desarrollo y afianza el compromiso.
- el horizonte de estimacion es de 2 semanas haciéndonos más precisos y no tenemos sorpresas.
- ver software funcionando (como lo expresa el manifiesto ágil) es el mejor indicador de avance y de felicidad del equipo y del cliente
- el coraje del equipo esta jalando hacia la mejora continua
- si hemos de fallar, fallamos a las 2 semanas y no a los 4 meses.
- el framework de Scrum y las prácticas agiles de ingeniería estan pensados en la mitigación del riesgo.
Definitivamente ganamos todos
- software funcionando y bonito (pruebas unitarias y funcionales automatizadas)
- cliente contento
- equipo contento
- scrum master contento
- gerente del cliente y del proveedor contento.
Creo que por fin encontramos el santo grial del software, lo que nos va a sacar de pobres, la gallina de los huevitos de oro
Ahora mis grandes interrogantes son:
- ¿que huevitos quiero poner?
- ¿mi ciuidad,. mi país, y latinoamérica aprovechará esta gran oportunidad?
Ágiles Colombia 