es agil suficiente?

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?


Participación de los Usuarios 16


14

Objetivos de Negocio Claros 12

Mínimo Alcance 10Mínimo Alcance 10


8

Requerimientos Básicos Bien Definidos

6

Metodologías Formales 6

Estimados Confiables 5

Otros 5

Que falta?



14


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

es agil suficiente?

Documents