La agilidad, una cuestión fundamental en la era de las aplicaciones

Informe técnico de negocio
La agilidad,
una cuestión
fundamental
en la era de las
aplicaciones
Pese a su potencial, algunas empresas aseguran que lo prometido
por la metodología ágil sigue siendo difícil de alcanzar. Otras
han descubierto que implica más cambios de los que esperaban.
E incluso hay otras que opinan que la necesaria velocidad que
supone esta metodología choca, con demasiada frecuencia, con la
necesidad de estabilidad que requieren las operaciones.
¿Cómo puede conseguir una empresa la verdadera agilidad si los
antiguos hábitos son tan difíciles de romper? Identificar y evitar
las medidas de agilidad parcial es un comienzo. El resto depende
de comprender el ciclo de vida completo y ser capaz de unificar
el desarrollo y las operaciones como parte de una "cadena de
suministro de las aplicaciones" continua.
Los cuellos de botella en el ciclo de vida de las
aplicaciones pueden lastrar los resultados de
la metodología ágil. Y, ¿cuál de esos cuellos de
botella es el principal? No tenga dudas, el vacío
que existe entre el desarrollo y las operaciones.
El movimiento DevOps busca llenar esos vacíos y
acelerar la última milla que lleva a la producción.
Introducción
Vivimos en la era de las aplicaciones. La agilidad empresarial,
por lo tanto, depende ya inexorablemente de ellas. Los métodos
ágiles, que han dejado atrás a la tradicional prestación secuencial
de las aplicaciones se ha convertido, en una de las historias
de modernización más exigentes desde la pasada década. La
metodología ágil promete ayudar a los responsables de las
aplicaciones a entregar un software de mayor calidad y con
mayor rapidez. Y dado que fomenta la colaboración entre éstos
y los comerciales, también favorece que esta parte fundamental
para el negocio esté estrechamente alineada con los requisitos
empresariales.
No todas las tendencias modernas podrían respaldar de la misma
manera los objetivos actuales de las TI en cuanto a predictibilidad,
calidad y preparación para el cambio. Si se practica de forma
correcta, la metodología ágil revela defectos en el código en
las etapas más iniciales del ciclo de desarrollo, reduce el riesgo
global del proyecto y permite dar una respuesta más veloz a las
cambiantes prioridades del negocio.
2
La metodología ágil se mide por la
agilidad que trae a la empresa
La trampa de la "scrummerfall" (melé en cascada)
En la carrera por beneficiarse de las prácticas ágiles, muchas
empresas tienden a la adopción gradual. En tales casos, los
técnicos de desarrollo adoptan con entusiasmo las iteraciones
de tipo sprint, que favorece la metodología ágil, mientras que
las compañías y los equipos de QA (Aseguramiento de la Calidad)
siguen manteniendo sus posiciones predeterminadas, antiguas y
secuenciales en la planificación de los proyectos. Podría decirse
que esas empresas se han pasado al desarrollo ágil, aunque sin
haber adoptado todavía la entrega ágil.
En consecuencia, el objetivo clave de la metodología ágil - la
rápida detección de los problemas - se ve frustrado. Terminar
el código a mayor velocidad no acorta el tiempo de puesta en el
mercado, ni mejora la calidad, si el resto de la organización que
presta el servicio (analistas empresariales, ingenieros de QA,
jefes de proyecto) sigue guiándose por las prácticas y plazos
secuenciales impuestos por la metodología tradicional o en
cascada.
Esa filosofía híbrida de metodologías en cascada / ágil se ha
convertido en algo tan común como para ganarse un apodo:
"scrummerfall" (melé en cascada). Y se dice que, usando la melé
en cascada, los proyectos fallan el doble de rápido de lo que lo
harían empleando solamente la metodología en cascada.
Usted precisa de una mentalidad ágil
Analicemos la metodología ágil desde la perspectiva de
lo que debería ser: una filosofía de entrega que se repite y
en crecimiento. Si se aborda solo una pequeña parte de la
funcionalidad de una aplicación en cada momento, el código
puede desarrollarse en un intervalo de tiempo mucho más corto.
Cuando se implanta tal y como se ha concebido, la metodología
ágil elimina el desorden del método de desarrollo. El equipo recibe
una continua realimentación con respecto al sistema, por medio
de actividades de validación y aportaciones de los interesados, a
fin de asegurarse de que mantiene su rumbo.
Cómo debería ser la metodología ágil:
Cómo es la metodología ágil con demasiada frecuencia:
División en el enfoque: la división del alcance de un proyecto en períodos
temporales cortos y diferenciados (por ejemplo, un sprint de entre dos y cuatro
semanas), obliga a los equipos a priorizar sus objetivos y a pensar con pragmatismo
acerca de lo que pueden conseguir en cada ventana.
Sin cambios.
Trabajo continuado con los interesados: en contraste con el modelo formal,
a cierta distancia, de la metodología en cascada, la ágil anima a mantener un
contacto estrecho y constante con los actores empresariales interesados. Recibir
la aprobación de los interesados a lo largo de todo el proceso ayuda a mantener las
expectativas alineadas y las sorpresas desagradables al nivel mínimo.
Sin cambios.
Diseñado para revelar los problemas: dado que cada sprint implica tareas de
desarrollo y prueba, los equipos adquieren la oportunidad de comprobar las
integraciones, desde su funcionalidad hasta las opciones de arquitectura. Con la
metodología en cascada tradicional, esas áreas no se someten a pruebas hasta una
etapa muy posterior del proyecto - cuando deshacer el entuerto puede ser mucho
más costoso.
La prueba unitaria se acepta como sustitutivo de la prueba del sistema, pero la
validación exhaustiva y veraz no se produce hasta etapas posteriores del proyecto.
Ese retraso deja el proyecto abierto a los mismos riesgos de la metodología en
cascada: problemas por sorpresa y escaso tiempo para resolverlos.
Pruebas rigurosas y acumulativas: a medida que los equipos de desarrollo se
desplazan por cada sprint, comprueban de modo regresivo todo lo que viene de
atrás. Esto les permite enterarse de si el último sprint de desarrollo ha roto algo en
los anteriores. Cuando surgen problemas, su localización queda confinada al último
sprint y no al proyecto por entero.
Las partes se confunden con el todo. Cada sprint se prueba por su cuenta, sin
pruebas de regresión que verifiquen el funcionamiento de los sprints anteriores.
El equipo no conoce hasta las fases más avanzadas del proyecto la funcionalidad,
rendimiento o seguridad acumulados de la aplicación, disponiendo de poco tiempo
para reaccionar a los problemas.
Diseñado para el cambio: en lugar de comenzar por todo el trabajo de diseño de
requerimientos (muchos de los cuales se modificarán con el paso del tiempo), en la
fase inicial se designan solamente el alcance y las funcionalidades de alto nivel (la
historia de usuario). Los detalles se van trabajando sprint por sprint, en respuesta a
la propia aplicación y a medida que ésta toma forma.
El equipo está abierto al cambio sin estar preparado para él. Las limitaciones
implican que el cambio se introduce con muy poca apreciación de su impacto.
Medido en su progreso real: La metodología ágil promueve la idea de que la bondad
del desarrollo de software se mide solamente por las realidades ejecutables que
produce. Su progreso se mide por el código trabajado y probado - no por el número
de reuniones de cierre que se hayan mantenido, las líneas de código escritas o los
documentos técnicos completados.
Si no hay resultados de pruebas con éxito, el progreso es un espejismo.
Las TI ágiles y las tradicionales, juntas y en perfecta
armonía
Quizás uno de los motivos para que las empresas adopten más
lentamente la metodología ágil sea su miedo a que engendre más
hábitos malos que buenos. Pero buscar los hechos diferenciales de
la metodología ágil, hechos como la flexibilidad y la capacidad de
respuesta, no significa que tenga que abandonar los objetivos de las
TI tradicionales, como la consistencia y la minuciosidad.
La verdad es que ambas metas pueden darse soporte mutuo.
Considere unas pocas áreas clave en las que los objetivos de las TI
tradicionales, si éstas se ejecutan de manera apropiada, puedan
ayudar a potenciar los fines de esta forma de desarrollo.
Velocidad y calidad
La métrica mejor conocida de un método ágil es la velocidad - la
velocidad con la que uno presta funcionalidades. Para mantener
esos indicadores en valores altos, los equipos podrían sacrificar las
pruebas de regresión, permitiéndose a sí mismos pensar que con las
pruebas unitarias es suficiente. O podrían retrasar las validaciones
no funcionales de cosas como el rendimiento o la seguridad.
¿El resultado? El descubrimiento tardío de los problemas y un
incremento de los defectos de producción.
Eso no significa que la velocidad y la calidad sean incompatibles,
sino que resulta crítico que los equipos eliminen el esfuerzo
manual, siempre que sea posible, si los equipos de QA esperan
poder seguir el ritmo del desarrollo. Por ejemplo: incluso las
pruebas manuales pueden acelerarse gracias a HP Sprinter, que
permite la introducción automática de datos así como las "pruebas
en espejo", en las que las acciones de una única herramienta de
prueba se duplican a través de múltiples entornos de búsqueda.
También proporciona la capacidad de registrar de forma automática
los pasos de prueba efectuados, haciendo más sencillo documentar
y reproducir los defectos.
A medida que la base de código crece de sprint a sprint, la relación
entre velocidad y calidad exige adoptar la automatización real de
las pruebas. La herramienta de prueba funcional unificada de HP
no solo ofrece la capacidad de automatizar la prueba de interfaces
gráficas de usuario (GUI), sino que también automatiza los
servicios y componentes que no disponen de una GUI en absoluto.
Y la virtualización de servicios de HP permite que los técnicos
de desarrollo y comprobación prueben incluso los servicios con
grandes restricciones, o no disponibles en un entorno simulado o
virtual.
3
Flexibilidad y consistencia
Capacidad de respuesta y minuciosidad
A diferencia de los métodos tradicionales, que confían en planes
de proyecto engorrosos y a menudo obsoletos, la metodología
ágil anima a los equipos a ser flexibles y receptivos al cambio. Sin
embargo, eso puede conducir a la gestión ad hoc de los proyectos.
La metodología ágil nos anima a que esperemos el cambio, en
lugar de temerlo. Todas las empresas desean la capacidad de
adaptarse velozmente, sin molestias de sobrecarga o burocracia
que las ralentice. ¿Pero cómo podemos conseguirlo sin perder la
perspectiva crítica sobre qué ha cambiado y por qué? La inteligencia
del ciclo de vida de las aplicaciones de HP (ALI), una parte de HP
ALM, se conecta automáticamente a una gran variedad de entornos
de desarrollo, códigos fuente y sistemas de creación integrados,
a fin de extender la trazabilidad directamente hasta el código y
permitiendo que uno vea las conexiones entre todos los activos desde los requerimientos al código, pasando por los desarrollos
y las pruebas. Los técnicos de desarrollo pueden trabajar con las
herramientas de su elección, al tiempo que se conectan de forma
automática con sus colegas y la organización prestadora en sentido
amplio.
La gestión del ciclo de vida de las aplicaciones de HP (HP ALM),
acoplada al acelerador HP Agile Accelerator, aporta eficacia tanto
a los proyectos secuenciales como a los basados en un desarrollo
ágil. Ello supone que los equipos disponen de la instrumentación
adecuada (definición y gestión eficaces de las historias de usuario;
gestión de entregas, sprints y pilas de producto; gráficos de valor
generado y avance de tareas y representaciones cruzadas de
velocidad de sprint; y tablero automatizado), a la par que se asegura
que los equipos ajenos a la metodología puedan emplear más
métricas tradicionales - todo ello a través de una misma solución.
Los emprendedores y las economías de escala
La metodología ágil fomenta los equipos de menor tamaño y
superior autonomía. Se trata de buenos objetivos, pero pueden
conllevar una pérdida de colaboración y conocimiento compartido.
Los equipos independientes también convierten la reutilización en
algo más complicado, lo cual puede provocar una duplicación del
esfuerzo y la funcionalidad y, con ellos, mayores costes de entrega
y soporte.
Eso significa que, cuando llega una nueva solicitud de modificación,
el usuario puede seleccionar el requisito sujeto a cambios y, dada
la trazabilidad de extremo a extremo, ser capaz de ejecutar una
evaluación rápida pero concienzuda de su impacto, actualizar
el código y desplegarlo con la confianza de haber identificado y
realizado todas las variaciones requeridas.
HP ALM proporciona un almacén unificado de activos reutilizables
para que cualquier equipo, sea cual sea su ubicación, pueda
comprobar de un vistazo si una prueba ya ha sido creada y puede ser
reutilizada, si un requisito ya ha sido destacado o si un defecto ya ha
sido puesto de manifiesto.
¿ Presa de la "scrummerfall"?
Una organización puede plantearse tres
preguntas esenciales para sondear la eficacia
de sus esfuerzos de adopción de la metodología
ágil:
Los equipos distribuidos y de mayor tamaño también sacan partido
de herramientas de colaboración como HP Enterprise Collaboration,
un módulo integrado, de apariencia similar a las redes sociales,
para la colaboración basada en el contexto y el conocimiento
compartido.
1. ¿ Están descubriendo mis proyectos ágiles los defectos del
código en etapas más tempranas del ciclo de vida que mis
proyectos tradicionales?
Con un desarrollo ágil, los problemas deberían salir a la
superficie mucho antes.
2. ¿ Estoy viendo menos defectos en los productos terminados
cuando comparo mis proyectos ágiles con los que no lo son?
Esta metodología debería mejorar la calidad de un proyecto de
software, así como reducir los costes de las reparaciones.
3. ¿ Se sienten más satisfechos los actores empresariales, en
general, con los proyectos ágiles?
La metodología ágil debería ayudar a que los equipos
comerciales y de TI a que comunicasen mejor sus expectativas.
4
La última y crítica milla
Los equipos de entrega ágil han dado grandes pasos en la creación
de software. ¿Pero qué sentido tiene que sean capaces de crear con
rapidez nuevas prestaciones si se enfrentan a los cuellos de botella
impuestos por los ralentizadores procesos de entrega que hemos
usado siempre?
Este desafío se refleja claramente en una encuesta dirigida por
Forrester sobre la gestión de las entregas. Cuando se les preguntó
cuánto tiempo les lleva realizarla en el caso de un cambio que
afecta a una única línea de código - como medida esencial de la
sobrecarga operativa del proceso de entrega - más del 80% de los
encuestados declaró que se necesita más de un día, opinando el
44% que una semana o más.
Para capitalizar los avances logrados mediante el desarrollo ágil y
traducirlos mejor en valor empresarial, es la hora de extender los
principios de la metodología ágil al mundo de las operaciones.
Figura 1: ¿Cuánto tiempo se tarda en llegar a la entrega?
"Si fuese a modificar una línea de código de su proyecto, ¿cuánto
tiempo tardaría su organización, típicamente, en llevar el cambio
resultante hasta su puesta en producción?"
Menos de cuatro horas:
7%
Más de cuatro horas pero
menos de un día completo:
11%
Más de un día pero menos
de una semana:
39%
Más de una semana pero
menos de dos semanas:
11%
Más de dos semanas pero
menos de un trimestre:
Más de un trimestre:
18%
4%
Fuente: Forrester Research Inc., "Five Ways To Streamline Release Management"
(Cinco vías para racionalizar la gestión de las entregas), febrero de 2011 (encuesta
realizada a 101 profesionales de las TI).
DevOps y la entrega continua
El movimiento emergente DevOps tiene exactamente este desafío
como finalidad y persigue cubrir el vacío existente en los equipos
de desarrollo y los de operaciones de TI. DevOps se compone de un
conjunto de principios y métodos - inspirados por la metodología
ágil - orientado a una mejor colaboración entre los dos grupos.
La entrega continua, que DevOps hace posible, pone el foco en lo
que es más importante: unos ciclos más cortos hasta poner las
funcionalidades realmente en manos de sus usuarios. No solo
se basa en una mejor colaboración, sino en la automatización
exhaustiva de los procesos de creación, prueba y entrega. Al nivel
extremo, todo cambio del código que supera una serie de pruebas
automatizadas podría, por concepto, entregarse de inmediato.
Aunque la puesta en producción automática tiene sentido
solamente en ciertos escenarios, este nivel de integración entre
el desarrollo y las operaciones es revolucionario, ya que permite
que las entregas las gobiernen las necesidades empresariales, en
oposición a las restricciones operativas.
Las claves del éxito en la adopción de DevOps y la entrega continua
son la calidad, la automatización y la colaboración. Juntos, esos
elementos fundamentales pueden unificar nuestros tradicionales
silos de TI y dar rienda suelta a la agilidad por todo el ciclo de vida de
las aplicaciones, de extremo a extremo.
Más calidad, más confianza
La eficacia de DevOps comienza por la confianza - confianza
por parte de los equipos de operaciones en que los equipos de
desarrollo, trabajando a velocidades ágiles, no han pasado nada por
alto para ahorrar tiempo. En contraste con la visión de desarrollo
de entregar los cambios con rapidez, la mentalidad tradicional de
las operaciones concibe el cambio como una introducción de riesgo
- riesgo de problemas y riesgo de cortes del servicio. La visión de
las operaciones, y que es, además, como suele medirse a éstas, se
basa en la disponibilidad y estabilidad de la aplicación. De modo
que es comprensible que traten, con frecuencia, de minimizar los
cambios, si ello evita el sufrimiento que conlleva la entrega de un
software de baja calidad. La clave para reconciliar esas dos visiones
diametralmente opuestas reside en la calidad. Sin ella, la confianza
necesaria para la relación DevOps es incapaz, simplemente, de
consolidarse.
El proceso de entrega, o ruta de desarrollo, comienza con la
comprobación del código. Una técnica correcta puede elevar de
forma considerable la calidad de un cambio, a medida que éste
progresa por dicha ruta. Quizás ya utilice la integración continua
para crear código varias veces al día. Algo que puede ganar
mucha más potencia cuando se complementa con la verificación
automatizada de desarrollos y las pruebas de regresión. El potencial
de HP Lab Management Automation en cuanto a programación, alta
y despliegue de laboratorios de prueba, en este sentido, permite que
este modelo aporte una calidad superior desde el primer momento.
Esa realimentación regular y más rápida hacia los técnicos de
desarrollo implica que los problemas funcionales y no funcionales
se identifiquen y resuelvan antes, teniendo como resultado un
crecimiento limitado de los defectos, una visión más precisa de los
progresos y una reducción de la volatilidad previa a la puesta en
producción. En consecuencia, los equipos de desarrollo se ganan el
derecho a prestar más funcionalidades y en menor tiempo, al tiempo
que se mitiga el riesgo, lo cual constituye la principal preocupación
de sus alter ego en las operaciones.
Automatizar para dar agilidad
El segundo factor clave es la automatización. Si somete a
consideración su proceso de entrega, cada paso manual que exista
en él, ya se trate de un traspaso o aprobación manual o de una
tarea de tipo manual, como las pruebas, impactará de manera
significativa sobre los plazos. Para la mayoría de empresas, el
proceso de entrega se compone de un conjunto de pasos manuales
seguido por múltiples personas, las cuales van armadas de
larguísimos documentos y listas de comprobación (que también
se ensamblan de forma manual y que son proclives a contener
errores). Esa técnica dista mucho de ser ágil y su potencial de
cometer errores es elevado.
La automatización permite a los equipos eliminar esos traspasos
manuales, reducir los errores y acelerar los plazos globales de
entrega. Algo fundamental para todo esto es la movilidad de las
aplicaciones, una capacidad que aporta la entrega continua de HP
5
Continuous Delivery Automation y que permite a los equipos crear
la aplicación una sola vez y desplegarla luego en cualquier lugar
y con facilidad. La movilidad se consigue mediante los modelos
de aplicación sensibles al entorno que se comparten entre las
fases de desarrollo, prueba y operaciones. Al desplegar todo el
mundo de la misma manera y empleando los mismos activos, el
resultado son unos despliegues coherentes y precisos, en todas
las ocasiones y en los distintos entornos de desarrollo, prueba,
organización y producción. Es más, soportan entornos basados en
instalaciones físicas, sobre diferentes proveedores en la nube o en
una combinación híbrida, lo cual aporta una flexibilidad máxima.
Figura 2: Cuadro de mando ejecutivo de HP;
Colaborar a través de los silos
La colaboración eficaz acaba con las "brigadas con cubos" y el dedo
acusador que caracteriza tradicionalmente las relaciones entre el
desarrollo y las operaciones. Evita la latencia asíncrona y las tramas
desconectadas del correo electrónico, las llamadas telefónicas y
demás soportes heredados y ayuda a que esos equipos se centren
en unos objetivos comunes. La colaboración también acarrea que se
compartan y reutilicen los activos, de manera que no sea necesario
que las lecciones aprendidas en un entorno se inventen de nuevo en
el siguiente.
La construcción de la colaboración DevOps puede empezar por algo
tan simple como la inclusión de representantes de las operaciones
en los equipos ágiles, tanto en las sesiones de planificación de los
sprints como en las demostraciones de final de sprint. Para las
ideas compartidas y la resolución de los problemas en el día a día,
la comunicación del equipo puede beneficiarse de las herramientas
del estilo de las redes sociales, como la antes mencionada HP
Enterprise Collaboration, que estructura las conversaciones
alrededor de los elementos de trabajo nombrados y hace posible las
discusiones orientadas y sensibles al contexto.
Las herramientas integradas entre los dos grupos también ayudan
a derribar las barreras y a que todos sus miembros hablen el mismo
idioma. Entre las funcionalidades integradas en el catálogo de HP,
se incluyen:
• Los archivos de texto ejecutables orientados al rendimiento y que
se emplean para que el QA pueda ser empaquetado y enviarse al
personal de operaciones, de manera que no tengan que crearlos
de nuevo por su cuenta.
• Los patrones de utilización originados en las fases de producción
pueden importarse directamente al Centro de rendimiento de
HP con el fin de crear escenarios de prueba más precisos y del
mundo real. Las sesiones de usuarios reales pueden convertirse
de forma automática en archivos de texto ejecutables orientados
al rendimiento, para su empleo en las pruebas.
• Las herramientas de diagnóstico del rendimiento comunes a
los grupos de desarrollo y de operaciones permiten que los
datos se compartan y se alcance una comprensión mutua de los
problemas, logrando su análisis y resolución con mayor rapidez.
• El intercambio de la información en los dos sentidos para resolver
las incidencias de producción: una incidencia en producción
puede registrar un defecto de modo automático para el
departamento de desarrollo, para su rápida priorización frente
a otros elementos de las pilas de producto; en cuanto el grupo
de desarrollo resuelve el defecto, se actualiza automáticamente
mediante el Servicio de Atención.
6
Algo a destacar es que el Cuadro de mandos ejecutivo de HP aporta
una visión en modo de pantalla única, ofreciendo el registro de
las tareas de desarrollo y las operaciones, además de una mejor
visibilidad de cómo están comportándose ambos equipos en su
trabajo conjunto. Las métricas específicas de DevOps y la capacidad
de establecer KPI en cascada también permiten que las medidas
e incentivos estén alineados, cerciorándose que todo el mundo
empuje en la misma dirección.
Reunir todos los elementos: el ciclo de
vida completo de la aplicación
La vida real de una aplicación es superior a los requisitos fijados
durante su desarrollo. Se trata de un ciclo continuo que engloba
la planificación, entrega y ejecución de la aplicación, el cual se
inicia con una idea de negocio y finaliza cuando la aplicación se
retira. Cada una de esas áreas tiene impacto y está vinculada de
manera fundamental a las demás. Si estamos tratando de ser
útiles, no podemos permitirnos que se traten como tres ciclos de
vida por separado – uno de planificación, otro de entrega y otro de
despliegue y administración. Se requiere un único ciclo de vida y sin
discontinuidades.
Gartner ha estimado que, para una aplicación
con una vida de unos quince años, solamente el
ocho por ciento de su coste total de propiedad
está asociado al despliegue inicial. El 92 por
ciento restante se emplea en mantener, mejorar
y ejecutar dicha aplicación. Esto subraya la
importancia de adoptar una visión más amplia,
para todo el ciclo de vida, a la hora de desplegar
y gestionar las aplicaciones.
Figura 3: El Ciclo de vida completo de la aplicación
de su valor, debiendo proporcionar luego los medios para archivar
los datos y sacar esa aplicación de la cadena, así como reasignar sus
recursos. Se permite así que las TI mantengan su agilidad y eviten el
escollo de los catálogos sobredimensionados, así como la espiral de
costes de mantenimiento que conllevan.
Ejecutar
La empresa ágil
Planificar
Retirar
Entregar
Planificar. Entregar. Ejecutar. Retirar.
La metodología ágil fue creada por los técnicos de desarrollo, razón
por la que su orientación natural sea la parte de entrega del ciclo de
vida de las aplicaciones. DevOps y la entrega continua constituyen
un paso significativo en todo el ciclo de vida, al llenar el vacío que
existe entre la entrega y la puesta en ejecución de las aplicaciones.
Eso deja fuera la planificación y la retirada.
Entregar con gran rapidez una cosa incorrecta no es la manera de
hacer feliz al negocio. Los ciclos de entrega más rápidos crean un
reto de planificación más significativo – dando soporte a docenas de
proyectos a gran velocidad sin perder la noción del esquema global.
La demanda llega de todas direcciones: necesidades de mejora
y estratégicas procedentes de la parte comercial, incidencias
de producción del Servicio de Atención y mejoras en la calidad
y facilidad de mantenimiento identificadas por los equipos de
desarrollo y operaciones.
Las integraciones entre la gestión de los proyectos y el catálogo
de HP, el gestor de servicios de HP y HP ALM ofrecen una visión
consolidada de toda esta demanda, de modo que pueda priorizarse
y alinearse con los objetivos empresariales. Esto se incluye luego
en los pasos necesarios para planificar y preparar la entrega; por
ejemplo, entender la demanda en el contexto del presupuesto
disponible o asignar recursos y llevar su seguimiento a lo largo de
los proyectos. Una vez que los proyectos se encuentran en marcha,
la planificación se convierte en un proceso continuo de gestión de
la demanda y seguimiento del estado, presupuestos y dotación de
personal del trabajo recopilado. Un método robusto de planificación
de los proyectos y el catálogo otorga al Equipo de Dirección de TI la
capacidad de basar todas sus decisiones en datos físicos y de poner
orden en el caos.
El impacto positivo para el negocio crece a medida que los
principios de una metodología ágil se extienden por la empresa.
La transición que lleva desde el desarrollo ágil a la entrega ágil
implica derribar los silos y potenciar a todos los actores para
que trabajen conjuntamente y en equipo, a fin de crear software
con rapidez. Constituye un paso crítico para evitar la trampa
de la “scrummerfall” y derrochar recursos preciosos creando
minicascadas en el interior de cada sprint.
El paso siguiente, constituido por la entrega continua, se comporta
mejor desde la promesa del método ágil de avanzar hasta la
última milla y poner en manos de los usuarios un resultado mejor,
y con mayor rapidez. Lo consigue automatizando los procesos de
creación, prueba y despliegue e intensificando la colaboración
mediante los principios de DevOps.
El paso final y más codiciado, la verdadera agilidad empresarial, es
lo que persiguen todas las empresas en última instancia. En cuanto
uno empieza a prestar nuevas funcionalidades a sus usuarios
con rapidez, está abriendo sus puertas a un flujo mantenido de
realimentación ofrecida por esos mismos usuarios. Esas reacciones
de los clientes pueden proporcionar una perspectiva puntual de
las preferencias de cambio, ayudándole a emprender correcciones
más precisas y a tomar decisiones mejor informadas. En esencia,
le permite aplicar el concepto presente en la metodología ágil de
inspeccionar y adaptar al nivel empresarial.
El resultado es que la empresa será ahora más flexible. Podemos
aportar valor a nuestros usuarios a un ritmo más veloz y tenemos
un conocimiento más profundo de nuestros clientes, al disponer de
un bucle de realimentación más afinado.
Figura 4: Expandir el impacto empresarial de la metodología ágil
Ag i
m
lidad e pr e s arial
Ent
rega continua
Entr
ega ágil
Desarrollo
ágil
• Realimentación continua de los
clientes como ayuda para decidir
la dirección para avanzar
• El foco se pone en los ciclos más
cortos de valor para los usuarios
• Habilitado por DevOps
• Aborda el ciclo de vida completo
de la aplicación
• La calidad se integra de manera
eficaz
• Capaz de escalarse según la
empresa
• El foco se pone en el desarrollo
• Iniciativas y equipos más
pequeños
Finalmente, la retirada de la aplicación es el paso que completa
su ciclo de vida. Consiste en reconocer que una aplicación tendrá
una vida útil y no se mantendrá viva más allá de ésta. Ello implica
conocer el punto a partir del cual el coste de una aplicación excede
7
HP IT Performance Suite (ITPS)
El conjunto de soluciones de software HP IT Performance Suite
ayuda a las empresas a asegurar un completo ciclo de vida
de sus aplicaciones. Se soporta en una plataforma conectada
que administra los procesos básicos a la hora de la entrega
ágil, incluyendo la gestión de las pilas de producto y los sprint,
la administración de las historias de usuario y la calidad y la
integración con los entornos de los técnicos de desarrollo.
HP también ayuda a las empresas a solucionar el ciclo de vida
completo. Las soluciones de entrega de HP se asientan en el centro
de un catálogo más amplio y que se integra con las otras partes del
ciclo de vida, a fin de incluir la gestión de proyectos y catálogo, el
gobierno de la arquitectura, la automatización del despliegue, la
gestión de los servicios e incluso una plataforma de colaboración. A
lo largo de cualquier función esencial y cada parte del ciclo de vida,
HP ayuda a las TI a alinearse con las metas empresariales, gestionar
los entornos de TI híbridos, protegerse de amenazas contra la
seguridad y mitigar los riesgos.
¿Por qué HP?
Ninguna otra compañía puede ofrecer un soporte de principio
a fin de las aplicaciones como el que asegura HP. En lugar de
utilizar herramientas con relativa integración, HP proporciona
una plataforma unificada para la gestión y automatización del
ciclo de vida que se ocupa de las necesidades de todos los actores
implicados. Las soluciones de HP dan soporte a más de 70 entornos
distintos (.Net, Java, SAP, Oracle, etc.), sin distinción. Ya trabajen con
métodos tradicionales o con el ágil, para un equipo de diez personas
o una plantilla de decenas de miles, ofrecen a las empresas sus
probados niveles de capacidad de configuración, escalabilidad y
adaptabilidad para conseguir una agilidad real y a lo largo del ciclo
de vida completo de las aplicaciones.
Los servicios de HP
Los servicios de HP ayudan a las empresas a materializar el
valor del paquete HP IT Performance Suite como soporte de
sus agendas ágil o DevOps. Reuniendo nuestra experiencia
en consultoría, propiedad intelectual y un extenso catálogo,
podemos ayudar a los clientes en las siguientes áreas:
Servicios de asesoría estratégica
Para tener éxito al ejecutar una transformación como DevOps,
necesita ser capaz de desarrollar una hoja de ruta estratégica,
apoyada en una visión común e impulsada por un conjunto
cohesivo de iniciativas que proporcionen, progresivamente,
competencias para alcanzar los objetivos empresariales
deseados.
Consultoría de soluciones
Esta oferta combina personas, procesos y software para ayudarle
a materializar sus metas estratégicas de TI. Nuestras soluciones
se basan en nuestra exclusiva propiedad intelectual, la cual se
ha creado y formulado mediante cientos de exitosos despliegues
en todo el mundo. La arquitectura y el diseño de soluciones, la
consultoría de procesos, la gestión del cambio y los servicios de
integración e implantación de software forman parte de esta
oferta.
Servicios de implantación del paquete HP IT Performance Suite
Un conjunto exhaustivo de paquetes de implantación y servicios
de actualización y migración de software que le ayudan a sacar
partido, con rapidez y eficacia, de las funcionalidades de su
software HP ITPS. Esto incluye componentes clave como la
gestión de los laboratorios y de las pruebas, pruebas funcionales,
pruebas de rendimiento y de seguridad, la colaboración y la
gestión de las operaciones y las TI.
Conéctese
hp.com/go/getconnected
Conozca las opiniones de los expertos sobre tendencias
tecnológicas, alertas de soporte y soluciones de HP.
© Copyright 2012 Hewlett-Packard Development Company, L.P. La información incluida en el presente documento se puede modificar sin previo aviso.
Las únicas garantías para los productos y servicios HP se establecen en las declaraciones expresas de garantía que acompañan a dichos
productos y servicios. Ninguna información incluida en el presente documento deberá ser considerada como una garantía adicional.
HP no se responsabiliza de los errores técnicos, de publicación o de omisión que haya en el presente documento.
Java y Oracle son marcas comerciales registradas de Oracle y/o de sus filiales.
4AA4-1750ESE, creado en junio de 2012