Software, una historia sin fin

Ilitumwa mnamo - Iliwekwa upya mnamo

La historia de Marcos y el software infinito

Marcos es un ingeniero de software que trabaja en la empresa XYZ SAS. En dicho lugar, Marcos contribuye a un proyecto nuevo el cual busca una forma de mostrar la información de interés a los usuarios de la plataforma FGHI. La persona encargada de liderar al equipo ha dejado clara las ambiciones del software que van a construir, así como las fechas de entrega y las labores que cada miembro del equipo debe completar. Pasados varios meses del proyecto, el líder el proyecto ha dejado ver su interés en abarcar otros desafíos, bien sea alejándose por completo de FGHI o dedicando menos tiempo. El líder está convencido que al llegar a la versión 2.0 será suficiente. Que implementar un chat será lo último que haya que hacer. Está convencido que FGHI tiene un final así sea que él no lo vea de esa forma. Por su parte, Marcos dedica su tiempo libre a proyectos personales. Desarrollos pequeños que utilizaba para aprender nuevas tecnologías, hacer algo diferente o tener un portafolio personal en su hoja de vida(para cuando decidiera buscar empleo en otro lugar). Y es durante el trabajo en esos proyectos pequeños que Marcos se da cuenta que es muy complicado, por no decir imposible, que FGHI tenga un punto final. Es muy difícil, por no decir imposible, concebir un software(sea este aplicación móvil, aplicación web o aplicación de escritorio) que tenga final. Sí, al inicio pensamos en la versión 3.5 que tiene X cantidad de características pero en todo el trayecto hasta esa versión aparecerán más elementos que añadir, habrá errores que resolver y volverán a surgir requerimientos por implementar. Incluso, en términos de tiempo, primero acaba el ciclo de vida de un desarrollador dentro de un proyecto de software que el ciclo de vida del producto "final" creado en el lapso del proyecto. Un proyecto de software puede fácilmente pasar a manos de otro desarrollador, a una comunidad (como cuando se hace open source) pero es muy complicado ver un punto final, donde no haya más nada que hacer, nada que resolver, características que desplegar.

¿Me estás diciendo la verdad?

Un ejemplo muy claro son los sistemas operativos. Windows, Mac OS X, y los basados en GNU/Linux(Ubuntu, CentOS, Fedora) nos dan una clara idea de proyectos de software que no culminan. El código pasa a ser mantenido por otros desarrolladores, el equipo pasa a ser organizado por otros gestores o todo pasa a ser parte de otra(s) empresa(s), pero no, no terminan de recibir mejoras y actualizaciones. Siempre habrá nuevas características por agregar, sea porque los usuarios las pedimos, porque la tecnología avanza o por estrategia comercial de la empresa que lo mantenga. Podrás pensar que hay proyectos que sí terminan, y sí, es cierto, sin embargo muy seguro ocurre porque no hay un desarrollador a cargo o falta una comunidad que quiera tomar las riendas. Tal vez esos proyectos termina por falta de liquidez económica, por que se tomó la decisión de dejarlo por parte de la junta directiva, pero nunca porque ya no haya más nada que hacer, no haya más requerimientos que agregar ni más bugs que resolver. Hace algunos años(en la era donde la web y lo móvil estaba muy lejos de lo que es ahora) teníamos programas de escritorio que nos ofrecían esa sensación de que todo estaba terminado. Versiones estables de un programa que tenía actualizaciones a los 6 meses o al año después. Obviamente es más complicado hacer que un usuario actualice un software desktop a actualizar una aplicación web. Es esa mentalidad desktop la que puede hacer que algunos desarrolladores piensen que un programa puede ser finito.

Software sin fin y las metodologías

Surge la pregunta, ¿es malo tener software infinito? ¿software con requerimientos constantes que nunca acaban? Mi respuesta es que no hay forma de decidir si es malo o no, lo realmente importante del asunto es cómo manejar todos los requerimientos habidos y por haber, es aquí donde las metodologías ágiles juegan un papel importante. [caption id="attachment_19079" align="aligncenter" width="500"]software sin fin inception ¿Se cae o no se cae? ¿Se acaba o no se acaba?[/caption] He estudiado en cierta medida el marco ágil Scrum y una de sus bases es definir lo que realmente le aporta valor al software(sea este app web, móvil o desktop) siempre pensando en que pueda ser utilizado desde sus primeras versiones estables por los usuarios. Con este enfoque el equipo de desarrollo se centrará primeramente en las características fundamentales, a las cuales se llega por consenso grupal. Esta es una de las formas de manejar los requerimientos de tal forma que siempre se trabaja sobre los estrictamente necesarios y la pila de requerimientos se va manejando, e incrementando, solo con los que darán valor al software que se está creando.

Getting Real

Este genial libro escrito por Jason Fried, Co-fundador de 37Signals(si usas Basecamp seguro conoces esta empresa) nos describe las múltiples formas en las que se puede lidiar con los requerimientos infinitos que pueden sugir en el proceso de crear una aplicación. Desde un no rotundo, pasando por negar lo que pidan los usuarios hasta llegar a la forma más eficiente de manejarlos. Sin duda alguna, si eres desarrollador de software o líder de equipo, deberías leer este libro. Leer Getting Real me hizo abrir los ojos ante la gran dificultad (la de los constantes requerimientos, los tiempos de entrega y el alcance) que se experimenta cuando se está desarrollando software y no solo eso, el libro te ofrece las mejores formas de manejar estas situaciones, eso sí, son solo recomendaciones que funcionaron en una ocasión al equipo de 37Signals, si las tomas puede que no te funcionen por lo que deben ajustarse siempre al tipo de equipo de trabajo.

Experiencia personal

Todas las ideas de este artículo nacen cuando estoy creando dos aplicaciones móviles. Son aplicaciones muy sencillas que simplemente hacen la lectura de algunas APIs públicas. En términos de alcance, son bien simples, sin embargo, y a medida que pasaban los días, me iban llegando ideas a la cabeza sobre qué cosas podría implementarles para que fueran de mayor utilidad. Una de ellas la hice en compañía de un amigo desarrollador y fue él quien en una reunión dio varias ideas muy buenas para agregar a una de esas aplicaciones que menciono. Le expliqué los conceptos de Getting Real y acordamos ir añadiendo poco a poco todas esas características. Las posibilidades son infinitas. Ahora mismo veo muchas cosas que hacer con esas dos apps, falta tiempo, podría faltar gente pero no van a faltar requerimientos por desarrollar.

Conclusión

Solo me queda aclarar que la intención de este texto no es desalentarte como desarrollador o líder de proyectos de software, ni mucho menos. Mi objetivo es hacerte entender o al menos ponerte a pensar sobre lo que aquí escribo. Soy consciente que los proyectos para crear programas o aplicaciones se rigen por un ciclo de vida, solo que ese ciclo es para lanzar una versión en particular la cual no estará exenta de fallos, además que los usuarios siempre vamos a pedir cosas nuevas(o características útiles) en los programas que usamos. Por eso creo firmemente que el software no tiene fin. Es válido mencionar que lo aquí escrito es muy subjetivo y si crees que estoy equivocado, te invito a comentar tus pensamientos sobre el hecho de que el software no tenga fin. Banner colaboración Desarrollo

Nakala Mpya

Guía rápida para contratar Millennials