ES ÁGIL
SUFICIENTE?




              Por: Rafael Alvarez
Introducción del ponente
Arquitecto de Software con 12 años de
experiencia.
Agilista desde 1999 (inicialmente en la lista de
extreme programming)
Miembro activo de dos grupos sobre Agile en
Linked In.
Autor de un articulo en AgileJournal
La historia hasta ahora
El paradigma del valor
CMMI Agile
Hello Agile!
Especificación Mediante Ejemplos
Agilidad PMI
Por qué surge Ágil?
Ágil es una reacción

 4 de cada 5
  proyectos                                16%

                         30%




No son                                  54%



Exitosos
                 Exitoso         Deficiente        Fallido

               Fuente: Chaos Report Summary 1994, Standish Group
Qué queremos resolver con Ágil ?
                           Objetivos En
    Requerimientos          Conflicto                  Requerimientos
                                             Metodologia
     Cambiantes                                          Poco Claros
                                               Inexistente
                              Funcionalidad Proceso por el
                                                              Requerimientos
   Planes Irreales              Incompleta      Proceso        Equivocados
                              Poco               Baja Calidad de
                        Involucramiento            lo Entregado
          Malos Estimados
                          del Usuario
Tecnologia                                   Funcionalidad
Equivocada                                    Equivocada        Cambios de
          Falta de Vision Muchos Jefes
                                                                  Alcance
                          Falta de
    Multitasking         Experticia                  Muchos Errores
                           Tecnica         Falta de
                                        Objetivos Claros
Que busca en realidad Ágil ?
Mejorar la Calidad?
Desarrollar más Rápido?
Facilitar Cambios de Requerimientos?
Documentar Menos?
Alinear Visiones?
En realidad, todo lo anterior…


Maximizar Valor Agregado




             Minimizar Costo de Cambio
Como pretende lograrlo?
Veamos el Manifiesto Ágil

Individuos e interacciones
                             Vs
                                   Procesos y Herramientas
Software funcionando
                              Vs
                                   Documentación Extensiva
Colaboración con el cliente
                             Vs

                                   Negociación Contractual
Respuesta ante el cambio
                              Vs
                                   Seguir un Plan
Los 12 Principios
Darle Valor al Cliente


  Entrega
Temprana y
Continua con
   valor



                     Aceptar
                     cambios
Excelencia tecnica
                        Atención a
                        Excelencia
                      Técnica y Buen
                          Diseño

   Software
Funcional como
  medida de
    avance


                     Simplicidad
Trabajo en Equipo

                     Equipos
                Auto-Organizados



Interacciones                      Individuos
Cara a Cara                        Motivados




     Un Solo
     Equipo                   Ritmo
                            sostenible
Mejora Continua


               Retrospección y
                   Ajustes




 Entregas
Frecuentes
En Resumen
              Valor
                al
             Cliente



                        Trabajo
Excelencia
 Técnica     Ágil          en
                        Equipo



             Mejora
             Continua
Como Vamos?
Hay más proyectos exitosos
1994
                        16%
                                            +16% en proyectos Exitosos!

         30%

                     54%                       2009


Chaos Report Summary 1994, Standish Group                24%             32%

                                                              44%
              Fallido
              Deficiente

              Exitoso                           Chaos Report Summary 2009, Standish Group
Ágil supera a Tradicional
Ágil 3 veces “mejor"
Pero… y los Challenged?



        Muy Similares
Y Entonces?


Ágil se quedo “corto” y por eso
       hay tantos proyectos
          “Challenged”?
Como influye Ágil en los proyectos?
Factores de Éxito según CHAOS

Soporte de la Alta Gerencia     18
Participación de los Usuarios   16
Gerente de Proyectos            14
Experimentado
Objetivos de Negocio Claros     12
Mínimo Alcance                  10
Infraestructura de Software     8
Estandarizada
Requerimientos Básicos Bien     6
Definidos
Metodologías Formales           6
Estimados Confiables            5
Otros                           5
Que cubre Ágil?

Soporte de la Alta Gerencia       18
Participación de los Usuarios     16
Gerente de Proyectos              14
Experimentado
Objetivos de Negocio Claros       12
Mínimo Alcance                    10
Infraestructura de Software       8
Estandarizada
Requerimientos Básicos Bien       6
Definidos
Metodologías Formales             6
Estimados Confiables              5
Otros                             5
Que falta?


Soporte de la Alta Gerencia   18
Gerente de Proyectos          14
Experimentado
Infraestructura de Software   8
Estandarizada
Otros                         5
Areas de un Proyecto de Software
4 tradicionales, 2 especiales


                Concepción

                              Planificación/
                               Seguimiento
Mercadeo
                Software
Negociación
                                 Construcción

                 Validación
Y tenemos la respuesta…

  Ágil se quedo “corto” porque
    se enfoca principalmente                             Concepcion

                                                                      Planificacion/Se
                                                                         guimiento
  en Planificación, Validación y,           Mercadeo
                                                         Software
                                           Negociacion

