Transcript Group Projects - Homepages | The University of Aberdeen

Agile Projects
Making working software as a team
Bruce Scharlau, University of Aberdeen, 2012
Projects have a life cycle
What are the parts of the life cycle for
projects in general?
Bruce Scharlau, University of Aberdeen, 2012
Projects have a process model
http://www.slideshare.net/wasitova/pmbok-and-scrum-best-of-both-worlds
Bruce Scharlau, University of Aberdeen, 2012
There are diverging views about
software development
Big bang vs salami tactics
Manufacturing vs product development
Bruce Scharlau, University of Aberdeen, 2012
Software projects often fail
Challenged means over budget, incomplete, late
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Bruce Scharlau, University of Aberdeen, 2012
Lots of delay in software projects
The project due in 12 months will arrive after 22
months, bit late if it was for specific event
Bruce Scharlau, University of Aberdeen, 2012
Delays cost money
Bruce Scharlau, University of Aberdeen, 2012
There are different methodologies
used for software development
http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf
Bruce Scharlau, University of Aberdeen, 2012
It doesn’t have to be like that
• Incremental and iterative delivery means
ship part of application early and get
feedback
• Firm can use and learn, and refine ideas
• Firm can start gaining income from product
Bruce Scharlau, University of Aberdeen, 2012
Important to do project right
Often it doesn’t work out correctly… lots of
failure
We need to build the project ‘right’ as well as
‘build the right project’ – balance to ensure
build efficiently, and that build project
business needs
Bruce Scharlau, University of Aberdeen, 2012
What communication is there in
waterfall?
Bruce Scharlau, University of Aberdeen, 2012
Waterfall lacks sufficient
communication
Documents produced at each stage of the
process
Always moves forward, and client may not
see anything until the end
Bruce Scharlau, University of Aberdeen, 2012
You follow regular workflow
5 days
All possible
features
Prioritized
current work
Bruce Scharlau, University of Aberdeen, 2012
Communication friendly process
models are preferred
Describe the types of features you’d expect
to see in a communication friendly project
process model
Bruce Scharlau, University of Aberdeen, 2012
The agile principles cover many
aspects of communication
The manifesto has the basics
http://agilemanifesto.org/
These form twelve principles: how many are
about communication?
Bruce Scharlau, University of Aberdeen, 2012
Ease of communication means
common code base for team
• Use source control with anyone on the team
expected to work on any part of the code as
required
• Work in pairs whenever possible
THERE ARE NO HERO PROGRAMMERS
Bruce Scharlau, University of Aberdeen, 2012
Agile adds better value than
traditional projects
http://www.versionone.com/Agile101/Agile_Benefits.asp
Bruce Scharlau, University of Aberdeen, 2012
Agile provides better feedback
Bruce Scharlau, University of Aberdeen, 2012
http://www.agilemodeling.com/essays/costOfChange.htm
You follow regular workflow
5 days
All possible
features
Prioritized
current work
Bruce Scharlau, University of Aberdeen, 2012
Ease of communication
provides many benefits
• Makes it easier to discuss options
• Makes it easier to decide later in the
process
• Means we don’t need to decide when we
know little about the product
Bruce Scharlau, University of Aberdeen, 2012
Knowing that can communicate
when required allows decisions
to be postponed
• Why decide early on, when the client
knows less about the product, when we
can postpone the decision until later?
• We don’t have to lock-in choices early, so
why should we?
Bruce Scharlau, University of Aberdeen, 2012
Use your real options to
procrastinate
deciding to do something is not the
same committing yourself to an action
When you commit early, then you must know
WHY you do so and what the costs will be
Go see lean procrastination blog
http://leanprocrastination.com/blog/
Bruce Scharlau, University of Aberdeen, 2012
Communication improves
position in cone of uncertainty
Cone of uncertainty
Project estimates improve
as we learn more about
the project
1.8
1.6
1.4
Project schedule
1.2
1
0.8
0.6
0.4
0.2
0
initial product
definition
approved product
definition
requirements
product design
specification
specification
Project deliverables
detaied design
specification
Bruce Scharlau, University of Aberdeen, 2012
accepted software
Seek short project feedback loops
• Look for feedback from coding, integration,
client, so that can make corrections as
soon as possible
Bruce Scharlau, University of Aberdeen, 2012
Communication enables choice
of project priorities
The customer knows what is required for
their application and this will be revealed
more with each iteration
Bruce Scharlau, University of Aberdeen, 2012
Stand up meetings aid
communication
• Daily meetings of all of the team in the
morning to determine who’s did what
yesterday, what they intend to do today,
and what issues are holding them up, which
need to be resolved
• Short, 10-15 meetings only: follow up as
needed with longer individual meetings
• Let people work on project if not needed for
meeting
Bruce Scharlau, University of Aberdeen, 2012
Pair programming aids
communication
• Two people work together at ONE
computer to program a feature, or task
• One person types, while the other catches
typos, suggests algorithms to make the
code work, asks questions
• This is proven to work better than two
people working separately and joining
code together later.
Bruce Scharlau, University of Aberdeen, 2012
TDD and BDD confirms that
communication is ok
• The client writes tests that the team use to
confirm the program does what it should.
These guide the team in development.
• Use Cucumber to clarify with the client
what is needed and then can use RSpec
for more testing underneath
Bruce Scharlau, University of Aberdeen, 2012
Continuous integration is a form
of communication
CI is the process of using a tool to download
the group source code and building the
project to see that it passes its tests and
runs as expected.
Assumes that everyone is submitting their
code regularly to the group repository
Bruce Scharlau, University of Aberdeen, 2012
Use PDCA cycle for development
Bruce Scharlau, University of Aberdeen, 2012
http://theleanstartup.com/principles
Can also be seen as lean startup
Bruce Scharlau, University of Aberdeen, 2012
Follow the TDD principles
Bruce Scharlau, University of Aberdeen, 2012
http://en.wikipedia.org/wiki/File:Test-driven_development.PNG
Use red, green, refactor to code
Make it green, then make it clean
4. Refactor
1. Write a little test
Cycle time < 10 minutes
3. Get test to pass
2. Stub out code.
Watch test fail
Bruce Scharlau, University of Aberdeen, 2012
http://patrickwilsonwelsh.com/?p=619
As <a user type> I’d like to <do
x> because <reason>
Stories cover basic requirements and we
supplement them with specifics
Bruce Scharlau, University of Aberdeen, 2012
User stories provide basic
requirements
Stories are ranked by business
priority and risk
Use burndown charts to
measure progress
Iteration burndown chart
250
Stories
200
150
Series1
Series2
100
50
0
1
2
3
4
5
6
Days
7
8
9
10
Evo process model provides clear
communication of objectives
Evo checks that the application has clear
business objectives and determines how to
measure them along an appropriate scale
to know whether the application is helping
to meet desired organisation goals.
Bruce Scharlau, University of Aberdeen, 2012
IET is precise means to
communicate priorities
Objectives
Design Ideas
#2
#1
#3
Total
Increase Market Share (12% -> 25%)
0%
0%
0%
0%
Increase Monetary Donations ($2.4m ->
$3.0m)
0%
0%
0%
0%
Increase Time Donations (2,400 hrs ->
3,200 hrs)
0%
0%
0%
0%
Total Impact
0%
0%
0%
Hardware / Software
$1
$1
$1
$3
Development Effort
$0
$0
$0
$0
Total Costs
$1
$1
$1
$3
0.00
0.00
0.00
Costs (thousands)
Performance to Cost Ratio
IET = Impact estimation table
Bruce Scharlau, University of Aberdeen, 2012
Lean and Kanban principles
ensure we only do what is needed
•
•
•
•
Limit the work in progress
Delay decisions until last possible moment
Minimize disruption at hand-offs
Make workflow visible
Bruce Scharlau, University of Aberdeen, 2012
Limit work in progress (WIP)
Limit tasks per stage speeds up delivery
Only
this
many
tasks
per
stage
Bruce Scharlau, University of Aberdeen, 2012
Too many tasks creates a
queue of work
• If you shuffle too many tasks for team
members everything slows down, and
– Feedback loops lengthen
– Work takes longer
– There is more work in progress
– The quality goes down
Bruce Scharlau, University of Aberdeen, 2012
Minimize disruptions at hand-offs
Provide work for next stage in suitable format
For example, build to test to deploy hand-offs
Improve throughput by focusing on ‘ready’
before sprint
Improve throughput by focusing on ‘done’
after sprint
Bruce Scharlau, University of Aberdeen, 2012
Focus on preparation and
completion
© Jeff Sutherland 1993-2009
http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf
Bruce Scharlau, University of Aberdeen, 2012
Make workflow visible with kanban
Seeing the work in hand aids issue resolution
Shows:
• Stuck
work
• Priorities
• Who’s
busy
• Problems
Bruce Scharlau, University of Aberdeen, 2012
We’ll use mixture of evo and lean
Use stories to gather minimum features
Use evo (IET) to determine implementation
Use kanban board to limit and see WIP
Automate testing and continuous build
Work in weekly iterations (stages)
Bruce Scharlau, University of Aberdeen, 2012
Build incrementally per greatest
need at the time
• Small slices of functionality with working
software at end of cycle
• Build with tests so you know it all works
• Track progress to see what’s left
• Provide release for people to use and offer
feedback
• Review your process regularly to improve it
Bruce Scharlau, University of Aberdeen, 2012