Software Processes. With a focus on Agile/Scrum CPSC310 Software Engineering

Transcription

1 Software Processes With a focus on Agile/Scrum CPSC310 Software Engineering

2 Learning Goals

3 Why do software projects fail? Unrealistic project goals Inaccurate estimates of needed resources Unmanaged risks Poor communication so many reasons!!!

4 When things go wrong Denver Baggage (mis)handling detailed report:

5 Denver Baggage (mis)handling summary: Underestimation of complexity. Complex architecture. Changes in requirements. Underestimation of schedule and budget. Dismissal of advice from experts. Failure to build in backup or recovery process to handle situations in which part of the system failed. The tendency of the system to enjoy eating people s baggage.

6 The Beginning risk flagged; ignored. scale changed risks flagged; ignored hasty contract requirements change requirements change guru dies

7 The End requirements change delays technical challenges more delays BAE blames the user manual system used instead BAE fined for overtime done! but badly scrapped

8 So what happened? bad planning: They left it late! The software production started only 17 months before the scheduled opening In Munich, engineers spent two years testing a similar but much smaller system. And even that system is not glitch free (nothing ever is - but at least it s 24/7 operational) physical problems: Most buildings were built before the baggage system was designed, meaning the baggage system had to adapt to an architecture that wasn t a good fit (sharp turns, narrow corridors) change of management: Death of the driving force of the project (you d think this was atypical, but gurus often leave a company mid-way through a project, leaving the project somewhat stranded if planning isn t good) accepting changing requirements: alterations to baggage sizes, types, paths, etc and the contractor said a firm yes to all these changes! lack of experience: this was the first time BAE had built a system like this. But for some reason they didn t choose to ask for outside advice from the Munich baggage system engineers who might have provided insights and helped mitigate risk.

9 Software Project Risks 6 dimensions of risks: USER: resistance to change; conflicts between them; negative attitudes towards the project; lack of commitment; lack of cooperation REQUIREMENTS: continually changing; inadequately identified; unclear; incorrect PROJECT COMPLEXITY: new technology; high technical complexity; immature technology; first use of technology PLANNING & CONTROL: poor process oversight; inadequate estimation resources; poor planning; unclear milestones; inexperienced pm s; ineffective communication TEAM: lack of experience; lack of training; lack of specialised skill ORGANISATIONAL ENVIRONMENT: change of management during the project; unstable organisation; ongoing restructuring

10 Projects need a good plan

11 Software Process Processes have descriptions that discuss Products (the outcome of a process activity) Stakeholders (people who care about the outcome) (managers, developers, customers, testers) what are some major types of software customers?

12 Software process Many different software process All include: requirements elicitation architectural design detailed design implementation integration testing the goal for each of these activities is to: - mark out a clear set of steps - produce tangible item(s) - allow for review of work - specify actions to perform next

13 Is Process Worth It? Process Phobic Team Process-Oriented Team When a project has paid too little early attention to the processes it will use, by the end of a project developers feel they are spending all of their time in meetings and correcting defects and little or no time extending the software. During the first few weeks of the project, the process-oriented team will seem less productive than the process-phobic team By the end of the project, the process-oriented team will be operating at a high-speed hum, with little thrashing, and performing its processes with little conscious effort.

14 Software Process Models Some models are better for some types of projects than others. Often models are combined to build a tailored process for building a certain type of product. Project leads need to be able to choose and tailor a model and assess risk Developers need to understand processes and work within them

15 Waterfall Model (this picture looks old, because this process is old!) Royce, AKA: Big Design Up Front

16 Benefits: Waterfall Model AKA: Big Design Up Front

17 Drawbacks: Waterfall Model AKA: Big Design Up Front

18 Spiral Model talk to customer features to add feedback on current version risks/problems identified ($$$) (time needed) Ultimate Reqt's Spec Boehm B, "A Spiral Model of Software Development and Enhancement",! ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986

19 Spiral Model Benefits:! Manages risk by repeated prototyping Requirements changes incorporated iteratively Drawbacks:! High administrative overhead Can be overly conservative if you have high confidence in the project outcome

20 Agile Models/Principles Application

21 What is agility? Adapt to change Particularly changes in requirements Use frequent, short iterations to flatten cost curve Focus on working software What works is how success is measured Process based on collaboration Heavy customer involvement A sustainable process Find a cadence that delivers reliably

22 Flavours of Agile extreme Programming communication stand-up simplicity meetings feedback courage

23 Values of XP Five principal values: Communication: common metaphors, frequent verbal communication, customer involvement Simplicity: do the simplest thing that could possibly work, then refactor Feedback: from the code (unit tests), the customer (colocation), the team (planning game) Courage: be willing to throw things away Respect: don't do things that make work for others

24

25 XP Practices Pair programming Test-driven development Continuous integration Shared metaphor Small releases Planning game

26 Test-Driven Development Test cases are written first Cover new functionality or improvement Then the necessary function is implemented Code is complete when all tests pass Refactor before adding feature if design could be better

27 Let s think What are some advantages of TDD?! What are some disadvantages of TDD?

