Download Group Projects - Homepages | The University of Aberdeen

Group Projects
Making working software as a team
Bruce Scharlau, University of Aberdeen, 2011
This is a full time course
• You are expected to spend 40+ hours a
week on this course.
• This works best when everyone meets at
agreed times and works together.
• Communication and learning occurs best
when working together.
Bruce Scharlau, University of Aberdeen, 2011
Teams will have two supervisors
• Every team will have me plus someone
else helping them manage the project and
the software development.
• You must come to the supervisor meetings
to sign in with the department.
• Teams also work with their external clients.
Bruce Scharlau, University of Aberdeen, 2011
This is work-like experience
• Follow same practices and use the same
tools as professional software houses.
• The more you participate, and follow our
guidelines, the more you will have to show
on your cv, and discuss at job interviews
Bruce Scharlau, University of Aberdeen, 2011
You work on a real project
Real projects for real clients using the same
processes as you will when working after
graduation
Provides insights into software processes
and craftmanship needed in working world
Bruce Scharlau, University of Aberdeen, 2011
Current week provides details
for summer work
•
•
•
•
Set up laptops and other machines
Learn skills needed for development
‘Games’ offer insight into working practices
Set up blog for use with individual report:
use ruby, rails and git (source control)
Bruce Scharlau, University of Aberdeen, 2011
How well did you make your
software last term?
Did it work, could it have been better?
Discuss in your group what you would do to
build a project together. Make a list of
main points.
Bruce Scharlau, University of Aberdeen, 2011
What would you have done
differently if you did it again?
Bruce Scharlau, University of Aberdeen, 2011
Explain why group projects are
different
Bruce Scharlau, University of Aberdeen, 2011
Projects have a life cycle
What are the parts of the life cycle for
projects in general?
Bruce Scharlau, University of Aberdeen, 2011
Projects have a process model
http://www.slideshare.net/wasitova/pmbok-and-scrum-best-of-both-worlds
Bruce Scharlau, University of Aberdeen, 2011
Software has its own life cycle
What parts are in the software life cycle?
Bruce Scharlau, University of Aberdeen, 2011
Software projects are different
from other projects
What are the differences?
Bruce Scharlau, University of Aberdeen, 2011
There are diverging views about
software development
Big bang vs salami tactics
Manufacturing vs product development
Bruce Scharlau, University of Aberdeen, 2011
Software is like manufacturing
Build product step by step, just like a car, etc
Take design and then build each part and
assemble in workshop to customer’s
specification
Bruce Scharlau, University of Aberdeen, 2011
Is it really like manufacturing?
Build product step by step, just like a car, etc
Take design and then build each part and
assemble in workshop to customers
specification
Are these statements correct?
Bruce Scharlau, University of Aberdeen, 2011
Software is like product
development
We are designing a new product. We have
some ideas about it, but we’ll need to get
some responses from our potential users
and see if they are correct.
Maybe our idea won’t work and we’ll have
to approach the problem differently.
Bruce Scharlau, University of Aberdeen, 2011
Software projects often fail
Challenged means over budget, incomplete, late
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
Delays cost money
Bruce Scharlau, University of Aberdeen, 2011
There are different methodologies
used for software development
http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
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, 2011
What communication is there in
waterfall?
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
Adding steps between parties
makes software harder to build
client
analyst
developer
What happens if the developer
never speaks directly to the client?
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
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, 2011
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, 2011
Agile adds better value than
traditional projects
http://www.versionone.com/Agile101/Agile_Benefits.asp
Bruce Scharlau, University of Aberdeen, 2011
Agile provides better feedback
Bruce Scharlau, University of Aberdeen, 2011
http://www.agilemodeling.com/essays/costOfChange.htm
You follow regular workflow
5 days
All possible
features
Prioritized
current work
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
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, 2011
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, 2011
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, 2011
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, 2011
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, 2011
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, 2011
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, 2011
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, 2011
Use PDCA cycle for development
Bruce Scharlau, University of Aberdeen, 2011
As <a user type> I’d like to <do
x> because <reason>
Stories cover basic requirements and we
supplement them with specifics
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, 2011
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, 2011
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, 2011
Limit work in progress (WIP)
Limit tasks per stage speeds up delivery
Only
this
many
tasks
per
stage
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
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, 2011
Focus on preparation and
completion
© Jeff Sutherland 1993-2009
http://jeffsutherland.com/PracticalRoadmapMunich20091020.pdf
Bruce Scharlau, University of Aberdeen, 2011
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, 2011
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, 2011