Embed Size (px)
Citation preview
Agile Software
Development
1
Who I am…
2
Rui Barreira
Senior Delivery Manager/Agile Coach
@ VORTAL
Agile Enthusiast since 2008
Experienced Software Architect and
Product Manager
pt.linkedin.com/in/ruimbarreira/
What is NOT!
3
4
Agile is NOT! – Reduced Team Capacity
5
Agile is NOT! – One Big Story
6
Agile is NOT! – No Process
7
Agile is NOT!
“letting the programming team do whatever they need to with
no project management, and no architecture, allowing a
solution to emerge, the programmers will do all the testing
necessary with Unit Tests…”
Business Value
8
9
What is Business Value?
• Value: is any desirable result for a stakeholder in a context;
• Stakeholder: are groups or individuals with a relationship to the
change or the solution;
• Needs: are problems, opportunities or constraints with potential of
value to a stakeholder;
• Changes: are any controlled transformations of an organization;
• Solutions: are specific ways to satisfy needs in a context;
• Contexts: are the part of the environment that encompasses a
change;
10
What is Business Value?
“Price is what you pay, Value is What you get!”
Warren Buffet
11
Types of Business Value?
12
Delivering Business Value is difficult!
• Of the work executed: “Many (possibly most) organisations lose as much as 45% of their total revenues due to costs associated with low quality”
• On Failing: Some 75 percent of most large-scale J2EE projects fail by missing both time and budget projections …”
• On Value: “64% of features actually delivered are either rarely or never used”
13
How to create Business Value!
WATERFALL (Royce)
Requirements, design
implementation,
verification &
maintenance
1960 85 9119801970
V-MODEL (Anon)
Aligns testing to
Waterfall development
SPIRAL MODEL
(Barry Boehm)
Iterative
RAD
(James Martin)
Prototyping, iterative,
time-boxed, user driven
RUP (Rational)
Object oriented,
iterative, time-boxed,
user driven
AGILE e.g. XP
(Kent Beck)
Incremental, user
driven, low process
98 99
Waterfall V-Model
Spiral Model
RAD
RUP
Agile Philosophy
14
15
The Philosophy
� Agile methods are considered
� Lightweight
� People-based rather than Plan-based
� Several agile methods
� No single agile method
� XP most popular
� No single definition
� Agile Manifesto closest to a definition
� Set of principles
� Developed by Agile Alliance
16
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
17
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
18
The 12 principles of Agile
19
On Image Agile
Agile Methodologies
20
21
All of them are Agile
� Agile methods:
� Scrum
� Extreme Programming
� Adaptive Software Development (ASD)
� Dynamic System Development Method (DSDM)
� Lean IT
� …
� Agile Alliance (www.agilealliance.org)
� A non-profit organization promotes agile development
22
Lets Talk About SCRUM
23
Sequencing vs Overlapping
Requirements Design Code Test
24
Scrum in 100 Words
� Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
� It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
� The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.
� Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance for another iteration.
25
Scrum Characteristics
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for delivering projects
• One of the “agile processes”
26
Scrum Framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
27
Scrum Roles – Product Owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results
28
Scrum Roles – Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
29
Scrum Roles – The Team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints
30
Scrum Ceremonies - Planning Meeting
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal
Product Backlog
31
Scrum Ceremonies - Planning Meeting
• Team selects items from the product backlog they can commit to completing
• Sprint backlog is created
• Tasks are identified and each is estimated (1-16 hours)
• Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
Sprint
goal
Sprint
goal
Sprint
backlog
Sprint
backlog
32
Scrum Ceremonies – The Daily Scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, ScrumMaster, product owner, can talk
• Helps avoid other unnecessary meetings
33
Scrum Ceremonies – The Daily Scrum
What did you do yesterday?What did you do yesterday?11
What will you do today?What will you do today?22
Is anything in your way?Is anything in your way?33
34
Scrum Ceremonies – The Sprint Review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
35
Scrum Ceremonies – The Sprint Retrospective
• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• ScrumMaster
• Product owner
• Team
• Possibly customers and others
36
Scrum Artifacts – The Product Backlog
• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint
37
Scrum Artifacts – The Sprint Backlog
• A subset of Product Backlog Items, which define the work for a Sprint
• Is created ONLY by Team members
• Each Item has it’s own status
• Should be updated every day
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
38
Scrum Artifacts – The Sprint Backlog
39
Scrum Artifacts – All Backlogs
Strategic Roadmap
All the features ofproduct roadmap
Products’s Backlog
All the features of a particular product
Sprint Backlog
Stories for thesprint
40
Scrum Artifacts – The Sprint Burndown Chart
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of the Sprint
• Actually is not a straight line
• Can bump UP
41
Scrum Artifacts – The Sprint Burndown Chart
42
Definition of Done
Code Commented
and Committed to
Line
Developmen
t Finished
Report
Unit Tests
Functional
Requirement
Document
Technical Requirement Document
Agile Practices
43
44
For Though Tasks – Pair Programming
45
For Though Tasks – Pair Programming
We help each other succeed. This practice comes
from XP.
46
For Though Tasks – Pair Programming
Pair-Pressure– Keep each other on task and focused
– Don’t want to let partner down
– “Embarrassed” to not follow the prescribed process
– Parkinson’s law “work expands to fill all available time.”
Pair-Think– Distributed cognition: “searching through larger spaces of alternatives”
» Have shared goals and plans
» Bring different prior experiences to the task
» Different access to task relevant information
» Must negotiate a common shared of action
Pair-Relaying– Each, in turn, contributes to the best of their knowledge and ability
– Then, sit back and think while their partner fights on
47
For Though Tasks – Pair Programming
Pair-Reviews– Continuous design and code reviews
– Ultimate in defect removal efficiency
– Removes programmers distaste for reviews
» 80% of all (solo) programmers don’t do them regularly or at all
Debug by describing– Tell it to the Furby
Pair-Learning– Continuous reviews � learn from partners techniques, knowledge of
language, domain, etc.
– “Between the two of us, we knew it or could figure it out”
– Apprenticeship
– Defect prevention always more efficient than defect removal
48
Roles – Pair Programming
The DriverThe person with "control" of the computer
Does the bulk of the typing
The NavigatorActively follows along with the driver with comments
Can take over at any time
49
For Quality – Continuous Integration
“ Continuous Integration is a software development practice
where members of a team integrate their work frequently, usually
each person integrates at least daily - leading to multiple
integrations per day. Each integration is verified by an automated
build (including test) to detect integration errors as quickly as
possible.“
http://martinfowler.com/articles/continuousIntegration.html
50
For Quality – Continuous Integration
• The ultimate goal of continuous integration is to be able to deploy all code.
• Although you won’t release in the middle of a sprint, the point is to be technologically ready, even if you are not functionally.
• With Continuous integration, you are integrating in short cycle and thus have smaller changes to deal with as you integrate.
• Continuous integration does not make sense unless it’s automated, has a short turn around time (fast builds), and everyone owns the concept of Green Builds.
• You need tests to fail or pass a build. Tests are the backbone that give you a green or a red light to take a snapshot of your build.
51
Challenges – Continuous Integration
• Don’t force this. It requires everyone to buy-in.
• CI also requires some setup, if you don’t have one.
• Keeping build times short. This might require some serious effort and might show you the deficiency of your builds.
• And you need a good version control system – VC systems like subversion that allows atomic check-in.
52
Start with the wheels – Interactive Design
53
It’s Simulation Time!
Agile Values
54
55
COMMITMENT
56
COLLECTIVE
OWNERSHIP
57
COMMUNICATION &
COLLABORATION
58
PEOPLE
Thank
You!
59