28 Other flavour of Agile: Scrum Management framework for incremental, overlapping, product development! Self-organizing, cross-functional teams Product progresses in a series of two- to four-week (fixed length) iterations: sprints Every iteration produces a potentially shippable (properly tested but not complete) product Requirements are captured as items in a list: the product backlog No specific engineering practices prescribed (unlike XP) e.g. unit testing, refactoring, code standards, etc

29 Sequential versus Overlapping Dev. Requirements Design Code Test

30 Scrum Framework Roles : Product Owner, Scrum Master, Team Artifacts : Product Backlog, Sprint Backlog Burndown Chart Ceremonies : Sprint Planning, Daily Scrum Meeting, Sprint Review

31 Scrum Timeline

32 Scrum Roles Roles : Artifacts : Product Owner, Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning, Daily Scrum Meeting, Sprint Review Product Owner! Defines features of the product Prioritizes features according to market value Adjust features and priorities every iteration, as needed Scrum Master! Team! Facilitates Scrum process Helps resolve impediments Shields team from external interferences NOT the manager Self-organizing, self-managing, cross-functional Developers, designers, managers, clients, etc 7 (+/- 2) people

33 Scrum Artifacts Roles : Artifacts : Product Owner, Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning, Daily Scrum Meeting, Sprint Review Product Backlog! prioritized list of backlog items (PBIs) PBIs specify a customer-centric feature (User Story form) effort estimated by Team, priority estimated by Product Owner Sprint Backlog! contains list of engineering tasks that are negotiated by team and product owner from the Product Backlog negotiated PBIs broken down into specific tasks Burndown Chart! Total remaining team task hours within one sprint

34 Sprint Backlog Roles : Artifacts : Product Owner, Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog! Burndown Chart Sprint Planning, Daily Scrum Meeting, Sprint Review Sprint Backlog! contains list of engineering tasks that are negotiated by team and product owner from the Product Backlog negotiated PBIs broken down into specific tasks List of tasks Scrum team commits to for sprint Based on priorities and team s perception of required time (normally between 4 and 16 hours) Tasks in Sprint Backlog represent developer s (technical) perspective, not customer perspective

35 Sprint Backlog Roles : Artifacts : Sprint Backlog! Weather App Backlog Items:! PBI: As a subscriber, I want contains to see a list 10-day of engineering forecast tasks that of conditions so that I can are plan negotiated least a week by team ahead and product Tasks: owner from the Product Backlog Parse the weather data in day packets negotiated PBIs broken down into Push several days data to the client specific tasks Product Owner, Scrum Master, Team Product! Backlog, Ceremonies : PBI: As a subscriber, I want List to of see tasks precipitation Scrum team commits to accumulations and forecast for so sprint that I can plan my activities. Tasks: Based on priorities and team s Parse snow/rain data perception from the of provider s required data time (normally Push the snow/rain between data to the 4 and client 16 hours) Redesign client screen Tasks for in Sprint new data Backlog represent Refactor the server code developer s (technical) perspective, not customer perspective Sprint Backlog! Burndown Chart Sprint Planning, Daily Scrum Meeting, Sprint Review

36 Sprint Burndown Chart Roles : Product Owner, Scrum Master, Artifacts : Team Ceremonies : Product Backlog, Sprint Backlog! Burndown Chart! Remaining Effort in Hours Progress /3/02 5/8/02 5/10/02 5/14/02 5/17/02 5/22/02 5/24/02 5/29/02 5/31/02 Sprint Planning, Date Daily Scrum Meeting, Sprint Review

37 Scrum Ceremonies Roles : Product Owner, Scrum Master, Sprint: A 2-4 week iteration, during which features are added Team Artifacts : Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Changes should not be made to requirements during the sprint Each Sprint begins with the Daily Scrum Meeting Sprint Planning! Daily Scrum Meeting, Sprint Review

38 Scrum Ceremonies Roles : Artifacts : Product Owner, Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning Daily Scrum Meeting! Sprint Review Parameters! Daily 15-minutes Stand-up Not for problem solving Three questions:! 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? Task estimates may need to be adjusted Everyone is invited Help avoid other unnecessary meetings But only team members should talk

39 Scrum Ceremonies Roles : Product Owner, Artifacts : Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning Daily Scrum Meeting! Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to track the progress of the Team Sprint Review

40 Scrum Ceremonies Roles : Parameters! Q: What might these people be doing with Product Owner, the colored Daily pieces of paper? Scrum Master, 15-minutes Artifacts : Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning Daily Scrum Meeting! Sprint Review Stand-up Not for problem solving Three questions:! 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? Task estimates may need to be adjusted Everyone is invited Help avoid other unnecessary meetings But only team members should talk

41 Scrum Ceremonies Roles : Artifacts : Product Owner, Scrum Master, Team Product Backlog, Ceremonies : Sprint Backlog Burndown Chart Sprint Planning Daily Scrum Meeting Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule As in the Daily Scrum, everyone is invited Sprint Review

42 There are other flavours of Agile Feature Driven Development (FDD)

43 Summary