Scrum. Software Engineering and. The Waterfall model. The Waterfall model - some arguments. The Waterfall model - some arguments. Time.

Transcription

1 Software Engineering and Scrum autumn 2010 Department of Computer and Information Science Linköping University, Sweden The Waterfall model Requirements One of the first life-cycle models (Royce, 1970) Very common, very criticized 2 System Design Finish each phase before continue Program Design to next. Why is the waterfall model so criticized? Implementation Which are the problems? Can it be useful sometimes? Integration Testing System Testing Milestone and deliverable at each step. (Artifacts such as Design Acceptance Test document, Req. Specification. etc.). Maintenance I The Waterfall model - some arguments 3 Pros Simple, manageable and easy to understand Fits to common project management practices (milestones, deliverables etc.) Focus on requirements and design at beginning, save money and time at the end Can be suitable for short projects (some weeks) Can be suitable for "stable" projects, where requirements do not change Focus on documents, saves knowledge which can be reused by other people. Widely used, e.g. US Department of Defense Can be suitable for fixed-price contracts The Waterfall model - some arguments Cons Software requirements change, hard to sign-off on a SRS. Early commitment. Changes at the end, large impact. Feedback is needed to understand a phase. E.g. implementation is needed to understand some design. Difficult to estimate time and cost for the phases. Handling risks are not part of the model. Pushes the risks forward. Software "is not" developed in such a way. It evolves when problems are more understood. Little room for problem solving. 4 I I

2 Can we improve the model? 5 Do it twice? 6 Requirements System Design Program Design Iteration back to previous phase Second round, do it right. Requirements System Design Program Design The original paper is actually misunderstood! (Royce, 1970) includes Iteration of phases "Do it twice" prototype Implementation Integration Testing System Testing First round, a prototype Implementation Integration Testing System Testing Danger! E.g. a performance problem can result in a major requirements change. Very expensive rollback... I Acceptance Test Maintenance Input to the phases in the second round I Acceptance Test Maintenance Is overlapping phases a solution? 7 Is overlapping phases a solution? 8 When do we "sign-off", e.g. when do we have all requirements? What kind of structure have we actually achieved? No sign-off. How does this help us? requirements What if a major design flaw is discovered at the testing phase? requirements design implementation Release! design implementation Release! test test deployment I I

3 What should be built? 9 Iterative Development 10 The hardest single part of building a software system is deciding precisely what to build (Frederick P. Brooks) When should the releases take place? -boxing - The time period is fixed for each iteration. What should be included in the release? Prioritized functionality - Do the most important parts first. Customer Feedback Customer Feedback How? By delivering several releases? R1 R2 Final Release! design implementation Release! design implementation test deployment Iteration 1 Iteration 2 test Iteration deployment 3 I I We are using an iterative process! 11 Agile Approaches - Agile Alliance 12 Define a plan with 1..N iterations. We do not have to care about plans... Now, let's hack! Harry the hacker Lightweight approaches to satisfy the customers with "early and continuous delivery of valuable software" Is this a good iterative process? Methodologies and defined Process frameworks Of course not. We need some structure! Manifesto for Agile Software development Favor Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan ( 2001) I I

4 Scrum 13 Scrum Overview 14 Approach public in 1995 at OOPSLA "Scrum" strategy used in rugby for getting and out-of-play ball back into play. I I The Sprint (1) 15 The Team 16 An iteration -boxed 30 days or less No time between sprints 40 hours week Open and visible Cross functional No titles Self-organized 7 plus/minus two Develops, tests, documents etc. in iterations = sprints I I

5 Product Owner 17 Scrum Master 18 One and only one person Prioritize and manage the product backlog Manage ROI The customer interface The product owner may not act as a project manager tell when and what something should be done Make sure the scrum team adheres Scrum values, practices and rules Run meetings Protects the team from disturbance Collects and removes obstacles (Impediment list) The scrum master may not Mange the scrum team - the scrum team is self-organized Scrum master cannot be product owner I I Pigs and Chickens Scrum team members are pigs Everyone else is a chicken Chickens cannot tell pigs how to do their work A chicken and a pig are together when the chicken says Let s start a restaurant!. The pig thinks it over and says What would we call this restaurant? The chicken says Ham n Eggs! The pig says No thanks, I d be committed, but you d only be involved! Exercise Project leading and selforganization I I

6 Product Backlog (2) 21 Release planning meeting (3) 22 List of product backlog items (PBI) (approx. List of potential requirements) Prioritized Available Never complete Features, bug fixes, documentation, tests etc. Value (PO) and estimates (Team) PO responsible, everyone can add Initial meeting create initial backlog Short meetings, end of each sprint - Update and prioritize product backlog I I Sprint planning, Part 1, what (4) 23 Prioritization 24 Part 1 What (4) Break down top items Estimate product backlog Select PBIs for a sprint -boxed 4h Customer Value High Sweet Spot Optional: Sprint GOAL Low Low Avoid High Development Effort I I

7 Effort Estimation a good approach? 25 Planning Poker - Exercise 26 How long time does it take for you to implement the encryption layer? Sam the seller Harry the hacker No idea. I have never done this before... I wonder if it is even possible. 8 months +- 2 months Customer value estimation Talk to the customer! Effort estimation (Planning poker ) Variant of the Delphi approach Speed-up estimations Everyone participate 1. List things to be done to make my party great! 2. Prioritize the list in regards to customer value 3. Base line e.g., Cook food is 2. Relative estimation. Choices:? 0 ½ infinity 4. Effort estimation for each item - Read and discuss item (short) - Make a decision (privately) - Show cards at the same time - Highest and lowest argue - Repeat until consensus I I Sprint planning, Part 2, how Sprint Backlog(6) 27 Task Board (6) 28 Part 2 - How (5) Design Identify tasks Estimate tasks (hours) Output: Sprint backlog Sprint backlog Consists of tasks Less than 2 day (preferable hours) Not ordered Task Board Not defined by Scrum Use non high-tech Example of columns PBI Todo In Process To Verify Done I I

8 Sample Task Board 29 Done 30 When are we done? No more remaining work Includes testing, documentation etc. Possible to ship after each sprint Everybody understand what done means Tools to support done Version handling (SCM) Automated build Automated tests (Continuous integration) I I Burn-down Chart 31 Daily Scrum 32 Burn-down chart Only track hours remaining, not hours worked X hours remaining Y days Remove meeting time, vacation etc. from total available hours Update only when PBIs are DONE Slope the team velocity. When not done Undone PBIs Stand-up meeting runs the meeting Every morning -boxed 15min 1 minute each person Do NOT solve problems! Chickens are not allowed to talk Questions What did you do yesterday? What will you do today? What impediments stand in your way? I I

9 33 Impediment List 34 Exercise Daily Scrum - Theater List of obstacles Scrum Master s backlog Daily update Open, visible and honest I I Sprint review (9) 35 Sprint retrospective (10) 36 -boxed 4h End of sprint + Scrum Master + Product owner (potentially also customer) Informal meeting what has been done Demonstrate no power points Show working functionality get feedback 3h, time-boxed Inspect the last sprint, regarding People Relationships Processes Tools How to make things better process improvements What was good? What was not so good? How can we improve? I I

10 37 Thanks for listening! I