Rational Agile Day. Caso de éxito

Transcripción

1 Rational Agile Day Caso de éxito

2 Agenda 15:00 a 15:15 Apertura - Presentación de los ponentes, contexto de desarrollo ágil Ariel Súcari, Director de Operaciones ItEra 15:15 a 16:00 Metodologías de desarrollo Amaury Quintero, Arquitecto de soluciones para desarrollo ágil 16:00 a 16:30 Cofee Break 16:30 a 17:30 Rational Team Concert Presentación y DEMO José M. Ordax, RTC Technical Specialist, IBM 17:30 a 18:00 Caso de éxito Tracsa Caterpillar José Manuel Acosta, Consultor en TRACSA

4 Flexibilidad de Negocio y Gobierno es lo de Hoy Los clientes y ciudadanos exigen: Mayor calidad Mayor seguridad de su información Precios más bajos Eficiencia en los servicios Mayor rapidez Mayor calidez Mayor valor añadido Mayor agilidad en los servicios La competencia y transparencia es: Mayor Más agresiva en la oferta Cada vez más preparada Innovadora El entorno está: Globalizado Más participativo e - gobierno Conectado Rendición de Cuentas Un solo punto de contacto Legislación más estricta

5 Las necesidades del ejecutivo de negocio y funcionarios públicos son Proporcionar rumbo y certeza Incrementar ganancias o servicios mientras se reducen los costes. Agilidad de respuesta a los cambios para concretar nuevas oportunidades de servicios Mejorar la capacidad y habilidades de la organización para sustentar el crecimiento, efectividad y cambio son los retos del ejecutivo de TI Alinear TI a las metas del negocio para incrementar ganancias o servicios y contener costes Facilitar la agilidad de la organización mediante servicios de TI Hacer más efectiva a la gente y a los equipos mediante TI

6 A qué nos dedicamos? Factores para Elevar la Calidad Todos reconocemos la importancia de tener un equipo de trabajo de calidad, motivado pero. Personas BPM Tecnología Procesos Mejora Iterativa de Procesos SCRUM

7 Es importante integrar todas las iniciativas de mejora en un programa integral

8 Dónde estamos?

9 Muchas organizaciones concentran sus esfuerzos en arreglar los errores en vez de prevenirlos

10 Soluciones con IBM Rational Ciclos de vida de desarrollo: Definición de procesos ágiles Automatización de procesos con Rational Team Concert Formación en procesos y herramientas Especialistas en: Rational ClearCase, ClearQuest, Doors, Quality Manager, Software Architect, RAD i y z Series. Websphere Portal y HATS Desarrollo seguro de aplicaciones: Análisis de riesgos y vulnerabilidades Auditorías de código seguro Adaptación de procesos Tablero de control de vulnerabilidades Implantación de Rational Appscan

11 Soluciones de productividad, calidad visibilidad Oficinas de proyectos y/o calidad: Definición Implantación Automatización Ejecución Implantación CMMI v1.3: Desarrollo, Adquisiciones y Servicios Implantación Automatización Evaluación (SCAMPI) Formación

12 Soluciones de formación Cursos Presenciales: PMP, RMP CMMI V1.3 CEH V7, CHFI, ECSP Lead Auditor ISO 27001, ITIL & ITIL Expert Cobit TOGAF CBCI SCRUM Cursos LIVE ONLINE: ITIL Foundation, Expert ISO 27002

13 Algunos clientes

14 Introducción

15 Introducción Varias compañías están utilizando Ágil. Por qué? Acaso la inversión paga la transición? Están evaluados los riesgos?

16 El 80% del negocio de IBM proviene de clientes existentes/retornados

17 Situaciones críticas Problemas de calidad Entrega tardía Solución: Ágil?

