1. ¿Qué metodología será
más adecuada para mi
proyecto software?
miércoles, 01 de agosto de 2012
@agustinvillena

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. ¿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. En búsqueda del
Sagrado Grial
@agustinvillena

5. • Muchos han tratado de encontrarlo
• Dicen que se encuentra en Lejano Oriente: Cathay,
India
@agustinvillena

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. @agustinvillena

8. Ford en el Desarrollo de Software
Modelo de cascada
¿Integrar recién
ahora?
¡congelados!
@agustinvillena

9. Creencia popular entre algunos managers de tecnología
@agustinvillena

10. Software Factory de Mr. Burns
@agustinvillena

11. El polo “caótico” del
desarrollo de software
¿Mejor que la Software Factory?
@agustinvillena

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. Recordemos los elementos de
un proyecto de software
@agustinvillena

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. 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. 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. Waterfall
• MANAGING THE DEVELOPMENT OF LARGE SOFTWARE
SYSTEMS
• Winston W. Royce, Proceedings, IEEE WESCON, August 1970,
pages 1-9.
@agustinvillena

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. 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. Epígrafe
Uno no se baña nunca dos veces
en el mismo río
Heráclito
@agustinvillena

21. ¿A qué se parece más el
desarrollo de software?
versus
@agustinvillena

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Emprender Agilmente
Lean Startup
@agustinvillena

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. ¿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. 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. 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. En resumen
@agustinvillena

43. Kanban
“Agile 2.0”
Evolución Guiada
de tu proceso
hacia la Agilidad
@agustinvillena

44. En las profesiones del conocimiento el
valor generado es invisible…
• entonces los profesionales serán permanentemente
interrumpidos
• Y sobrecargados
@agustinvillena

45. Suelen existir múltiples fuentes
de demanda
Proyecto
Múltiples
Clientes
Equipo
@agustinvillena

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. OPTIMIZANDO EL FLUJO
@agustinvillena

48. Si generamos un modelo
compartido de nuestro trabajo…
Equipo
Líder
ó Cliente
@agustinvillena

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. Historia del Kanban
Aplicado al Desarrollo de Software
• David J. Anderson lo aplica por primera vez el 2004 en Microsoft
@agustinvillena

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. 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. Gestión Visual
de diferentes Tipos de Trabajo
@agustinvillena

54. Cambiar para Mejor
Kaizén
@agustinvillena

55. Ciclo de Aprendizaje
@agustinvillena

56. Mejorar paso a paso
constantemente
@agustinvillena

57. Caso real
@agustinvillena

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. contacto@leansight.com
@leansight
@chileagil
www.leansight.com
www.chileagil.cl
failfast.chileagil.cl
grupo.chileagil.cl
@agustinvillena