Llegamos a ustedes gracias a:



Reportajes y análisis

Nuevas fronteras en el desarrollo de software

Los proveedores con visión de futuro mezclan metodologías, contratan programadores de funciones cruzadas -y llevan a los viejos proveedores hacia mercados más emergentes de aplicaciones populares.

[28/06/2013] El tamaño (y la movilidad) importan. A medida que las PC de escritorio pierden terreno ante las tabletas y los teléfonos inteligentes, y la nube se convierte en un medio más accesible para la implementación de software, las aplicaciones de escritorio están siendo dejadas de lado por las aplicaciones móviles y servicios web, lo que indica un cambio significativo en la forma en que es creado el software.
Las grandes y pequeñas organizaciones de desarrollo de software se están moviendo rápidamente para adoptar nuevas herramientas y nuevos paradigmas, adaptando sus conjuntos de herramientas existentes, grupos de talento y procesos, para aprovechar al máximo los nuevos entornos de computación y las oportunidades emergentes.
Atrás han quedado los días en que los bits se transmitían de un equipo aislado a otro en servicio de una sola manera. El desarrollo de aplicaciones modernas requiere un enfoque ágil y multifuncional para el despliegue rápido.
Aquí mostramos la forma en que varias tiendas de desarrollo de vanguardia alcanzan los desafíos de esta nueva frontera.
1. Primer desarrollo móvil y servicios: La ola del mañana -o por lo menos de hoy
Desde fuera, la tendencia de desarrollo que se volvió rápidamente evidente para todos -los usuarios finales, clientes y desarrolladores por igual- es el énfasis en el primer desarrollo móvil, junto con toda la complejidad que ello conlleva.
"Las aplicaciones ahora son enormes", señala Matt Powers, director de tecnología de Applico, un desarrollador de aplicaciones móviles e Internet para una variedad de grandes clientes como Google, Asics, National Oceanic and Atmospheric Administration, AT& T, y Mayo Clinic. "Solían ejecutarse localmente fuera del dispositivo, por lo que la infraestructura de soporte era pequeña. Ahora hay gente que lleva su marca, y todo lo que hace al sitio web, si es que tienen, en su móvil".
Si la infraestructura se despliega como SaaS (software como servicio), requiere prácticas de desarrollo que son órdenes de magnitudes más rigurosas y complejas que las utilizadas para la implementación de aplicaciones stand-alone.
Intuit, los creadores de QuickBooks y GoPayment, aprendieron esta lección cuando la empresa amplió sus servicios para satisfacer un mercado internacional de 1,3 millones de usuarios -que cubren 150 países, 143 monedas y 46 idiomas.
"Tuvimos que escalar el desarrollo de pequeños equipos de 10 a 15 ingenieros a un equipo de más de 70 ingenieros", explicó Anshu Verma, arquitecto en Intuit para QuickBooks Online. Los ingenieros necesitaban desarrollar con mayor rapidez, y por lo tanto adoptaron lo que él llama un "primer modelo de seguridad", que se inspira en la forma de funcionamiento de los interruptores de circuito. Este diseño permite que coexistan los flujos de trabajo nuevos y antiguos -una característica importante para un servicio web. "En caso de exigencias, volvemos al viejo flujo de trabajo sobre la marcha, y cortamos el nuevo flujo cuando estamos seguros de ello. Realmente nos ayudó a movernos más rápido sin afectar a los clientes".
El propio ciclo de desarrollo de nuevas características en Intuit toma hoy en día solo de dos a cuatro semanas, lo que les obliga a utilizar los procesos Scrum y la automatización de pruebas. "Utilizamos herramientas como Jira, Greenhopper y Rally para facilitar las iteraciones en las partes principales -la gestión de productos, desarrollo, control de calidad, implementación- y crear marcos de pruebas con herramientas modernas como WebDriver, PhantomJS, JSUnit, DOH [Dojo Objective Harness], JUnit, y así sucesivamente".
Por otro lado, el cambio de prácticas en aras de la movilidad no tiene mucho sentido si no está respaldado por una estrategia empresarial. Tal como piensa Joel Semeniuk, quien ha sido director de proyecto por más de 20 años y ahora es vicepresidente ejecutivo de gestión de proyectos en Telerik,  que crea una amplia gama de herramientas de prueba de software y componentes de interfase de usuario para .Net.
"Desde que lo móvil está de moda", señala Semeniuk, "es muy fácil quedar atrapado en la estrategia del primer desarrollo móvil y no dejar de tener en cuenta el valor real que la aplicación móvil le proporciona al cliente". Este valor incluye la creación de las herramientas adecuadas para el trabajo que se necesita: "Algunas aplicaciones no están bien adaptadas a escenarios móviles -por ejemplo, las que requieren grandes cantidades de entrada de datos".
2. Encuentre la combinación adecuada de metodologías de desarrollo para satisfacer las necesidades del proyecto
Las guerras por las metodologías ágiles de desarrollo -ágil, XP (programación extrema), cascada, etc.- están dando rápidamente paso a un enfoque más fluido y flexible para producir y refinar un producto. Semeniuk de Telerik es uno de muchos en el mundo del desarrollo moderno que ve metodologías de desarrollo, no como dogmas que deben ser seguidos al pie de la letra, sino como herramientas que se distinguen por lo que es útil. Confinar a un equipo de desarrollo en una metodología se está convirtiendo en algo del pasado.
"Tenemos un patrón de repetición para cada problema", señala Semeniuk, "en el que continuamente nos adaptamos o jalamos nuevas prácticas ágiles que resuelvan esos problemas. A veces jalamos todo de Scrum, ya que resuelve la amplia gama de problemas que se presentan en ese ambiente particular. A veces sacamos trozos de Scrum y XP o Combine, ya que tiene más sentido si se encuentra en modo de mantenimiento". Semeniuk llama a esto el modelo mesa de bufet ágil.
Para Telerik, sin embargo, el motivo más importante detrás del uso de cualquier práctica de desarrollo se debe al por qué. "Nos gusta empezar con el por qué y utilizar agile para resolver un problema real que estamos teniendo. La razón principal para ello es porque cuando solo intentamos sacar las prácticas, no pegan; las personas no identifican las razones por las que estas prácticas tienen sentido. Y no todas las prácticas se ajustan a todos los proyectos", agrega.
Powers de Applico señala que su compañía también utiliza una variedad de modelos de desarrollo -sobre todo ágiles e iterativos. En su caso, el "por qué" es impulsado por las necesidades del cliente.
"A algunos clientes les gustan las líneas de tiempo rígidas y la documentación", comenta Powers, "sobre todo los que se la quieren llevar a casa. A otros les gusta la fluidez del proceso ágil y la capacidad de ser llevados al loop en todo momento".
Algunos, sin embargo, advierten que agile no puede limitarse a ser pulverizada sobre un proceso de desarrollo existente. Un ex director del programa que se ha negado a ser nombrado, pero tiene cinco años de experiencia como master de Scrum, ha visto el uso de agile en el desarrollo una y otra vez, pero sin cambios correspondientes en otras facetas aparte de poner software en el mercado.
"No hay control de calidad intermitente, en su lugar hay un control de calidad de la vieja escuela", señala. "En lugar de lanzamientos regulares, están utilizando agile para sacar algo, y luego interrumpir el cronograma con el soporte". En su ámbito, hay una batalla entre las versiones de software tradicionales y agile, con mucha gente que utiliza agile solo para impulsar modelos de la vieja escuela.
3. Busque ciclos de vida más cortos, equipos multi-funcionales
La filosofía "móvil primero" del desarrollo moderno ha cambiado la gestión del ciclo de vida de las aplicaciones en formas sorprendentes.
"La referencia a un ciclo de desarrollo más corto es engañosa para el desarrollo web", señala Andrew Frankel, ex vicepresidente de ingeniería en TopShelfClothes.com. "Ya no es necesario completar un ciclo completo de un lanzamiento de control de calidad para todos los cambios. Los cambios pequeños, como modificar el texto, pueden saltarse el proceso habitual, ya que se pueden implementar sin ningún impacto en el usuario. Esto libera al equipo de control de calidad para que pueda centrarse en probar los cambios reales en las aplicaciones". Los desarrolladores de aplicaciones móviles y de escritorio, añade, no son tan afortunados, ya que cada cambio requiere una nueva versión.
Para Semeniuk de Telerik, los mayores cambios en la gestión de aplicaciones están en la web y la movilidad. Para esas áreas, dice, "son imprescindibles los ciclos cortos de lanzamiento, porque es muy difícil precisar cierto valor para el cliente y la interacción, sin tener que medirla".
Esto significa poner artículos en manos de los clientes rápidamente a través de un modo de implementación sólido y automatizado. "Esto ha dado lugar a un nuevo sabor de la gestión de aplicaciones llamada devops, donde el equipo de desarrollo y el equipo de operaciones tienen que trabajar juntos para asegurarse de que, así como se requiere retroalimentación, se pueda entregar el software en las manos de los usuarios sin mucha dolor", agrega.
Semeniuk también considera que, para las grandes organizaciones, la composición del equipo en general está cambiando tan rápidamente como debería para poder reaccionar a estos cambios: "Los equipos (en las organizaciones más pequeñas) han indo cambiando de los roles funcionales -equipos de analistas de negocios, equipos de pruebas, equipos de implementaciones, etc.- a equipos multi-funcionales, en los que todas las habilidades a imaginar, crear e implementar en una aplicación, se encuentran en un solo equipo. Los equipos trabajan en conjunto como un todo para entregar ese software en lugar de retenerlo entre equipos funcionales".
Algunas empresas tienen dificultades para hacer este cambio de papeles entre funciones, pero Semeniuk cree que esto dejará de suceder cuando "las organizaciones puedan darse cuenta de que una estructura de recursos humanos no tiene que dictar una estructura de equipo".
4. Uso inventivo de la caja de herramientas de desarrollo estándar
Los equipos de desarrollo modernos están ampliando la chimenea del ingenio hasta en las herramientas que utilizan, empleando instrumentos de desarrollo populares en nuevas formas de estimular la innovación del proceso de desarrollo. Considere a Git, el sistema de control de revisiones de código abierto- que puede ser utilizado para mucho más que su propósito principal. Para Andrew Frankel, ex vicepresidente de ingeniería en TopShelfClothes.com, Git fue también una manera de llevar a cabo la automatización de procesos.
"Conducir implementaciones con Git es fantástico para la gestión de lanzamientos", señala Frankel. "Tenemos un registro completo de lo que ha cambiado, en qué momento y por qué razones. Las organizaciones más grandes a menudo tratan de recoger con exactitud esos puntos de datos con peticiones de cambios formales, que tienden a generar fricción en un entorno de ritmo rápido. Es mucho más eficiente crear un proceso en el que la información se recoge de forma automática".
En Telerik, Git fue adoptado por un equipo como una vía de escape de la metodología habitual de desarrollo interno.
"Tenemos una división que ha optado por no utilizar nuestra infraestructura de desarrollo, que está basada principalmente en Microsoft Team Foundation", señala Semeniuk de Telrik. "Decidieron utilizar algo que encaje mejor con su cultura, experiencia y necesidades, y comenzaron con Git. Una forma totalmente diferente de gestión de versiones con diferentes herramientas, pero encaja mucho mejor en su cultura y en la experiencia de los miembros de su equipo". El equipo en cuestión podría no tener que elegir entre el flujo de trabajo y Git, de Microsoft antes de tiempo; sin embargo, Microsoft ha añadido recientemente soporte de Git a Visual Studio y a Team Foundation Server.
Git también ha sido utilizado para dar apoyo a otras partes del desarrollo, tales como la documentación. El sistema Gitit wiki utiliza Git (u otro sistema de control de versiones) para rastrear y mantener cambios en un conjunto de documentos creados por la comunidad.
También debe sorprender que la nube figure en la obra de casi todo el mundo como una herramienta de desarrollo de software de vanguardia. Pero no es sólo un lugar para albergar código o un sitio -también está vista como marco de pruebas. Applico, en particular, está desarrollando una fundación basada en la nube para realizar pruebas automatizadas de sus aplicaciones.
"Con Android, especialmente, tiene un mercado internacional pues el producto se ejecuta en más de 500 dispositivos", explica Powers de Applico. "Si puede integrar esto en un sistema en el que se puedan simular todos estos diferentes tipos de dispositivos, va a encontrar muchos problemas antes de salir al mercado". Para ello, Applico ha estado observando a algunos proveedores para proporcionarles herramientas que tomen las compilaciones de aplicaciones de la empresa, las alojen en la nube, y lleven a cabo la emulación allí.
Este enfoque parece ser un intento por refutar lo que Sebastian Holst ha afirmado en "The Rise of Application Analytics: A New Game Demands New Rules" (El crecimiento del análisis de aplicaciones: Un nuevo juego exije nuevas reglas). Allí, Holst señala que "no se puede simular la producción", lo cual significa que "la diversidad y distribución de los servicios en las instalaciones y en la basados en la nube, en combinación con la increíble variedad de dispositivos y los tiempos de ejecución de los clientes, hace que las pruebas completas y perfiladas antes de la producción no solo sean difíciles, sino imposibles".
Para Holst, la solución está en el análisis de la aplicación: la cosecha en tiempo real de los datos del comportamiento de las aplicaciones como en el trabajo de Telerik. La idea de Applico es ampliar la forma de realizar y automatizar pruebas -no desplazar el análisis como una metodología de prueba, sino utilizar la nube como una forma de reducir la carga de las pruebas.
Dos de las herramientas más utilizadas para la automatización, Puppet y Chef, también se están utilizando de manera creativa.
"El uso de servidores en la nube y Chef para las pruebas manuales es fantástico", señala Frankel, "ya que los servidores solo se utilizan de vez en cuando por unas horas. Cuando terminamos las pruebas, apagamos las luces y evitamos el pago de la capacidad ociosa. Solo se utiliza un único comando para volver a crear un nuevo entorno de ensayo la próxima vez que queramos probar". Con Puppet también es posible el mismo proceso.
5. HTML5 - un práctico, aunque exagerada, solución para la creciente fragmentación del dispositivo
Dado el enfoque actual en el primer desarrollo móvil, se le está prestando mucha atención para saber qué papel va desempeñar. Por un lado, los desarrolladores se están pasando rápidamente a HTML5, porque no hacerlo sería autodestructivo. Por otro lado, es evidente que no es la cura para todo.
Powers de Applico tiene una mala opinión de HTML5 como plataforma móvil. "HTML5 nunca se pondrá al día con el desarrollo nativo", insiste. "Si piensa manejar todo desde una vista web, está abstrayendo una capa entre usted y el código nativo. Siempre va a estar un paso atrás, y a medida que salgan las nuevas versiones de los sistemas operativos, las herramientas como PhoneGap y Titanium tienen que reaccionar ante esos cambios".
En su opinión, HTML5 es la mejor opción para las aplicaciones empresariales, como formularios de presentación de datos y de experiencia no inmersiva.
Powers describió experiencias en su trabajo que arrojan más luz sobre esto. Los competidores de Applico atrajeron clientes ofreciendo construir aplicaciones con HTML5 a la mitad del precio de Applico. "Ocho meses más tarde, esos clientes regresaron a nosotros y nos dijeron: tomamos la decisión equivocada, nos fuimos con alguien que nos prometió el mundo, y realmente no entendía las limitaciones de las tecnologías".
El año pasado, Hung Lehong y Jackie Fenn, de Gartner, colocaron a HTML5 en el "pico de expectativas infladas" del informe anual Hype Cycle Report de Gartner, estimando que pasarían de cinco a diez años antes de que puedan alcanzar la verdadera meseta de la norma. Sin embargo, muchos desarrolladores están adoptando HTML5 y no toman en cuenta el informe de Gartner.
Kendo UI, una división de Telerik, realiza sus propios estudios y encontró que el 82% de los desarrolladores "consideran a HTML5 importante para su trabajo en los próximos doce meses", con un 31% que planea utilizarlo y un 63% que lo desarrolla activamente.
Dicho esto, la redacción de estas preguntas no se refiere a las preferencias de los desarrolladores, solo a lo que los desarrolladores están haciendo -es decir, la creación de aplicaciones HTML5 porque es parte de su descripción de trabajo. Es más, otro estudio patrocinado por Appcelerator e IDC para el año 2012, encontró que la mayoría de los desarrolladores de aplicaciones móviles encuestados eran "neutrales ante HTML5" en varias categorías, incluyendo el rendimiento (72,4% de los encuestados), la fragmentación (75,4%), y experiencia del usuario (62%). Esto es sorprendente a la luz de cómo un estudio anterior del mismo grupo le preguntó a los desarrolladores, "¿Tiene planes para integrar HTML5 como un componente en las aplicaciones móviles que planea construir en el 2012?" - De los cuales el 79% respondió que sí.
Todd Anglin, vicepresidente de HTML5 Web y herramientas móviles de Telerik, cuestionó esta conclusión, y no solo por el rápido desarrollo de HTML5 en todos los lados: "Los desarrolladores deben tener en cuenta que la nuevas aplicaciones nativas de Facebook todavía incluyen HTML5 en las secciones que Facebook quiere cambiar con mayor rapidez", escribió Anglin, haciendo referencia al muy discutido cambio que hizo Facebook en el 2012 para aplicaciones móviles nativas, debido a las deficiencias que experimentó con HTML5.
En resumen, por ahora HTML5 puede ser considerado simplemente como un ingrediente en la composición general de la aplicación, en lugar de la forma de crear una aplicación.
Conclusiones
Con tanto software producido ahora, dirigido a un mercado de telefonía o servicio móvil, las técnicas de desarrollo están evolucionando para adaptarse. Los programas de escritorio que durante años condujeron las revisiones, están siendo suplantados por aplicaciones móviles que son mejoradas cada pocos meses o por los servicios que se renuevan constantemente detrás de las escenas.
Las exigencias ante esos cambios son importantes, pero también han estimulado numerosas nuevas soluciones creativas, incluyendo nuevos casos de uso de las herramientas tradicionales y la nube como plataforma de desarrollo y pruebas, y no solo como un mecanismo de entrega de software.
El aumento de la velocidad del desarrollo (y los comentarios de los desarrolladores) significa que las nuevas tecnologías -HTML5- se ponen a prueba y se absorbe en la mezcla con mayor rapidez, acelerando el ritmo de relevancia.
Sin embargo, como siempre, el desarrollo de aplicaciones no se trata de un paradigma, herramienta o metodología particular; se trata de lo que funciona, aquí y ahora.
Serdar Yegulalp, InfoWorld (EE.UU.)