Qué metodología será más adecuada para mi proyecto software

13,774 views

Published on

Published in: Technology
2 Comments
8 Likes
Statistics
Notes
  • @Jüllÿ Rängël Gracias! Cualquier feedback se agradece porque estamos mejorando este material
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • muuyy buenoo! ;) me sirvio mucho,, ademas es muy simpatica y amigable la presentacion! :D excelente!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
13,774
On SlideShare
0
From Embeds
0
Number of Embeds
1,329
Actions
Shares
0
Downloads
271
Comments
2
Likes
8
Embeds 0
No embeds

No notes for slide

Qué metodología será más adecuada para mi proyecto software

  1. 1. ¿Qué metodología será más adecuada para mi proyecto software? miércoles, 01 de agosto de 2012 @agustinvillena
  2. 2. Agustín Villena • Emprendedor desde 1998 • Aplicando agilidad desde 2002 en – – – – – Desarrollo de Software Industria de la Creatividad Sector Público Sociedad Civil Academia @agustinvillena
  3. 3. ¿Quieres saber más? • Desafio Kanban, tu primer paso a la gestión ágil – http://leansight.com/desafio-kanban • Síguenos en twitter – @leansight – @agustinvillena • Únete a la conversación – http://grupo.chileagil.cl • Comparte tus dudas en la más completa base en español sobre agilidad – http://failfast.chileagil.cl @agustinvillena
  4. 4. En búsqueda del Sagrado Grial @agustinvillena
  5. 5. • Muchos han tratado de encontrarlo • Dicen que se encuentra en Lejano Oriente: Cathay, India @agustinvillena
  6. 6. Fabricas de Software el Santo Grial de desarrollo de Software • Efecto de producción masiva y economía de escala • Mano de obra barata – Modelo programático simplificado – Herramientas de modelado, CASE, visual • Especialización – Análisis, Diseño, Implementación, Testing etc. @agustinvillena
  7. 7. @agustinvillena
  8. 8. Ford en el Desarrollo de Software Modelo de cascada ¿Integrar recién ahora? ¡congelados! @agustinvillena
  9. 9. Creencia popular entre algunos managers de tecnología @agustinvillena
  10. 10. Software Factory de Mr. Burns @agustinvillena
  11. 11. El polo “caótico” del desarrollo de software ¿Mejor que la Software Factory? @agustinvillena
  12. 12. Soy tellible de guen programador • • • • • • “Echandole pa’ adelante” programming No documento nada Lo pruebo yo solito Arreglo las cosas directo en producción En el camino arreglamos la carga Mi codigo es MIO @agustinvillena
  13. 13. Recordemos los elementos de un proyecto de software @agustinvillena
  14. 14. Porqué es difícil desarrollar software Los planos (ideales) de un proyecto Plano de Negocio Valor Problema (Necesidad) (meta) Lenguaje de Negocio Lenguaje Común Base Para qué Funcionalidades (Soluciones) Qué (producto) Lenguaje Técnico Calidad TAREAS Cómo (tarea, actividad) Plano Técnico @agustinvillena Ámbito de la Gestión
  15. 15. Entorno de un proyecto de Software Cliente Problema de Negocio Proyecto de Software Ingeniero de Software Producto de Software Equipo de Desarrollo Tecnología @agustinvillena
  16. 16. Desarrollo de Producto Tradicional Medida de Progreso: Avance a la siguiente Etapa Waterfall Requerimientos Especificación Problema:conocido Solución:conocida Diseño Implementación Verificación Mantención Fuente: Eric Ries - Lean Startups Doing More with Less http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx @agustinvillena
  17. 17. Waterfall • MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS • Winston W. Royce, Proceedings, IEEE WESCON, August 1970, pages 1-9. @agustinvillena
  18. 18. Waterfall • MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS • Winston W. Royce, Proceedings, IEEE WESCON, August 1970, pages 1-9. STEP 2: DOCUMENT THE DESIGN At this point it is appropriate to raise the issue of - "how much documentation?" My own view is "quite a lot;" certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements. @agustinvillena
  19. 19. Waterfall • MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS • Winston W. Royce, Proceedings, IEEE WESCON, August 1970, pages 1-9. STEP 3: DO IT TWICE After documentation, the second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned. @agustinvillena
  20. 20. Epígrafe Uno no se baña nunca dos veces en el mismo río Heráclito @agustinvillena
  21. 21. ¿A qué se parece más el desarrollo de software? versus @agustinvillena
  22. 22. Matriz de Complejidad de Stacey Las dimensiones de la incertidumbre/riesgo • La complejidad/riesgo de un proyecto se puede ubicar a partir de dos dimensiones de incertidumbre: el grado de certeza y el grado de acuerdo • Para bajar la complejidad: Poca certeza => Realizar experimentos pequeños Poco acuerdo => Negociar @agustinvillena
  23. 23. El sesgo técnico ante el valor • “A classic engineering mistake and one I've made is confusing what is hard and what is valuable” – Max Levchin at StartUp School 2011 @agustinvillena
  24. 24. Paradigmas sobre el Costo de los Cambios a medida que avanza el proyecto Visión Tradicional Sólo aplica a cambios arquitectónicos Costo Visión Ágil Mayoría de cambios pueden tener este impacto Tiempo @agustinvillena
  25. 25. Manifiesto Ágil (2001) • En 2001, Kent Beck y otros autores de enfoques similares proponen los Principios Ágiles: Individuos e interacciones Software funcional Colaboración con el cliente Procesos y herramientas. por sobre Responder al cambio @agustinvillena Documentación exhaustiva Negociación de contratos Seguir un plan
  26. 26. 12 Principios Ágiles Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. La sencillez, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. @agustinvillena Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. El software funcionando es la medida principal de progreso. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
  27. 27. Armonización ágil del entorno de desarrollo Ciclo de Gestión del Proyecto Orientada al Valor Cliente Problema de Negocio Proyecto de Software Ciclo de Gestión del Desarrollo en Equipo Ingeniero de Software Ciclo de Programación de calidad Producto de Software Equipo de Desarrollo Tecnología XP lo organiza en ciclos de retroalimentación y aprendizaje acelerado Entorno de un proyecto de software @agustinvillena
  28. 28. Desarrollo Ágil de Productos Medida de Progreso: Funcionalidad Validada por el Cliente “Product Owner” or cliente in situ Problema:conocido Solución:desconocida Fuente: Eric Ries - Lean Startups Doing More with Less http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx @agustinvillena
  29. 29. Scrum (1996) • Inspirado en el enfoque de gestión de la innovación de productos de Hirotaka Takeuchi and Ikujiro Nonaka, 1986 • Sutherland and Schwaber , lo presentan en OOPSLA (1995) • Define un conjunto de herramientas de gestión y visualización de avance • Metáfora: – se requiere abarcar todas las disciplinas requeridas, tal como la formación de scrum del rugby • Es una metodología para gestionar desarrollos de productos – ¡Cualquier tipo de producto! @agustinvillena
  30. 30. Agile Framework Value Oriented Management Cycle Scrum Product Owner Role Release Planning Meeting Product Backlog Development Sprint Planning Meeting Teamwork Management Cycle Potencially Shippable Release Tasks Scrum Master Role Burn down Charts Task Board Daily Scrum Meeting Sprint Retrospective Meeting Scrum Scoreboard @agustinvillena avillena@dcc.uchile.cl
  31. 31. eXtreme Programming (1998) • • • • Kent Beck, 1999, “Extreme Programming Explained” Enfoque empírico e integral de un proyecto de software Equipos pequeños que incluyen al cliente Premisa – Llevar las buenas prácticas de desarrollo al extremo @agustinvillena
  32. 32. Small Releases eXtreme Programming Agile Framework Value Oriented Management Cycle Planning Game On Site Customer (One team) User Stories Definition Acceptance Tests Validation Development Iteration Planning Tracking / Informative Workspace Stand Up Meeting No Overtime Pair Programming (+ Move people around) Code Standards Collective Code Ownership @agustinvillena Quality Oriented Incremental Development Cycle Coaching Team Development Teamwork Management Cycle Tasks Simple Design Test Driven Development Continuous Integration Refactoring avillena@dcc.uchile.cl
  33. 33. Software Craftmanship http://manifesto.softwarecraftsmanship.org/ • Manifiesto sale a la luz Marzo de 2009 • Busca devolver la excelencia técnica al rango de pilar del movimiento ágil Individuos e interacciones Una comunidad de profesionales Software funcional Software bien hecho No sólo Colaboración con el cliente Responder al cambio @agustinvillena sino que Sociedades productivas Constantemente agregar valor
  34. 34. Desarrollo versus Operaciones Desarrollo • Desarrollo aporta valor mediante nuevas funcionalidades Conflicto Nuevas funcionalidades implican riesgos @agustinvillena Operación Operaciones aporta valor mediante sistemas estables y rendimiento de éstos.
  35. 35. Pero el cambio es inevitable… • Operaciones: cómo convivir con el cambio manteniendo el riesgo bajo? – Agilidad! • Todos los involucrados en el nuevo sistema deben trabajar juntos • Migrar según metas pequeñas, usando mecanismos de fácil restauración – Ej: Máquinas virtuales con puntos de restauración @agustinvillena
  36. 36. La solución: DevOps Área 3: Incorporar conocimiento de proyectos en Operaciones Área 1: Extender entrega hasta producción Área 2: Extender retroalimentación de operaciones hasta el proyecto Área 4: Incorporar conocimiento de Operacione en los proyectos @agustinvillena
  37. 37. Emprender Agilmente Lean Startup @agustinvillena
  38. 38. ¿Innovación Exitosa? • No existen empresas innovadoras exitosas, sino productos innovadores exitosos – Que viven en un Océano Azul • Ejemplo: Apple Newton : Fracaso @agustinvillena iPod: Éxito
  39. 39. ¿Deseas resolver problemas imposibles? ¡Encuentra la forma de fallar más rápido! • 1959: – Premio de MMUS$ 1,3 al primer avión propulsado por fuerza humana • 1969: aun sin ganadores – Paul MacCready miró el problema y observó: • «Demoran 1 año en construir el avión, y 1 día en ponerlo a prueba» – Solución: • avión fácilmente re construible • 1 prueba por día – Resultado: • falló muchas veces, pero ganó el premio en poco tiempo @agustinvillena
  40. 40. Qué dicen los líderes del emprendimiento • Steve Blank – Check your hypotheses – Get out of the building! – Good engineers understand their customers! • Eric Ries – Stop wasting people’s time! @agustinvillena
  41. 41. Desarrollo de Producto en una Innovación Ágil Medidad de Progreso: Aprendizaje Validado acerca de los Clientes ($$$) Desarrollo de Cliente desconocido Problema: Hipótesis, Experimentos, Revelaciones Datos, Retroalimentación, Revelaciones Solución: desconocida Fuente: Eric Ries - Lean Startups Doing More with Less http://assets.en.oreilly.com/1/event/30/Lean%20Startups_%20Doing%20More%20with%20Less%20Presentation.pptx @agustinvillena
  42. 42. En resumen @agustinvillena
  43. 43. Kanban “Agile 2.0” Evolución Guiada de tu proceso hacia la Agilidad @agustinvillena
  44. 44. En las profesiones del conocimiento el valor generado es invisible… • entonces los profesionales serán permanentemente interrumpidos • Y sobrecargados @agustinvillena
  45. 45. Suelen existir múltiples fuentes de demanda Proyecto Múltiples Clientes Equipo @agustinvillena
  46. 46. Gestión Tradicional Push Scheduling Work Items Stage 1 Queue In Process Stage 2 Queue … In Process Queue … Fuente: Lean & kanban 101 http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/ @agustinvillena Stage n In Process Done
  47. 47. OPTIMIZANDO EL FLUJO @agustinvillena
  48. 48. Si generamos un modelo compartido de nuestro trabajo… Equipo Líder ó Cliente @agustinvillena
  49. 49. Pull Scheduling Para de comenzar… ¡Comienza a terminar! • Vamos realizando la tarea correcta en el momento justo en que tenemos capacidad Work Items Stage 1 Queue In Process Stage 2 Queue … In Process Queue … Fuente: Lean & kanban 101 http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/ @agustinvillena Stage n In Process Done
  50. 50. Historia del Kanban Aplicado al Desarrollo de Software • David J. Anderson lo aplica por primera vez el 2004 en Microsoft @agustinvillena
  51. 51. Partiendo con Kanban 1. Parte con la forma en que trabajas ahora – Inicialmente, respeta los roles actuales, las responsabilidades y los títulos de los puestos de trabajo. 2. Acordar el buscar una mejora incremental y evolutiva @agustinvillena
  52. 52. 1. 2. 3. 4. 5. Visualizar el Flujo de Trabajo Limitar el Trabajo-en-Progreso Medir y Administrar el Flujo Explicitar las Políticas del Proceso Mejorar Colaborativamente – Usando modelos y método científico @agustinvillena Profundidad Niveles de profundidad en Kanban
  53. 53. Gestión Visual de diferentes Tipos de Trabajo @agustinvillena
  54. 54. Cambiar para Mejor Kaizén @agustinvillena
  55. 55. Ciclo de Aprendizaje @agustinvillena
  56. 56. Mejorar paso a paso constantemente @agustinvillena
  57. 57. Caso real @agustinvillena
  58. 58. Resumen Extreme Programming Scrum Lean Startup Kanban Qué es Framework de Valores, Principios y Prácticas para desarrollo de nuevo producto Evolución Funcionalidades Funcionalidades y Código Modelo de Negocio, Funacionalidades y Código Flujo de valor (proceso) Clientes Único Único Por dscubrir Múltiples Cambio Organizacional Big Change Upfront @agustinvillena Meta-proceso de gestión del cambio Evolutivo
  59. 59. contacto@leansight.com @leansight @chileagil www.leansight.com www.chileagil.cl failfast.chileagil.cl grupo.chileagil.cl @agustinvillena

×