Post on 08-Jul-2015
description
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 � 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� Agilidad PMI
Por qué surge Ágil?
Ágil es una reacción
16%
30%
4 de cada 5 proyectos
54%
Exitoso Deficiente Fallido
No son Exitosos
Fuente: Chaos Report Summary 1994, Standish Group
Qué queremos resolver con Ágil ?
Requerimientos Cambiantes
Requerimientos Poco Claros
Baja Calidad de lo Entregado
Planes Irreales
Objetivos En Conflicto
FuncionalidadIncompleta
PocoInvolucramiento
MetodologiaInexistente
Proceso por el Proceso
RequerimientosEquivocados
lo Entregado
Falta de Vision
Falta de Objetivos Claros
Muchos Jefes
Muchos Errores
FuncionalidadEquivocada
TecnologiaEquivocada
Involucramientodel Usuario
Falta de ExperticiaTecnica
Malos Estimados
Multitasking
Cambios de Alcance
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
Procesos y HerramientasVs
Software funcionandoVs
Documentación ExtensivaVs
Respuesta ante el cambio
Seguir un PlanVs
Colaboración con el cliente
Negociación Contractual
Vs
Los 12 Principios
Darle Valor al Cliente
Entrega Temprana y Continua con
valorvalor
Aceptarcambios
Excelencia tecnica
Software
Atención a Excelencia
Técnica y Buen Diseño
Software Funcional comomedida de avance
Simplicidad
Trabajo en Equipo
IndividuosInteracciones
EquiposAuto-Organizados
Un Solo Equipo
IndividuosMotivadosCara a Cara
Ritmosostenible
Mejora Continua
Retrospección y Ajustes
Entregas Frecuentes
En Resumen
Ágil
Valor al
Cliente
Trabajo Excelencia Ágil
Trabajo en
Equipo
Mejora Continua
Excelencia Técnica
Como Vamos?
16%
54%
30%
Hay más proyectos exitosos
+16% en proyectos Exitosos!1994
2009
32%
44%
24%Chaos Report Summary 1994, Standish Group
Chaos Report Summary 2009, Standish Group
2009
Fallido
Exitoso
Deficiente
Ágil supera a Tradicional
Ágil 3 veces “mejor"
Pero… y los Challenged?
Muy Similares
Y Entonces?
Ágil se quedo “corto” y por esohay tantos proyectoshay 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 Experimentado
14
Objetivos de Negocio Claros 12
Mínimo Alcance 10Mínimo Alcance 10
Infraestructura de Software Estandarizada
8
Requerimientos Básicos Bien Definidos
6
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 Experimentado
14
Objetivos de Negocio Claros 12
Mínimo Alcance 10Mínimo Alcance 10
Infraestructura de Software Estandarizada
8
Requerimientos Básicos Bien Definidos
6
Metodologías Formales 6
Estimados Confiables 5
Otros 5
Que falta?
Soporte de la Alta Gerencia 18
Gerente de Proyectos Experimentado
14
Infraestructura de Software Estandarizada
8
Otros 5
Areas de un Proyecto de Software
4 tradicionales, 2 especiales
Concepción
Planificación/Seguimiento
Mercadeo
Software
Construcción
Validación
Negociación
Mercadeo
Y tenemos la respuesta…
Ágil se quedo “corto” porque
se enfoca principalmente
en Planificación, Validación y,
en algunos casos, la Construcción.Software
Concepcion
Planificacion/Seguimiento
Construccion
Negociacion
Mercadeo
en algunos casos, la Construcción.
Ágil no dicta las practicas para apoyar sus principios(y nosotros no las buscamos)
Construccion
Validacion
Concepción
Como transformarEpicos en Historias?
Como escribir Historias?O Casos de Uso?
O Requerimientos?
Como determinarque necesito?
Planificación (y seguimiento)
Como detectar riesgos a tiempo?
Como reconciliar Timeboxes o flujo de trabajo con Gantts?
Qué forma tiene un proyecto
“Ágil”?
Construcción
Qué es esode manejo de
versiones?
Como se diseña y se construye el software?
Validación
Como saber que el sistemacumple los SLA de
performance?
Como saber que se programo lo que se
queria?
Como saber que el entregable esta
completo?
Como saber que el sistema “funciona”
Negociacion de Contratos
Como debe ser un contrato Agil?
Como conciliarlas exigenciasde los clientes
con la metodologiaAgil?
Mercadeo
Como se mercadeaun 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.Proyectos.
Que hacer?
1. Adoptar una metodología Ágil (y contratar un Coach)2. Identificar carencias.3. Adoptar practicas para eliminar las carencias.4. Volver a 2.
Con la Metodología
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)Adoptar practicas de QA (Validació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, � 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� http://www.geraldmweinberg.com - Jerry Weinberg
� Robert C. Martin (Uncle Bob)
ES AGIL
SUFICIENTE?
Muchas gracias
NO, NO LO ES