Download - Bug first Zero Defect
Bugs first, even before new Features?
orZero Defect
1
What is “Bugs first”?
Alternative one: Fix bugs immediately
“Fix all bugs before starting next user story.”
Sprint: “User story can be closed only when all bugs have been fixed.”
Kanban: “Work in progress (WIP) can only be closed when all bugs have been fixed.”
Alternative two: Fix bugs in sprint
“No bugs at end of sprint.”
“No bugs as done-done criteria.”
2Oliver Schreck
Potentially shippable product
3Oliver Schreck
Why?
Bug-free, stable software makes a tremendous impression, especially when
you demonstrate intermediate versions.
Closer to full product quality in each sprint
Higher Product quality
4Oliver Schreck
Why?
Each unsolved bug is a piece of work that need to be done “later”
Reducing bugs leads to less “later work”
The need of stabilization sprints after “end of development” decrease
Velocity measurements become more true
In sum: Release planning becomes much more reliable!
Higher predictability
5Oliver Schreck
Finding Bugs early
6Oliver Schreck
Finding Bugs early
7Oliver Schreck
Zero Defect
Maintain the software at highest quality during the development
Improving quality actually reduces development time
Programmer writes between eight and twenty lines of code a day;
the rest of the day is usually spent on debugging
Studies done at e.g. NASA, IBM, have shown that better QA leads to shorter schedules.
An IBM study concluded that software projects that make quality a top priority typically have the shortest schedules, the highest productivity, and even the best sales.
8Oliver Schreck
9Oliver Schreck
10Oliver Schreck
11Oliver Schreck
12Oliver Schreck
13Oliver Schreck
14Oliver Schreck
15Oliver Schreck
16Oliver Schreck
Ten basic rules – (1-5) Test your product every day as you develop it, and fix defects as soon as you find them.
Gated checkin, 20 minute build, Daily Build
Once you find a defect, fixing it becomes your number one priority, and you avoid writing any new code until the defect is 100% eliminated.
Review your code regularly.
Code inspections are far more effective than testing
Code reading detected almost twice as many defects per hour as testing
Rewrite poor-quality modules.
Typically you find that 20% of your routines are responsible for 80% of your errors
Assume full responsibility for every bug.
95% of all software defects are caused by the programmer. Only 1% of defects are hardware errors, and the remaining 4% are caused by the compiler, the OS, or other software
Never dismiss a potential bug; find out the exact cause of any anomaly, especially if irregular
Handle change effectively.
Carefully consider how each change will impact your pre-existing code. Poor integration of unanticipated features is a major cause of defects
17Oliver Schreck
Ten basic rules – (6-10) Rewrite all prototyping code from scratch.
Rapidly prototyped features that slip into the final product are a major source of bugs because they are not subject to the samequality standards as the rest of the code.
Set QA objectives at the beginning of every project.
Set QA goals, e.g. performance, quality standards, coding guidelines
Don't rush debugging work.
50% of all bug fixes are done incorrectly the first time, often introducing new bugs in the process.
Take the time to understand the source of the bug.
Write UT first to verify your correction.
Treat the quality of your code at the same level of importance as the quality of your product.
Rate your code on a scale of one to ten for overall quality.
Are you sure that it is above 8, if not rewrite it.
Learn from every bug; each one represents a mistake that you made.
Learn why you made each mistake
Adopt simple coding conventions to avoid common bugs, e.g. initialize each variable, release memory, try/catch, comment your code
18Oliver Schreck
Accumulation of “Undone”
19Oliver Schreck
preparation development
Undone UndoneUndone
Stabilization Iterations
Planned Release
Actual Release
Undone
Unknown amount of undone work !
(Ken Schwaber)
Open Bugs Compared Waterfall compared to “Bugs First”
20Oliver Schreck
Why? - Faster Learning
Fast feedback enables fast learning
Improve coding practices
Improve system knowledge
Improve domain knowledge
Additional bugs can be avoided
21Oliver Schreck
Why? - Less total effort
The earlier a bug is fixed, the less is the administrative cost
Fix bugs as long as the code is still fresh in mind – is faster
Fix bugs before the code has developed further – is easier
A lot of time can be saved in system integration and test – expensive test environments
can be better used
Each sprint provides a stable platform for the next one
22Oliver Schreck
If you see a problem fix it!
23Oliver Schreck
Questions?
If (unclear == true) then askme();
Oliver Schreck