ÁGIL ES ALGO QUE ERES, CMMI ES ALGO QUE USAS

Transcripción

1 ÁGIL ES ALGO QUE ERES, CMMI ES ALGO QUE USAS Qué significa ser ágil? Versión Luis Antonio Jorge Hernán Abad

2 Miembros de Ágiles Colombia facebook.com/agilescolombia Meetup.com/agilescolombia

3 Contenido Presentación Métodos ágiles y Métodos tradicionales El Manifiesto por el desarrollo ágil de software Sobre la Evolución a Ágil Factores clave de éxito para implementar métodos ágiles Mitos, Monstruos, leyendas urbanas y otros desvaríos de ágil y Scrum Conclusiones Referencias

4 Los ingenieros se contratan para crear valor del negocio, no para programar cosas. Patrick McKenzie (Desarrollador)

5 Presentación Precepto 1: La calidad de un producto está dada en gran medida por la calidad de los procesos que usamos para crearlo y mantenerlo Anterior a la era ágil William Edwards Deming ( )

6 Antes de la era ágil: comando y control + procesos

7 Personas y sus interacciones Lo más importante de un proceso son las personas que realizan las actividades del proceso

8 Líderes actuales versus Nuevos líderes Los líderes actuales deberían trabajar con los nuevos líderes Principios de Lean SW Development* Optimice el todo Enfóquese en el cliente Energice a las personas Elimine el desperdicio Entregue rápido Construya con la calidad en mente Continúe mejorando

9 Métodos ágiles y métodos tradicionales Manejo de: Complejidad + Cambios en Requisitos + Innovación Tecnológica = Éxito La Complejidad requiere disciplina Los cambios en los requisitos requieren adaptabilidad

10 Métodos ágiles y métodos tradicionales CMMI, PMI e ISO dan idea de cuales procesos son necesarios para mantener una organización madura y disciplinada. Ágil proporciona guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad.

11 Métodos ágiles y métodos tradicionales El valor de los métodos ágiles solo se puede conseguir vía su uso disciplinado Institucionalización según CMMI: Forma tradicional de hacer negocios que una organización sigue de manera rutinaria como parte de su cultura corporativa. Empecemos a definirla simplemente como esta es la forma en que hacemos las cosas por aquí.

12 Ejemplo: GP 2.1 Establecer una política organizacional Establecer y mantener una política de la organización para planificar y realizar el proceso. El propósito de esta práctica genérica es definir las expectativas de la organización en relación con el proceso y hacerlas visibles a aquellos en la organización que están afectados. En general, la dirección es responsable de establecer y comunicar los principios, guías, orientación y expectativas para la organización. No toda orientación de la dirección llevará la etiqueta política. Lo que se espera de esta práctica genérica es la existencia de una orientación apropiada de la organización, independientemente de cómo sea llamada o comunicada.

13 GP 2.1 Ágil - Establecer una política organizacional Establecer y mantener una política organizacional para planear y ejecutar Métodos Ágiles El primer paso hacia la institucionalización de Métodos Ágiles es establecer cómo y cuándo estos se usarán en la organización. Una organización podría determinar que los métodos ágiles se usarán en todos los proyectos o en algún subconjunto de proyectos, basada en el tamaño, tipo de producto, tecnología u otros factores. Esta política es una forma de comunicar claramente la intención de la organización en cuanto a métodos ágiles se refiere. VERSIÓN 1 - DESACTUALIZADA

14 GP 2.1 Ágil - Establecer una política organizacional Establecer y mantener una política organizacional para planear y ejecutar Métodos Ágiles El primer paso hacia la institucionalización de Métodos Ágiles es establecer cómo y cuándo estos se usarán en la organización. La organización establece y da a conocer una Visión de Transformación hacía Ágil y busca que las personas no solo entiendan la Visión sino que la compartan, que haya consenso en la Visión. Esta política es una forma de comunicar claramente la intención de la organización en cuanto a métodos ágiles se refiere.

15 Ejemplo: GP 2.5 Entrenar a las personas Formar, según sea necesario, a las personas para realizar o dar soporte al proceso. El propósito de esta práctica genérica es asegurar que las personas tengan las habilidades y la experiencia necesaria para realizar o dar soporte al proceso. Las personas que realizarán el trabajo reciben una formación apropiada. Se proporciona una formación general para orientar a las personas que interactúan con los que realizan el trabajo. Ejemplos de métodos para proporcionar formación incluyen el autoestudio, la auto-formación dirigida, a su propio ritmo, instrucción programada, formación en el puesto de trabajo, tutoría y formación formal en el aula. VERSIÓN 1 - DESACTUALIZADA

16 GP 2.5 Ágil Entrenar a las personas Entrenar a las personas en la ejecución de Métodos y Prácticas Ágiles El entrenamiento correcto puede aumentar el desempeño de profesionales competentes y soporta la introducción de nuevos métodos en una organización. La institucionalización de Métodos Ágiles en uso requiere un entrenamiento consistente, que defina el entrenamiento exacto a brindar, y realizando el entrenamiento necesario. El entrenamiento puede hacerse usando diferentes enfoques, incluyendo instrucción programada, entrenamiento formalizado en-el-trabajo, acompañamiento, coaching y entrenamiento formal. Es importante que se defina un mecanismo para asegurar que el entrenamiento ha ocurrido y que es benéfico para las personas y para la Organización. VERSIÓN 1 - DESACTUALIZADA

