2. Abstarct
Presentar una mirada general a las
metodologías "Agiles" de Desarrollo de Software
y desbancar el mito de que desarrollo "Ágil" es
simplemente desarrollar sin seguir un proceso, o
sin crear documentación.
Hablar un poco sobre la experiencia de
implementar una metodología Ágil en un
proyecto de software de gran volumen, las
ventajas, desventajas y especialmente los retos
que se esto presenta para un equipo de
desarrollo.
3. Un ejemplo: Entrevista
Entrevistador: Dice en su hoja de vida que usted
tiene experiencia en metodologías agiles, en cuales
ha trabajado?
Candidato: Como en cuales? En Ágil! Cual mas?
Entrevistador: Y entonces que es Ágil?
Candidato: Pues es desarrollar software sin seguir
un proceso, sin tantas complicaciones y sin tanta
documentación, es mas rápido y mas ágil.
Entrevistador: Gracias, que pase el siguiente!
5. Mitos
Metodologías Agiles = Cowboy Coding
Metodologías Agiles = Hay una sola! (XP?)
Metodologías Agiles != Procesos
Metodologías Agiles != Documentación
Metodologías Agiles != Buenas Practicas
Metodologías Agiles = Para Todo el Mundo
Metodologías Agiles != CMMI
6. Realidades
Metodologías Agiles != Cowboy Coding
Metodologías Agiles = Muchas Diferentes
Metodologías Agiles = Procesos
Metodologías Agiles = Buena Documentación
Metodologías Agiles = Buenas Practicas
Metodologías Agiles != Para Todo el Mundo
Metodologías Agiles = CMMI
7. El Manifiesto Ágil:
Principios Fundamentales
Process and tools
Individuals and
interactions
over
Following a planResponding to change over
Source: www.agilemanifesto.org
Comprehensive
documentation
Working software over
Contract negotiationCustomer collaboration over
8. Metodologías Agiles
XP (eXtreme programming)
Scrum
DSDM (Dynamic Systems Development
Method)
FDD (Feature Driven Development)
Kanban
11. Las 12 Practicas de XP
Fine scale feedback
• Pair programming
• Planning Game
• Test drive
development
• Whole team
Continuous process
• Continuous
integration
• Design improvement
• Small releases
• Shared understanding
– Coding Standards
– Collective code
ownership
– Simple design
– System metaphor
• Programmer welfare
– Sustainable pace
13. Seis Roles
Project Manager
Chief Architect
Development Manager
Chief Programmers
Class Owners (aka Developers)
Domain Experts
14. OK—Mas de seis!
Supporting Roles
Domain manager
Release manager
Language guru
Build engineer
Toolsmith
System administrator
Sometimes Helpful
Testers
Deployers
Technical writers
15. Five Processes
Develop an overall
model
Build a features
list
Plan by feature
Design by feature Build by feature
Per project Per feature
16. 2. Build a features list
http://www.nebulon.com/articles/fdd/DevView.html
17. 3. Plan By Feature
Form the planning
team
Determine the
development
sequence
Assign features to
chief programmers
Assign classes to
developers
18. 3. Plan By Feature
http://www.nebulon.com/articles/fdd/planview.html
19. 5. Develop by feature
Code
Unit Testing
Code inspections
Promote to build
20. Project Tracking Methodology
Develop an overall
model
Build a features
list
Plan by feature
Design by feature Build by feature
10% initial,
4% ongoing
4% initial,
1% ongoing
2% initial,
2% ongoing
77%
Process 1’s 10% is the most significant.
Other numbers are fungible.
21. Project Tracking Methodology
Design by feature Build by feature
77%
Walk through: 1%
Design: 40%
Inspection: 3%
Code/test: 45%
Inspection: 10%
Promote: 1%
walkthrough + design =
41% complete
22. FDD defines 6 milestones
1) walkthrough – explanation of the requirement to
the developers (face-to-face)
2) design – creation of the sequence diagram
3) design review – peer review to check the
design meets the requirements
4) coded – methods are written in class files to
deliver the design
5) code review and unit test – test & peer review
to check that code does what was specified in
the design
6) promotion – into the integrated build for system
/ product testing.
23. 23
Six exact meaningful milestones per feature
Percentage complete assigned to each milestone
Record completion dates for each milestone
Roll up by Feature Set, Feature Area
Represent graphically for upper management
Trend and graph as desired
Domain
Walkthrough
Design Design
Inspection
Code Code
Inspection
Promote to
Build
1% 40% 3% 45% 10% 1%
Project Tracking Methodology
24. 24
To steer you need to know…
Exactly where you are
Exactly where you are going
Roughly how fast you are going
Project Tracking Methodology
25. Achieving Smooth Flow
Device Management Ike II Cumulative Flow
0
20
40
60
80
100
120
140
160
180
200
220
240
10-Feb
17-Feb
24-Feb
2-M
ar
9-M
ar
16-M
ar
23-M
ar
30-M
ar
Time
Features
Inventory Started Designed Coded Complete
28. Features of SCRUM
Scrum is a simple “inspect and adapt” framework that has three
roles, three ceremonies, and three artifacts designed to deliver
working software in Sprints, usually in iterations of 1 to 4 weeks.
• Product Owner
• ScrumMaster
• The Team
Roles
• Sprint Planning
• Sprint Review
• Daily Scrum Meeting
Ceremonies
• Product Backlog
• Sprint Backlog
• Burndown Chart
Artifacts
29. What’s the process?
• A sprint is considered the “heartbeat” of the Scrum cycle
Sprint
Planning
Sprint Sprint Review
Sprint
Retrospective
• Time-Boxing is used to control the duration of each step
and must be adhered to
34. CMMI
CMMI no dice que es lo que hay que
hacer, Ni mucho menos como hacerlo.
CMMI no dice que solo sirve con RUP o
con Waterfall.
Hay muchos caso de éxito de empresas
CMMI utilizando metodologías agiles
