Quality in software development. Geir Amsjø

Transcription

1 Quality in software development Geir Amsjø 1

2 Dedication Three stonecutters were asked: What are you doing? Thanks to Mary Poppendieck 2

3 Can you solve this problem for me? Organization of Work Of course! a a a a blabl

4 Pull vs Push ablab la a ablab la a abl abla a abl abla Geir Amsjø Certified ScrumMaster course

5 Pull System Benefits Can you solve this problem for me? Of Course! ablab la a ablab Responsiveness Learning Cross-functional Teamwork Knowledge Sharing Improvement Responsibility Quality Throughput Efficiency Motivation Customer satisfaction

6 Problems)in)IT.systems) Omissions) Percieved)Quality) Defects' Discovered)) at)delivery) Discovered)) quite)fast) Architecture'and'design' Understandability' Maintainability Complexity' Structure' Discovered)) a)long)dme)) aeer)) handover) Geir)Amsjø,)agile42))))))))))))))The)curse)of)the)end)date) 6

7 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 7

8 Create a Learning Organization Traditional Signoff Signoff Analysis Design Develop Defined Process Control Signoff Learning opportunity Accept and Deploy Agile Feedback Visioning Feedback Feedback Timebox Timebox Timebox Timebox Empirical Process Control 8

9 Process Control vs Complexity The Cynefin Framework Empirical Process Control Defined Process Control From A Leader s Framework for Decision Making by D. Snowden & M. Boone in Harvard Business Review, NOV

10 Tradeoffs Scope Time Project attributes Quality Cost 10

11 Cost of Change CoC Real CoC Technical Debt Ideal CoC Time What may the consequences of large Technical Debt be? Sign 11

12 Fixed Date planning Will have by <date> May have by <date> Ordered by Importance Will not have by <date> 12

13 Sample Definition of Done (DoD) Code commented, checked in and tested against current version in source control Peer reviewed (or produced with pair programming) and meeting development standards Builds without errors Unit tests written and passing Deployed to system test environment and passed system tests Any build/deployment/configuration changes implemented/ documented/communicated Relevant documentation/diagrams produced and/or updated Remaining hours for task set to zero and task closed 13

14 extreme Programming Practices - XP The Planning Game - Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. Small releases - Put a simple system into production quickly, then release new versions on a very short cycle. Metaphor - Guide all development with a simple shared story of how the whole system works. Simple design - The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered. Testing - Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. Refactoring - Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. Pair programming - All production code is written with two programmers at one machine. Collective ownership - Anyone can change the code anywhere in the system at any time. Continuous integration - Integrate and build the system many times a day, every time a task is completed. 40-hour week - work no more than 40 hours a week as a rule. Never work overtime a second week in a row. Be happy and have fun. On-site customer - Include a real, live user on the team, available full-time to answer questions. Coding standards - Programmers write all code in accordance with rules emphasizing communication through the code. 14

15 Scrum Vision Product Backlog Selected Product Backlog Sprint planning part 1 & 2 Sprint Backlog Feedback Daily Scrum Sprint Burndown chart $ Sprint review & retrospective Potentially Shippable Product Increment 15

16 Agile / Scrum Values Focus Commitment Respect Courage Openness 16

17 Support tasks To Do In Progress To be Verified DONE PBI #1 Owner:` Sanjay Owner:` Sanjay PBI #2 Owner:` Sanjay PBI #3 Support Owner:` Sanjay Owner:` Sanjay What kind of issues are these? How many hours used? DONE Geir Amsjø Certified ScrumMaster course 17

18 Make sure that everybody involved share interests Create a pull system Dare to trust people Have developers and customer meet regularly Work in short iterations Enable great craftsmanship Focus on the product, not projects 18

19 Contact and information Blog (norwegian): scrummaster.no The Agile Atlas: agileatlas.org Open Courses: glasspaper.no/scrum, smidigkurs.no Coaching and training: 19