18 Pittsburgh Poughkeepsie Somers Canada Toronto,Ottawa Montreal, Victoria Beaverton Kirkland Seattle Foster City San Francisco SVL/San Jose Almaden Agoura Hills Irving El Segundo Costa Mesa Las Vegas Southbury New York City Princeton Rochester, MN Boulder Denver Lenexa, KA Tucson Phoenix Austin Dallas Equipo de desarrollo de IBM Andover Bedford, MA Bedford, NH Lexington Westborough Westford Cambridge Cork Dublin Galway Paris Pornichet Fairfax Raleigh Charlotte Lexington, KY Atlanta Boca Raton Tampa Sao Paulo Edinburgh London / Staines Milton Keynes Stockholm Rome Hursley Warwick York Boeblingen Cairo Delft Haifa Rehovot India Bangalore Pune Hyderabad Gurgaon Krakow Warsaw Perth China Beijing Shanghai Taiwan Malaysia US Canada Latin America EMEA AP Total Yamato Gold Coast Sydney Canberra 11,000 3, ,900 6,600 25,100

19 Cómo evaluarlo? Debemos demostrar beneficios económicos: Productividad Calidad de la oferta Satisfación Coste de desarrollo Valor al negocio

20 Datamatrix, o codificación de datos 2D, es un nuevo sistema industrial de codificación bidimensional que permite la generación de un gran volumen de información en un formato muy reducido, con una alta fiabilidad de lectura gracias a sus sistemas de información redundante y corrección de errores (legible hasta con un 20%-30% dañado). Además no es necesario un alto contraste para reconocer el código. El código está formado por celdas de color blanco y negro (perforadas o no perforadas en el caso de la micropercusión) que forman una figura cuadrada o rectangular. Cada una de esas celdas representa un bit de información. La información puede estar codificada como texto o datos en bruto (raw data en inglés).

21

22 Gracias!!! Ariel Súcari Director de Operaciones ItEra

24 Métodologías de Desarrollo Ágiles Qué, cómo, cuándo y dónde? Preparado por: Amaury Quintero

25 Agenda Qué es Desarrollo Ágil? Retos del Desarrollo Ágil Mejorando Ágil Podemos utilizar RUP en Ágil? Tomando lo necesario Conclusiones

26 Un Proceso Malo es un Proceso Malo sin importar la metodología que uses

27 Qué es Desarrollo Ágil? Un enfoque iterativo e incremental (evolucionario) ejecutado en un ambiente altamente colaborativo con solamente la justa cantidad de ceremonia para producir software de alta calidad de una manera efectiva y con costos adecuados, que satisface los requisitos cambiantes del cliente. Principios Básicos Sólo use el proceso necesario Pruebas y validaciones continuas Colaboración consistente entre el equipo Rápida respuesta a cambios Participación del cliente Entrega frecuente de software

28 Planificación Tradicional vs. Ágil La Planificación Tradicional hístóricamente define el alcance para todo el sistema Crea el plan, ejecuta el plan El plan se basa en tareas arquitectónicas y detalle de como construir cada componente Es una metodología predictiva Ágil enfatiza entregar el mayor valor posible al negocio Trabaja en las tareas de mayor valor primero No planifica el sistema completo, usa iteraciones (2 semanas 1 mes) Planifica y prioriza basado en User Stories

29

30 Introducción Visual a Scrum Task Board Sprint Planning (Sprint goals) Sprint backlog Sprint Review & Sprint Restrospective Release burndown

31 Métricas Ágiles Comunes

32 Nuestra Historia Iniciamos con un pequeño grupo Puesta en Producción El equipo creció a 70, mas desarrollo externo Nuestro producto comenzó a brindar servicios compartidos a toda la organización

33 un poco mas de Historia Empezamos a depender de otros servicios empresariales para nuestro producto Nuestro producto se convirtió en un producto de productos

34 Queremos seguir teniendo el valor de lo ágil pero no encajamos en el perfil ágil

35 Ágil sólo ofrece Cobertura Parcial Mike Griffiths, Leading Answers

