Qué metodología será más adecuada para mi proyecto software
59
¿Qué metodología será más adecuada para mi proyecto software? miércoles, 01 de agosto de 2012 @agustinvillena
-
Upload
leansight-consulting -
Category
Technology
-
view
6.541 -
download
1
description
Transcript of Qué metodología será más adecuada para mi proyecto software
¿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
¡congelados!
¿Integrar recién
ahora?
@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
@agustinvillena
TAREAS
Plano de Negocio
Plano Técnico
Problema
(Necesidad)
Lenguaje de Negocio
Lenguaje Técnico
Leng
uaje
Com
ún
Bas
e Funcionalidades
(Soluciones)
Calidad
Valor
Ámbito
de la
Gestión
Para
qué (meta)
Qué (producto)
Cómo (tarea,
actividad)
Entorno de un proyecto de Software
@agustinvillena
Ingeniero
de Software
Equipo de
Desarrollo
Producto de
Software
Tecnología
Problema de Negocio Cliente
Proyecto de
Software
Waterfall
Requerimientos
Especificación
Diseño
Implementación
Verificación
Problema:
Solución:
Desarrollo de Producto Tradicional Medida de Progreso: Avance a la siguiente Etapa
@agustinvillena
conocido
conocida
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
Mantención
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:
@agustinvillena
Poca certeza =>
Realizar
experimentos
pequeños
Poco acuerdo => Negociar
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
@agustinvillena
Costo
Tiempo
Visión Tradicional
Sólo aplica a cambios
arquitectónicos
Visión Ágil
Mayoría de cambios pueden
tener este impacto
Manifiesto Ágil (2001)
• En 2001, Kent Beck y otros autores de enfoques similares proponen
los Principios Ágiles:
@agustinvillena
Individuos e interacciones
por
sobre
Procesos y herramientas.
Software funcional Documentación exhaustiva
Colaboración con el cliente Negociación de contratos
Responder al cambio Seguir un plan
12 Principios Ágiles
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.
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.
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.
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.
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.
La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
La sencillez, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
@agustinvillena
Armonización ágil del entorno de
desarrollo
@agustinvillena
Ingeniero
de Software
Equipo de
Desarrollo
Producto de
Software
Tecnología
Problema de Negocio Cliente
Proyecto de
Software
Ciclo de Gestión del Proyecto Orientada al Valor
Ciclo de Gestión del Desarrollo en Equipo
Ciclo de
Programación
de calidad
Entorno de un
proyecto de software
XP lo organiza en ciclos de retroalimentación y
aprendizaje acelerado
Problema:
Solución:
“Product Owner” or cliente in situ
Desarrollo Ágil de Productos Medida de Progreso: Funcionalidad Validada por el Cliente
@agustinvillena
conocido
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
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
Team
wo
rk M
anag
eme
nt
Cyc
le
Burn down Charts
Task Board
Scrum Master Role
Daily Scrum Meeting
Sprint Planning Meeting
Scrum Agile
Framework Val
ue
Ori
ente
d
Man
agem
en
t C
ycle
Release Planning Meeting
Potencially Shippable
Release Product Owner Role
Development
Sprint Retrospective Meeting Scrum Scoreboard
Product Backlog
Tasks
[email protected] @agustinvillena
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
Team
wo
rk M
anag
em
en
t C
ycle
Tea
m D
eve
lop
men
t
Qu
alit
y O
rien
ted
In
cre
men
tal D
eve
lop
men
t
Cyc
le Continuous
Integration
Code Standards
Collective Code Ownership
Pair Programming (+ Move people
around)
Simple Design
Refactoring
Test Driven Development
No Overtime
Tracking / Informative Workspace
Coaching
Stand Up Meeting
Iteration Planning
eXtreme
Programming
Agile
Framework Val
ue
Ori
ente
d
Man
age
me
nt
Cyc
le
Planning Game
Acceptance Tests
Small Releases
On Site Customer
(One team)
Development
Definition Validation
User Stories
Tasks
[email protected] @agustinvillena
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
@agustinvillena
No sólo
Individuos e interacciones
sino
que
Una comunidad de
profesionales
Software funcional Software bien hecho
Colaboración con el cliente Sociedades productivas
Responder al cambio Constantemente agregar valor
Desarrollo versus Operaciones
Desarrollo
• Desarrollo
aporta valor
mediante
nuevas
funcionalidades
Operación
Operaciones
aporta valor
mediante
sistemas estables
y rendimiento de
éstos.
Conflicto
Nuevas
funcionalidades
implican riesgos
@agustinvillena
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
Lean Startup
Emprender Agilmente
@agustinvillena
¿Innovación Exitosa?
• No existen empresas innovadoras exitosas, sino
productos innovadores exitosos
– Que viven en un Océano Azul
• Ejemplo: Apple
@agustinvillena
Newton :
Fracaso
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
Problema:
Solución:
Desarrollo de Cliente
Hipótesis,
Experimentos,
Revelaciones
Datos,
Retroalimentación,
Revelaciones
Desarrollo de Producto en una Innovación Ágil Medidad de Progreso: Aprendizaje Validado acerca de los Clientes ($$$)
@agustinvillena
desconocido
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
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
…
Stage 1 Done Stage 2 Stage n … Work Items
Queue
In
Process Queue
In
Process Queue
In
Process
Gestión Tradicional
Push Scheduling
Fuente:
Lean & kanban 101
http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/
@agustinvillena
OPTIMIZANDO EL FLUJO
@agustinvillena
Si generamos un modelo
compartido de nuestro trabajo…
Líder
ó Cliente
Equipo
@agustinvillena
…
Stage 1 Done Stage 2 Stage n … Work Items
Queue
In
Process Queue
In
Process Queue
In
Process
• Vamos realizando la tarea correcta en el momento justo en que tenemos capacidad
Pull Scheduling Para de comenzar… ¡Comienza a terminar!
Fuente:
Lean & kanban 101
http://availagility.wordpress.com/2009/06/11/zurich-lean-agile-scrum-slides/
@agustinvillena
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
Niveles de profundidad en Kanban
1. Visualizar el Flujo de Trabajo
2. Limitar el Trabajo-en-Progreso
3. Medir y Administrar el Flujo
4. Explicitar las Políticas del Proceso
5. Mejorar Colaborativamente
– Usando modelos y método científico
@agustinvillena
Pro
fun
did
ad
Gestión Visual de diferentes Tipos de Trabajo
@agustinvillena
Kaizén
Cambiar para Mejor
@agustinvillena
Ciclo de Aprendizaje
@agustinvillena
Mejorar paso a paso
constantemente
@agustinvillena
Caso real
@agustinvillena
Resumen
ScrumExtreme
ProgrammingLean Startup Kanban
Qué esMeta-proceso de
gestión del cambio
Evolución FuncionalidadesFuncionalidades y
Código
Modelo de Negocio,
Funacionalidades y
Código
Flujo de valor
(proceso)
Clientes Único Único Por dscubrir Múltiples
Cambio
OrganizacionalEvolutivo
Framework de Valores, Principios y Prácticas para desarrollo de
nuevo producto
Big Change Upfront
@agustinvillena
@leansight @chileagil
www.leansight.com www.chileagil.cl
failfast.chileagil.cl
grupo.chileagil.cl
@agustinvillena
