- Metodologías ágiles y porque son ideales para el desarrollo de software.
- Desarrollo de software, ¿velocidad o precisión?.
- Reflexiones sobre el desarrollo de aplicaciones móviles.
Metodologías ágiles y porque son ideales para el desarrollo de softwareFuente: tumblr.com |
El día de ayer tuvimos una reunión un grupo de compañeros y yo, los cuales tenemos varias cosas en común: compartimos una enorme pasión por las tecnologías, tenemos un espíritu emprendedor muy fuerte y casi todos trabajamos con metodologías ágiles.
Salieron en cuestión diversos temas de plática, pero hubo uno que me incitó mucho a escribir esta publicación y sobre el que le dedicamos gran parte de la noche, las metodologías de desarrollo.
El desarrollo de software es un arte y un proceso relativamente nuevo, que ha ido creciendo y hasta hace unos pocos años no había tenido metodologías bien definidas que aseguren la calidad del producto, con las menores pérdidas (dígase código basura y dinero) y en el menor tiempo posible.
Primero fue el desarrollo artesanal, “vamos a hacer que funcione”, pero muy pronto se dieron cuenta los desarrolladores que esto traía problemas de mantenibilidad, se reescribía mucho código y era código completamente ilegible.
Es ahí cuando aparecen varías metodologías, entre ellas la metodología cascada que es la favorita de la mayoría de nuestros profesores hoy en día, una metodología que proponía hacer un desarrollo por etapas, empezando por el análisis, diseño, desarrollo, implementación y al final el mantenimiento; Esto evidentemente agrega un gran overhead en las primeras etapas del desarrollo en las que se hace mucho diseño pero no se tiene nada funcional, es la etapa en la que se trabaja con el cliente; luego se dedica otro tiempo al desarrollo del producto, siendo este un momento clave del proceso se tiene un contacto casi nulo con el cliente, y ya al final implementar y documentar. ¿Suena muy bonito no? pues no lo es así, porque empezaron a surgir diferentes problemas, empezando con que a los desarrolladores no les gusta para nada el overhead de análisis, diseño y documentación, y personalmente podría asegurar que a cualquier “guru” de estas metodologías si se les pide su opinión real de estas etapas te van a decir que las odian. Otros problemas fueron que al momento de implementar el sistema, los requerimientos ya no son los mismos, o no se entendieron bien y sucede una de dos cosas, o el proyecto se descarta y representa una pérdida de dinero o el proyecto se adapta, pero un pequeño cambio de requerimientos puede llegar a implicar muchísimos cambios en código.
Durante el paso de los años fueron saliendo varias modificaciones a esta metodología para tratar de atacar esos problemas que fueron saliendo con el tiempo, sin embargo sigue siendo una metodología que no le agrada a ningún desarrollador, que sigue significando mucho tiempo empleado solamente para analizar, diseñar y documentar y que sigue dejando muy de fuera al cliente durante los tiempos críticos del proceso.
Hace muy pocos años surgió una nueva metodología, una metodología que en sus inicios fue vista como un retroceso al desarrollo del software y sigue siendo vista de ese modo por muchos Ingenieros en Sistemas de generaciones mayores, las metodologías ágiles.
La metodologías ágiles proponen quitar tanto overhead de Análisis, Diseño y Documentación y enfocarse en lo que realmente importa, el producto en sí y tratando al cliente como lo que realmente es, un miembro más del desarrollo del producto, ¿suena como un retroceso? tal vez en primera instancia sí, pero si lo analizamos bien y le damos una oportunidad, no lo es, las metodologías ágiles han ido creciendo, evolucionando, adaptándose a un nivel que me atrevo a decir que son las metodologías ideales para el desarrollo de software.
Las nuevas tecnologías y los nuevos lenguajes de programación hacen posible poder trabajar con metodologías ágiles de tal forma que no representen un riesgo, que el cliente siempre tenga el producto que espera, que el sistema sea mantenible y lo más importante que el sistema esté documentado ¿Pero como, no habías dicho que en estas metodologías no se documenta? pues así es y es que en estas metodologías el proceso de análisis, diseño, documentación y desarrollo van prácticamente de la mano, al mismo tiempo y son transparentes unas de otras (en realidad parece que solamente se está planeando y desarrollando) con herramientas que ayuden a definir User Stories y un controlador de versiones ya tenemos un gran paso para la auto-documentación, pero no es todo también los lenguajes de programación aportan mucho al ser lenguajes que propicien que el código sea entendible al leerlo.
Técnicas como BDD(Behavior Driven Development), XP(Extreme Programming), Scrum, entre otras son las que han ido evolucionando dentro del mundo ágil para asegurar todos esos puntos, BDD por ejemplo, se trata de desarrollar en base al comportamiento, se realiza un documento, con cierto formato y ciertas palabras claves, que describe el comportamiento de dada funcionalidad, un documento completamente legible para cualquier persona que es en realidad un meta-lenguaje que puede ser ejecutado en terminal y funciona como las pruebas del sistema, sí, las pruebas del sistema, increíble ¿cierto?, y funciona así: inicialmente las pruebas, como es de esperarse, no pasan; después se escribe el suficiente código para que pasen las pruebas ya una vez que pasan se refactoriza el código para que sea óptimo. Esta y otras metodologías son mucho más aceptables y divertidas que las que exigen separar el proceso de desarrollo del proceso de documentación, análisis y diseño, y creo que los desarrolladores en sí trabajan mucho más felices con este tipo de prácticas; Esto no quiere decir que no hay una fase de Análisis y Diseño inicial, si la hay, pero en comparación con metodologías más antiguas, se le dedica muchísimo menor tiempo a estas al inicio.
Salieron en cuestión diversos temas de plática, pero hubo uno que me incitó mucho a escribir esta publicación y sobre el que le dedicamos gran parte de la noche, las metodologías de desarrollo.
El desarrollo de software es un arte y un proceso relativamente nuevo, que ha ido creciendo y hasta hace unos pocos años no había tenido metodologías bien definidas que aseguren la calidad del producto, con las menores pérdidas (dígase código basura y dinero) y en el menor tiempo posible.
Primero fue el desarrollo artesanal, “vamos a hacer que funcione”, pero muy pronto se dieron cuenta los desarrolladores que esto traía problemas de mantenibilidad, se reescribía mucho código y era código completamente ilegible.
Es ahí cuando aparecen varías metodologías, entre ellas la metodología cascada que es la favorita de la mayoría de nuestros profesores hoy en día, una metodología que proponía hacer un desarrollo por etapas, empezando por el análisis, diseño, desarrollo, implementación y al final el mantenimiento; Esto evidentemente agrega un gran overhead en las primeras etapas del desarrollo en las que se hace mucho diseño pero no se tiene nada funcional, es la etapa en la que se trabaja con el cliente; luego se dedica otro tiempo al desarrollo del producto, siendo este un momento clave del proceso se tiene un contacto casi nulo con el cliente, y ya al final implementar y documentar. ¿Suena muy bonito no? pues no lo es así, porque empezaron a surgir diferentes problemas, empezando con que a los desarrolladores no les gusta para nada el overhead de análisis, diseño y documentación, y personalmente podría asegurar que a cualquier “guru” de estas metodologías si se les pide su opinión real de estas etapas te van a decir que las odian. Otros problemas fueron que al momento de implementar el sistema, los requerimientos ya no son los mismos, o no se entendieron bien y sucede una de dos cosas, o el proyecto se descarta y representa una pérdida de dinero o el proyecto se adapta, pero un pequeño cambio de requerimientos puede llegar a implicar muchísimos cambios en código.
Durante el paso de los años fueron saliendo varias modificaciones a esta metodología para tratar de atacar esos problemas que fueron saliendo con el tiempo, sin embargo sigue siendo una metodología que no le agrada a ningún desarrollador, que sigue significando mucho tiempo empleado solamente para analizar, diseñar y documentar y que sigue dejando muy de fuera al cliente durante los tiempos críticos del proceso.
Hace muy pocos años surgió una nueva metodología, una metodología que en sus inicios fue vista como un retroceso al desarrollo del software y sigue siendo vista de ese modo por muchos Ingenieros en Sistemas de generaciones mayores, las metodologías ágiles.
La metodologías ágiles proponen quitar tanto overhead de Análisis, Diseño y Documentación y enfocarse en lo que realmente importa, el producto en sí y tratando al cliente como lo que realmente es, un miembro más del desarrollo del producto, ¿suena como un retroceso? tal vez en primera instancia sí, pero si lo analizamos bien y le damos una oportunidad, no lo es, las metodologías ágiles han ido creciendo, evolucionando, adaptándose a un nivel que me atrevo a decir que son las metodologías ideales para el desarrollo de software.
Las nuevas tecnologías y los nuevos lenguajes de programación hacen posible poder trabajar con metodologías ágiles de tal forma que no representen un riesgo, que el cliente siempre tenga el producto que espera, que el sistema sea mantenible y lo más importante que el sistema esté documentado ¿Pero como, no habías dicho que en estas metodologías no se documenta? pues así es y es que en estas metodologías el proceso de análisis, diseño, documentación y desarrollo van prácticamente de la mano, al mismo tiempo y son transparentes unas de otras (en realidad parece que solamente se está planeando y desarrollando) con herramientas que ayuden a definir User Stories y un controlador de versiones ya tenemos un gran paso para la auto-documentación, pero no es todo también los lenguajes de programación aportan mucho al ser lenguajes que propicien que el código sea entendible al leerlo.
Técnicas como BDD(Behavior Driven Development), XP(Extreme Programming), Scrum, entre otras son las que han ido evolucionando dentro del mundo ágil para asegurar todos esos puntos, BDD por ejemplo, se trata de desarrollar en base al comportamiento, se realiza un documento, con cierto formato y ciertas palabras claves, que describe el comportamiento de dada funcionalidad, un documento completamente legible para cualquier persona que es en realidad un meta-lenguaje que puede ser ejecutado en terminal y funciona como las pruebas del sistema, sí, las pruebas del sistema, increíble ¿cierto?, y funciona así: inicialmente las pruebas, como es de esperarse, no pasan; después se escribe el suficiente código para que pasen las pruebas ya una vez que pasan se refactoriza el código para que sea óptimo. Esta y otras metodologías son mucho más aceptables y divertidas que las que exigen separar el proceso de desarrollo del proceso de documentación, análisis y diseño, y creo que los desarrolladores en sí trabajan mucho más felices con este tipo de prácticas; Esto no quiere decir que no hay una fase de Análisis y Diseño inicial, si la hay, pero en comparación con metodologías más antiguas, se le dedica muchísimo menor tiempo a estas al inicio.
En resumen ¿Porque son ideales para el desarrollo de software? Porque desde sus inicios del desarrollo de software se demostró que no es muy agradable tener que implementar ese overhead que no nos deja ningún producto tangible y tampoco representa un avance en el desarrollo, un overhead que a ningún desarrollador le gusta y muchos odian. Las metodologías ágiles han demostrado que se puede hacer un desarrollo de calidad, con un producto beta en muy poco tiempo, que cumpla todas las expectativas del cliente y lo más importante que es un trabajo muy cómodo y feliz para el desarrollador.
Desarrollo de software, ¿velocidad o precisión?Fuente: tumblr.com |
Antes de empezar con el post como tal, veamos algunas frases celebres recurrentes de personas que no están en el mundo de la computación:
- “Oye, y no le podemos quitar una semana de desarrollo?”
- “Sí, ya me explicaste por que queda hasta mañana, sin embargo yo no veo la complicación”
- “¿Todo el sistema queda en 2 semanas? ¿Tanto?”
- “Pero como que 1 semana de desarrollo, si Excel ya lo hace”
- “¿Y si le quitamos las pruebas, si queda mañana?”
- Si quieres le quitamos todo el desarrollo y ya me voy
- Pues vas
- Voy a asumir que el “tanto” se refiere a todo el desarrollo que obtendrás por 2 semanas, no a que te sorprende el tiempo porque si no te pierdo el respeto
- (sólo te sales del cuarto)
- Sí, pero mal
Pero hasta que inventemos una forma de trasladar la percepción de una mente a otra, no quedará más que usar la antigua técnica de negociar, o como se le llama en el mundo geek, “usar poderes Jedi”, para que los tiempos se respeten y el cliente quede feliz.
Ahora bien, sobre dichos poderes Jedi, ¿qué opinan de un Tryout que evalúe dichas habilidades?, me imagino una simulación donde se te describa un sistema y el cliente te propine unas brillantes preguntas como las descritas arriba, donde tu selecciones en cierto límite de tiempo la respuesta, como si fuese una conversación, creo que sería tan útil como programar.
¿Qué opinan? ¿Se avientan a cambiar percepciones usando poderes Jedi? ¿O mejor mandan a todos al garete hasta que encuentren el cliente perfecto?
Reflexiones sobre el desarrollo de aplicaciones móvilesFuente: caraballomaestre.blogspot.com |
Ahora mismo existen distintos mercados diferenciados dentro de las aplicaciones móviles. Hace relativamente poco tiempo, las empresas que desarrollábamos aplicaciones móviles, buscábamos realizar un solo desarrollo multiplataforma, y que valiera para el mayor número de dispositivos posible. Esto se intentaba mediante tecnología Java J2ME. En este post hice una pequeña introducción.
El coste de desarrollar estas aplicaciones era altísimo, ya que siempre había que realizar adaptaciones para sacar el mayor rendimiento de cada dispositivo, y aun así no se conseguía. Cada fabricante instalaba una máquina virtual distinta, había particularidades a la hora de gestionar cada pila de Bluetooth... toda una odisea.
Actualmente hay distintas plataformas diferenciadas y las empresas optan por desarrollar aplicaciones nativas para cada plataforma. Los clientes suelen pedir que la aplicación funcione en distintas plataformas, para así llegar al mayor número de usuarios posibles. Si las empresas desarrolladoras no tienen el know how para desarrollar la aplicación en las plataformas requeridas, se suelen buscar alianzas para completar los servicios ofrecidos. Pero el planteamiento es utilizar tecnología nativa para cada puerto de la aplicación.
El mercado mundial actual, en cuanto a smartphones se refiere, lo copan las plataformas Android, iPhone, y Blackberry. Aun hay un parque bastante amplio de dispositivos Symbian pero, además de estar en el límite de lo que hoy denominamos smartphones, están en claro retroceso. Para ilustrar estas afirmaciones, podemos ver el artículo de Poder PDA basado en las estadísticas de Gartner del tercer trimestre de 2011. Cabe reseñar que Windows Phone 7, actualmente tiene una cuota de mercado bastante pequeña probablemente motivada por lo tarde que llegaron al mercado.
Blackberry tradicionalmente ha tenido una cuota de mercado amplia en dispositivos de empresa. La larga duración de la batería (cuando trabajamos, no nos podemos permitir el lujo de agotar la batería en 4 horas, sobretodo si estamos desplazados), su correo push, la seguridad (Blackberry implementa por omisión distintos protocolos de seguridad), o cuestiones relacionadas con la usabilidad (teclado qwerty físico, muy apropiado para escribir muchos correos), son factores que han influido en que las empresas eligieran Blackberry. Otro motivo importante, que no tiene que ver con la tecnología, y sí con el canal de distribución, es la apuesta que realizan las operadoras con respecto a los terminales que facilitan. Si Vodafone, o Movistar en España optan por favorecer la distribución de un modelo concreto, influirá decisivamente en las estadísticas de cuota de mercado. Esto último puede que sea factor clave en el avance de iPhone en usuarios de empresa.
Hasta la fecha, la mayoría de proyectos de desarrollo Blackberry que hemos llevado acabo en elDepartamento de Ingeniería de Software de Soltel IT Solutions estaban orientados a soluciones empresariales, es decir desarrolladas por la empresa, para la empresa (modelo de negocio B2B). Sin embargo hemos recibido peticiones de proyectos Android y iPhone, cuyo usuario final, es el consumidor de a pie (modelo de negocio B2C). Esta separación, cada vez es menos evidente, ya que iPhone se está extendiendo en el entorno empresarial, y Blackberry ha intentado acercarse al gran público con dispositivos de gama media, como la Curve y aplicaciones como Blackberry Messenger, con gran aceptación entre los más jóvenes.
Android mantiene una cuota relevante en el mercado. Hay factores que han influido en que proliferen aplicaciones de esta plataforma, como por ejemplo, el ser una apuesta de Google, haber dispositivos potentes de varios fabricantes como HTC y Samsung, ser nativo Java, tener un SDK (Software Development Kit) abierto, con grandes facilidades para publicar en Android Market...
No podemos perder de vista la alianza subscrita entre Microsoft y Nokia (dispositivos Nokia con sistema operativo Windows Phone). En mi opinión, más allá de la calidad del producto, han llegado muy tarde, y puede que ya no haya pastel que repartir.
El mundo de la tecnología es cambiante. El pasado es hace dos años, y el futuro es dentro de un minuto. Esto se acentúa en la tecnología móvil, donde los cambios son constantes. Una empresa experta en desarrollo de software para móvil, no puede permitirse el lujo de no conocer las plataformas más importantes que copan el mercado, aunque estas queden fuera de su stack tecnológico. Por otro lado las librerías y frameworks que los fabricantes ponen a disposición de desarrolladores hacen que el escalón entre el desarrollo de una aplicación móvil y una web o de escritorio se reduzca.
El coste de desarrollar estas aplicaciones era altísimo, ya que siempre había que realizar adaptaciones para sacar el mayor rendimiento de cada dispositivo, y aun así no se conseguía. Cada fabricante instalaba una máquina virtual distinta, había particularidades a la hora de gestionar cada pila de Bluetooth... toda una odisea.
Actualmente hay distintas plataformas diferenciadas y las empresas optan por desarrollar aplicaciones nativas para cada plataforma. Los clientes suelen pedir que la aplicación funcione en distintas plataformas, para así llegar al mayor número de usuarios posibles. Si las empresas desarrolladoras no tienen el know how para desarrollar la aplicación en las plataformas requeridas, se suelen buscar alianzas para completar los servicios ofrecidos. Pero el planteamiento es utilizar tecnología nativa para cada puerto de la aplicación.
El mercado mundial actual, en cuanto a smartphones se refiere, lo copan las plataformas Android, iPhone, y Blackberry. Aun hay un parque bastante amplio de dispositivos Symbian pero, además de estar en el límite de lo que hoy denominamos smartphones, están en claro retroceso. Para ilustrar estas afirmaciones, podemos ver el artículo de Poder PDA basado en las estadísticas de Gartner del tercer trimestre de 2011. Cabe reseñar que Windows Phone 7, actualmente tiene una cuota de mercado bastante pequeña probablemente motivada por lo tarde que llegaron al mercado.
Blackberry tradicionalmente ha tenido una cuota de mercado amplia en dispositivos de empresa. La larga duración de la batería (cuando trabajamos, no nos podemos permitir el lujo de agotar la batería en 4 horas, sobretodo si estamos desplazados), su correo push, la seguridad (Blackberry implementa por omisión distintos protocolos de seguridad), o cuestiones relacionadas con la usabilidad (teclado qwerty físico, muy apropiado para escribir muchos correos), son factores que han influido en que las empresas eligieran Blackberry. Otro motivo importante, que no tiene que ver con la tecnología, y sí con el canal de distribución, es la apuesta que realizan las operadoras con respecto a los terminales que facilitan. Si Vodafone, o Movistar en España optan por favorecer la distribución de un modelo concreto, influirá decisivamente en las estadísticas de cuota de mercado. Esto último puede que sea factor clave en el avance de iPhone en usuarios de empresa.
Hasta la fecha, la mayoría de proyectos de desarrollo Blackberry que hemos llevado acabo en elDepartamento de Ingeniería de Software de Soltel IT Solutions estaban orientados a soluciones empresariales, es decir desarrolladas por la empresa, para la empresa (modelo de negocio B2B). Sin embargo hemos recibido peticiones de proyectos Android y iPhone, cuyo usuario final, es el consumidor de a pie (modelo de negocio B2C). Esta separación, cada vez es menos evidente, ya que iPhone se está extendiendo en el entorno empresarial, y Blackberry ha intentado acercarse al gran público con dispositivos de gama media, como la Curve y aplicaciones como Blackberry Messenger, con gran aceptación entre los más jóvenes.
Android mantiene una cuota relevante en el mercado. Hay factores que han influido en que proliferen aplicaciones de esta plataforma, como por ejemplo, el ser una apuesta de Google, haber dispositivos potentes de varios fabricantes como HTC y Samsung, ser nativo Java, tener un SDK (Software Development Kit) abierto, con grandes facilidades para publicar en Android Market...
No podemos perder de vista la alianza subscrita entre Microsoft y Nokia (dispositivos Nokia con sistema operativo Windows Phone). En mi opinión, más allá de la calidad del producto, han llegado muy tarde, y puede que ya no haya pastel que repartir.
El mundo de la tecnología es cambiante. El pasado es hace dos años, y el futuro es dentro de un minuto. Esto se acentúa en la tecnología móvil, donde los cambios son constantes. Una empresa experta en desarrollo de software para móvil, no puede permitirse el lujo de no conocer las plataformas más importantes que copan el mercado, aunque estas queden fuera de su stack tecnológico. Por otro lado las librerías y frameworks que los fabricantes ponen a disposición de desarrolladores hacen que el escalón entre el desarrollo de una aplicación móvil y una web o de escritorio se reduzca.
Publicado por Alejandro R. Caraballo Maestre
No hay comentarios:
Publicar un comentario