Upload
others
View
16
Download
0
Embed Size (px)
Citation preview
© Codemanship Ltd 2015
Agile Software Development
© Codemanship Ltd 2015
What To Expect Today
• Introduction to Agile
• The History of Agile Software Development
• The Agile Manifesto
• The 4 Agile Values
• Core principles of Agile
• Continuous Delivery
• Extreme Programming
• Planning
• Managing
• Designing
• Coding
• Testing
© Codemanship Ltd 2015
What To Expect Tomorrow
• Scrum
• Roles
• Scrum Master
• Product Owner
• Development Team
• Events
• Sprints
• Daily Scrum
• Sprint Review (Retrospectives)
• Artefacts
• Product Backlog
• Sprint Backlog
• Product Increment
• Sprint Burn-down Chart
• Product Burn-down Chart
• Agile Pitfalls
• Agile, the CodemanshipWay
• Goals, not features
• Reality-driven Development
• How to build great Agile teams
• Scaling Agile - the reality
INTRODUCTION TO AGILE
© Codemanship Ltd 2015
HISTORY OF AGILE SOFTWARE DEVELOPMENT
© Codemanship Ltd 2015
Waterfall Model (1970)
© Codemanship Ltd 2015
Managing The Development of Large Software Systems (1970)
Winston W. Royce
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
"I believe in this concept, but the implementation described above is risky
and invites failure"
Agile Is Older Than You Think #1
© Codemanship Ltd 2015
"We were doing incremental development as early as
1957, in Los Angeles, under the direction of Bernie
Dimsdale at IBM's Service Bureau Corporation. He was
a colleague of John von Neumann, so perhaps he
learned it there, or assumed it as totally natural. I do
remember Herb Jacobs (primarily, though we all
participated) developing a large simulation for Motorola,
where the technique used was, as far as I can tell ... All
of us, as far as I can remember, thought waterfalling of a
huge project was rather stupid, or at least ignorant of the
realities. I think what the waterfall description did for us
was make us realize that we were doing something else,
something unnamed except for 'software development.'"
Gerald Weinberg
"Iterative and Incremental
Development: A Brief History".
IEEE Computer, June 2003
Agile Is Older Than You Think #2
© Codemanship Ltd 2015
Started writing about evolutionary
project management in 1970,
leading to Evo method described
in Principles of Software
Engineering Management (1988)
Tom Gilb
Agile Is Older Than You Think #3
© Codemanship Ltd 2015
"A Process for the Development of Software for
Nontechnical Users as an Adaptive System".
Edmonds, E. A.
General Systems, 1974
(According to Edmonds, this was first submitted to
Computer Aided Design magazine in 1970, and was
rejected with the criticism:
“If you don't know what you are going to do before
you start you shouldn't start"
Earnest Edmonds
Agile Is Older Than You Think #4
© Codemanship Ltd 2015
Rapid Application Development (RAD) developed and
deployed by the New York Telephone Company's
Systems Development Center under the direction of Dan
Gielan in 1974
Gielan went on to lecture extensively about their
approach
Dan Gielan
Spiral Model (1986)
© Codemanship Ltd 2015
A Spiral Model of Software Development and Enhancement (1986)
Barry Boehm
http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf
When Dinosaurs Ruled The Earth (1980’s)
© Codemanship Ltd 2015
The Lightweight Backlash (1990’s)
© Codemanship Ltd 2015
Snowbird, Utah, 2001
© Codemanship Ltd 2015
THE AGILE MANIFESTO
© Codemanship Ltd 2015
© Codemanship Ltd 2015
We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
• 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.
Agile Principles
© Codemanship Ltd 2015
1. Customer satisfaction by early and continuous delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximizing the amount of work not done—is essential
11.Self-organizing teams
12.Regular adaptation to changing circumstances
CONTINUOUS DELIVERY
© Codemanship Ltd 2015
What Is Continuous Delivery?
Continuous delivery is the process of having a shippableproduct/ piece of software after each check in to source control.
Business Implications Of Continuous Delivery
• Deployment becomes entirely a business decision
• Deployment can happen as frequently as the business requires
• Deployment can happen as soon as features & changes are ready
• At any given time, the amount of work in progress is minimised
• Cycle times from conception to delivery can be massively reduced
• Features/changes per release can be minimised
• Business feedback cycles can be minimised
• Businesses can learn faster
Technical Implications of Continuous Delivery
• The software must always be fit for purpose
• Test assurance needs to be high
• Programmers must be able to build and properly test the software quickly and cost-effectively
• Deploying software must be fast, reliable and cost-effective
• Building, testing & deploying software must be fully automated
• Whatever you deliver, it must be easy to change so it can continue to evolve
EXTREME PROGRAMMING
© Codemanship Ltd 2015
History of XP
• 1993 - Chrysler C3 payroll project initiated
• 1994 - Kent Beck brought in to performance-tune Smalltalk code
• Beck’s role widens to look at development process
• 1996 – Beck becomes C3 project leader
• Implements ideas from collaborations with Ward Cunningham
• Ron Jeffries brought in to develop ideas, acts as coach on C3 project
• 1995 - Principles & practices of XP shared with wider world via original c2.com Wiki (invented by Cunningham)
• 1999 – Beck’s Extreme Programming Explained published
© Codemanship Ltd 2015
Nothing New (Examples)
© Codemanship Ltd 2015
1957 – NASA Project Mercury software
teams drive development by agreeing
failing tests up-front and specifically
writing code to pass those tests (Test-
driven Development)
1984 – Thinking Forth by Leo Brodie first
in-print use of term “refactoring” to
describe practice of simplifying code to
make it more readable
Why “Extreme”?
© Codemanship Ltd 2015
If it’s a good idea to test early
and often, it must be a great idea
to test continuously
If nobody ever reads the
architecture document, let’s not
waste time writing one
Principles of XP
© Codemanship Ltd 2015
Minimise delay between
action and feedback
speeds learning
Assume solution to
every problem is
extremely simple
(Y.A.G.N.I. – you ain’t
gonna’ need it)
Embrace changes to
requirements, no matter
how late. Embrace
learning.
XP Values
© Codemanship Ltd 2015
The XP Process
© Codemanship Ltd 2015
XP PRACTICES - PLANNING
© Codemanship Ltd 2015
User Stories
© Codemanship Ltd 2015
Borrow a DVD
As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy
Release Planning
© Codemanship Ltd 2015
Donate a DVD
As a video library member, I want to donate a DVD to the library so that other members can borrow it and I can earn points for priority services
Borrow a DVD
As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy
Return a DVD
As a video library member, I want to return a copy of a DVD I’ve borrowed so that I can other members can borrow and earn priority points when I return it on time
Send Weekly Newsletter
As the video library administrator, I want a newsletter emailed to all members once a week listing all the new titles added since the last newsletter so that members can see what new titles are available
Join the Library
As a movie lover, I want to join the video library so that I can get access to its collection of titles
Reserve a DVD
As a video library member, I want to reserve titles for which all rental copies are currently on loan so I can borrow it when copies are returned. If there’s a queue for a title, I want to be able to use my priority points to fast-track myself up the queue.
1. 2. 3.
4. 5. 6.
5 days 2 days 3 days
3 days 5 days 3 days
Small Releases
© Codemanship Ltd 2015
? ? ? ?
Iteration Planning
© Codemanship Ltd 2015
Donate a DVD
As a video library member, I want to donate a DVD to the library so that other members can borrow it and I can earn points for priority services
Borrow a DVD
As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy
Return a DVD
As a video library member, I want to return a copy of a DVD I’ve borrowed so that I can other members can borrow and earn priority points when I return it on time
Send Weekly Newsletter
As the video library administrator, I want a newsletter emailed to all members once a week listing all the new titles added since the last newsletter so that members can see what new titles are available
Join the Library
As a movie lover, I want to join the video library so that I can get access to its collection of titles
Reserve a DVD
As a video library member, I want to reserve titles for which all rental copies are currently on loan so I can borrow it when copies are returned. If there’s a queue for a title, I want to be able to use my priority points to fast-track myself up the queue.
1. 2. 3.
4. 5. 6.
5 days 2 days 3 days
3 days 5 days 3 days
Next Iteration
Project Velocity = 7 days/iteration
Estimating & Signing Up
© Codemanship Ltd 2015
• Various units used for
estimation – it’s actually
academic, because time
taken = story points /
velocity in any unit
• Any developer can estimate
a story
• Estimating means you are
bidding to do that work
• The lowest bid wins
XP PRACTICES - MANAGING
© Codemanship Ltd 2015
Open Workspace
© Codemanship Ltd 2015
Sustainable Pace
© Codemanship Ltd 2015
Daily Stand-up Meeting
© Codemanship Ltd 2015
Project Velocity
© Codemanship Ltd 2015
0
5
10
15
20
25
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6
Project Velocity
Story Points Completed 3 Iteration Average Story Points Remaining
Today’s
weather is
likely to be
like
yesterday’s
weather“burn-down”
Move People Around
© Codemanship Ltd 2015
Retrospectives
© Codemanship Ltd 2015
Kristian Sørensen, 2014
XP PRACTICES - DESIGNING
© Codemanship Ltd 2015
Simple Design
© Codemanship Ltd 2015
System Metaphor
© Codemanship Ltd 2015
Modeling with CRC Cards
© Codemanship Ltd 2015
Library
• Knows about titles• Knows about new
titles• Adds donated titles• Adds new titles
• Title• Member
Title
• Knows its name, director & year of release
• Knows about rental copies
• Registers rental copy
• Email Alert
Email Alert
• Sends email to members who specified matching title
?
Member
• Knows about priority points
• Awards priority points
class
responsibilities collaborations
Solutions Spike
© Codemanship Ltd 2015
Send Weekly Newsletter
As the video library administrator, I want a newsletter emailed to all members once a week listing all the new titles added since the last newsletter so that members can see what new titles are available
?
Can’t estimate because not sure what
technical solution might take
…knock up quick
prototype to learn what’s
involved, then…
Estimate time required to…
…feed back lessons to
estimate story
You Ain’t Gonna Need It (YAGNI)
© Codemanship Ltd 2015
Refactoring
© Codemanship Ltd 2015
Refactoring - Overview
© Codemanship Ltd 2015
Agility & The Cost of Change
© Codemanship Ltd 2015
Refactoring – Obstacles To Change
© Codemanship Ltd 2015
Lack of Test Assurance Poor Readability High Complexity
Duplication Dependencies
Refactoring Discipline
© Codemanship Ltd 2015
1. Identify problem
(complexity - method
does too much) 2. Apply appropriate
refactoring (Extract
Method)
3. Run tests!!!
XP PRACTICES - CODING
© Codemanship Ltd 2015
On-Team Customer
© Codemanship Ltd 2015
Coding Standards
© Codemanship Ltd 2015
Test-driven Development
© Codemanship Ltd 2015
TDD process
© Codemanship Ltd 2015
Write a test
that fails
Write simplest
code to pass
the test
Refactor to
keep code
maintainable
Test #2 –
Boiled eggs
with toast
TDD Example – Designing a Kitchen
© Codemanship Ltd 2015
Test #1 –
Boiling
eggs Refactor to
remove
duplication
Simplest
solution
Simplest
solution
Pair Programming
© Codemanship Ltd 2015
DriverNavigator
Continuous Integration
© Codemanship Ltd 2015
Repository
Continuous Integration
© Codemanship Ltd 2015
Frequent automated…
• Compilation of
source code
• Packaging of
executables &
supporting files
• Testing
Team Heartbeat
© Codemanship Ltd 2015
Check-In Dance
© Codemanship Ltd 2015
1. Grab build token
2. Merge
3. Run tests
4. Commit
5. Wait for
successful build
6. Release build
token
Collective Code Ownership
© Codemanship Ltd 2015
server-side
code
web front
end
SQL
reporting
Collective Code Ownership
© Codemanship Ltd 2015
The Code
XP PRACTICES - TESTING
© Codemanship Ltd 2015
Writing Tests For Bugs
© Codemanship Ltd 2015
Bug: Invoice total not calculated correctly
Invoice totals should include sales tax
Acceptance Test-driven Development
© Codemanship Ltd 2015
Acceptance Test-driven Development
© Codemanship Ltd 2015
Borrow a DVD
As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy
Test: Borrow a DVD that has one copy for loan
Given that title ‘The Abyss’ has one copy available for loan,
When member jasongormanborrows that copy
Then the count of available copiesis reduced by one, leaving zerocopies for loan, so other memberscannot borrow The Abyss
Executable Specification
Effect of action
Definition of “Done”
© Codemanship Ltd 2015
Borrow a DVD
As a video library member, I want to borrow a copy of a DVD so that I can watch it without buying my own copy
Test: Borrow a DVD that has one copy for loan
Given that title ‘The Abyss’ has one copy available for loan,
When member jasongormanborrows that copy
Then the count of available copiesis reduced by one, leaving zerocopies for loan, so other memberscannot borrow The Abyss
Test: Borrow a DVD that has more than one copy for loan
Given that title ‘The Abyss’ has two copies available for loan,
When member jasongormanborrows that copy
Then the count of available copiesis reduced by one, leaving one copyfor loan, so other members can still borrow The Abyss
Measuring completeness by
acceptance tests passed gives
an objective and honest account
of real progress
SCRUM
© Codemanship Ltd 2015
Origins of Scrum
• “A flexible, holistic product development strategy where a development team works as a unit to reach a common goal“
• Hirotaka Takeuchi & Ikujiro Nonaka, New Product Development Game (1986)
• New approach to commercial product development to increase speed & flexibility
• Based on case studies from manufacturing firms in automotive, photocopier & printer industries
• Team "tries to go the distance as a unit, passing the ball back and forth“, like in rugby
• Jeff Sutherland & Ken Schwaber presented paper describing the scrum methodology at OOPSLA '95
• Sutherland & Schwaber attend Agile summit at Snowbird, Utah in 2001
© Codemanship Ltd 2015
Scrum Process
© Codemanship Ltd 2015
Daily Scrum
e.g. 14 days
SCRUM ROLES
© Codemanship Ltd 2015
Product Owner
© Codemanship Ltd 2015
The Product Owner…
• Represents stakeholders & is “voice of the customer”
• Represents development team to stakeholders
• Writes user stories
• Manages product backlog
• Does NOT interfere in technical decisions
© Codemanship Ltd 2015
Development Team
© Codemanship Ltd 2015
The Development Team is…
• Responsible for delivering potentially shippable increments (PSIs) of product at end of each sprint
• Made up of 3–9 individuals who do the actual work (analyse, design, develop, test, technical communication, document, etc.)
• Cross-functional; having all skills necessary to complete product increment
• Self-organising
© Codemanship Ltd 2015
Scrum Master
© Codemanship Ltd 2015
The Scrum Master…
• Facilitates Scrum on the team
• Helps to remove obstacles to progress
• Buffers team from distractions
• Coaches team, product owner & stakeholders on Scrum principles & practices
• Promotes self-organisation within team
• Is NOT a project manager or team leader
© Codemanship Ltd 2015
SCRUM EVENTS
© Codemanship Ltd 2015
Sprint
© Codemanship Ltd 2015
• Time-boxed iteration
• Duration of 1-4 weeks (average
2 weeks)
• Emphasis on work product at
end that is really done
Sprint Planning
© Codemanship Ltd 2015
• Identify user stories to form sprint backlog
• Estimate effort required to complete sprint backlog
• Team votes to commit to sprint goal
• Sets a 4-hour window to complete planning per 2-week
sprint (pro rata)
• 1st half: team agree on backlog items to include
in sprint
• 2nd half: team decompose items and to
estimate effort required)
Planning Poker
© Codemanship Ltd 2015
Technique to eliminate
“anchoring” in estimates and
achieve consensus
• Product Manager explains
requirement
• Team members place
estimate card face down
• Cards turned over at once
• Outliers explain their
reasoning
• If necessary, play another
round
• TimeboxedEstimate numbers are far apart to
avoid “I say it’s a 9” “I say it’s a 10”
quibbling.
e.g., Fibonacci series
Daily Scrum
© Codemanship Ltd 2015
Development Teams meets for
max 15 minutes daily, each
answering:
• What did I do yesterday?
• What will I do today?
• What is blocking me from
achieving sprint goals?
Teams ensure:
• Everyone comes prepared
• Starts on time
• Same time/place every day
(typically early in the day in
the team area)
Sprint Review
© Codemanship Ltd 2015
• Review completed work
• Present product increment to
stakeholders (“show & tell”)
Sprint Retrospective
© Codemanship Ltd 2015
• Reflect on previous Sprint
• What went well, what not-so-well?
• Agree plans to improve processes
SCRUM ARTIFACTS
© Codemanship Ltd 2015
Product Backlog
© Codemanship Ltd 2015
Type Requirement Effort Value
Feature Review a movie 5 21
Feature Rate review usefulness 1 5
Bug All movies should have poster
images
3 8
Non-Func App should install in < 30
seconds
13 13
Feature Follow a movie network user’s
reviews
2 5
Feature Add movie trivia 5 3
Bug Movies users aren’t old
enough to rent shouldn’t be
displayed
8 5
Priority
• Your product’s “TO DO”
list
• Managed by Product
Owner
• An ordered list of
requirements that
includes new features,
bug fixes, non-
functional requirements
• Prioritised by business
value, risk,
dependencies and date
needed
• Includes estimates of
business value by
stakeholders, and
development effort by
team
Sprint Backlog
© Codemanship Ltd 2015
To Do In Progress Done
Sprint: #8 w/c 15/7/13 Due Date: 27/7/13 • Sprint’s “TO DO” list
• Managed by
Development Team
• Team takes highest
priority items from
product backlog they
believe they can
commit to for this sprint
• Once committed, no
more backlog items
can be added
• At sprint completion,
product backlog is
revisited and updated
as necessary
Product Increment
© Codemanship Ltd 2015
• Sum of all product backlog
items completed during
current sprint & previous
sprints
• Must be complete
according to agreed
Definition of Done
• Must be shippable, even if
product owner decides not
to release
Sprint Burn-down Chart
© Codemanship Ltd 2015
• Charts work
remaining against
estimated total
effort in a sprint
• Managed by
development team
Release Burn-down Chart
© Codemanship Ltd 2015
• Provides visibility
of overall progress
on the product
• Shows how scope
changes over
multiple sprints
• Helps identify
trends in
productivity and
scope
• Managed by
Scrum Master
AGILE PITFALLS
© Codemanship Ltd 2015
Incremental Waterfall (“WAgile”)
© Codemanship Ltd 2015
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
Incrementally executing a
detailed plan that’s not
supposed to change cuts
out opportunities to learn
Absentee Customer
© Codemanship Ltd 2015
Lack of customer engagement is
consistently cited as the primary
cause of software project failure
frAgile – Lack of Technical Discipline
© Codemanship Ltd 2015
If the code is difficult to
maintain, teams cannot
respond to change
Piecemeal Architecture
© Codemanship Ltd 2015
When team members
pursue different
architectural styles
because they’re not
communicating about it
enough
Lack of Training & Support
© Codemanship Ltd 2015
Task Focus vs Goal Focus
© Codemanship Ltd 2015
Teams who focus on tasks tend to
struggle to lose sight of the end goals,
and struggle to achieve objectivity in
measuring progress
Build Blindness #1
© Codemanship Ltd 2015
When teams know
their build is broken,
and they ignore it
Build Blindness #2
© Codemanship Ltd 2015
When teams assume
that because tests are
all passing, software
is working
Scrum Master as Project Manager
© Codemanship Ltd 2015
The Scrum Master is NOT in charge
Product Owner as Customer
© Codemanship Ltd 2015
The Product Owner is NOT the customer
Estimates vs. Commitments
© Codemanship Ltd 2015
Going Agile Overnight
© Codemanship Ltd 2015
Adopt and improve Agile practices iteratively
AGILE THE CODEMANSHIP WAY
© Codemanship Ltd 2015
Goals, Not Features
© Codemanship Ltd 2015
• Establish testable,
realistic goals for
software and
systems
• Iterate towards
those goals, rather
than following a plan
or working through a
list of features
• BALANCED:
Consider multiple
stakeholder
perspectives (not
just financial goals)
Features From Goals
© Codemanship Ltd 2015
Recruitment Process
Recruitment Management System
edit job ad approve job ad publish job ad Send link to online skills test
<< goal >>
Reduce hiring time from 8 to 6 weeks
Reality-driven Development
© Codemanship Ltd 2015
• Analyse requirements and
test designs and working
software in as close an
approximation to the real
world as possible
• Try software out in realistic
situations on real end users
• Simulated business
environments are sometimes
referred to as Model Offices
• Business scenarios can be
explored and repeated,
allowing testing in edge
cases and operational
extremes
Business Stories
© Codemanship Ltd 2015
Recruit a developer
As development manager, I want to recruit software developers who have the necessary skills and experience to work on our in-house business systems, so that we can take on new work and maintain systems in production
Business Test Scripts
© Codemanship Ltd 2015
The CRM team require a full-stack web developer to replace a team
member who is leaving in 2 months.
They create a job spec that reads:
“WANTED: Full-stack Web Developer
Seeking full-stack web developer with Java/JEE, JavaScript, HTML and
SQL skills to enhance CRM system.”
The HR dept approve the job spec and publish it on the company
website. It is also syndicated automatically to Jobserve.com and Stack
Overflow.
After 20 mins, Jill Smith applies with her CV via email.
After 60 mins, Ken Chan applies with his CV through the website.
After 90 mins, Amanda Johnson calls the advertised number to enquire.
… etc etc
Designing A Model Office
© Codemanship Ltd 2015
Recruitment
Management
server
Dev manager’s
laptop (web
browser)
HR manager’s
laptop (web
browser)
Company web
server
Candidate’s tablet
computer
Switchboard/Call
Management
System
Candidate’s phone
Fake jobserve.com
Fake stackoverflowpublish
syndicate
create job spec
approve
job spec
apply via
enquire via
connect via
application
application
Building Great Agile Teams
© Codemanship Ltd 2015
• Self-organising teams build themselves
• Favour small teams (4-6 people)
• Favour experienced developers
• Be flexible about technologies
• Recruit proactively
• Always be recruiting
• Build a strong dev culture & a good
reputation
• If you can’t find good enough people,
seriously consider:
• Paying more
• Offering greater autonomy
• Abandon prejudices and
preconceptions
Scaling Agile – The Reality
© Codemanship Ltd 2015
• There’s no compelling evidence that any software
organisation has ever achieved economy of scale
• Favour small, independent, autonomous self-
organising teams doing what’s best for them and their
customer
• Promote continuous opportunities for teams to interact
and learn from each other
• Favour loose project dependencies and interop
protocols over “enterprise architecture”
• Be continually aware of project and product
dependencies
• Favour clear goals and simple standards over
prescribed processes
• Look to nature – swarm intelligence
• Dev culture can scale - massively
www.codemanship.com
© Codemanship Ltd 2015