17 Entrenar a las personas en la ejecución de Métodos y Prácticas Ágiles Promover ciclos sensei- sempai- kohai Promover que haya rotación hacia la izquierda (hacia arriba en la figura) en el ciclo Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos. GP 2.5 Ágil Entrenar a las personas

18 Experiencia del autor Con esto podemos empezar una Transformación Organizacional que sea Sostenible y Saludable Podemos encontrar un sistema de valores o una cultura organizacionales sobre los cuales queremos hacer un cambio En ese cambio, las raíces son los equipos y estos no se transforman solos El objetivo es que las personas a su vez se conviertan en agentes de cambio

19 Sabemos y hemos probado que con Scrum/Ágil es posible: Experiencia del autor Establecer iteraciones de 2 semanas (10 días hábiles), o menos En cualquier caso, de menos de 4 semanas Involucrar (comprometer) al usuario en el proyecto Obtener retroalimentación continua (del usuario) A partir del producto (de incrementos del producto) Es más efectiva Ampliar el ancho de banda de la comunicación cliente-proveedor y al interior del equipo. Con esto hemos logrado una más alta satisfacción del Cliente/Usuario Y, sobre todo, la felicidad de todos los involucrados, incluyendo a los miembros del equipo

20 Experiencia del autor Es importante tener una discusión franca y abierta con el usuario para encontrar cuáles son las necesidades reales. El éxito no se alcanza haciendo el proyecto más grande, sino haciendo que el proyecto proporcione el mayor valor al usuario, dejando tiempo para que los desarrolladores trabajen con otros usuarios con necesidades reales. Scrum soporta fuertemente esta estrategia. Esto es, maximizar el trabajo no realizado

21 Experiencia del autor Con Scrum, desarrollo basado en historias de usuario, automatización de pruebas y otras prácticas ágiles, y con Lean como fuente de identificación de nuevas mejoras, la filosofía ágil puede adoptarse mientras mantenemos el nivel de madurez y capacidad actual de CMMI.

22 La Filosofía Ágil No podemos predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo entregaremos y cuánto será su costo. Empecemos con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfoquémonos en la revisión continua de estas restricciones a medida que avanzamos. La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es mejor.

23

24 24

25 Radioactividad de los Requisitos «Estudio de la Universidad de Missouri: la vida media del valor de los requisitos ha ido disminuyendo Exponencialmente. En 1980 esta fue de alrededor de 10 a 12 años, en el 2000 había caído a 2 a 3 años, y actualmente está funcionando a alrededor del 6 meses». "Software Development: How the Traditional Contract Model Increases the Risk of Failure" de Susan Atkinson y Gabrielle Benefield 25

26 El Manifiesto Ágil (Valores) htttp://

27 El Manifiesto por el Desarrollo Ágil de Software (Valores) El Manifiesto NO sugiere abandonar las prácticas de la izquierda...

28 El Manifiesto Ágil (Principios) Satisfacer al cliente es la prioridad Aceptar cambios en los requisitos Entregar software funcional con frecuencia Trabajar juntos Usuario y Desarrolladores Desarrollar en torno a individuos motivados Comunicar información cara a cara Software funcionando: medida de progreso Promover el desarrollo sostenible Atención continua a la excelencia técnica La simplicidad es esencial Equipos autoorganizados Reflexionar (Inspeccionar) y adaptar

29 Sobre la evolución a ágil Los métodos tradicionales son prescriptivos Se enfocan en definir y reforzar procesos Gastan muy poco en identificar y entregar lo que los usuarios necesitan Usan herramientas monolíticas y pesadas Los métodos ágiles son generativos Los procesos de software más efectivos no pueden definirse por adelantado Es un proceso continuo

30 Sobre la evolución a ágil Entregar software funcionando y probado cada 4 semanas o menos Entregar lo que el negocio necesita más El proceso está mejorándose continuamente

31 Sobre la evolución a ágil Defina un proceso de mejora continua que lo lleve del enfoque actual a una estrategia ágil. La implementación de ágil empieza con la interiorización de los valores y principios ágiles La transformación es progresiva, integre paso a paso las prácticas ágiles requeridas Al tomar elementos actuales, use prácticas Lean para hacerlos más livianos y eliminar el desperdicio Implemente los conceptos de: Valor, Software de Valor para el negocio, Definición de Terminado, Definición de Preparado, y Criterios de Aceptación Despójese y remueva de la organización los vicios y las comodidades actuales Tenga el coraje para decir que implementar Ágil no es fácil

32 Sobre la evolución a ágil Para implementar Scrum usando Scrum: Tener una Lista de elementos a implementar Separarlos en sprints Implementar gradualmente Haga que las personas se sientan cómodas con el cambio Esto es Scrum Orgánico Algoritmo general de la implementación de Scrum usando Scrum