36 Retos del Desarrollo Ágil Mismo sitio Distribución Geográfica Global Bajo riesgo Cumplimiento de Estándares Crítico, Auditado Desarrollo Ágil Complejidad de procesos, políticas, gente Mínima Significante Complejidad Técnica Simple, única plataforma Compleja, multi-plataforma RUP - Agility@Scale Contratación distribución (outsourcing, convenios) En casa Terceros Tamaño del Equipo Grado de Gobierno < Informal Formal

37 Scrum no es suficiente Caso de Negocio Visión Backlog ( De donde viene?) Arquitectura Documentación Planes de Despliegue y Roadmaps

38 Cómo hacemos que esto funcione? Tome lo que es bueno de ágil, lo que escala y lo que lo estimula Reemplace lo que no le alcance con ciertos componentes de RUP Mantenga las cosas lo mas simple posibles

39 RUP: Procesos Predefinidos RUP for Service-Oriented Modeling and Architecture RUP for Maintenance Projects RUP for COTS Package Delivery RUP for System z RUP for Small Projects RUP for Medium Projects RUP for Large Projects RUP for Systems Engineering RUP for Compliance Management RUP for Asset-Based Development RUP for Globally Distributed Development (beta)

40 Mitos comunes sobre RUP La gente de la comunidad Ágil realmente ODIA en Proceso Unificado de Rational RUP es muy grande RUP se enfoca demasiado a documentos RUP no es configurable

41 Las Verdades RUP está diseñado para ser configurable En la práctica la gente lo ejecuta muy pobremente Lo aplican como un proceso en cascada Puede ser tan ágil como se quiera si se le da el enfoque adecuado

42 Scrum pero introduzca Manejo de Riesgos Desviandonos un poco de lo ágil introducimos la Administración de Riesgos Necesitamos saber como mitigar los riesgos

43 Mitigando los Riesgos Cuando escalamos el equipo, necesitamos tener un poco mas de formalidad Mas control intelectual sobre la arquitectura Mas control intelectual sobre los requisitos

44 Método de Soluciones Ágiles basadas en RUP Basada en las prácticas de IBM Rational Method Composer para escalar el Desarrollo Ágil Una combinación de Ágil y RUP Mayor reutilización de estándares Durante el ciclo de vida, mantiene foco en el par Riesgo / Valor para el Cliente

45 Arquitectura Las Grandes Ideas La Arquitectura debe ser una parte importante de un desarrollo ágil disciplinado Establecer algún tipo de visión de la arquitectura al principio La arquitectura se deberá probar con código ejecutable Esta arquitectura va evolucionar a lo largo del proyecto ágil No haga demasiada arquitectura al principio Lo arquitectos trabajan muy cerca de los desarrolladores Un enfoque ágil para la arquitectura es crítico para tener exito con los factores de Agility@Scale Modelado y documentación no deben dejarse a un lado, sin perder foco en los ejecutables Hay dos apectos arquitectónicos, Negocios y Técnico. Estos dos aspectos vienen del equipo no sólo de los arquitectos

46 (factores) Tamaño del Equipo Menos de Cumplimiento de Estándares Bajo riesgo Críticos, auditados Mismo sitio Foco en Proyecto Distribución Geográfica Disciplina Empresarial Global Foco en Empresa Disciplined Agile Delivery Sencillo Complejidad del Dominio Intrincado, emergente Organización (outsourcing, convenios) Colaborativo Contractual Complejidad de la Organización Flexible Rígida Complejidad Técnica Homogénea Heterogénea, legada

47 Método de Soluciones Ágiles basadas en RUP Incrementar el rigor del control de cambios a medida que el proyecto progresa

48 Métricas

49 Cosas que debo mantener de Ágil Pequeños equipos, equipos de equipos si es necesario Ciclos cortos de planificación Visibilidad, inspección, adaptación Reuniones Retrospectivas Comunicación cara a cara con el cliente Elaboración progresiva de la planificación Historias de Usuario pequeñas e independientes Autonomía y auto-organización Propiedad y responsabilidad

50 Cosas que debo eliminar de Ágil Excesiva carencia de documentación La no planificación Arquitectura Emergente Propiedad compartida y universal del código

