Post on 17-Dec-2015
Agile Programming9 OCTOBER 2013
History
1960’s
60’s “Cowboys” wrote software anyway that they couldDifference between best programmers and worst as high as 28:1
(many sources)Start of the “software crisis”
1968Edsger Dijkstra, “GOTO Statement Considered Harmful” (CACM)Recognition that rules can improve the average programmer
Structuring Software Development
Few rules helped immenselyGood rules and practices developed over the 70’s
and 80’sIf a few rules are good, more are better…Late 80’s, major focus on process as a key to quality
ISO 9000 (first published 1987)Malcolm Baldrige National Quality Award (just celebrated
25th anniversary)
Why not apply to software development?
Companies started codifying their practicesLarge documents and people to manage them
Rise of the project manager
“Honored in the breach”More large projects and more late or failed
projects1995 Standish Group StudyJerry Saltzer SOSP 1999
Agile Methodologies: Backlash
Agile Methodologies
Keep only those rules and processes that helpAntidote to bureaucracyLicense to hack
Key characteristicsAdaptivePeople-oriented
Agile Manifesto
February 2001 Representatives from
Extreme Programming SCRUM
DSDMAdaptive Software Development
Crystal Feature-Driven Development
Pragmatic Programming
SCRUMWITH ACKNOWLEDGEMENT TO MIKE COHN FROM MOUNTAIN GOAT SOFTWARE, LLC
We’re losing the relay race
Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.
“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”
•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. Teams self-organize 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 it for another sprint.
Scrum in 100 words
Characteristics
Self-organizing teamsProduct progresses in a series of month-long
“sprints”Requirements captured in “product backlog”No specific engineering practices prescribedUses generative rules to create an agile
environment for delivering projects
The Process
© www.mountaingoatsoftware.com/scrum
Sprints
Scrum projects make progress in a series of “sprints”
Typical duration is 2–4 weeks or a calendar month at most
A constant duration leads to a better rhythmProduct is designed, coded, and tested during
the sprint
Sequential vs. overlapping development
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Rather than doing all of one thing at a time... ...Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprint
Plan sprint durations around how long you can commit to keeping change out of the sprint
Change
Scrum framework
•Product owner•ScrumMaster•Team
Roles
•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting
Ceremonies
•Product backlog•Sprint backlog•Burndown charts
Artifacts
The teamTypically 5-9 peopleCross-functional:
Programmers, testers, user experience designers, …
Members should be full-timeMay be exceptions (e.g., database administrator)
Sprint planning meeting
Sprint prioritization• Analyze and evaluate
product backlog• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal (design)
• Create sprint backlog (tasks) from product backlog items (user stories / features)
• Estimate sprint backlog in hours
Sprintgoal
Sprintbacklog
Business conditions
Team capacity
Product backlog
Technology
Current product
Sprint planning Team selects items from product backlog they can commit
to 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
As a vacation planner, I want to see photos of the hotels.
Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
The daily scrumDaily15-minutesStand-up
Not for problem solvingWhole world is invitedOnly team members, Scrum Master, product owner talkHelps avoid other unnecessary meetings
Everyone answers 3 questions
not status for the ScrumMastercommitments in front of peers
What did you do yesterday?1
What will you do today?2
Is anything in your way?3
A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50
Hours
40
30
20
10
0Mon Tue Wed Thu Fri
TasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Mon8
16
8
12
Tues Wed Thur Fri4
12
16
7
11
8
10
16 8
50
Scaling through the Scrum of scrums
Extreme Programming
Complete development process First code drop 2-3 weeks after start
(what is the start?) Customer part of the development
team Iterative development to the max Derive requirements with customer
through hands-on experimentation Agile methodology
XP Bills of Rights
Developer has a right toClear requirements and prioritiesDetermine how long a requirement will
takeRevise estimatesAlways produce quality code
XP Bills of Rights
Customer has a right toAn overall planSee progress in a running systemChange requirements and prioritiesBe informed of changes to schedule
and have input as to how to adaptCancel in the middle and still have
something to show for the investment
XP Value System
Communication Focus on people, not documentation
Simplicity Of process and code
Feedback Mechanism to make useful progress
Courage To trust in people (Bollinger: what you would like to know about
software that your life depended on)
User Stories
Use cases Written by customer Used for planning
Developers estimate by story Stories basis for iteration
Used to build acceptance tests Remember that correctness equals meeting
requirements
System Metaphor
Initial system design
Spikes
Technology explorationsFocus on high risk itemsTypically considered throw-away code
If not, needs to be agreed to by the whole team
Release Planning Each iteration has its own plan
Function OR date (other is adjusted accordingly)(Recall 4 variables: function, date, resources, quality)
Planning adapts as the project progresses Measure project velocity
Number of user stories and tasks completed
Next iteration looks at planned vs. actual time Allowed to plan last iteration’s number for this
iteration
Iteration
Scope: all parts of the system Only add functions needed for current user stories
Recommendation: 3 weeks Moving people around
Backup and training Code is owned by the whole team
Pair programming Re-factoring
Pair Programming
Two people working at a single computer Built-in backup and inspections Collaboration builds better code Mechanical model
One drives, the other talks Keyboard slides between the two
Logical model One tactical, the other strategic Both think about the full spectrum but bring different
perspectives
Pair Programming Experiments
Typical numbers show the total manpower consumed not very different Numbers range, but no more than ¼ additional
manpower Implication: actual time is reduced Improved satisfaction also improves productivity Williams et al, “
Strengthening the Case for Pair-Programming”
Refactoring
Each iteration adds just the function needed If you continue to add new functions every two weeks,
code can get messy Refactoring is the cleaning up of the code at the end of
the iteration Critical to maintaining quality code (Also applies to the design) Difference between refactoring & rewriting?
Feedback Loops
The Rules of Extreme Programming
Planning
Managing Designing
Coding Testing
When to Use XP
Types of projectsHigh riskPoorly understood requirements
TeamSmall size: 2 to 12Needs to include customer
Automated testingTiming issue
What Makes a Project XP Paradigm
see change as the norm, not the exception optimize for change
Values communication, simplicity, feedback, and courage honor in actions
Power sharing business makes business decisions development makes technical decisions
Distributed responsibility and authority people make commitments for which they are accountable
Optimizing process aware of process and whether it is working experiment to fix acculturate new team members
Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck
NOT everyone loves XP