Tema II – Métodos ÁgilesPS... · METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS...
Transcript of Tema II – Métodos ÁgilesPS... · METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS...
06/10/2011
1
Procesos de Software www.kybele.urjc.es
Tema II – Métodos Ágiles
Dr. Javier Garzás
Universidad Rey Juan Carlos
Procesos de Software www.kybele.urjc.es
2
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
06/10/2011
2
¿Se puede desarrollar softwaredesarrollar softwareigual que industrialmente se construyen coches o casascoches o casas?
“La ingeniería softwareingeniería softwareera igual igual que la hardwarehardware. Aquellos tiempos, todos eran ingenieros hardware hardware o matemáticos”o matemáticos”
B. Boehm
1955
06/10/2011
3
1968
2010
06/10/2011
4
2005
Diseño previo e previo e inamovible…inamovible…
06/10/2011
5
…antes de laConstrucciónConstrucción
Predictibilidad…
06/10/2011
6
Ciclo de vida en CascadaCascada…
06/10/2011
7
06/10/2011
8
==
% avance
06/10/2011
9
Software
Tradicional
Diseño Construcción
V1V1
V2V2
V3V3
06/10/2011
10
Predicción vs Evolución
06/10/2011
11
EL CICLO DE VIDA ITERATIVO INCREMENTAL (I)
21
Se va liberando parte del producto periódicamente y cada entrega es un
incremento respecto a la anterior . Cada fasese realiza varias veces . Lo cual difiere del
desarrollo en cascada , donde las fases del ciclo de vida se realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta
que termina la fase que le precede
ITERATIVO = INCREMENTAL
22
http://jan-so.blogspot.com/2008/01/difference-between-iterative-and.html
06/10/2011
12
EL CICLO DE VIDA ITERATIVO INCREMENTAL (II)
23
la construcción del
Se comenzó a aplicar en 1950, en la construcción del avión cohete X-15
En 1960 es aplicado por la
NASA en el proyecto Mercury
06/10/2011
13
1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y
contínua de software con valor.
2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles
aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas
a un par de meses, con preferencia por los periodos más cortos posibles.
4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente
a lo largo del proyecto.
5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte
que necesitan, y confiando en ellos para que realicen el trabajo.
Principios Ágiles
6. El método más eficiente y efectivo de comunicar la información a un equipo de
desarrollo y entre los miembros del mismo es la conversación cara a cara.
7. Software que funciona es la principal medida de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Esponsores,
desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de
forma indefinida.
9. La atención continua a la excelencia técnica y los buenos diseños mejoran la
agilidad.
Principios Ágiles
06/10/2011
14
10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se
autoorganizan.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces
mejora y ajusta su comportamiento de acuerdo a sus conclusiones.
Traducción realizada por Agile Spain del original en Inglés. Éste pueden encontrarse en http://www.agilemanifesto.org/principles.html
Principios Ágiles
06/10/2011
15
Procesos de Software www.kybele.urjc.es
HAY 3 TIPOS DE METODOLOGÍAS
29
ÁgilesTradicionales
Híbridas
Procesos de Software www.kybele.urjc.es
30
ÁgilesTradicionales
Híbridas
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
16
Procesos de Software www.kybele.urjc.es
31
Cambiabilidad:
Las metodologías ágiles están preparadas para adaptarse a cambios ,
mientras que las tradicionales presentan cierta resistencia a los mismos
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Procesos de Software www.kybele.urjc.es
32
Metodologías tradicionales:
conceptos característicos de
la fabricación industrial o la
arquitectura
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
17
Procesos de Software www.kybele.urjc.es
33
�Producción en cadena -> Trabajo repetible, generalmente más manual que
intelectual y operario sustituible
�División del trabajo y métodos Tayloristas (“Principles of Scientific
Management” (1912)) Actividades diferenciadas: el diseño y la construcción.
�Construcción: poca actividad intelectual y más manual.
�Los costes de la construcción (y sus cambios) son muy superiores a los del
diseño.
�Por ello el diseño pretende controlar el 100% la construcción
�Diseño basado en matemáticas - física
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Procesos de Software www.kybele.urjc.es
34
PERO EN SOFTWARE ¿ES LO MISMO?
•¿CUÁNDO SABEMOS QUÉ SOFTWARE QUERÍAMOS CONSTRUIR?
•¿CUESTA LO MISMO CAMBIAR UNA COLUMNA QUE UNA LÍNEA DE CÓDIGO?
•¿EXISTE UNA BASE MATEMÁTICA – CIENTÍFICA?
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
18
Procesos de Software www.kybele.urjc.es
CHOQUES ENTRE “OLAS”: ADAPTATIVO VS. PREDICTIVO
Procesos de Software www.kybele.urjc.es
36
Algunas diferencias entre ágil y tradicional…
Algunas diferencias entre ágil y tradicional…
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
19
Procesos de Software www.kybele.urjc.es
37
Contrato:
En las metodologías tradicionales normalmente existe un contrato cerrado , mientras que en las ágiles no existe este tipo de contrato o, si existe, es bastante
flexible
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Procesos de Software www.kybele.urjc.es
38
Interacción con el cliente:
En las metodologías tradicionales, el cliente interactúa con el equipo de desarrollo mediante reuniones . Sin
embargo, en las metodologías ágiles el cliente forma parte del equipo de
desarrollo
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
20
Procesos de Software www.kybele.urjc.es
39
Tamaño de los grupos:
Las metodologías ágiles están definidas para grupos pequeños (menos de 10
integrantes) que trabajan en el mismo sitio. Sin embargo, las metodologías
tradicionales se definen para grupos grandes y posiblemente distribuidos
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Procesos de Software www.kybele.urjc.es
40
Arquitectura del software:
Para las metodologías tradicionales la arquitectura del software es esencial y se
expresa mediante modelos . Las ágiles, por su parte, ponen un menor énfasis en
la arquitectura del software
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
06/10/2011
21
Procesos de Software www.kybele.urjc.es
41
documentación en los procesos ágiles
Documentación:
La documentación en los procesos ágiles es más relajada , mientras que en los
procesos tradicionales es más exhaustiva .
METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES
Procesos de Software www.kybele.urjc.es 42
1. Gran cambiabilidad de los requisitos
2. Necesidad de una arquitectura robusta
3. Documentación muy detallada
4. Un contrato cerrado
5. Se necesita interacción con el cliente
6. Tamaño equipo pequeño
7. Se necesita predicción
8. Se necesita Reacción - Adaptación
ÁGIL / TRADICIONAL
EJERCICIO: ¿CUÁL ES MÁS ADECUADO?
06/10/2011
22
Procesos de Software www.kybele.urjc.es
43
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
Procesos de Software www.kybele.urjc.es
METODOLOGÍAS HÍBRIDAS
44
ÁgilesTradicionales
Híbridas
06/10/2011
23
Procesos de Software www.kybele.urjc.es
45
METODOLOGÍAS HÍBRIDAS
La realidad en las empresas refleja posturas moderadas en la implantación
de metodologías ágiles , hibridas y orientadas por la necesidad, al negocio y mejor práctica para cada organización y
proyecto
Procesos de Software www.kybele.urjc.es
46
METODOLOGÍAS HÍBRIDAS
Consisten en adaptaciones de las Metodologías Ágiles , muchas veces
incorporándole prácticas formales , como, por ejemplo, el robustecer y hacer menos
iterativa la fase de diseño de la arquitectura software
06/10/2011
24
Procesos de Software www.kybele.urjc.es
CUATRO MÉTODOS DE DESARROLLO
47
El intercambio de la cultura organizacional
y la estabilidad del proyecto sugieren dos
métodos nuevos de desarrollo además de
los métodos formales y ágiles
Procesos de Software www.kybele.urjc.es
48
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
06/10/2011
25
Procesos de Software www.kybele.urjc.es
SCRUM
49
Metodología ágil que proporciona un marco para la gestión de proyectos . Está especialmente indicada para proyectoscon un cambio rápido en los requisitos
Procesos de Software www.kybele.urjc.es
SCRUM
50
Basada en entregas parciales priorizadas por el beneficio que aporta al receptor del
proyecto
06/10/2011
26
Procesos de Software www.kybele.urjc.es
SCRUM
51
Permite obtener resultados tempranos y que permite adaptarse a los cambios en
los requisitos
Procesos de Software www.kybele.urjc.es
CARACTERÍSTICAS PRINCIPALES
52
Desarrollo software mediante
iteraciones
Reuniones a lo largo del
proyecto
06/10/2011
27
Procesos de Software www.kybele.urjc.es
EL PROCESO DE SCRUM
53
Procesos de Software www.kybele.urjc.es
SPRINT
54
A cada iteración se le denomina sprint . El sprint es
un periodo de corta duración (2-4 semanas) en el
que se crea un producto potencialmente entregable
06/10/2011
28
Procesos de Software www.kybele.urjc.es
PRIMER PASO: PRODUCT BACKLOG
55
Las características que van a implementarse en el sprint provienen de la Pila del
Producto (Product Backlog), que contiene una serie de
requisitos priorizados para su aplicación
Procesos de Software www.kybele.urjc.es
PRIMER PASO: PRODUCT BACKLOG
56
HISTORIAS DE USUARIO
El product backlog debe ser una lista priorizada y estimada de historias
de usuario
Como xxx, quiero hacer yyy con el objetivo de
zzz
06/10/2011
29
Procesos de Software www.kybele.urjc.es
PRIMER PASO: PRODUCT BACKLOG
57
PRIORIZACIÓN: ESTIMACIÓN Y VALOR
Planning Poker
Secuencia de Fibonacci
Procesos de Software www.kybele.urjc.es
PRIMER PASO: PRODUCT BACKLOG
58
http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil#historias-usuario
PRIORIZACIÓN: RESPONSABILIDAD DEL PRODUCT OWNER (CLIENTE)
06/10/2011
30
Procesos de Software www.kybele.urjc.es
SPRINT BACKLOG
59
Una vez seleccionadas las características que van a desarrollarse en el Sprint ,
se conforma la Pila del Sprint (Sprint Backlog), que se mantendrá inamovible durante toda la iteración
Procesos de Software www.kybele.urjc.es
SPRINT BACKLOG
60
•Velocidad: cantidad de storypoints o historias de usuario que terminan por iteración .
• Burndown charts
06/10/2011
31
Procesos de Software www.kybele.urjc.es 61
HIS
TO
RIA
S
Procesos de Software www.kybele.urjc.es
LAS REUNIONES
62
Son una parte importantedentro de Scrum. Se definendiversos tipos de reuniones :
• Daily Scrum
• Sprint Planning Meeting
• Sprint Review Meeting
• Sprint Retrospective
06/10/2011
32
Procesos de Software www.kybele.urjc.es
REUNIÓN DIARIA (DAILY SCRUM)
63
Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada
miembro del equipo , que va a hacer hoy y que problemas se ha encontrado
Procesos de Software www.kybele.urjc.es
REUNIÓN DE PLANIFICACIÓN DEL SPRINT (SPRINT PLANNING MEETING)
64
Se realiza al principio de cada Sprint , definiendo en ella que se va a realizar en
ese Sprint. Esta reunión da lugar al Sprint Backlog . Su duración no debe ser mayor
de 8 horas
06/10/2011
33
Procesos de Software www.kybele.urjc.es
REUNIÓN DE REVISIÓN DEL SPRINT (SPRINT REVIEW MEETING)
65
Se realiza al final del Sprint . Durante la misma se indica qué ha podido
completarse y qué no , presentando el trabajo realizado a los implicados. No debe
durar más de 4 horas
Procesos de Software www.kybele.urjc.es
RETROSPECTIVA DEL SPRINT (SPRINT RETROSPECTIVE)
66
sobre Se realiza al final del Sprint , sirve para que los implicados den sus impresiones sobre el Sprint que acaba de terminar . Se utiliza para la mejora del proceso . Esta reunión
debería durar 4 horas
06/10/2011
34
Procesos de Software www.kybele.urjc.es
RESUMEN
67
•Scrum: Metodología ágil que proporciona un marco para la gestión de proyectos, indicada especialmente para proyectos con un cambio rápido en los requisitos.
•Sprint: Período de corta duración (2-4 semanas) en el que se crea un producto potencialmente entregable.
•Product backlog: Lista priorizada que contiene una serie de los requisitos del producto priorizados para su realización.
•Sprint backlog: Lista con las características que van a desarrollarse en el Sprint.
Procesos de Software www.kybele.urjc.es
RESUMEN
68
•Daily Scrum: Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada miembro del equipo, que va a hacer hoy y los problemas que se ha encontrado.
•Sprint planning meeting: Reunión de no más de 8 horas realizada al principio de cada Sprint, en la que se define que se va a realizar en el mismo.
•Sprint review meeting: Reunión de no más de 4 horas realizada al final del Sprint, en la que se presenta el trabajo realizado a los implicados.
•Sprint retrospective: Reunión de no más de 4 horas que se realiza al final del Sprint, realizada para recoger las impresiones de los implicados respecto al Sprint realizado.
06/10/2011
35
Procesos de Software www.kybele.urjc.es
69
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
Procesos de Software www.kybele.urjc.es 70
Automated builds
Continuous integration
Unit testing
Refactoring
Iterative development
Pair programming
Daily meetings
On-site customer
06/10/2011
36
Procesos de Software www.kybele.urjc.es
71
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
72
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
37
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
73
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
Procesos de Software www.kybele.urjc.es
eXtreme Programming (XP)
74
Centrada en potenciar las relaciones interpersonales . Se basa en la
realimentación continua entre el cliente y el equipo de desarrollo , la comunicación
fluida entre todos los participantes, la simplicidad en las soluciones implementadas y el coraje para
enfrentarse a los cambios
06/10/2011
38
Procesos de Software www.kybele.urjc.es
CARACTERÍSTICAS DE eXtreme Programming (XP)
75
El juego de la planificación : hay una comunicaciónfrecuente entre el cliente y los programadores. Los técnicosestiman el esfuerzo requerido para la implementación,mientras que los clientes deciden sobre el tiempo de cadaiteración.
Entregas pequeñas : una entrega no debería tardar más detres meses, tiempo en el que debe desarrollarse una versióndel sistema que sea operativa aunque no cuente con toda lafuncionalidad del sistema.
Metáfora : es una historia que describe el funcionamiento delsistema. El sistema es definido por una metáfora o unconjunto de ellas compartidas por el cliente y el equipo dedesarrollo.
Procesos de Software www.kybele.urjc.es
CARACTERÍSTICAS DE eXtreme Programming (XP)
76
Diseño simple : se debe diseñar la solución más simple quepueda funcionar.
Pruebas : la producción del código está dirigida por pruebasunitarias.
Refactorización : la reestructuración del código es necesariapara la mejora de la calidad del mismo. Se mejora la estructurainterna del código sin alterar su comportamiento externo.
Programación por pares: la producción se hace en parejas, loque conlleva evitar errores, mejorar el diseño, etc.
Propiedad colectiva del código: cualquier programador puedecambiar cualquier parte del código en cualquier momento.
06/10/2011
39
Procesos de Software www.kybele.urjc.es
CARACTERÍSTICAS DE eXtreme Programming (XP)
77
Integración continua :Integración continua: cada parte del código es integrada enel sistema una vez que está lista.
40 horas por semana: de debe trabajar un máximo de 40horas semanales, y no realizar horas extra durante dossemanas seguidas. Si esto ocurre, algo está realizándosemal.
Cliente in-situ: el cliente debe estar presente y disponibletodo el tiempo para el equipo, conduciendo el trabajo hacia loque aportará mayor valor de negocio.
Estándares de programación: la comunicación entreprogramadores se realiza a través del código, por lo que esimportante que se sigan unas reglas para mantener el códigolegible.
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
78
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
40
Procesos de Software www.kybele.urjc.es
DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)
79
Primera metodología ágil (1994) y la mas próxima
a los métodos tradicionales. Metodología iterativa e
incremental en el que equipo de desarrollo y
usuario trabajan juntos. Propone cinco fases :
estudio de viabilidad, estudio del negocio, modelado
funcional, diseño y construcción y por último
implementación. Las tres últimas fases son
iterativas, y existe realimentación entre cada fase.
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
80
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
41
Procesos de Software www.kybele.urjc.es
ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
81
Metodología iterativa, orientada a los
componentes software más que a las tareas y
tolerante a los cambios . Su ciclo de vida consta de
tres fases : especulación , en la que se inicia el
proyecto y se planifican las características del
software; colaboración , en la que se desarrollan las
características; y aprendizaje , en la que se revisa su
calidad y se entrega al cliente.
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
82
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
42
Procesos de Software www.kybele.urjc.es
FEATURE-DRIVEN DEVELOPMENT (FDD)
83
Metodología iterativa que consta de 5 pasos .
Las iteraciones son cortas , centrándose en
las fases de diseño e implementación del
sistema partiendo de una lista de
características que debe reunir el software
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
84
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
43
Procesos de Software www.kybele.urjc.es
LEAN DEVELOPMENT (LD)
85
Los cambios se consideran riesgos , pero si
se manejan adecuadamente se convierten en
oportunidades que mejoren la
productividad del cliente . Es necesario
introducir un mecanismo que permita
implementar dichos cambios
Procesos de Software www.kybele.urjc.es
OTRAS METODOLOGÍAS ÁGILES
86
eXtreme Programming
Dynamic Systems Development Method
Adaptive Software Development
Feature-Driven Development
Lean Development (LD)
Kanban
06/10/2011
44
Procesos de Software www.kybele.urjc.es
KANBAN
87
Metodología que ayuda a controlar de modo
armónico la fabricación de productos en la
cantidad y tiempo necesarios en cada uno de
los procesos
Procesos de Software www.kybele.urjc.es
KANBAN
88
•Divide el trabajo en bloques , se escribe cada elemento en unatarjeta/post-it y se coloca en una superficie visible (pizarra,pared, etc.)
•Utiliza columnas con nombre para indicar en que lugar delflujo de trabajo se encuentra cada elemento .
•Limita el Work in Progress (trabajo en curso). Asigna límitesconcretos a los elementos que están en progreso en cadaestado del flujo de trabajo.
•Mide el lead time (tiempo de ciclo). Optimiza el proceso paraque el tiempo de ciclo sea lo más pequeño y predecible posible.
06/10/2011
45
Procesos de Software www.kybele.urjc.es
KANBAN
89
PENDIENTE DESARROLLO PRUEBA ENTREGA FINALIZADO
FLUJO
A
B
C
DE
F
G
H
I
J
K
L
3 3 2 1 3
Procesos de Software www.kybele.urjc.es
90
ÍNDICE
METODOLOGÍAS ÁGILES VS TRADICIONALES
2 METODOLOGÍAS HÍBRIDAS
3 SCRUM
4
1
PRÁCTICAS ÁGILES
5 OTRAS METODOLOGÍAS ÁGILES
6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES
06/10/2011
46
Procesos de Software www.kybele.urjc.es
Number of people involved
Crit
ical
ity
(def
ects
cau
se lo
ss o
f...)
Comfort(C)
Essentialmoney
(E)
Life(L)
+20%
Prioritized for Legal Liability
1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000
C6 C20 C40 C100 C200 C500 C1000
D6 D20 D40 D100 D200 D500 D1000
E6 E20 E40 E100 E200 E500 E1000
L6 L20 L40 L100 L200 L500 L1000
Prioritized for Productivity & Tolerance
Different methodologies are possible & needed (project size, system criticality, priorities, fears)
Discretionarymoney
(D)
Alistair Cockburn
Procesos de Software www.kybele.urjc.es
¿Y QUE OCURRE CON LA DOCUMENTACIÓN?
92
06/10/2011
47
Procesos de Software www.kybele.urjc.es
DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR
93
encuentran útil, pero… ¿No era el objetivo principal
[…] Frecuentemente escucho a los desarrolladores
decir que no les gusta documentar , que no lo
encuentran útil, pero… ¿No era el objetivo principal
de documentar el ayudar a otros? ¿Cómo es
posible una visión tan distorsionada de la
documentación?
“Agile Documentation, Anyone?” por Bran Selic IEEE Software de noviembre (Diciembre, 2010)
Procesos de Software www.kybele.urjc.es
DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR
94
[…] El propósito de la documentación es enseñar a quienes no
están familiarizados con un sistema cómo este se estructura,
funciona y los motivos que llevaron a decidirse por ese diseño.
Los principales usuarios de la documentación de dis eño
son los futuros responsables del mantenimiento del
sistema . La única alternativa a no tener documentación de
diseño es explorar directamente el sistema , buscar un camino
a través de una selva sin mapa ni brújula. Así, mientras que
documentar tiene un coste, la inversión, si se hace
correctamente, vale la pena […]
“Agile Documentation, Anyone?” por Bran Selic IEEE Software de noviembre (Diciembre, 2010)
06/10/2011
48
Procesos de Software www.kybele.urjc.es 95
Procesos de Software www.kybele.urjc.es 96
06/10/2011
49
Procesos de Software www.kybele.urjc.es 97
Procesos de Software www.kybele.urjc.es
98
Cuando preparo una batalla,
encuentro que los planes son
inútiles, pero la planificación es
indispensable”
“
Dwight Eisenhower
En la batalla…
06/10/2011
50
Procesos de Software www.kybele.urjc.es
¿QUÉ hacer? MODELO DE PROCESOS
¿CÓMO hacerlo? METODOLOGÍAS
CMMI-DEV
ISO 12207
CMMI-ACQ
CMMI-SVC
ÁgilesTradicionales