adopting agile
DESCRIPTION
These slides quickly illustrate how you can successfully adopt Agile to improve your development efforts. In addition to discussing how and why teams are interested in Agile, it covers some of the challenges of adopting it and suggestions for ensuring success.TRANSCRIPT
Adopting AgileEnsuring Success
Copyright 2013 Coverity, Inc.
2
More. Better. Faster.• Customers demand new, innovative features
• And quickly
• Features are often implemented in software• Size of software projects is exploding
• And often includes third-party/open-source code
• Security and stability cannot be compromised
Today’s Reality
In other words: software organizations must provide
more, with excellent quality, security, and stability, using
reliably less time
3
A popular way to address these challenges
Many organizations are adopting practices commonly associated with Agile:
• Development via rapid iteration over bite-sized, self-contained work units rather than large process phases
• Automated testing: unit, regression, etc.
• Continuous integration builds
• In some cases, even continuous delivery
Agile
4
Business Benefits:
• More easily manage change
• Better align IT and business objectives
• Accelerate time to market
Development Benefits:
• Visibility: Discover problems sooner
• Efficiency: Fix problems more quickly and easily
• Predictability: Avoid late-stage schedule disruptions
Why Agile?
5
Theme: Avoid large backlogs; get early feedback• Test code as it is written, minimizing significant last-
minute disruptions
Practice/Benefit
Shorten Cycles, Distribute the Load
►Split development cycle into bite-sized sprintsImprove responsiveness, predictability
►Developers code, test, designAll team members are experts with the code; improve efficiency
►Use small, fast, automated tests like unit testsGet early feedback about whether the code is working properly
►Routinely integrate, build, test code changesGet early feedback about whether the product is in a working state
6
Adopting AgileWe need to go Agile—it will
solve our development
problems!
We can’t put the business on hold to rebuild
R&D, Bob!
7
• Even with a plan and support, adopting Agile practices often encounters resistance
• Business Risk: How to maintain developer productivity while onboarding testing responsibilities?
• Culture: How to convince developers to actually write tests?
• Adoption: How to enforce adoption of the new practices?
• IT: How to manage infrastructure?
• Politics: How to assure QA that their jobs are safe?
• Governance: How to manage the transition to ensure it is successful?
It’s Not Always Easy
8
Justifying Agile
We don’t have to! We’ll ease in,
starting with our new code and new projects.
We can’t put the
business on
hold…
9
• Business Risk (productivity with new testing requirements)
• Ease into Agile, e.g. focus on new code/projects first
• It’s not all-or-nothing, so plan a transition
• Culture (developers must write tests)• Enforce testing standards for important/high-risk code
• Phased deployment convinces skeptics and provides escape hatch
• Adoption (new practices stick)
• Automate enforcement as part of standard process
• Politics and Governance• Provide visibility into the new process
• Reassure stakeholders—process enables them to fulfill their mission, e.g. independently verify quality or security; not police R&D
Overcome the Resistance
10
• How do you determine if code is sufficiently tested?• It’s not practical (or possible) to automate tests for all code
• Are you testing all of the important code?
• Are you wasting effort testing unimportant code?
• How do you enforce testing of changes to legacy code?
• You need to require tests for all important code
• Without trying to boil the ocean
• How do you eliminate manual interpretation and noise?• You need to reduce adoption barriers and increase confidence
• Visibility without sufficient context is (worse than) useless
But…the Devil’s in the Details
11
Is Code Sufficiently Tested?
Sweet, safeClose() is fully tested now! I’m glad I don’t need to
test that catch block—I’m not sure I can even trigger an
IOException there.
12
dbgStub()
Partial Visibility is Worse Than Useless
Only 86% coverage for safeClose()? That untested 14% worries
me…
Why are we wasting time
testing dbgStub()?
Hey Bob, we need to
fix this!
13
• Leverage static analysis to get early feedback about common coding errors
• No need to invest time writing test cases for these issues
• It’s critical to automate, look for important problems and configure for minimal noise
• Don’t simply measure testing coverage
• Enforce a testing policy that focuses on the important/high-risk code
• Focus on certain components, modules, classes or functions
• Test all code impacted by recent changes
• No need to test debug, logging or exception-handling code
• Recognize field-tested code; consider code complexity
• Leverage SCM systems (age, author), testing artifacts, etc. to improve accuracy and automation
Let Your Tools Do the Heavy Lifting
14
Make It Easy On DevelopersJust add a
test covering line 1084 and I’m
golden. Glad I don’t need to test those
aborts!
Don’t need to be tested
15
• Automate, automate, automate
• Use a consistent workflow for all types of issues
• Generate prescriptive work items for identified problems• Automatically interpret and prescribe action
• “Here is your problem. Do this to fix it…”
• AVOID: “Does anything look wrong in this output? Don’t forget to check the build logs and the test output, too.”
• Provide easy access to all information, especially the source code and context relevant to the problem
• Automatically assign to appropriate team members for accountability
• E.g. by most recent SCM committer, or component owner
Make It Easy On Developers
16
Visibility With Context is Priceless
Awesome progress on our
improvement goals!
Development is right on schedule
17
• Measure coverage in the context of your testing policy and definition of “important” and “high-risk” code• Eliminate manual interpretation
• Measure performance against objective, meaningful standards
• All stakeholders will understand the reports
• Automate development testing in your process• Objective, meaningful assessments enable you to automate
with confidence and accurately fail the build when something is wrong
• Developers become accountable for code quality/security
• Gain visibility into pending problems and completeness
• Gain scheduling predictability
Visibility and Governance
18
Bob, you did a great job fixing
our development problems. I’m giving you a
raise!
Want to try Coverity on your code? For a free trial, visit:
www.coverity.com