Download ¿Por qué el desarrollo ágil paralelo es esencial para su estrategia

Document related concepts

IPhone Dev Team wikipedia , lookup

Proceso para el desarrollo de software wikipedia , lookup

Jailbreak (iOS) wikipedia , lookup

Transcript
Serie de libros electrónicos para el desarrollo ágil paralelo: Capítulo 1
¿Por qué el desarrollo ágil
paralelo es esencial para su
estrategia de transformación
digital?
La necesidad de velocidad, eficiencia
y calidad en la economía de
aplicaciones
En la economía de aplicaciones actual, el software está cambiando las reglas de los negocios.
Debido a la presión competitiva para innovar e iterar
aplicaciones rápidamente, las organizaciones como la
suya están adoptando estrategias de transformación
digital en las que los componentes digitales se agregan
a los productos y servicios existentes (por ejemplo,
aplicaciones móviles, compatibilidad universal para
dispositivos, Internet de las cosas [IoT], etc.).
A medida que las empresas intentan construir
un ecosistema de valor en torno a estos productos
"conectados", la transformación digital produce
una nueva generación de software, y las interfaces
de programación de aplicaciones (API) necesarias
para prosperar en este entorno de colaboración.
Al mismo tiempo, las expectativas del cliente
de servicios originales y de alta calidad son más
altas que nunca; esto obliga a las organizaciones de
TI a repensar la manera en la que desarrollan, prueban
e implementan software para maximizar la velocidad,
la eficiencia y la confiabilidad a fin de satisfacer
las demandas del mercado.
Para el 2016, más de la mitad
de la colaboración entre
empresas se llevará a cabo a
través de API (interfaces de
programación de aplicaciones) web .
1
1
2
artner Hype Cycle for Application Development (Ciclo de sobreexpectación de Gartner para
G
el desarrollo de las aplicaciones), 2014, Thomas E. Murphy, et al, 29 de julio de 2014.
La transformación digital crea nuevos
desafíos en el ciclo de vida del desarrollo
de software (SDLC)
A medida que las organizaciones expanden sus objetivos de entrega de aplicaciones en respaldo de las iniciativas de transformación digital, los
grupos de TI deben enfrentarse a nuevos desafíos del ciclo de vida del desarrollo de software (SDLC), entre los cuales se incluyen los siguientes:
Complejidad en aumento
Integración requerida
A pesar de que la cara de una aplicación moderna podría ser simplemente una
colección de botones y campos, su arquitectura comprende un embrollo de
servicios e integraciones compuestos, cada uno de los cuales debe tenerse en
cuenta durante el desarrollo y las pruebas. Además, la mayor parte del
desarrollo se trata de conectar nuevos front ends de interfaz de usuario (UI) a
sistemas de registro heredados en el back end, lo cual genera nuevos desafíos
de codificación e integración.
Debido a que las aplicaciones modernas se deben integrar con servicios
complementarios y de terceros (además de los sistemas de registro internos),
las API deben construirse y probarse regularmente, pero los equipos de
desarrollo y prueba no siempre cuentan con el acceso a estos recursos esenciales
cuando los necesitan. A medida que las modas como la IoT avanzan, los equipos
de TI ahora deben integrar un conjunto de objetos totalmente nuevos con
atributos y requisitos únicos.
Falta de automatización
Limitaciones de recursos
A medida que las aplicaciones se vuelven más complejas y tienen más capas,
a menudo, las organizaciones adoptan herramientas de prueba diferentes que
requieren codificación manual o traducción entre distintas capas y entornos.
Si se utilizan métodos ágiles entre equipos distribuidos para acelerar las
actividades de desarrollo y prueba, los subcomponentes de la aplicación no
pueden probarse en su totalidad hasta la prueba de integración, momento en
el que todas las partes se unen por primera vez.
Se les pide a los equipos de TI que construyan e implementen más
aplicaciones más rápido que nunca, pero solo hay una cantidad determinada
de recursos para codificar y realizar pruebas. Cuando aparecen las limitaciones,
los equipos se enfocan en otras cosas en lugar de esperar a que los recursos
necesarios estén disponibles; esto genera tiempo de inactividad en el proyecto,
lo que a su vez demora el cronograma de entrega general.
En conjunto, estos desafíos impiden que los equipos de TI logren adoptar prácticas de desarrollo y prueba en paralelo.
3
El fracaso de la solución temporal
de simulacros auxiliares
Muchas organizaciones de TI intentan una solución alternativa
a las limitaciones de desarrollo y prueba mediante la codificación
manual de simulacros auxiliares personalizados. Por ejemplo, cuando
un desarrollador necesita acceder a un sistema o API no disponible,
puede crear un código que simula el comportamiento de esa limitación
y le da la respuesta que necesita para avanzar al siguiente paso.
El problema de los simulacros auxiliares es que, a pesar de solucionar
las limitaciones específicas al instante, generan problemas mayores
que ponen en riesgo los objetivos de transformación digital.
También existe un problema de escala. A medida que las aplicaciones
compuestas actuales se vuelven más intrincadas y complejas en el
back end, requieren más simulacros auxiliares personalizados para
simular las partes que las componen. Además, cada simulacro auxiliar
nuevo representa una chance de que el error humano entre en juego,
lo que puede ralentizar el paso de una aplicación por el SDLC
e impactar en la calidad en general.
Es por eso que, en lugar de resolver desafíos, los simulacros
auxiliares crean trabajo adicional y recurrente para los desarrolladores
y evaluadores. Además, ocupan el tiempo que podría dedicarse a otras
actividades de codificación más productivas y abren la posibilidad de
que la aplicación sufra de defectos o errores.
En primer lugar, los desarrolladores deberían maximizar su
tiempo codificando la aplicación en lugar de perder tiempo en
simulacros auxiliares que tienen sus propias limitaciones de
mantenimiento, consistencia y datos. Como los equipos crean
estos recursos para pruebas específicas, al final deben descartarlos
y así desperdician tiempo y esfuerzo.
94 %
2
de los ejecutivos de líneas empresariales sienten la presión de lanzar nuevas
aplicaciones más rápido y consideran que "la demanda del cliente"
y "las acciones competitivas" son los principales impulsores2.
CA y Vanson Bourne, investigación sobre la economía de las aplicaciones, 2014.
4
Las diferencias entre "realizar
con agilidad" y "ser ágil"
Pregúntese esto:
"¿Realmente estamos entregando
versiones de alta calidad
al mercado de forma más rápida
y con menor costo para la
empresa?"
Si la respuesta es "No", entonces
usted no se percata del verdadero
valor del desarrollo ágil.
Otra manera en la que las organizaciones están afrontando los desafíos
de la transformación digital es mediante las metodologías de desarrollo ágil.
El objetivo original del desarrollo ágil era el de dividir las prácticas lentas y monolíticas
de desarrollo en fragmentos más pequeños para que los desarrolladores, evaluadores y el
personal de desarrollo de negocios pudiesen trabajar en conjunto y acelerar el lanzamiento
de nuevas características al mercado A pesar de tener las mejores intenciones, muchos
grupos de TI no logran llevar las aplicaciones a producción con la velocidad y calidad que
quisieran; hay muchas razones para ello.
En algunos casos, siguen las prácticas ágiles durante el desarrollo pero realizan todas
las pruebas al final y, básicamente, atrasan la aparición de cuellos de botella a una etapa
posterior del SDLC y dejan los errores y las fallas hasta una etapa en la que es más difícil
identificarlos y más costoso repararlos.
En otros casos, los equipos de TI están limitados por la cantidad de recursos de desarrollo
y prueba a su disposición. Esto los obliga a escalonar sus esfuerzos en lugar de trabajar
en forma paralela, lo que reduce la velocidad y eficiencia que supuestamente deberían
incrementar con los métodos ágiles, a la vez que prolonga la producción de una aplicación.
5
Los beneficios del desarrollo ágil paralelo
Con el desarrollo ágil paralelo, puede:
Reducir la complejidad al simular una
variedad de entornos de desarrollo y prueba,
servicios y comportamientos cuando
y donde lo necesite
Dinamizar la integración
y colaboración con terceros mediante
la aceleración de la creación de
prototipos de API y su administración
Eliminar las limitaciones que impiden
el desarrollo y prueba en paralelo para que
pueda acelerar la salida al mercado
e incrementar la calidad de sus
aplicaciones en general
Automatizar las pruebas más
temprano en el SDLC y así reducir la
necesidad de pruebas manuales que
toman tiempo y mejorar la calidad de
las aplicaciones en general
6
El desarrollo ágil paralelo en tres pasos
Paso 1
Paso 2
Eliminación de limitaciones
Traslado de las pruebas
a la izquierda
Elimina las limitaciones de tiempo, datos,
disponibilidad y costos mediante la
simulación de sistemas dependientes
y comportamientos del cliente como
servicios virtuales, en el lugar y el
momento en que sean necesarios.
Aprovecha los servicios virtuales y recursos
de prueba para automatizar las pruebas en
etapas más tempranas del SDLC (donde los
defectos pueden resolverse más rápido
y a menor costo) y mejorar la calidad
y estabilidad de sus aplicaciones
de producción.
Paso 3
Desarrollo en paralelo
Gracias a que simula los sistemas,
servicios y recursos necesarios según sea
preciso y a que automatiza las pruebas,
puede incrementar drásticamente la
productividad del desarrollador y permitir
que los equipos trabajen en paralelo.
Costos de la corrección de defectos
$16000
$14000
$12000
$10000
cci
u
$8000
%
92
$6000
$4000
Co
n
ció
ca
l
tro
n
Co
d
da
ni
u
de
DEV 1
te
In
P
a
m
te
ba
DEV 1
DEV 1
a
e
ru
Aplicación 1
DEV 3
DEV 2
Aplicación 2
DEV 3
DEV 2
DEV 3
Aplicación 3
$5,596
eb
ru
P
g.
DEV 2
DEV 1
en paralelo
$-
fi
di
Semana 1Semana 2 Semana 3 Semana 4 Semana 5 Semana 6 Semana 7
secuencial
$7,136
$4,057
$2,517
$977
$2000
ed
de r
o
os p
ost
ec
ón d
HORA
$14,272
ar
cion
lu
r so
is
ls
de
a
eb
de
ac
n
ió
ac
t
ep
u
Pr
Fuente: Lyon, Dan, “Ingeniería de sistemas: necesaria para el desarrollo rentable de
productos seguros", The SANS Institute, 2012
7
n
ió
cc
u
od
Pr
DEV 2
DEV 1
DEV 1
Aplicación 1
DEV 3
DEV 2
DEV 3
DEV 2
DEV 3
Aplicación 2
Aplicación 3
¿Qué sigue?
En el capítulo 2 de nuestra serie de libros electrónicos, analizaremos a fondo los distintos tipos
de limitaciones del SDLC, cómo impactan en el negocio y qué pueden hacer los equipos de desarrollo
y prueba para eliminarlas.
Para obtener más información, visite ca.com/ar/agiledevelopment.
CA Technologies (NASDAQ: CA) crea un software que impulsa la transformación en las empresas y les permite aprovechar
las oportunidades de la economía de aplicaciones. El software es el centro de cada empresa, en cada industria. Desde la
planificación hasta el desarrollo, la administración y la seguridad, CA trabaja con empresas en todo el mundo para cambiar la
forma de vivir, realizar transacciones y comunicarse, mediante entornos móviles, de nube pública y privada, centrales
y distribuidos. Obtenga más información en ca.com/ar.
© Copyright CA 2015. Todos los derechos reservados. El propósito de este documento es meramente informativo y no constituye ningún tipo
de garantía. Todas las marcas registradas, los nombres comerciales, las marcas de servicios y los logotipos mencionados en este documento
pertenecen a sus respectivas empresas.
CS200-127705-1