51 Qué debo modificar de Ágil? El cliclo de vida Ágil

52 Cosas que debo mantener de RUP El Espíritu de RUP Fases Iteraciones Casos de Uso Arquitectura Deliberada Algunos artefactos

53 Qué debo fusionar de RUP y Ágil? El ciclo de vida de entrega Ágil disciplinado (DAD)

54 Qué debo eliminar de RUP Definición de roles exhaustiva Guía del proceso, a menos que algo de valor en su contexto La mayoría de los artefactos

55 Manifiesto Ágil Valores Individuos e interacciones "Agile" Tradicional Procesos y herramientas Software funcionando Documentación exhaustiva Colaboración con el cliente Negociación de un contrato Respuesta a cambios Seguimiento a un plan La Agilidad es un término relativo

56 RUP - Valores A B C D E F Adaptar el proceso Balancear prioridades de los involucrados Colaborar entre equipos Demostrar Valor iterativamente Elevar el nivel de abstracción Foco continuo en la calidad El Espíritu de RUP Linea Base Arquitectura Uso de Componentes Trabajo en Equipo Calidad, una forma de vida Fases Iterationes Casos de Uso Arquitectura Algunos otros artefactos

57 Recomendaciones Proceso Adaptable Requisitos inciertos o volatiles Desarrolladores responsables y motivados Clientes que entienden y se involucran Fase de Ingeniería del Proyecto Proceso Predictivo Un equipo de mas de 100 Un precio fijo, o mas concretamente un alcance o contrato fijo Fase de Producción del proyecto No se preocupes si ud. Tiene un equipo ágil, pequeño y ubicado en el mismo sitio Sea pragmático acerca de la modificación del proceso y adopte elementos que hagan sentido para el tamaño y la complejidad de su organización

58 Conclusión Haga lo mas simple posible La motivación de los desarrolladores es lo que más influye en la productividad

59 Algunas Estadísticas de la Industria Adopción: 76% de las organizaciones han adoptado técnicas ágiles 44% de los proyectos, en promedio, dentro de las organizaciones han adoptado ágil Fuente: DDJ Julio 2009 State of IT Union survey Efectividad: Promedio de éxito ágil: 70% Promedio de éxito tradicional: 66% Los proyectos ágiles e iterativos han batido a los tradicionales en cuestiones de calidad entregada, habilidad de entregar funcionalidad necesaria, retorno de inversión, y time to value Fuente: DDJ 2008 Project Success Survey Calidad Funcionalidad Dinero Tiempo Ágil Iterativo Tradicional Ad-Hoc Encuesta disponible en

60 Porcentaje de Exito: Desarrollo Distribuido Iterativo 59% 71% 80% 74% Ágil Tradicional 55% 55% 70% 79% 73% 66% 73% 69% Promedio Mismo Sitio Cercanos Lejanos Ad Hoc 62% 72% 65% 48% Fuente: 60 Dr Dobb s Project Success Survey

61 Gracias!!! Amaury Quintero Arquitecto de soluciones para desarrollo ágil

64 Proyecto: Desarrollo Ágil con Soluciones Rational

65 Agenda Antecedentes. Objetivos Elementos del Proceso. TRACSA UNIFIED PROCESS. Arquitectura Conceptual. Conclusiones

66 Soluciones Integrales TRACSA fue fundada en Agosto de 1974 mediante la adquisición de los activos del distribuidor anterior, Agro-mecánica S.A., en aquel tiempo solo contaba con sucursales en Guadalajara, Celaya, Colima y Lázaro Cárdenas, dando servicio a los segmentos de construcción, agrícola y minero principalmente y ofreciendo soluciones de venta, renta de maquinaria nueva y seminueva, refacciones y servicio, principalmente de la marca Caterpillar. Servicios

