Agile
http://www.flickr.com/photos/tropicaliving/3672347622/sizes/o/
Problems with requirements?
•
•
•
•
Consistency problem
Completeness problem
Ambiguity/lack of clarity problem
….
• Solution?
– Formal specifications…?
You cant build a right system unless
you understand what it should do
Use cases = the activities a system supports
e.g.: tweet a vote report, view delays on map
• Entities = the kinds of objects that are
involved in use cases
e.g.: tweets, user accounts, polling locations, maps
• Attributes = the properties of the entities
e.g.: tweets have: timestamp, text, sender
The four P’s
Effective software project management focuses
on the four P’s: People, product, process and
project.
1) People
2) Product
3) Process
4) Project
The four P’s
• People must be organized into effective teams,
motivated to do high quality software work
and coordinated to achieve effective
communication.
• Product requirements must be communicated
from customer to developer, partitioned
(decomposed) into their constituent parts and
positioned for work by the software team.
The four P’s
• The process must be adapted to the people
and the product. A common process
framework is selected an appropriate software
engineering paradigm is applied, and a set of
work tasks is chosen to get the job done.
• Finally the project must be organized in a
manner that enables the software team to
succeed.
People
The software process is populated by
stakeholders who can be categorized into one
of five categories:
a) Senior managers who define the business
issues that often have a significant influence
on the project
b) Project managers who must plan, motivate
organize and control the practitioners who
do software work
People
• Practitioners who deliver the technical skills
that are necessary to engineer a product or
application.
• Customers who specify requirements for the
software to be engineered.
• End users who interact with software once
released for production use.
End users vs customers
• Software engineers communicate with
different people. The most important are
these:
• In some cases end users and customers are
the same but for many projects customers and
end users are different people working for
different people, managers or even different
organizations.
• Eg: excel might be used in bank or by a
teacher to enter grades
End users vs customers
Customer is a person or a group who:
• Originally requested the software to be built.
• Defines business objective for the software.
• Provide basic product requirements
• Coordinates funding for the project.
End users vs customers
• End user on the other hand is a person or a
group of people who
• Will actually use the software that is built to
achieve some business purpose
• Will define operational details of the software
so the business purpose can be achieved.
The product
A detailed analysis of software requirements would
provide necessary information for estimates but
analysis often takes weeks or even months to
complete.
At a minimum the scope must be established.
Two important steps are:
• Software scope
• Problem decomposition
Product
Scope is defined by answering the following
questions:
• Context: how does software to be built fit into a
large system or business context?
• Information objectives: what data objects are
required for input?
• Function and performance: what function does
the software perform to transform input data
into output? Any special characteristics to be
addressed?
Product
• Problem decomposition:
divide and conquer : partitioned to smaller
problems - decomposition
The W5HH principle
• Why is the system being developed? Does the
business purpose justify the expenditure of
people, money and time?
• What will be done? Task set required for the
project
• When will it be done? Establishing a schedule
by identifying project tasks and hence setting
up milestones
W5HH principle
• Who is responsible for a function? The role
and responsibility of each member of the
team must be defined.
• Where are they located organizationally? Not
all roles and responsibilities reside within
software practitioners. The customer, user and
stakeholders also have roles.
W5HH principle
• How will the job be done technically and
managerially? Once the product scope is
established, a management and technical
strategy for the project must be defined.
• How much of the resource is needed? The
answer to this question is derived by
developing estimates based on answers to
earlier questions.
Three of a kind in a team
• Team leaders: motivation, collaboration,
organization ability
• Project managers: problem solving,
managerial identity, influence and team
building.
• Designer: innovative
Choosing a process
• Waterfall is often a good choice for small
systems whose requirements can be fully
understood before any design or coding.
• Spiral is often a good choice for larger systems
with vague requirements and many
alternatives for designing and coding.
• Agile is often a good choice for systems where
you can rapidly create something small but
useful, and then expand from there.
Contrasting processes
Waterfall
Spiral
Agile
Emphasizes:
-Simplicity
-Traceability
-Risk management
-Exploring alternatives
-Flexibility
-Immediacy
Weakness:
Requirement/design
mistakes can be costly
Exploring alternatives
can be costly
Continual rework can
be costly
Style:
-Highly controlled
-High ceremony
-Moderately controlled
-Moderate ceremony
-Rapid & organic
-Low ceremony
Some definitions
-“traceability”: relationships between requirements and system elements are documented
-“immediacy”: getting some sort of working system to the customer as fast as possible
-“rework”: redesigning the architecture and/or refactoring the program code
-“controlled”: conformance to process is highly valued, even if it slows a project down
-“ceremony”: how much analysis, documentation, and planning is involved
A catalog of some processes
• Waterfall
– Traditional
– With prototyping
• Spiral
• Agile
– Dynamic Systems Development Method (DSDM)
– eXtreme Programming (XP)
And many more..
What is it?
• Agile SE combines a philosophy and a set of
development guidelines. The philosophy
encourages customer satisfaction and early
incremental delivery of software.
• Small, highly motivated project teams.
• Informal methods; overall development simplicity.
• Active and continuous communication b/w
developers and customers.
Who are involved
• Software engineers and other project
stakeholders(managers, customers, users)
work together in an agile team
• Fosters communication among all these
people
Why is it important?
• The modern business environment is fast
paced and ever changing.
• Agile SE represents a reasonable alternative to
conventional SE for certain classes of software
and certain types of software projects.
• It has demonstrated to deliver successful
systems quickly.
What are the steps?
• Also called SE lite: basic framework activities
like communication planning modeling
construction and deployment
• These morph into a minimal task set that
pushes the project team towards construction
and delivery
What is the work product?
• Both customer and SE have the same view –
the only really important work product is an
operational software increment that is
delivered to the customer on the appropriate
commitment date.
How do I ensure that I’ve done it
right?
• If the agile team agrees that the process
works, and the team produces deliverable
software increments that satisfy the customer,
you’ve done it right
Agile manifesto
• Individuals and interactions vs processes and
tools
• Working software vs comprehensive
documentation
• Customer collaboration vs contract
negotiation
• Responding to change vs following a plan
Agile processes
Evaluate & control risk
Customer provides short
requirements
Prioritize
requirements
and plan
Operation
Write/run/modify
unit tests
Implement
System and acceptance tests
Iterations
• Purpose
– Iterative development gives you a few "oh drat"s instead
of one big OMG at the end.
• Timing
– Scrum: 1 month
– XP: 1-2 weeks
• Grouping
– Iterations can be grouped into releases… not every
iteration necessarily results in a new product release
• Sub-dividing
– Each iteration has “micro-iterations” inside of it, where
your team tries to complete some stories and
communicates progress back to the customer, potentially
refining the iteration’s goals.
principles behind agile manifesto
• 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.
principles behind agile 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.
principles behind agile manifesto
• Working software is the primary measure of
progress.
• 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.
principles behind agile manifesto
• 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.
Looking at some specific agile
processes
• DSDM
– Dynamic systems development method
(briefly, as a point of comparison)
• XP
– Extreme programming ( in detail)
Principles of DSDM
• Cases that have tight time constraints: incremental
process!
• Active user involvement is imperative. The team must
be empowered to make decisions.
• Principle: 80% of application can be delivered in 20% of
the time it would take to deliver the complete 100%
application :
• Fitness for business purpose is the essential criterion
for acceptance of deliverables.
• Requirements are specified at a high level.
• The focus is on frequent delivery of products.
• All changes during development are reversible.
• Testing is integrated throughout the life cycle.
Some key practices of DSDM
• Ambassador Users & Facilitated Workshops
– Users on-call & users en-masse (respectively)
• Stages of iterations:
– Pre-project exploratory phase (kick around ideas)
– Feasibility study (explore if ideas are do-able)
– Business study (explore if ideas are worth doing)
– Model, design, implement (a “timebox” of work)
– Post-project phase (what went well, what didn’t?)
Principles of XP
• Communication – it is good to talk with
customer and between developers
• Simplicity – keep it simple and grow the
system and models when required
• Feedback – let users provide feedback early
and often
• Courage – speak the truth, with respect
Practices of XP
•
•
•
•
•
•
•
Whole team
Metaphor
The planning game
Simple design
Small releases
Customer tests
Pair programming
•
•
•
•
•
•
Test-driven development
Design improvement
Collective code ownership
Continuous integration
Sustainable pace
Coding standards
XP Practices: Role of customer
• Whole team
– The customer is part of the team
• Customer tests
– The customer participates in testing
XP Practices: Role of realism
• The planning game
– Customer sketch scenario: developers assign cost development weeks.
Story with highest value. Riskiest ones first. Be
realistic about meeting customer needs
• Small releases
– Meet customer needs in small increments
• Sustainable pace
– No all-nighters, no superheroes
XP Practices: Role of design
• Simple design
– CRC : class responsibility collaboration cards.
Simple models, simple architecture, simple code
• Design improvement
– Refactor as needed (change code without
effecting)
• Metaphor
– Design around a coherent idea
• Continuous integration
– Regularly check to see if the system is on track
XP Practices: Role of teamwork
• Pair programming
– All code is written with a “co-pilot”
• Test-driven development
– Write tests first, then write code
• Collective code ownership
– A big ego… one that includes the team!
• Coding standards
– Pick a format, use it, and move on
XP process in detail
Evaluate & control risk
Customer provides short
requirements
Collect user
stories
DoDivide
Estimate
“spike” for
stories
unfamiliar
effort
intoof
tasks/stories
tasks
tasks
Customer
selects stories
Allocate work
among team
Operation
Write unit
tests
Customer gets
to use system
Customer tests
system
System and acceptance tests
Prioritize
requirements
and plan
Write/run/modify
unit tests
Implement
Write and
refactor code
Concerns about XP
•
•
•
•
Constant refactoring can be expensive
Pair programming can take extra effort
Programmers don’t always specialize
XP is not very standardized
Lessons from DSDM & XP
• Learn from…
– Users (DSDM)
– Customers (XP)
• Design based on…
– Business value (DSDM)
– Customer direction (XP)
• Requirements should be…
– High-level (DSDM)
– Succinct (XP) /compact
• Engineers must demonstrate…
– Empowerment (DSDM)
– Courage (XP)
What’s next?
Due Friday midnight: Insights you have drawn
from this in-class activity
(could be about collaboration , design) : one
page
 Teams will be uploaded on the website
 Thursday Friday : observation assigment