Charla de Rafael Alvarez para el Caracas Agile Tour 2012

1. ES ÁGIL
SUFICIENTE?
Por: Rafael Alvarez

2. 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

3. La historia hasta ahora
El paradigma del valor
CMMI Agile
Hello Agile!
Especificación Mediante Ejemplos
Agilidad PMI

4. Por qué surge Ágil?

5. Á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

6. 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

7. Que busca en realidad Ágil ?

8. Mejorar la Calidad?

9. Desarrollar más Rápido?

10. Facilitar Cambios de Requerimientos?

11. Documentar Menos?

12. Alinear Visiones?

13. En realidad, todo lo anterior…
Maximizar Valor Agregado
Minimizar Costo de Cambio

14. Como pretende lograrlo?

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. Los 12 Principios

17. Darle Valor al Cliente
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. Como Vamos?

23. 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

24. Ágil supera a Tradicional

25. Ágil 3 veces “mejor"

26. Pero… y los Challenged?
Muy Similares

27. Y Entonces?
Ágil se quedo “corto” y por eso
hay tantos proyectos
“Challenged”?

28. Como influye Ágil en los proyectos?

29. 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

30. 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

31. Que falta?
Soporte de la Alta Gerencia 18
Gerente de Proyectos 14
Experimentado
Infraestructura de Software 8
Estandarizada
Otros 5

32. Areas de un Proyecto de Software

33. 4 tradicionales, 2 especiales
Concepción
Planificación/
Seguimiento
Mercadeo
Software
Negociación
Construcción
Validación

34. 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)

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 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”

39. Negociacion de Contratos
Como debe ser
un contrato Agil?
Como conciliar
las exigencias
de los clientes
con la metodologia
Agil?

40. Mercadeo
Como se mercadea
un proyecto Agil?

41. Finalmente

42. 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.

43. 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.

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)
CHAOS Report, 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