Download as PDF, PPTX
Uploaded bySTX Next
What scrum masters and product owners should know about software quality and technical debt.
The document discusses technical debt in software projects. It defines technical debt as compromises in quality or maintainability that accumulate when developers take shortcuts or make quick fixes rather than implementing clean code. Technical debt comes from decisions to cut corners, such as not refactoring code or thoroughly testing features. Over time, technical debt can lead to slower development, more bugs, and heavier testing needs. The document recommends calculating technical debt through software metrics like code complexity, duplication, and test coverage. It also suggests effective ways to manage technical debt in agile projects, such as creating a technical debt backlog, educating stakeholders, automating tests, and conducting retrospectives to improve practices and prevent accumulating further debt. Regularly paying down
More Related Content
Similar to What scrum masters and product owners should know about software quality and technical debt.
What scrum masters and product owners should know about software quality and technical debt.
- 1. What scrum masters andproduct owners should know about software quality and technical debt. [email protected]
- 2. AGENDA 45 MINUTES ABOUT 1.What is Technical Debt and where does it come from? 2. What would I need to do in order to calculate technical debt for a software project? 3. How much technical debt is too much technical debt? 4. What are the most effective ways to manage technical debt in a software project (agile approach)?
- 3. What is Technical Debtand where does it come from?
- 4. planning daily stand-ups releasetoPROD restart featurefreeze regression tests feature request FEATUREREQUEST quick & dirty solution clean & smart solution
- 5. ILLUSION OF “everythingis ok” “we will refactor it later” “there is no time for testing” SPRINT 12SPRINT 10 SPRINT 11 quick & dirty solution
- 6. CARRYING OVER TECH.DEBT quick & dirty solution “we will refactor it later” quick & dirty solution “we will refactor it later” “there is no time for testing” SPRINT 12SPRINT 10 SPRINT 11 quick & dirty solution
- 7. What is TECHNICALDEBT? Technical debt is the difference between what was promised and what was actually delivered. Tom Poppendieck defines technical debt as everything that makes your code harder to change. Consequence of cutting corners throughout software development. Technical Debt are all of those things you choose not to do now and after some time you still leave them undone. Figure 1: Technical debt grid quadrant http://martinfowler.com/bliki/TechnicalDebtQuadrant.html lekkomyślny brawurowy rozważny roztropny nieumyślny celowy
- 8. Classifying technical debt Figure1: Technical debt grid quadrant http://martinfowler.com/bliki/TechnicalDebtQuadrant.html Entry into a new market – first to market may mean that lower quality or features with more workarounds might be acceptable. This is a natural occurrence. Teams would like to improve upon whatever has been done after gaining experience and relevant knowledge. This happens typically to programmers who are incompetent and unaware of the implications of adding/removing a piece of code, thus incurring a huge technical debt. Pushing the project through because the client wants it on a set date, and no one has built a relationship with the client to discuss the details, nor has the client been informed of the effect on quality if the delivery is rushed.
- 9. TIME REVEALS THETRUTH “we will refactor it later” quick & dirty solution “there is no time for testing” SPRINT 12SPRINT 10 SPRINT 11 quick & dirty solution “we will refactor it later” few months quick & dirty solution SPRINT 31 more bugs unreadable code code duplication slower development postponed releases heavy manual testing
- 10. What would Ineed to do in order to calculate technical debt for a software project? You cannot improve what you don’t measure. What you don’t measure, you cannot prove.
- 11.
- 12. SOFTWARE METRICS CODE COMPLEXITY ● Indicatorof where the logic is stored and how the logic is distributed. ● Files with high value of Mcc most of the time are responsible for too many things at the same time. Refactoring of such files can be reflected in more granular logic distribution in project.
- 13. SOFTWARE METRICS NESTED CODE ● Codein deep nesting levels is very difficult to understand. ● Developers spend overly much time “thinking and searching” before they modify it. ● Higher risk of introducing changes. ● Nearly impossible to be tested completely.
- 14. SOFTWARE METRICS CODE LEFTOVERS ● Codeis only commented not deleted. ● An indicator that developers are unsure about their code changes. ● Understanding mixed real-and-commented code is slow, because the commented code is probably relevant and also needs to be understood.
- 15. How much technical debtis too much technical debt?
- 18.
- 19.
- 20.
- 21.
- 22. File detailed viewwith issue explanation
- 23.
- 25. Monitoring & steeringdashboard
- 26.
- 27.
- 28. What are themost effective ways to manage technical debt in a software project (agile approach)?
- 29. managing technical debt DEBT backlog makeup stories(chores) technical retrospective build relationship on transparency make risk prominent, use numbers educate on true cost of technical debt test often automate tests invest in CI strong DOD build awareness at the management level of the hidden cost behind the quality cleanup releases / warranty phase inspect & adapt software development cycle agile >> scrum just make it work for you inject best practices build quality culture encourage knowledge sharing
- 30.
- 31. TECHNICAL DEBT IS #1IMPEDIMENT FOR TEAMS TO BE AGILE