Qué metodología será más adecuada para mi proyecto software
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
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
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
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
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
44. En las profesiones del conocimiento el
valor generado es invisible…
• entonces los profesionales serán permanentemente
interrumpidos
• Y sobrecargados
@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
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
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