Menu



Herramientas para ser más eficientes

¿Por qué se demoran o fracasan los grandes desarrollos de software? En tiempos en que la competitividad de muchas organizaciones suele estar atada a la rápida puesta en marcha de estos desarrollos y los procesos asociados, la pregunta resulta acuciante. Por otra parte, el surgimiento del Software como Servicio y del Cloud Computing demanda mayores niveles de eficiencia y agilidad para estos proyectos. En el reciente Software Innovate 2012, celebrado en Orlando, Florida, IBM anunció varias novedades y actualizaciones que apuntan a resolver mejor estos desafíos. Conózcalas y acceda a la filosofía detrás de dichas herramientas.


En El gorila invisible, y otras maneras en las que nuestra intuición nos engaña, Christopher Chabris y Daniel Simons describen una estrategia exitosa para vencer la llamada “ilusión de conocimiento”, que consiste en creer que sabemos más de lo que realmente sabemos sobre un tópico. Según los investigadores, a veces confundimos familiaridad con conocimiento, o creemos que porque sabemos hacer funcionar algo, entendemos cómo funciona. En sistemas complejos, como los que se dan en la construcción de un software, esta ilusión prevalece y puede tener graves consecuencias. Chabris y Simons citan un artículo de The Wall Street Journal, del 20 de mayo de 2008, titulado “Keeping it simple pays off for winning programmer”, de Ben Worthen. Allí se cuenta el caso del ganador del TopCoder Open (una competencia de programadores) de ese año, Tim Roberts, cuyo secreto para triunfar fue: “Preguntar hasta saber exactamente qué era lo que quería el jurado que el software hiciera”.

El secreto de Tim Roberts puede parecer básico, casi infantil, pero apunta al corazón de uno de los grandes desafíos de la industria de TI, que es la creación de silos y la falta de colaboración entre las áreas que están llevando adelante un proyecto. Worthen señala que la mayoría de los proyectos de tecnología fracasan, o bien porque se entrega tarde, o bien porquen los desarrollos no cumplen con lo que se esperaba de ellos. Dos de las principales razones para esto, según Worthen, son que existe una comunicación pobre entre el departamento de TI que desarrolla el sistema y la gente de negocios que debe usarlo, y la afluencia de nuevos requisitos, que en última instancia puede hacer que el proyecto descarrile.

Según un relevamiento sobre CIOs de IBM, realizado en base a cientos de compañías, el 50% de las aplicaciones desplegadas deben volver atrás, y el re-trabajo significa más del 30% del costo de los proyectos. Esto se vuelve más crítico en los años recientes, cuando muchas organizaciones que fallan en el uso y la gestión del software ven lastrado su desempeño a la hora de competir en el mercado.

Hace más de una década, una de las tentativas para resolver este conflicto fue Agile Software Development, un método colaborativo de desarrollo de software que apuntaba a que ese desarrollo fuera iterativo y a que se diera en pequeños pasos evolutivos. En esta misma línea colaborativa, más recientemente surgió DevOps: una metodología que impulsa la comunicación y la integración entre los desarrolladores de software, el área de Quality Assurance (que revisa que el desarrollo cumpla con las necesidades del negocio) y los profesionales de TI del área de operaciones, que son los encargados de desplegarlo y darle soporte.


De esta manera, las áreas de las organizaciones tradicionales de TI pueden colaborar de manera mucho más íntima para, en última instancia, acelerar los desarrollos y aumentar la eficiencia. Al mismo tiempo, se lidia con la tensión entre las expectativas y deseos de las áreas de Desarrollo (que impulsan el cambio) y de Operaciones (que buscan la estabilidad).

Algunos de los puntos de anarquía entre ambas áreas son:

• Los desarrolladores a menudos no están al tanto del impacto de sus códigos sobre Operaciones. Esta última no participa de las decisiones de arquitectura o de las revisiones de los códigos.
• Los desarrolladores no le dicen al área de Operaciones qué cambios se requieren para correr el código base actualizado.
• El área de Desarrollo está impulsada por requerimientos funcionales, en general relacionados con el área de negocios, en tanto que Operaciones se mueve por requerimientos no funcionales como disponibilidad, estabilidad o performance.
• Operaciones no está interiorizada totalmente sobre los elementos internos de la aplicación, de modo que no siempre pueden definir correctamente el entorno de ejecución y los procedimientos de actualización. Por otra parte, Desarrollo no siempre sabe en qué entorno correrá la aplicación, de modo que no siempre puede adaptar el código de manera concordante.

En tiempos en que la competitividad de una empresa está relacionada con la rapidez con que se implementan nuevas aplicaciones y procesos, el impacto de DevOps en esas organizaciones es significativo. Por otra parte, el surgimiento del sistema de distribución de Software como Servicio y de la Nube en general aceleró la esta necesidad de tirar abajo los silos entre Desarrollo y Operaciones, porque en este escenario es importante que el desarrollador esté al tanto de cómo la aplicación será desplegada, escalada y mantenida, de forma de modificar el código para evitar cualquier barrera operacional.

En el caso de IBM, existen dos familias de soluciones que generan sinergia. En 1996, IBM compraba la texana Tivoli Systems, por US$ 743 millones. La especialidad de Tivoli son las herramientas de gestión de sistemas. Seis años después, IBM hacía lo mismo con Rational Software (por US$ 2.100 millones). En aquel momento la Nube no existía como hoy la conocemos, pero IBM ya se preparaba para la incipiente “computación bajo demanda”. En este marco, Rational proveía soporte para el desarrollo de aplicaciones empresariales en varias plataformas (como J2EE y .NET, entre otras).


Con todo, las aplicaciones de Rational no estaban integradas. “Jazz fue un esfuerzo para establecer una capa de colaboración entre los desarrolladores, los usuarios y la gente que administra las aplicaciones en el departamento de TI —explica José Ramón Peña, responsable de Rational para América Latina, en ocasión de Innovate 2012, celebrado en junio pasado—. Nosotros creamos además una comunidad semicomercial basada en Eclipse, llamada Jazz.net. Allí lanzamos los estándares y los diseños de cómo queríamos hacer las cosas, y en conjunto construimos Jazz con desarrolladores independientes”. El estándar propuesto para esto fue OSCL, hoy suscripto por proveedores como Oracle y HP.

José Ramón Peña - IBM Innovate 2012
El responsable de Rational para América Latina explica los inicios de Jazz.

Durante Innovate 2012, IBM anunció la nueva versión del software integrado para la Gestión del Ciclo de Vida Colaborativa (Collaborative Lifecycle Management ó CLM), que extiende las capacidades de gestión de diseño. CLM se basa en la plataforma de desarrollo abierta de IBM, Jazz, y reúne al IBM Rational Requirements Composer, IBM Rational Team Concert e IBM Rational Quality Manager. El nuevo software CLM asegura que el diseño de software se integre con el resto del ciclo de vida de desarrollo de aplicaciones.

Para IBM es claro que hay cuatro drivers que provocan una necesidad de contar con sistemas desarrollados en la forma más rápida posible. Por un lado está la creciente globalización que dificulta el trabajo colaborativo. Luego esta la consumerización de la tecnología, ahora es la gente la que lleva tecnología a la empresa sea en forma de celulares, tablets o notebooks, y ello implica demandas por realizar cambios en forma rápida. Además está la aparición de tecnologías disruptivas como sucedió con las redes sociales y eso conlleva la tarea de bajar los tiempos en los ciclos de desarrollo que tienen las empresas. Y por último el software tiene un rol cada vez más crucial en brindarle a la empresa innovación pero al mismo tiempo necesita de nuevas reglas de governance.

Read more http://www.pymeyemprendedores.com/2012/07/herramientas-para-ser-mas-eficientes.html

volver arriba

Comentarios

ULTIMOS ARTICULOS