67 Antecedentes TRACSA decide el cambiar su ERP actual Core puesto que ya no cubre las necesidades actuales del negocio. Por parte de la Dirección de TI se toma la decisión estratégica de para desarrollar un nuevo ERP el cual tiene como alcance: Implantar una nueva metodología de trabajo ágil. Implantar herramientas que ayuden a soportar el modelo ágil para desarrollo y mantenimiento. Seguir las mejores prácticas en procesos y herramientas en base a estándares y modelo de automatización. Se diseña un plan de mejora para dar solución a esas necesidades con la plataforma mas robusta para desarrollo en ambiente colaborativo (IBM Rational), con las mejores prácticas de los marcos de referencia de mayor presencia en la actualidad y la experiencia de It Era en la mejora de procesos y automatización.

69 Objetivos GESTION DEL CICLO DE VIDA DEL PRODUCTO Agilidad Procesos Operativos Trazabilidad Control y seguimiento Integración Trabajo en Equipo Calidad Evaluación Continua Visibilidad Reportes y Métricas Definición, Implementación y Automatización de Procesos con base a Estándares y Mejores Prácticas

71 Elementos del Proceso Se toma como marcos de referencia las mejores prácticas: Las disciplinas del RUP, Metodologías OpenUP y Scrum Preparado por: Itera

73 Entendimiento de la Necesidad del Negocio TRACSA UNIFIED PROCESS (TUP) Comité de Cambios y Requerimientos Solicitudes Dirección Control Medición y Análisis Calidad de Requerimientos Arquitectura Desarrollo Despliegue Operación Software RRC Requirements Composer RSA Software Arquitect for WebSphere RTCp Team Concert for p RQM Quality Management Application Lifecycle Management TUP RMC Method Composer

74 TUP -Procesos de Modelado de Negocios y Requerimientos Requerimientos con texto enriquecido Objetivos de Negocio Procesos de Negocios Infraestructura Colaborativa Obtener, capturar, elaborar, revisar y discutir los requerimientos. Casos de Uso Prototipos Procesos de Negocio Casos de Uso Texto enriquecido

75 TUP - Áreas de trabajo de Requirements Composer Rich Authoring Environment Web Review and Approval Casos de Uso Glosario Requirementos con texto enriquecido Server Colaborativo Interfaz con estilos WIKI. Categorias / Etiquetas. Comentarios. Revisión / Aprobación. Compartir trabajo al instante. Usuarios / equipos / autorizaciones. Vínculos entre todos los artefactos. Control de versiones. Diagramas de Flujo

76 TUP - Áreas de trabajo de Team Concert Uso de Dashboards para la Gestión del Proyecto. Espacio de Trabajo Integrado y colaborativo.

77 TUP - Áreas de trabajo de Quality Manager Uso de Dashboards para la gestión de la calidad. Manejo de Planes, Casos, Guiones y Resultados de Prueba. Vinculación con los Requerimientos establecidos.

78 TUP -Procesos de Modelado de Negocio Usuarios de Negocio Consultores Ing. de Procesos Comité de Procesos Define las actividades de su Procesos. Define las Reglas de Negocio. Entiende los objetivos. Transfiere el conocimiento de cómo debe realizarse el trabajo. Entiende el trabajo a realizar. Realiza el trabajo conforme lo explicado. Unifica los criterios Dicta Necesidades mismas que serán atendidas en la etapa de requerimientos. Entrega documentación de Soporte. Facilita Entrevistas para las diferentes iteraciones del proyecto. Colaborar en la definición de los trabajos a realizar. Asesora en el trabajo y productos generados. Apoyar en el monitoreo y control del avance del los entregables Generar y Ajustar los productos comprometidos. Utilizar los manuales de procedimiento como entrada. Asistencias a reuniones Acepta entregables..

