Recognizing Software Debt - Beyond Agile Puget Sound
-
Upload
chris-sterling -
Category
Technology
-
view
7.272 -
download
0
description
Transcript of Recognizing Software Debt - Beyond Agile Puget Sound
Recognizing So+ware Debt
Wednesday, November 30, 2011
Chris Sterling
Co-‐founder of Agile Advantage and VP of Engineering (www.AgileAdvantage.com)
Author of Book “Managing SoAware Debt: Building for Inevitable Change”
Consults on soAware technology, Agile technical pracKces, Scrum, and effecKve management techniques
CerKfied Scrum Trainer
InnovaKon Games® Trained Facilitator
Open Source Developer
2
Email: [email protected] Web: h3p://www.agileadvantage.comFollow me on Twi0er: @csterwaBlog: h3p://www.ge8ngagile.comHashtag for presenta:on: #swdebt
Wednesday, November 30, 2011
Go to ImpedimentMonkey.com!!!
3
Send an email to [email protected] to get invited with your first impediment now!!!
Wednesday, November 30, 2011
Agenda
Managing SoAware Debt• An OverviewTypes of SoAware Debt• Technical• Quality• ConfiguraKon Management
• Design• PlaUorm Experience
Balancing Signal to Noise• DefiniKon of Done• Source Control Management
• ConKnuous IntegraKon• Quality DashboardsRelease Management• The Power of 2 Scripts: Deploy and Rollback
• ConKnuous IntegraKon• Automated PromoKon
• Turn On/Off FeaturesExercise• SoAware Debt Management Strategy
4
Wednesday, November 30, 2011
Managing So+ware Debt
An Overview
Wednesday, November 30, 2011
THE DISECONOMIES OF SCALE IN SOFTWARE DEVELOPMENT*
* “SoIware Es:ma:on: Demys:fying the Black Art “ – Steve McConnell
Project size is easily the most significant determinant of effort, cost and schedule [for a soIware project].
Wednesday, November 30, 2011
“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-‐tape-‐and-‐baling-‐wire, spagheZ-‐code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Informa:on is shared promiscuously among distant elements of the system, oIen to the point where nearly all the important informa:on becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recogni:on. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the iner:a of the day-‐to-‐day chore of patching the holes in these failing dikes, are content to work on such systems.” *
Big Ball of Mud
* Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Pa0erns Languages of Programs (PLoP '97/EuroPLoP '97) Mon:cello, Illinois, September 1997
Wednesday, November 30, 2011
Wednesday, November 30, 2011
Lack of emphasis on so'ware quality a2ributes contributes to decay
Wednesday, November 30, 2011
Types of So+ware Debt
Wednesday, November 30, 2011
Technical debt tended to focus more on programming aspects of soIware delivery and leI out full soIware development life cycle
Each type of soIware debt can be managed and monitored using different tools and approaches
Focusing on managing each type of soIware debt simplifies crea:on of an overall strategy that promotes holis:c perspec:ve
Why not just call it all “Technical Debt”
11
Wednesday, November 30, 2011
Types of SoIware Debt
Technical Debt: These are the ac:vi:es that a team or team members do not to do well now that will impede future development if leI as is.
Quality Debt: There is a diminishing ability to verify the func:onal and technical quality of soIware: the “Break/Fix” mentality.
ConfiguraHon Management Debt: Integra:on and release management become more risky, complex, and error-‐prone.
Design Debt: The cost of adding features is increasing toward the point where it is more than the cost of wri:ng from scratch.
PlaJorm Experience Debt: The availability and alignment of people to business objec:ves that involve soIware changes is becoming more limited or cost-‐prohibi:ve.
8
Wednesday, November 30, 2011
Principle: No maOer what, the cost of addressing so+ware debt increases
with Hme.
Wednesday, November 30, 2011
Balancing Signal to Noise at Scale
Wednesday, November 30, 2011
Balancing Signal Indicators
Value
Quality Constraints(Schedule, Cost, Scope)Source: Jim Highsmith
15
Wednesday, November 30, 2011
DefiniMon of Done -‐ Assert QualityAcceptance defined criteria for each user story
Unit tests written and passed
Code compiles with no errors and no warnings
New code doesn’t break existing code
Test case review (Dev to review test case written)
Architectural impact assessed and artifacts updated if necessary
Comments in code
Error codes added
Code reviewed by peer
Code checked in with reference to US#/Task#
Tested on FE
Integration test written & passes
Test code reviewed
Environment requirements documented
Interface document updated/added and checked in to SVN
Acceptance criteria verified complete
All P1-P3 bugs for the story are closed
Test approves user story
Story demonstrated to product owner and accepted on Target Platform
16
Wednesday, November 30, 2011
Release DefiniMon of Done
Every release should have clear quality criteria
With a “Release Defini:on of Done” you can understand targets be0er
Measure the gap between the teams’ Defini:on of Done and a Release Defini:on of Done.• This gap is a source of quality issues and represents significant risk to schedule
Wednesday, November 30, 2011
Release DefiniMon of Done
Every release should have clear quality criteria
With a “Release Defini:on of Done” you can understand targets be0er
Measure the gap between the teams’ Defini:on of Done and a Release Defini:on of Done.• This gap is a source of quality issues and represents significant risk to schedule
Wednesday, November 30, 2011
TradiMonal Source Control Management
18
Wednesday, November 30, 2011
TradiMonal Source Control Management
18
Main Branch
Wednesday, November 30, 2011
TradiMonal Source Control Management
18
Main Branch
Version 1Branch
Integrate forVersion 2
CodeComplete
Wednesday, November 30, 2011
TradiMonal Source Control Management
18
Main BranchDebt
Death March
Version 1Branch
Integrate forVersion 2
CodeComplete
Wednesday, November 30, 2011
TradiMonal Source Control Management
18
Main BranchDebt
Death March {Debt accrues quickly within stabilizaHon periods
Version 1Branch
Integrate forVersion 2
CodeComplete
Wednesday, November 30, 2011
Flexible Source Control Management
19
Wednesday, November 30, 2011
Flexible Source Control Management
19
Main Branch
Wednesday, November 30, 2011
Flexible Source Control Management
19
Main Branch
Version 1
Wednesday, November 30, 2011
Flexible Source Control Management
19
Main Branch
Version 1 Version 2
Wednesday, November 30, 2011
Flexible Source Control Management
19
Main Branch
Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.
Wednesday, November 30, 2011
ConMnuous IntegraMon
20
Wednesday, November 30, 2011
21
Quality Dashboard -‐ Sonar
Wednesday, November 30, 2011
22
Quality Dashboard -‐ Sonar
Wednesday, November 30, 2011
23
Quality Dashboard -‐ Sonar
Wednesday, November 30, 2011
24
Quality Dashboard -‐ Sonar
Wednesday, November 30, 2011
Early Warning Signs
25
Early Warnings:•Broken Builds•Broken Automated Tests•Broken Custom Thresholds
Wednesday, November 30, 2011
26
Early Warnings:•Design Debt in Duplica:on (DRY)•Technical Debt in Code Complexity•Quality Debt in Bug DB (Break/Fix)•Other Custom Thresholds
Early Warning on Quality Dashboard
Wednesday, November 30, 2011
Release Management Strategy
Wednesday, November 30, 2011
“If releases are like giving birth, then you must be doing something wrong.”
-‐ Robert Benefield
Wednesday, November 30, 2011
Case Study: Enterprise Agile AdopMon
180+ person “Web 2.0” product organiza:on
Waterfall SDLC that development uses to deliver in 6 month release cycles
Want to use Agile methods to be more responsive to users and keep up with other “Web 2.0” companies
Transi:oned to Agile methods on 15 teams in 3 months
Changed release management strategy, added XP technical prac:ces, and implemented Scrum product development framework for scaled coordina:on
Able to release every week to users within 4 months
Used streamlined deployment environment process to validate product changes daily using Con:nuous Integra:on and automated promo:ons
29
Wednesday, November 30, 2011
The Power of 2 Scripts: Deploy & Rollback
30
Wednesday, November 30, 2011
Scaling ConMnuous IntegraMon
31
ComponentValidaHon
Integrated ComponentValidaHon
End-‐to-‐End &Load/Stress
Wednesday, November 30, 2011
Automated PromoMon to Environments
32
Wednesday, November 30, 2011
29
The value of technical aspects in an applica:on or its surrounding infrastructure
is the cost of not addressing them.
Wednesday, November 30, 2011
30
Describe as Abuse User Stories
Implement Securityfor User Information
* From “User Stories Applied” presented by Mike Cohn Agile 2006
Wednesday, November 30, 2011
30
Describe as Abuse User Stories
Implement Securityfor User Information
As a Malicious Hacker I want to steal credit card information so that I can make fraudulent charges
* From “User Stories Applied” presented by Mike Cohn Agile 2006
Wednesday, November 30, 2011
Some PotenMal Abusers
• Malicious Hacker
• Mass of users
• SQL injector• Disgruntled employee
• Naïve API user• ImpaBent clicker
• Denial-‐of-‐service (DoS) aFacker• Sleazy user
31
Wednesday, November 30, 2011
SoIware Quality A0ributes Defined
32
Wednesday, November 30, 2011
SoIware Quality A0ributes Ra:ng Tool
33
Wednesday, November 30, 2011
Put SoIware Debt on Product Roadmap
34
* Image from Dean Leffingwell’s blog -‐ h0p://scalingsoIwareagility.wordpress.com/
38
Wednesday, November 30, 2011
Exercise: So+ware Debt Management Strategy
Wednesday, November 30, 2011
Thank you!
QuesHons & Answers
Wednesday, November 30, 2011
Come see us at AgileAdvantage.com
41
Wednesday, November 30, 2011