en algunos casos, la Construcción.                                     Construccion

                                                         Validacion




Ágil no dicta las practicas para apoyar sus principios
                (y nosotros no las buscamos)
Concepción

 Como transformar      Como escribir Historias?
Epicos en Historias?      O Casos de Uso?
                         O Requerimientos?




                         Como determinar
                          que necesito?
Planificación (y seguimiento)


  Como reconciliar
                       Como detectar riesgos
Timeboxes o flujo de
                            a tiempo?
trabajo con Gantts?




                          Qué forma tiene
                           un proyecto
                             “Ágil”?
Construcción

                Como se
 Qué es eso    diseña y se
de manejo de   construye el
 versiones?
                software?
Validación

Como saber que el sistema      Como saber que el    Como saber que se
   cumple los SLA de            entregable esta     programo lo que se
     performance?                 completo?               queria?




                            Como saber que el
                            sistema “funciona”
Negociacion de Contratos

Como debe ser
un contrato Agil?




                                    Como conciliar
                                    las exigencias
                                    de los clientes
                                  con la metodologia
                                         Agil?
Mercadeo


Como se mercadea
 un proyecto Agil?
Finalmente
En Definitiva….
Ninguna metodología es suficiente.
Ágil requiere de practicas que apoyen sus
principios.
Ágil no debe estar divorciado de disciplinas como
Ingeniería de Requerimientos, QA y Gerencia de
Proyectos.
Que hacer?

Con la Metodología
1. Adoptar una metodología Ágil (y contratar un Coach)
2. Identificar carencias.
3. Adoptar practicas para eliminar las carencias.
4. Volver a 2.
Que practicas adoptar?
1.   Adoptar técnicas de Ingeniería de Requerimientos.
     (Concepción)
2.   Contratar un Gerente de Proyecto que entienda Ágil.
     (Planificación/Seguimiento)
3.   Adoptar buenas practicas de programación y diseño.
     (Construcción)
4.   Adoptar practicas de QA (Validación).
Lecturas Recomendadas
Clean Code, de Robert C. Martin
Clean Coder, de Robert C. Martin
Software Quality Management series, de Gerald
(Jerry) Weinberg.
Perfect Software And Other Illusions About Testing,
de Gerald (Jerry) Weinberg.
Release It! De Johanna Rothman
Creditos
http://openclipart.org (imagenes)
http://www.sxc.hu (fotos)
CHAOS Report, Standish Group, 1994, 2009,2011
http://www.ambysoft.com/
http://www.geraldmweinberg.com - Jerry Weinberg
Robert C. Martin (Uncle Bob)
ES AGIL
SUFICIENTE?




              NO, NO LO ES
                   Muchas gracias

