SOFTWARE DEVELOPMENT PRACTICE
SOFTWARE PROJECT
MANAGEMENT 1
SOFTWARE PROJECT MANAGEMENT
SOFTWARE PROJECT MANAGEMENT 1
Outline
▸ Agile methods
▸ Extreme Programming
▸ Scrum
SOFTWARE PROJECT MANAGEMENT
AGILE METHODS
▸ In the late 1990s a number of new approaches to
software project management began to gain
prominence.
▸ In 2001 the Manifesto for Agile Software Development
was proposed by a group that included the main
proponents of Extreme Programming, Crystal, and
Scrum.
SOFTWARE PROJECT MANAGEMENT
MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
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.
SOFTWARE PROJECT MANAGEMENT
MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
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.
SOFTWARE PROJECT MANAGEMENT
PRINCIPLES BEHIND THE MANIFESTO
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
SOFTWARE PROJECT MANAGEMENT
PRINCIPLES BEHIND THE MANIFESTO
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
SOFTWARE PROJECT MANAGEMENT
PRINCIPLES BEHIND THE MANIFESTO
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING
Developed by Kent Beck and Ward Cunningham
in the 1990s.
(These notes are based on Kent Beck, Extreme
Programming Explained, A-W, 2000.
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: REDUCE RISK
Reduce risk.
NPV(t0) =
∞
∫t
p(t) (r(t) − c(t)) dt
0
where r(t) is revenue flow*, c(t) is the cost flow*, and p(t) is
the probability that the project hasn't been cancelled.
We can try to increase revenue, decrease cost, increase
revenue, decrease the time until the project produces positive
net cash flow, or decrease the probability of cancellation.
* Revenue and cost flows are in constant dollars per unit time.
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: REDUCE RISK
Assuming costs are
the same, early
demonstrated benefit
(e.g., revenue)
reduces risk of
cancellation.
This increases NPV
(and morale).
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: 4 VALUES
‣ Communication
‣ Direct between team members promoted over indirect via
documentation
‣ Simplicity
‣ "Ask 'What's the simplest thing that could possibly work?'" [Beck 2000]
‣ Feedback
‣ E.g., use tests to ensure the system is not regressing
‣ E.g. customer involvement and frequent release
‣ Courage
‣ When needed, make big changes to get out of local optima
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Small, frequent releases
‣ Starting with a minimal viable product
‣ Iteration (typically 2 to 4 weeks not timeboxed)
‣ Plan
‣ Daily cycle: design/code/test/integrate
‣ Release (optional)
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ The Planning Game
‣ Technical and business people work
together to plan the next release
‣ Create scope by selecting features to be
completed in the iteration
‣ Start with a minimal viable product
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Metaphor
‣ Create a central metaphor for the system
‣ Conceptual integrity
‣ Beck advocates metaphor over architecture
‣ I don't see these as alternatives. Metaphor
should guide architecture.
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Simple design
‣ At each point the design should be as simple as
possible to
‣ Implement the feature
‣ I.e., passing all tests that define the feature
‣ State every intention important to the
programmer
‣ E.g., ensuring modularity
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Testing
‣ "Any program feature without a test simply doesn't
exist." [Beck 2000]
‣ Tests should all be automated
‣ Test at
‣ Unit level -- individual classes or modules
‣ Integration level
‣ System level
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Refactoring
‣ Modify design without changing
functionality
‣ Reduce duplication and poor design
‣ Don't refactor on speculation
‣ Do it as needed
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Refactoring example
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Pair programming
‣ All production code is written by two people with one
keyboard/mouse.
‣ Pairing is dynamic
‣ Continuous code review
‣ Aids communication, learning, and exposes information
‣ Avoids the one-critical-person-hit-by-a-bus problem
‣ (Common variation: two keyboards/mice, one for coding,
one for writing tests and documentation.)
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Collective ownership
‣ Anyone can work on any code at any time
‣ if it adds value to the project
‣ Everyone takes responsibility for all parts
‣ "Everyone knows something about every part"
‣ But "information hiding" is still crucial to good
design
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Continuous integration
‣ Integrate your changes frequently (at most
once a day)
‣ Integrate one set of changes at a time
‣ Run all tests until 100% coverage
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ 40-Hour work week
‣ Overtime is a band-aid over a serious
problem.
‣ Fix the underlying problem.
‣ It stifles creativity and ultimately
productivity.
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ On-Site Customer
‣ One or more real customers (e.g., users)
should be embedded in the team
‣ They can have other duties too, but should
be on site and involved
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES
‣ Coding Standards
‣ A programmers should code to a collectively
agreed on coding standard.
‣ Consistent naming conventions.
‣ Consistent parameter usage (e.g., results first
or results last).
‣ Consistent ordering (e.g., fields / constructors
/ methods)
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING: PRACTICES WORK TOGETHER
‣ The practices compensate for each other
‣ For example Short Release cycles could be a bad idea unless
‣ Planning ensures that each release brings more value
‣ Constant integration reduces the need for a long
integration phase
‣ Continuous testing reduces the need for a long separate
testing phase
‣ The design is kept as simple as possible to achieve the
immediate goal
SOFTWARE PROJECT MANAGEMENT
GRADIENT DESCENT
‣ Extreme programming resembles the
optimization technique of iterated gradient
descent (or ascent).
‣ Based on where you are, what small step
increases value most quickly?
‣ Take that step
‣ Repeat
SOFTWARE PROJECT MANAGEMENT
GRADIENT DESCENT
‣ Of course the danger of gradient descent is that it can
get stuck in a local optimum
‣ So it is important to
‣ Resolve risk early
‣ E.g. by ensuring unfamiliar technologies are
incorporated early
‣ E.g. by exploring architectural alternatives early
‣ Have courage to make large changes when needed
SOFTWARE PROJECT MANAGEMENT
80-20
‣ You can often get 80% of the benefit from
20% of the functionality
‣ Try to put the most valuable 20% into
production in early iterations
SOFTWARE PROJECT MANAGEMENT
EXTREME PROGRAMMING
‣ Looks at practices holistically
‣ Emphasizes
‣ Feedback
‣ frequent iteration and release
‣ continuous interaction with customers
‣ continuous testing
‣ Communication and shared purpose
‣ Simplicity over anticipated complexity