79 Ingeniero de Requerimientos (IR) TUP - Requerimientos Revisor Interno (RI) Usuario de Negocio (UN) El Ingeniero de Requerimientos se presenta e informa las actividades a Realizar El IR presenta al UN los Casos de Uso de Sistema (Inventario de Casos de Uso de Sistema) identificados a partir del documento del Modelado de Negocio El IR lleva a cabo el proceso de Obtención de Requerimientos con el UN El IR Recolecta y administra requerimientos funcionales y no funcionales del sistema. EL RI descargará del Repositorio los productos generados por el IR para colaborar en la revisión. El UN dicta los Requerimientos Funcionales y No Funcionales de manera clara al IR Documenta con base en las técnicas para obtención de requerimientos: Especificación de Casos de Uso. Especificaciones Suplementarias. Complementar el documento de Reglas de Negocio. El IR deberá subir los productos generados al Repositorio Asesora al IR en el trabajo y productos generados. Verifica y valida los productos generados, de acuerdo a la técnica empleada.

80 Ingeniero de Requerimientos (IR) TUP - Requerimientos Revisor Interno (RI) Usuario de Negocio (UN) Realiza modificaciones a los productos generados. Si el RI identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección El UN verifica y valida los productos generados. Una vez actualizados los productos generados el IR deberá subirlos al Repositorio como una nueva Versión. Sólo se validará una vez los productos generados por el IR El IR realiza la impresión de los productos generados El IR revisa los productos generados con el UN Si el UN identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección. Realiza modificaciones a los productos generados y los sube al Repositorio como una nueva versión. Dará el Vo.Bo. los productos generados. El IR realiza la impresión de los productos generados

81 TUP Aseguramiento de Calidad Ingeniero de Pruebas (IP) Desarrolladores (DEV) Usuario de Negocio (UN) Con base a las Especificaciones de Modelado y Requerimientos el Ingeniero de Pruebas analizará y diseñará Pruebas. Si el IP o el UN identifica inconsistencias en los productos generados por el DEV, se le notificarán estas observaciones para su corrección. Se ejecutaran pruebas funcionales y de sistema previas a las pruebas de Usuario. El DEV realizará la corrección de las incidencias Reportadas y Entregara los productos corregidos para su Revisión El UN verifica y valida los productos generados. El IP Programará las etapas de pruebas con el UN para revisar los productos generados Si el UN identifica inconsistencias en los productos generados por el IR, se le notificarán estas observaciones para su corrección. Dará seguimiento a las Incidencias Reportadas por el UN hasta su corrección y programará la sesión de pruebas. Dará el Vo.Bo. los productos generados.

83 Arquitectura Conceptual IBM i OS on the Power Systems platform -DB2 for p -WAS for p IBM Nuevo ERP Windows Server

85 Conclusiones - Resultados Para el primer modulo de Maquinaría se logró especificar los requerimientos de negocio y funcionales en los tiempos establecidos logrando agilizar la participación de los usuarios en la acreditación de los mismos. Se ha logrado una dinámica de colaboración y trabajo en equipo que esta permitiendo cumplir en los tiempos establecidos para cada iteración en la implementación Mediante la integración de la plataforma de herramientas se están generando los elementos de trazabilidad que permiten identificar las dependencias entre los componentes del sistema, mismas que facilitaran en un futuro las estimaciones de impacto a los cambios y nuevos desarrollos. La Gestión de Calidad, está logrando garantizar el cumplimiento de los requerimientos solicitados por el usuario y el entregar compontes libres de defectos.

86 Conclusiones - Beneficios Se logró fortalecer la forma de trabajo del área para Desarrollo de Nuevas Aplicaciones, con la adopción de prácticas que les han permitido estandarizar su proceso de desarrollo de forma rápida. Con la documentación del conocimiento y las lecciones aprendidas disponen de herramientas que en corto y mediano plazo les dan una base de conocimiento y activos reutilizables que les permitirá reducir tiempos y costos en los futuros desarrollos y mantenimientos de sus aplicativos.

87 Gracias!!! José Manuel Acosta Consultor en Tracsa - Caterpillar

88 Credits Ariel Sucari Amaury Quintero Jose M Ordax José Manuel Acosta Dudas, consultas, sugerencias: es.mad.mkt@iteraprocess.com Rational Team Concert:

89