• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Qué metodología será más adecuada para mi proyecto software
 

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

on

  • 5,384 views

 

Statistics

Views

Total Views
5,384
Views on SlideShare
4,213
Embed Views
1,171

Actions

Likes
3
Downloads
106
Comments
0

2 Embeds 1,171

http://www.leansight.com 1170
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • ¿Qué metodología será más adecuada para mi proyecto software? miércoles, 01 de agosto de 2012 @agustinvillena
    • 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
    • ¿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
    • En búsqueda del Sagrado Grial @agustinvillena
    • • Muchos han tratado de encontrarlo • Dicen que se encuentra en Lejano Oriente: Cathay, India @agustinvillena
    • 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
    • @agustinvillena
    • Ford en el Desarrollo de Software Modelo de cascada ¿Integrar recién ahora? ¡congelados! @agustinvillena
    • Creencia popular entre algunos managers de tecnología @agustinvillena
    • Software Factory de Mr. Burns @agustinvillena
    • El polo “caótico” del desarrollo de software ¿Mejor que la Software Factory? @agustinvillena
    • 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
    • Recordemos los elementos de un proyecto de software @agustinvillena
    • 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
    • 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
    • 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
    • Waterfall • MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS • Winston W. Royce, Proceedings, IEEE WESCON, August 1970, pages 1-9. @agustinvillena
    • 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
    • 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
    • Epígrafe Uno no se baña nunca dos veces en el mismo río Heráclito @agustinvillena
    • ¿A qué se parece más el desarrollo de software? versus @agustinvillena
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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
    • Emprender Agilmente Lean Startup @agustinvillena
    • ¿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
    • ¿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
    • 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
    • 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
    • En resumen @agustinvillena
    • Kanban “Agile 2.0” Evolución Guiada de tu proceso hacia la Agilidad @agustinvillena
    • En las profesiones del conocimiento el valor generado es invisible… • entonces los profesionales serán permanentemente interrumpidos • Y sobrecargados @agustinvillena
    • Suelen existir múltiples fuentes de demanda Proyecto Múltiples Clientes Equipo @agustinvillena
    • 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
    • OPTIMIZANDO EL FLUJO @agustinvillena
    • Si generamos un modelo compartido de nuestro trabajo… Equipo Líder ó Cliente @agustinvillena
    • 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
    • Historia del Kanban Aplicado al Desarrollo de Software • David J. Anderson lo aplica por primera vez el 2004 en Microsoft @agustinvillena
    • 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
    • 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
    • Gestión Visual de diferentes Tipos de Trabajo @agustinvillena
    • Cambiar para Mejor Kaizén @agustinvillena
    • Ciclo de Aprendizaje @agustinvillena
    • Mejorar paso a paso constantemente @agustinvillena
    • Caso real @agustinvillena
    • 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
    • contacto@leansight.com @leansight @chileagil www.leansight.com www.chileagil.cl failfast.chileagil.cl grupo.chileagil.cl @agustinvillena