se_lec 04_agile software development
TRANSCRIPT
1
2
A software development methodology or system
development methodology is used to structure, plan,
and control the process of developing an information
system.
Classical methods of software development have many
disadvantages:
Huge effort during the planning phase.
Poor requirements conversion in a rapid changing
environment.
Treatment of staff as a factor of production.
New philosophy : Agile Software Development
3
4
An iterative process is one that makes progress through
successive refinement
An incremental process is one in which software is built
and delivered in pieces. Each piece, or increment,
represents a complete subset of functionality
5
6
7
8
Able to move quickly and easily
9
A group of software development methods based on
iterative and incremental development
Requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams
Promotes adaptive planning, evolutionary development
and delivery, a time-boxed iterative approach, and
encourages rapid and flexible response to change
10
On February 11-13 2001, 17 people met to find common
grounds in software development methodologies
What emerged is the Agile Software Development
Manifesto
11
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.
12
13
Manifesto for waterfall Software Development
Software development can be equated to any other engineering task. We
believe software development projects can be effectively managed by:
………………………………………………………………………………………………………………..
Understanding and writing specifications that define how the software will look
and what it will do
Performing in-depth analysis and design work before estimating development
costs
Ensuring software developers follow the specifications
Testing the software after implementation to make sure it works as specified,
and Delivering the finished result to the user
………………………………………………………………………………………………………………..
That is, if the specification is of sufficient detail, then the software will
be written such that it will satisfy the customer, will be within budget,
and will be delivered on time.
14
Qualities:
Minimize risk short iterations
Real-time communication (prefer face-to-face) very
little written documentation
Indicated for unpredictable / rapidly changing
requirements
15
The following principles are those that differentiate
agile processes from others.
Our Highest Priority is to Satisfy the Customer through Early
and Continuous Delivery of Valuable Software.
Welcome Changing Requirements, even late in Development.
Deliver working software frequently, from a 2-4 weeks. with
a preference to the shorter timescale.
Business People and Developers must Work Together Daily
through out the Project.
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done.
16
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.
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. [i.e. High quality is the key to
high speed]
17
Simplicity--the art of maximizing the amount of work not
done--is essential.
• Agile teams take the simplest path that is consistent with
their goals.
• They don’t anticipate tomorrow’s problems and try to
defend against them today.
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
18
Effective (rapid and adaptive) response to change (team
members, new technology, requirements)
Effective communication in structure and attitudes
among all team members, technological and business
people, software engineers and managers。
Drawing the customer into the team. Eliminate “us and
them” attitude. Planning in an uncertain world has its
limits and plan must be flexible.
Organizing a team so that it is in control of the work
performed.
19
Emphasize an incremental delivery strategy as opposed
to intermediate products that gets working software to
the customer as rapidly as feasible.
Rapid, incremental delivery of software.
The development guidelines stress delivery over analysis
and design although these activates are not discouraged,
and active and continuous communication between
developers and customers
20
Key features must exist among the people on an agile
team and the team itself:
Competence. ( talent, skills, knowledge)
Common focus. ( deliver a working software increment )
Collaboration. ( peers and stakeholders)
Decision-making ability. ( freedom to control its own
destiny)
Problem-solving ability. (ambiguity and constant changes,
today problem may not be tomorrow’s problem)
Mutual trust and respect.
Self-organization. ( themselves for the work done, process
for its local environment, the work schedule)
21
Agile methods:
Scrum
Kanban
Scrum ban
eXtreme Programming (XP)
Agile Unified Process (AUP)
Feature Driven Development (FDD)
Dynamic System Development Method (DSDM)
Adaptive Software Development (ASD)
Lean Software Development
Crystal Clear Methods
Custom Hybrids
…
22
23
24
Scrum in the sport of rugby, is a way of restarting the
game, either after an accidental infringement or (in
rugby league only) when the ball has gone out of play
25
26
Scrum is an agile process that allows us to focus on
Delivering the highest business value in the shortest
time.
It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
The business sets the priorities: teams self-organize to
determine the best way to deliver the highest priority
features.
Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
27
SCRUM:
is an agile, lightweight process.
can manage and control software and product development.
uses iterative, incremental practices.
has a simple implementation
is Team-based approach.
increases productivity
reduces time to benefits
is developing systems/ products with rapidly changing
requirements.
Controls the chaos(فوضى) of conflicting interest and needs.
Improve communication and maximize cooperation.
Protecting the team form disruptions (اضطرابات) and impediments
.(العوائق)
28
Microsoft
Yahoo
Electronic Arts
High Moon Studios
Lockheed Martin
Philips
Siemens
Nokia
Capital One
BBC
Intuit
Intuit
Nielsen Media
First American Real Estate
BMC Software
Ipswitch
John Deere
Lexis Nexis
Sabre
Salesforce.com
Time Warner
Turner Broadcasting
Oce
29
Commercial software
In-house development
Contract development
Fixed-price projects
Financial applications
ISO 9001-certified
applications
Embedded systems
24x7 systems with 99.999%
uptime requirements
the Joint Strike Fighter
Video game development
FDA-approved, life-critical
systems
Satellite-control software
Websites
Handheld software
Mobile phones
Network switching
applications
ISV applications
Some of the largest
applications in use
30
Jeff Sutherland
Initial scrums at Easel Corp in 1993
IDX and 500+ people doing Scrum
Ken Schwaber
ADM
Scrum presented at OOPSLA 96 with Sutherland
Author of three books on Scrum
Mike Beedle
Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
Co-founded Scrum Alliance in 2002, initially within Agile Alliance
31
Product BacklogAs prioritized by Product Owner
Sprint Execution2-4 Weeks
32
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Requirements Design Code Test
33
•Product owner
•Scrum Master
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
34
Product Owner Possibly a Product Manager or Project Sponsor
Knows what needs to be build and in what Sequence this should be
done
Decides features, release date, prioritization, $$$
Accept or reject work results.
Scrum Master Typically a Project Manager or Team Leader
Responsible for enacting Scrum values and practices
Remove impediments / politics, keeps everyone productive
Project Team 5-9 members; Teams are self-organizing
Cross-functional: QA, Programmers, UI Designers, etc.
Membership should change only between sprints
35
Pig: Team member committed to success of project
Chicken: Not a pig; interested but not committed
A pig and a chicken are walking down a road. The chicken looks at
the pig and says, "Hey, why don't we open a restaurant?" The pig
looks back at the chicken and says, "Good idea, what do you want to
call it?" The chicken thinks about it and says, "Why don't we call it
'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed
but you'd only be involved."
36
Sprint Planning Meeting
Daily Scrum
Sprint Review Meeting
37
A collaborative meeting in the beginning of each Sprint
between the Product Owner, the Scrum Master and the
Team
Takes 8 hours and consists of 2 parts (“before lunch and
after lunch”)
1st Part:
• Determining the Sprint Goal.
• Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
• Participants: Scrum Master, Scrum Team
• Creating Sprint Backlog
38
Sprint planning meeting
Sprint prioritization
• Analyze/evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items (user
stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product
39
Parameters
Daily, ~15 minutes, Stand-up
Anyone late pays a $1 fee
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind the
schedule
Is a meeting in which team members make commitments to
each other and to the Scrum Master (Pig & chicken)
Is a good way for a Scrum Master to track the progress of the
Team
Three questions answered by each team member:
1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?
40
Is held at the end of every sprint
Business functionality which was created during the
Sprint is demonstrated to the Product Owner
Informal
2-hour prep time rule
No slides
Whole team participates
Invite the world
41
A special form of Sprint Planning Meeting
Meeting before the begin of the Project
42
Typical individual team is 7 ± 2 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+ person projects
43
44
Scrum has remarkably few artifacts
Product Backlog
Sprint Backlog
Burndown Charts
Can be managed using just an Excel spreadsheet
More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project manager who
travels
• Still under development
45
The requirements
A list of all desired work on
project
Ideally expressed as a list of
user stories along with "story
points", such that each item
has value to users or
customers of the product
Prioritized by the product
owner
Reprioritized at start of each
sprint
Is only a FORECAST!-> is not
exact
46
Instead of Use Cases, Agile project owners do "user stories"
Who (user role) – Is this a customer, employee, admin, etc.?
What (goal) – What functionality must be achieved/developed?
Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
Example:
"As a user, I want to log in, so I can access subscriber content.“
47
Story points: Rating of effort needed to implement this story
common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.
Methods of estimation:
Expert Review
Creating a Work Breakdown Structure (WBS)
48
Backlog item Estimate
Allow a guest to make a reservation 3 (story points)
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50
49
50
Scrum projects make progress in a series of “sprints”
Typical duration is 2–4 weeks or a calendar month at
most
Product is designed, coded, and tested during the sprint
NO outside influence can interference with the Scrum
team during the Sprint
51
Individuals sign up for work of their own choosing
Work is never assigned
Estimated work remaining is updated daily
Any team member can add, delete change sprint backlog
If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
No more then 300 tasks in the list
If a task requires more than 16 hours, it should be
broken down
52
53
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the Foo class
Mon
8
16
8
12
8
Tue
4
12
16
8
Wed Thu
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8
54
55
A display of what work has been completed (work done)
and what is left to complete
There are three-types:
Sprint Burn down Chart (progress of the Sprint)
Release Burn down Chart (progress of release)
Product Burn down chart (progress of the Product)
56
Ho
urs
X-Axis: time (usually in days)
Y-Axis: remaining effort
57
Hours
40
30
20
10
0Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tue Wed Thu Fri
4
12
16
7
11
8
10
16 8
50
58
No work being performed
Sprint 1 Burndown
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Ho
urs
rem
ain
ing
59
Work being performed, but not fast enough
Sprint 1 Burndown
40
41
42
43
44
45
46
47
48
49
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Ho
urs
rem
ain
ing
60
Work being performed, but too fast!
Sprint 1 Burndown
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Ho
urs
rem
ain
ing
61
Will the release be done on right time?
X-axis: sprints
Y-axis: amount of hours remaining
The estimated work remaining can also burn up
62
Is a “big picture” view of project’s progress (all the
releases)
63
Advantages
Completely developed and tested features in short iterations
Simplicity of the process
Clearly defined rules
Increasing productivity
Self-organizing
each team member carries a lot of responsibility
Improved communication
Combination with Extreme Programming
Drawbacks
“Undisciplined hacking” (no written documentation)
Violation of responsibility
Current mainly carried by the inventors
64
65
66
Principle Description
Customer involvement
The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of thesystem.
Incremental deliveryThe software is developed in increments with the customerspecifying the requirements to be included in each increment.
People not process
The skills of the development team should be recognised and
exploited. The team should be left to develop their own waysof working without prescriptive processes.
Embrace changeExpect the system requirements to change and design thesystem so that it can accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and
in the development process used. Wherever possible,actively work to eliminate complexity from the system.
67
It can be difficult to keep the interest of customers who
are involved in the process.
Team members may be unsuited to the intense
involvement that characterizes agile methods.
Prioritizing changes can be difficult where there are
multiple stakeholders.
Maintaining simplicity requires extra work.
Contracts may be a problem as with other approaches to
iterative development.
68
Perhaps the best-known and most widely used agile
method.
Extreme Programming (XP) takes an ‘extreme’ approach
to iterative development.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;
All tests must be run for every build and the build is only
accepted if tests run successfully.
69
Formulated in 1999 by Kent Beck, Ward Cunningham and
Ron Jeffries
Agile software development methodology (others:
Scrum, DSDM)
Developed in reaction to high ceremony methodologies
70
71
Previously:
Get all the requirements before starting design
Freeze the requirements before starting development
Resist changes: they will lengthen schedule
Build a change control process to ensure that proposed
changes are looked at carefully and no change is made
without intense scrutiny
Deliver a product that is obsolete on release
72
Recognize that:
All requirements will not be known at the beginning
Requirements will change
A key assumption of XP is that the cost of changing a program
can be hold mostly constant over time
Use tools to accommodate change as a natural process
Do the simplest thing that could possibly work and refactor
mercilessly
Emphasize values and principles rather than process
Hence XP is a lightweight (agile) process:
Instead of lots of documentation nailing down what customer wants up
front, XP emphasizes plenty of feedback
Embrace change: iterate often, design and redesign, code and test
frequently, keep the customer involved
Deliver software to the customer in short (2 week) iterations
Eliminate defects early, thus reducing costs
73
(Source: http://www.xprogramming.com/xpmag/whatisxp.htm)
74
All contributors to an XP project are one team
Must include a business representative--the ‘Customer’
Provides requirements
Sets priorities
Steers project
Team members are programmers, testers, analysts,
coach, manager
Best XP teams have no specialists
75
Two key questions in software development:
Predict what will be accomplished by the due date
Determine what to do next
Need is to steer the project
Exact prediction (which is difficult) is not necessary
76
XP Release Planning Customer comes up with a list of desired features for the system
Each feature is written out as a user story• Describes in broad strokes what the feature requires
• Typically written in 2-3 sentences on 4x6 story cards
Programmers estimate difficulty
Developers estimate how much effort each story will take, and
how much effort the team can produce in a given time interval
(iteration)
XP Iteration Planning Two week iterations
Customer presents features required
Programmers break features down into tasks
Team members sign up for tasks
Running software at end of each iteration
77
Development team has continuous access to a real live
customer, that is, someone who will actually be using
the system, or a proxy
The Customer defines one or more automated
acceptance tests for a feature
Team builds these tests to verify that a feature is
implemented correctly
Once the test runs, the team ensures that it keeps
running correctly thereafter
System always improves, never backslides
78
Start with the smallest useful feature set (release(
Team releases running, tested software every iteration
The Customer can evaluate or in turn, release to end
users, and provide feedback
Important thing is that the software is visible and given
to the Customer at the end of every iteration
79
Always use the simplest possible design that gets the job
done
Through programmer testing and design improvement,
keep the software simple and the design suited to
current functionality
Not a one-time thing nor an up-front thing
Design steps in release planning and iteration planning
Teams design and revise design through refactoring,
through the course of the project
80
All production software is built by two programmers,
sitting side by side, at the same machine
Driver enters code, while navigator critiques it
Periodically switch roles
All production code is therefore reviewed by at least
one other programmer
Research into pair programming shows that:
pairing produces better code (High Quality Code) in the
same time as programmers working singly
Pair programming increases productivity
Pairing also communicates knowledge throughout the
team
81
Teams practice TDD by working in short cycles of adding
a test, and then making it work.
Writing tests before code clarifies the requirements to
be implemented (or before adding a feature, write a
test for it!).
Tests are written as programs rather than data so that
they can be executed automatically. The test includes a
check that it has executed correctly.
Easy to produce code with 100 percent test coverage
Each time a pair releases code to the repository, every
test must run correctly
82
Tests come in two basic flavors…
1. Unit Tests automate testing of functionality as developers
write it Each unit test typically tests only a single class, or a small cluster of classes
Unit tests typically use a unit testing framework, such as JUnit (xUnit)
Experiments show that test-driven development reduces debugging time
Increases confidence that new features work, and work with everything
If a bug is discovered during development, add a test case to make sure it
doesn’t come back!
2. Acceptance Tests (or Functional Tests) are specified by the
customer to test that the overall system is functioning as
specified When all the acceptance tests pass, that user story is considered complete
Could be a script of user interface actions and expected results
Ideally acceptance tests should be automated, either using a unit testing
framework, or a separate acceptance testing framework
83
Continuous design improvement process called
‘refactoring’:
Removal of duplication
Increase cohesion
Reduce coupling
Refactoring is supported by comprehensive testing--
customer tests and programmer tests
84
All changes are integrated into the code base at least
daily, or multiple times a day builds
Avoid ‘integration hell’
Avoid code freezes
Tests have to run 100% both before and after integration
85
No single person "owns" a module
Any developer (pair of programmers) can work on any
part of the code base at any time
No ‘secure workspaces’
All code gets the benefit of many people’s attention
Avoid duplication
Programmer tests catch mistakes
Pair with expert when working on unfamiliar code
86
Use common coding standard
All code in the system must look as though written by an
individual
Code must look familiar, to support collective code
ownership
87
XP Teams develop a common vision of the system
With or without imagery, define common system of
names
Ensure everyone understands how the system works,
where to look for functionality, or where to add
functionality
88
Team will produce high quality product when not overly
exerted
Avoid overtime, maintain 40 hour weeks
Programmers go home on time
“fresh and eager every morning, and tired and satisfied every
night”
In crunch mode, up to one week of overtime is allowed
More than that and there’s something wrong with the process
‘Death march’ projects are unproductive and do not
produce quality software
Work at a pace that can be sustained indefinitely
89
Goal: Identify items to be accomplished for the day and
raise issues
Everyone attends, including the customer
Not a discussion forum
Take discussions offline
Everyone gets to speak 15 minutes
90
Communication
Simplicity
Feedback
Courage
91
Poor communication in software teams is one of the root
causes of failure of a project
Stress on good communication between all stakeholders-
-customers, team members, project managers
Customer representative always on site
Paired programming
92
DTSTTCPW principle (‘Do the Simplest Thing That Could
Possibly Work’)
Implement a new capability in the simplest possible way
Refactor the system to be the simplest possible code with
the current feature set
YAGNI principle (‘You Aren’t Going to Need It’)
Never implement a feature you don’t need now
93
Feedback at different time scales
Always a running system that delivers information about
itself in a reliable way
The system and the code provides feedback on the state
of development
Unit tests tell programmers status of the system
Programmers produce new releases every
2-3 weeks for customers to review
Catalyst for change and an indicator of progress
94
Projects are people-centric
Ingenuity of people and not any process that causes a
project to succeed
The courage to communicate and accept feedback
The courage to throw code away (prototypes)
The courage to refactor the architecture of a system
95
Williams, L. and Kessler, R., “All I Really Need to Know
about Pair Programming I Learned In Kindergarten,”
Communications of the ACM (May 2000)
Share everything. (Collective code ownership)
Play fair. (Pair programming—navigator must not be passive)
Don’t hit people. (Give and receive feedback. Stay on track.)
Clean up your own mess. (Unit testing.)
Wash your hands before you eat. (Wash your hands of
skepticism: buy-in is crucial to pair programming.)
Flush. (Test-driven development, refactoring.)
Take a nap every afternoon. (40-hour week.)
Be aware of wonder. (Ego-less programming, metaphor.)
96
Unrealistic--programmer centric, not business focused
Detailed specifications are not written
Design after testing
Constant refactoring
Customer availability
12 practices are too interdependent
97
The best design is the code.
Testing is good. Write tests before code. Code is
complete when it passes tests.
Simple code is better. Write only code that is needed.
Reduce complexity and duplication.
Keep code simple. Refactor.
Keep iterations short. Constant feedback.
9898
Will you incorporate XP practices in your projects?
What does this life cycle imply relationship between
customer and team, analyst/designers and programmers?
Keep customer involved?
The planning game—learn how to estimate effort for small
tasks?
Embrace change? Many iterations and releases?
Pair programming? Maintain discipline of switching
drivers?
Junit tests before writing code?
Stand up meetings?
99
100
101
102
103
104
105
Advantages:
More effective feedback
More effective iterations (sprints) planning
Disadvantages:
Smaller stories are often too small to be valuableand
difficult to identify
In the backlog of smaller stories could be hundreds of
items, instead of couple dozen in Kent Beck’s days
(eXtreme Programming). New problem of management
of stories has emerged.
106
Doing Scrum well is verydifficult. Most teams do not
reliably deliver their sprint commitment by the end of
the sprint.
There is no one right way to do Scrum. Both
"Successful“ and "Improvable„ teams come in all sizes
and configurations.
At least upto a point, more stories per sprint are
better. It looks like 10 to 15 is a good number. Most
teams should consider slicing their stories smaller.
Very big stories are unlikely to be completed in the
sprint, butan occasional moderately sized story doesn't
look like it's a problem.
107
Development work often continues throughout a cycle while
testing starts late and never seems to get enough time.
108
Lean has been defined in many different ways.
Is a systematic method in which the core idea is to
maximize customer value while minimizing waste
(“Muda”)
Derived mostly from Toyota Production System (TPS) or
“Just-in-time production”
109
In 1990 James Womack, Daniel T. Jones, and Daniel
Roos wrote a book called “The Machine That Changed
the World: The Story of Lean Production -- Toyota's
Secret Weapon in the Global Car Wars That Is Now
Revolutionizing World Industry”
In this book, Womack introduced the Toyota Production
System to American.
What was new was a phrase– "Lean Manufacturing"
110
Value = What the customer pays money for
Waste = Everything else!
Muda ("non-value-adding work")
• Type 1: The non value added activity for end customer but it is
necessary.
• Type 2: The non value added activity for end customer which are
not necessary. It is targeted to eliminate this type of wastage.
The first seven types of muda in manufacturing system:
• Storage
• Transportation
• Waiting
• Motion
• Process
• Defects
• Over-production
111
Building features no one needs
Write more specs than you can code
Write more code than you can test
Test more code than you can deploy
112
Eliminate/Minimize waste
Amplify learning
Decide as late as possible
Deliver as fast as possible
Empower the team
Build quality in
See the whole
113
Continuous Flow-of-Value
Value Stream Mapping
Bottleneck Analysis
Kanban (Pull System)
Poka-Yoke (Error-proofing)
5 Whys
Kaizen (Continuous Improvement)
SMART Goals (Specific, Measurable, Attainable,
Relevant, and Time-Specific)
114
Rather than focusing on being Agile which may (and
should) lead to being successful, Kanban focuses on
becoming successful, which may lead to being Agile.
Anyone that has used a Scrum has used a simple Kanban
system.
In Japanese the word Kan means "signal" and "ban"
means "card" or “board”. A Kanban card is a signal that
is supposed to trigger action. Therefore Kanban refers to
"signal cards".
115
Start with existing process
Agree to peruse incremental, evolutionary change
Respect current process, roles, responsibilities and titles
Leadership at all levels
116
Visualize the Workflow
Lead using a team approach
Learn and Improve Continuously
Reduce the Batch Size of your Efforts (BASE)
Little’s Law:
Cycle Time = Work-in-progress / Average Completion Time
117
118
119
120
A concise, written description of a piece of functionality
that will be valuable to a user (or owner) of the
software.
Stories are:
User’s needs
Product descriptions
Planning items
Tokens for a conversation
Mechanisms for deferring conversation
seek to combine the strengths of written and verbal
communication, where possible supported by a picture.
121
Description - A written description of the user story
for planning purposes and as a reminder
Conversation - A section for capturing further
information about the user story and details of any
conversations
Confirmation - A section to convey what tests will be
carried out to confirm the user story is complete and
working as expected
122
As a [user role] I want to [goal]
so I can [reason]
As a [type of user] I want to [perform some task] so
that I can [reach some goal]
Example:
As a registered user, I want to log in, so I can access
subscriber-only content.
123
Who (user role)
What (goal)
Why (reason)
gives clarity as to why a feature is useful
can influence how a feature should function
can give you ideas for other useful features
that support the user's goals
124
Steps:
Start with a title.
Add a concise description using the templates.
Add other relevant notes, specifications, or sketches
Before building software write acceptance criteria (how do weknow when we’re done?)
127
Detailed enough
For the team to start working from
To establish further details and clarifications
at the time of development.
128
Independent – User Stories should be as independent as possible.
Negotiable – a User Story is not a contract. It is not a detailed
specification. It is a reminder of features for the team to discuss
and collaborate to clarify the details near the time of development.
Valuable – User Stories should be valuable to the user (or owner) of
the solution. They should be written in user language. They should
be features, not tasks.
Estimatable – User Stories need to be possible to estimate. They
need to provide enough information to estimate, without being too
detailed.
Small – User Stories should be small. Not too small and not too big.
Testable – User Stories need to be worded in a way that is testable,
i.e. not too subjective and to provide clear details of how the User
Story will be tested.
129
Agile customers or product
owner prioritize stories in a
backlog
A collection of stories for a
software product is referred toas the product backlog
The backlog is prioritized so
that the most valuable items
have the highest priorities
130
User Story Mapping is an approach to Organize and
Prioritize user stories
Unlike typical user story backlogs, Story Maps:
make the workflow or value chain visible
show the relationships of larger stories to their child
stories
help confirm the completeness of your backlog
provide a useful context for prioritization
plan releases in complete and valuable slices of
functionality.
131
Spatial arrangement:
By arranging activity and task-centric story cards spatially,
we can identify bigger stories
Arrange activities left to right in the order you’d explain
them to someone when asked the question: “What do
people do with this system?”
time
132
Overlap user tasks vertically if a user may do one of
several tasks at approximately the same time
If in telling the story I say the systems’ user typically
“does this or this or this, and then does that”. “or”
signal a stacking vertically, and “then” signal stepping
horizontally.
time
133
The map shows decomposition and typical flow across
the entire system.
Reading the activities across the top of the system helps
us understand end-to-end use of the system.
time
Below each activity, or large story are the child stories that make it up
134
Prioritizing based on product goal Product goals describe what outcome or benefit is received by
the organization after the product is put into use
Use product goals to identify candidate incremental releases,
where each release delivers some benefit
Create horizontal swim-lanes to group features into releases
Arrange features vertically by necessity from the user’s
perspective
Split tasks into parts that can be deferred till later releases
Use the product goals to identify slices that incrementally
realize product goals.
135
optionality
necessary
less
optional
more
optional
136
We can also use templates to write test cases for the
use stories. One tool that employs such templates is
CUCUMBER.
The template is as follows:
Scenario: a short description of the test scenario
Given: test preconditions
When: test action – input
Then: test result – output
And: can be used to include more than one
precondition, input or output.
137
Scenario: memory BIT
When: we have inserted a memory fault
And: run a memory BIT
Then: the memory fault flag should be set
And: the system should move to the error state
138
User Stories combine written and verbal communications,
supported with a picture where possible.
User Stories should describe features that are of value to the
user, written in the user’s language.
User Stories detail just enough information and no more.
Details are deferred and captured through collaboration
just in time for development.
Test cases should be written before development, when the
User Story is written.
User Stories should be Independent, Negotiable, Valuable,
Estimatable, Small and Testable.
139
140