33 Sobre la evolución a ágil (Scrum) Scrum (m): Un marco de trabajo por el cual las personas pueden resolver problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente.* Scrum es: Liviano Fácil de entender Extremadamente difícil de llegar a dominar * Fuente: la guía de Scrum.

34 Factores clave de éxito para implementar métodos ágiles Dedíquese al 100% Comprometa a la Gerencia Reclute al Cliente (DP) El Scrum Master es básico Defina una estrategia No se impaciente Empiece con pocas métricas Para medir la realidad de los proyectos No a las personas Use la Guía a la Agilidad

35 Ágil significa reemplazar la predictibilidad falsa por la eficiencia

36 Ágil significa reemplazar la predictibilidad falsa por la eficiencia

37 Mitos, Monstruos, leyendas urbanas y otros desvaríos de ágil y Scrum Ágil no necesita documentación Ágil significa no hay un plan Ágil es la bala de plata a todos los problemas de la ingeniería de software Ágil no necesita diseño previo Ágil siempre usa Historias de Usuario"

38 Mitos, Monstruos, leyendas urbanas y otros desvaríos de ágil y Scrum Scrum siempre Funciona Scrum Master igual a Gerente de Proyecto Podemos hacer Scrum sin un Dueño de Producto Scrum no funciona con CMMI u otros modelos de procesos Scrum produce equipos de súper héroes Ágil significa más rápido

39 Conclusiones y Recomendaciones Usar CMMI y Scrum arroja un desempeño significativamente mejorado mientras se mantiene el cumplimiento con CMMI Los proyectos Scrum muestran una ganancia significativa en productividad y calidad sobre los métodos tradicionales Las compañías Ágiles pueden usar las Prácticas Genéricas de CMMI para institucionalizar las prácticas ágiles Lean puede usarse para identificar oportunidades de mejora en una compañía CMMI 5 Una organización no puede forzar la filosofía ágil en su cultura Ágil no es una construcción de conveniencia Si no puedes adoptar los valores y principios del Manifiesto, entonces eres un ADNS Ágil De Nombre Solamente

40 [1] Salazar-Caraballo Luis Antonio. Asuntos de la Ingeniería del Software: Volumen II. Ingenier%C3%ADa-del-Software- Volumen/dp/ /ref=la_B00B1FN726_1_ 3?s=books&ie=UTF8&qid= &sr=1-3 [2] Salazar-Caraballo Luis Antonio. Asuntos de la Ingeniería del Software: Volumen I. Ingenier%C3%ADa-Software-Art%C3%ADculos- Seleccionados/dp/ /ref=la_B00B1FN72 6_1_2?s=books&ie=UTF8&qid= &sr=1-2 Referencias Web/Bibliográficas El Gazafatonario

41 Acerca del Lucho Salazar: autor, conferencista, coach ágil, experto en procesos y métodos de software, incluyendo métodos y prácticas ágiles, Ingeniería de Requisitos, Arquitectura de software, Análisis y Diseño de software y Gerencia de Proyectos. Sus artículos han sido publicados por medios como Líder de Proyecto, Asociación Española de Profesionales en Dirección de Proyectos, Scrum Alliance y la revista PROIECTUS, editada también en España. Lucho es autor de los libros Asuntos de la Ingeniería de Software, Volumen I y Volumen II. Es traductor al español de la guía oficial de Scrum y de los libros de Ivar Jacobson Casos de Uso 2.0 y La Esencia de la Ingeniería del Software: aplicando el Kernel de Semat. Es miembro del Comité Ejecutivo de Semat Latinoamérica, una iniciativa mundial que busca refundar la Ingeniería del Software. Es miembro de IEEE. Su blog se puede leer en Lucho también escribe poemas, su libro Ansiedad de un Náufrago fue publicado en Su próximo libro, El VademeScrum, una especie de marco referencial de Scrum y de sus componentes, está en proceso de edición.

42 Acerca del Jorge Abad es Ingeniero Civil, Especialista en desarrollo de software y Magíster en Informática, con más de 15 años en la industria del software, en la cual se ha desempeñado como consultor, experto en metodologías, gerente de calidad, gerente de proyectos y en los últimos tres años como coach para equipos ágiles de desarrollo y Scrum Master. Apasionado por la gerencia de proyectos y por encontrar formas en que los trabajadores de conocimiento logren el cumplimiento de sus proyectos y metas. jorge.abad@gmail.com Su blog se puede leer en

43 PREGUNTAS?

44 Sobre el material utilizado Además de las referencias explícitas, esta presentación puede contener material o ideas de otras personas u organizaciones que omití sin intención. Nota: Trate de dar crédito a todos, pero si consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad, por favor, no dudes en hacérmelo saber, contactándome a: lucho.salazar@gmail.com

45 Aviso de Copyright Eres libre de: Compartir- copiar, distribuir y transmitir este trabajo Modificar- adaptar el trabajo Bajo las siguientes condiciones Atribución: debes atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo). Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor. Para más información ver

46 Información de contacto Luis Antonio Lucho Salazar-Caraballo