Post on 18-Jan-2018
description
transcript
Agile Programming
Simple
ComplexAnarchy
Complicated
Technology
Requirements
Far fromAgreement
Close toAgreement
Close to
Certainty
Far from
Certainty
Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
Project noise level
History: Quick Review
1960’s60’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 DevelopmentFew 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 MethodologiesKeep only those rules and processes that
helpAntidote to bureaucracyLicense to hack
Key characteristicsAdaptivePeople-oriented
Agile Manifesto
February 2001 Representatives from
Extreme Programming SCRUMDSDMAdaptive Software Development Crystal Feature-Driven DevelopmentPragmatic 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
• Jeff Sutherland• Initial scrums at Easel Corp in 1993
• Ken Schwaber• Scrum presented at OOPSLA 95 with
Sutherland• Mike Beedle
• Scrum patterns in PLOPD4• Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002
Scrum origins
CharacteristicsSelf-organizing teamsProduct progresses in a series of 2-week to
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
Unified (Software Development) ProcessIterations within phases4 phases and core workflows for each
Requirements
Analysis
Design
Implementation
Test
ElaborationInception Construction Transition
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
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
The ScrumMaster
• 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
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 consideredAs 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
The sprint review
• Team presents what it accomplished during the sprint• demo of new features or underlying architecture
• Informal• 2-hour prep time rule• No slides
• Whole team participates• Invite the world
Sprint retrospectivePeriodically look at what is and is not workingTypically 15–30 minutesDone after every sprintWhole team participates
ScrumMasterProduct ownerTeamPossibly customers and others
Product backlog: User Stories• 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
Sprint Backlog: How
Breaks the user story down into tasks
Burn-Down Chart Tracks Remaining Effort
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 RightsCustomer has a right to
An 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
SpikesTechnology 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
PlanningManaging
Designing Coding
Testing
When to Use XPTypes of projects
High 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