Ágil, Scrum y palabras elegantes para escribir software que ofrezca resultados
No importa cómo se mire, en términos generales los desarrolladores de software de aplicaciones empresariales tienen mala reputación. Es casi inevitable que los sistemas se entreguen tarde o incluso no se entreguen. El usuario promedio en una empresa promedio pasará literalmente horas cada semana quejándose de los sistemas informáticos que se ve obligado a soportar. “¿Por qué hizo eso?”, “¿Qué diablos significa eso?” son algunas de las cosas que escucho a diario.
Pasé años escribiendo sistemas empresariales, en su mayor parte los usuarios eran positivos acerca de lo que obtenían y usaban. Sistemas escritos según una especificación inicial, probados hasta el final y luego adaptados cuando sea necesario a un costo acordado si es necesario. El apoyo continuo al cliente y los ingresos sostenidos para la empresa de software fueron una combinación ganadora. La especificación inicial basada en un análisis detallado de los requisitos siempre sería una descripción general funcional y no contendría ningún código específico. Creo que usé pseudocódigo una vez (cuando estaba escribiendo juegos). "Esto es lo que necesitamos que haga", por lo general era suficiente para mí. Aparte de eso, fueron algunas maquetas de interfaz de usuario y mucho diseño de base de datos y listo. La fase de prueba y "ajustes" del ciclo de vida del desarrollo fue muy importante. En general, los sistemas se entregaron a tiempo y funcionaron.
Hoy en día (nunca pensé que diría eso), todo lo relacionado con los sistemas tiene que ver con planificación, más planificación y luego reutilización. Lo que me parece tan extraño es que gran parte de esta planificación no tiene como objetivo cumplir un requisito funcional sino más bien detallar cómo y por qué vamos a escribir lo que escribimos cuando lo escribimos. ¿Espero que eso tenga sentido? ¿Por qué escribir algo en 10 líneas que podrías hacer en 1000 con la posibilidad de que “quizás” necesites reutilizarlo dentro de 2 años? A nivel personal nunca he escrito nada que no pudiera reescribir mejor 2 años después. Siempre estoy aprendiendo y mejorando, cuando miro el código, incluso cuando tiene 12 meses, a menudo me estremezco. Al mirar anuncios de empleo es fácil perderse en las metodologías y habilidades que se solicitan, ¿es humanamente posible que una persona sepa tanto?, me pregunto a menudo. Otra pregunta es: ¿alguna vez producen un producto? Con toda esta planificación y preocupación por reutilizar el código, ¿alguna vez se hace algo? Conozco una empresa que contrató desarrolladores académicos que estaban tan ocupados concentrándose en el diseño que la empresa quebró antes de que cualquier producto estuviera siquiera listo, ¡en serio! ¡Cuántos retrasos podemos esperar que tolere la gente, la fase de prueba nunca fue un problema allí! ¿Por qué debería esperarse que la empresa que nos paga por un producto pague por un código que se utilizará una y otra vez en proyectos posteriores y no para ellos?
No me malinterpretes, no digo que la planificación sea mala, es una parte esencial del desarrollo de sistemas, pero no es la única. Tal vez soy de la vieja escuela, pero lo que disfruto es escribir el sistema y hacerlo funcionar. Ok, sé que los sistemas son cada vez más grandes y complejos. Los grandes equipos de desarrolladores son la norma. Es solo que creo que por mucho que planifiques, visualices y hagas una lluvia de ideas, siempre se perderá algo. Nos esforzamos por conseguir sistemas imposibles y perfectos, pero en el peor de los casos no conseguimos ningún sistema. ¿No me crees? Mire Microsoft. ¿Imagínese las horas de trabajo que se dedican a planificar cualquiera de sus aplicaciones? ¿Con qué frecuencia se descubre un nuevo error o vulnerabilidad? ¿Por qué no se debatieron en la etapa de diseño? Al equipo de desarrollo ni siquiera se le pasó por la cabeza que pudiera ocurrir la "vulnerabilidad X". En pocas palabras, con algo más que el sistema más básico es casi imposible planificar todas las eventualidades, sin importar cuán lógico sea. ¿Por qué no se encuentran durante las pruebas? ¿La solución está aquí en el desarrollo de la vieja escuela, menos tiempo para planificar (hablar), más tiempo para escribir y realizar pruebas? ¿Menos tiempo preocupándose por reutilizar el código y más tiempo para darle al cliente un producto que funcione? ¿Microsoft sería mejor o peor si dedicaran menos tiempo a planificar y más a realizar pruebas? En defensa de Microsoft, son muy buenos parcheando, supongo que se podría considerar que nos utilizan como evaluadores. ¿Quizás si dedicaran más tiempo a realizar las pruebas adecuadas no necesitaríamos realizarlas?
El peor ejemplo de planificación excesiva que todavía no he encontrado es un sistema financiero que uso a diario. La implementación de este sistema costó millones de dólares, años de planificación y quién sabe cuántos consultores. Está escrito por uno de los actores más importantes de la industria del software, adaptado por una consultoría de software especializada. El resultado final de esto es un sistema que es prácticamente inutilizable y no muy lejos de ser reemplazado por un producto de venta libre. Es tan malo en el nivel más bajo que incluso un clic incorrecto del mouse bloqueará la aplicación. No puedo creer que este sistema haya sido probado antes de su entrega. Su entrega fue muy tardía, debido a que el “ciclo de planificación” fue más largo de lo esperado. Lo que hace no es tan complejo, es sólo que obviamente ha sido planeado hasta el punto en que su implementación ha sido un pensamiento apresurado. Toda esta planificación ni siquiera ha resultado en un sistema que cumpla con los requisitos funcionales básicos de sus usuarios, pero je, estoy seguro de que reutilizarán ese código en algún momento.
De todos modos, acabo de comenzar un diploma que me ayudará a comprender por qué es tan importante utilizar varias estrategias de planificación diferentes. ¿Por qué escribir en 1 día lo que podría dedicar un mes a hacer “bien”? Sé que leeré esto dentro de un par de años y me preguntaré qué estaba pensando; O eso o me digo a mí mismo “wow, ahí era cuando terminaba lo que estaba escribiendo”. En serio, estoy seguro de que al final me daré cuenta de dónde me estoy equivocando. Mientras tanto, seguiré escribiendo aplicaciones usando mi estilo RAD (¡me alegro de que tenga un nombre!) Aunque no es del gusto de todos, a mí me funciona bien.
nb ¿Quién lo habría adivinado? Mi enfoque del desarrollo tiene un nombre: ¡está clasificado como Metodología Ágil! Aquí hay un excelente artículo que explica Metodologías ágiles con cierto detalle.