Your SlideShare is downloading. ×
Es agil suficiente?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Es agil suficiente?

133

Published on

Charla de Rafael Alvarez para el Caracas Agile Tour 2012

Charla de Rafael Alvarez para el Caracas Agile Tour 2012

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
133
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ES ÁGILSUFICIENTE? Por: Rafael Alvarez
  • 2. Introducción del ponenteArquitecto de Software con 12 años deexperiencia.Agilista desde 1999 (inicialmente en la lista deextreme programming)Miembro activo de dos grupos sobre Agile enLinked In.Autor de un articulo en AgileJournal
  • 3. La historia hasta ahoraEl paradigma del valorCMMI AgileHello Agile!Especificación Mediante EjemplosAgilidad 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 UsuarioTecnologia FuncionalidadEquivocada 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 ÁgilIndividuos e interacciones Vs Procesos y HerramientasSoftware funcionando Vs Documentación ExtensivaColaboración con el cliente Vs Negociación ContractualRespuesta ante el cambio Vs Seguir un Plan
  • 16. Los 12 Principios
  • 17. Darle Valor al Cliente EntregaTemprana yContinua con valor Aceptar cambios
  • 18. Excelencia tecnica Atención a Excelencia Técnica y Buen Diseño SoftwareFuncional como medida de avance Simplicidad
  • 19. Trabajo en Equipo Equipos Auto-OrganizadosInteracciones IndividuosCara a Cara Motivados Un Solo Equipo Ritmo sostenible
  • 20. Mejora Continua Retrospección y Ajustes EntregasFrecuentes
  • 21. En Resumen Valor al Cliente TrabajoExcelencia Técnica Ágil en Equipo Mejora Continua
  • 22. Como Vamos?
  • 23. Hay más proyectos exitosos1994 16% +16% en proyectos Exitosos! 30% 54% 2009Chaos 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 CHAOSSoporte de la Alta Gerencia 18Participación de los Usuarios 16Gerente de Proyectos 14ExperimentadoObjetivos de Negocio Claros 12Mínimo Alcance 10Infraestructura de Software 8EstandarizadaRequerimientos Básicos Bien 6DefinidosMetodologías Formales 6Estimados Confiables 5Otros 5
  • 30. Que cubre Ágil?Soporte de la Alta Gerencia 18Participación de los Usuarios 16Gerente de Proyectos 14ExperimentadoObjetivos de Negocio Claros 12Mínimo Alcance 10Infraestructura de Software 8EstandarizadaRequerimientos Básicos Bien 6DefinidosMetodologías Formales 6Estimados Confiables 5Otros 5
  • 31. Que falta?Soporte de la Alta Gerencia 18Gerente de Proyectos 14ExperimentadoInfraestructura de Software 8EstandarizadaOtros 5
  • 32. Areas de un Proyecto de Software
  • 33. 4 tradicionales, 2 especiales Concepción Planificación/ SeguimientoMercadeo SoftwareNegociació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 Negociacionen 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 riesgosTimeboxes 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 sede manejo de construye el versiones? software?
  • 38. ValidaciónComo 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 ContratosComo debe serun contrato Agil? Como conciliar las exigencias de los clientes con la metodologia Agil?
  • 40. MercadeoComo se mercadea un proyecto Agil?
  • 41. Finalmente
  • 42. En Definitiva….Ninguna metodología es suficiente.Ágil requiere de practicas que apoyen susprincipios.Ágil no debe estar divorciado de disciplinas comoIngeniería de Requerimientos, QA y Gerencia deProyectos.
  • 43. Que hacer?Con la Metodología1. 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 RecomendadasClean Code, de Robert C. MartinClean Coder, de Robert C. MartinSoftware Quality Management series, de Gerald(Jerry) Weinberg.Perfect Software And Other Illusions About Testing,de Gerald (Jerry) Weinberg.Release It! De Johanna Rothman
  • 46. Creditoshttp://openclipart.org (imagenes)http://www.sxc.hu (fotos)CHAOS Report, Standish Group, 1994, 2009,2011http://www.ambysoft.com/http://www.geraldmweinberg.com - Jerry WeinbergRobert C. Martin (Uncle Bob)
  • 47. ES AGILSUFICIENTE? NO, NO LO ES Muchas gracias

×