Es agil suficiente?

  • 1.
    ES ÁGIL SUFICIENTE? Por: Rafael Alvarez
  • 2.
    Introducción del ponente Arquitectode Software con 12 años de experiencia. Agilista desde 1999 (inicialmente en la lista de extreme programming) Miembro activo de dos grupos sobre Agile en Linked In. Autor de un articulo en AgileJournal
  • 3.
    La historia hastaahora El paradigma del valor CMMI Agile Hello Agile! Especificación Mediante Ejemplos Agilidad PMI
  • 4.
  • 5.
    Ágil es unareacción 4 de cada 5 proyectos 16% 30% No son 54% Exitosos Exitoso Deficiente Fallido Fuente: Chaos Report Summary 1994, Standish Group
  • 6.
    Qué queremos resolvercon Ágil ? Objetivos En Requerimientos Conflicto Requerimientos Metodologia Cambiantes Poco Claros Inexistente Funcionalidad Proceso por el Requerimientos Planes Irreales Incompleta Proceso Equivocados Poco Baja Calidad de Involucramiento lo Entregado Malos Estimados del Usuario Tecnologia Funcionalidad Equivocada Equivocada Cambios de Falta de Vision Muchos Jefes Alcance Falta de Multitasking Experticia Muchos Errores Tecnica Falta de Objetivos Claros
  • 7.
    Que busca enrealidad Ágil ?
  • 8.
  • 9.
  • 10.
    Facilitar Cambios deRequerimientos?
  • 11.
  • 12.
  • 13.
    En realidad, todolo anterior… Maximizar Valor Agregado Minimizar Costo de Cambio
  • 14.
  • 15.
    Veamos el ManifiestoÁgil Individuos e interacciones Vs Procesos y Herramientas Software funcionando Vs Documentación Extensiva Colaboración con el cliente Vs Negociación Contractual Respuesta ante el cambio Vs Seguir un Plan
  • 16.
  • 17.
    Darle Valor alCliente Entrega Temprana y Continua con valor Aceptar cambios
  • 18.
    Excelencia tecnica Atención a Excelencia Técnica y Buen Diseño Software Funcional como medida de avance Simplicidad
  • 19.
    Trabajo en Equipo Equipos Auto-Organizados Interacciones Individuos Cara a Cara Motivados Un Solo Equipo Ritmo sostenible
  • 20.
    Mejora Continua Retrospección y Ajustes Entregas Frecuentes
  • 21.
    En Resumen Valor al Cliente Trabajo Excelencia Técnica Ágil en Equipo Mejora Continua
  • 22.
  • 23.
    Hay más proyectosexitosos 1994 16% +16% en proyectos Exitosos! 30% 54% 2009 Chaos Report Summary 1994, Standish Group 24% 32% 44% Fallido Deficiente Exitoso Chaos Report Summary 2009, Standish Group
  • 24.
    Ágil supera aTradicional
  • 25.
    Ágil 3 veces“mejor"
  • 26.
    Pero… y losChallenged? Muy Similares
  • 27.
    Y Entonces? Ágil sequedo “corto” y por eso hay tantos proyectos “Challenged”?
  • 28.
    Como influye Ágilen los proyectos?
  • 29.
    Factores de Éxitosegún CHAOS Soporte de la Alta Gerencia 18 Participación de los Usuarios 16 Gerente de Proyectos 14 Experimentado Objetivos de Negocio Claros 12 Mínimo Alcance 10 Infraestructura de Software 8 Estandarizada Requerimientos Básicos Bien 6 Definidos Metodologías Formales 6 Estimados Confiables 5 Otros 5
  • 30.
    Que cubre Ágil? Soportede la Alta Gerencia 18 Participación de los Usuarios 16 Gerente de Proyectos 14 Experimentado Objetivos de Negocio Claros 12 Mínimo Alcance 10 Infraestructura de Software 8 Estandarizada Requerimientos Básicos Bien 6 Definidos Metodologías Formales 6 Estimados Confiables 5 Otros 5
  • 31.
    Que falta? Soporte dela Alta Gerencia 18 Gerente de Proyectos 14 Experimentado Infraestructura de Software 8 Estandarizada Otros 5
  • 32.
    Areas de unProyecto de Software
  • 33.
    4 tradicionales, 2especiales Concepción Planificación/ Seguimiento Mercadeo Software Negociación Construcción Validación
  • 34.
    Y tenemos larespuesta… Ágil se quedo “corto” porque se enfoca principalmente Concepcion Planificacion/Se guimiento en Planificación, Validación y, Mercadeo Software Negociacion en algunos casos, la Construcción. Construccion Validacion Ágil no dicta las practicas para apoyar sus principios (y nosotros no las buscamos)
  • 35.
    Concepción Como transformar Como escribir Historias? Epicos en Historias? O Casos de Uso? O Requerimientos? Como determinar que necesito?
  • 36.
    Planificación (y seguimiento) Como reconciliar Como detectar riesgos Timeboxes o flujo de a tiempo? trabajo con Gantts? Qué forma tiene un proyecto “Ágil”?
  • 37.
    Construcción Como se Qué es eso diseña y se de manejo de construye el versiones? software?
  • 38.
    Validación Como saber queel sistema Como saber que el Como saber que se cumple los SLA de entregable esta programo lo que se performance? completo? queria? Como saber que el sistema “funciona”
  • 39.
    Negociacion de Contratos Comodebe ser un contrato Agil? Como conciliar las exigencias de los clientes con la metodologia Agil?
  • 40.
    Mercadeo Como se mercadea un proyecto Agil?
  • 41.
  • 42.
    En Definitiva…. Ninguna metodologíaes suficiente. Ágil requiere de practicas que apoyen sus principios. Ágil no debe estar divorciado de disciplinas como Ingeniería de Requerimientos, QA y Gerencia de Proyectos.
  • 43.
    Que hacer? Con laMetodología 1. Adoptar una metodología Ágil (y contratar un Coach) 2. Identificar carencias. 3. Adoptar practicas para eliminar las carencias. 4. Volver a 2.
  • 44.
    Que practicas adoptar? 1. Adoptar técnicas de Ingeniería de Requerimientos. (Concepción) 2. Contratar un Gerente de Proyecto que entienda Ágil. (Planificación/Seguimiento) 3. Adoptar buenas practicas de programación y diseño. (Construcción) 4. Adoptar practicas de QA (Validación).
  • 45.
    Lecturas Recomendadas Clean Code,de Robert C. Martin Clean Coder, de Robert C. Martin Software Quality Management series, de Gerald (Jerry) Weinberg. Perfect Software And Other Illusions About Testing, de Gerald (Jerry) Weinberg. Release It! De Johanna Rothman
  • 46.
    Creditos http://openclipart.org (imagenes) http://www.sxc.hu (fotos) CHAOSReport, Standish Group, 1994, 2009,2011 http://www.ambysoft.com/ http://www.geraldmweinberg.com - Jerry Weinberg Robert C. Martin (Uncle Bob)
  • 47.
    ES AGIL SUFICIENTE? NO, NO LO ES Muchas gracias