Agile Project Management

Transcription

1 Object-Oriented Software Engineering Using UML, Patterns, and Java Agile Project Management

2 Outline A mountaineering example Project context Goals, client types Environment, methods, tools, methodology Different types of planning Processes in software development Defined process control model Empirical process control model Scrum 2

3 Key Decisions in an Expedition A leader must answer several key questions to create a successful expedition What mountain should be climbed? What types of tools should be used? Who should be member of the team? Does the expedition need a leader? Different answers to these questions lead to different styles: Siege style Fixed-rope Free Solo Alpine style

4 Key Decisions in a Software Project Project goals Schedule Cost Project organization Software life cycle model Tools Methods Team members and organization Influenced by Methodology 4

5 Methodology Software engineering methodology (See Software Engineering I) Collection of methods and tools for developing and managing a software system to achieve a specific goal while change occurs in a given project environment Defined by the client and current state of the development organization. Constrains the project manager (Example: Hierarchical or project-based organization) A methodology specifies for a specific project environment 1) when methods or tools should be used and when not 2) what to do when unexpected events occur. 5

6 Project Environment Participants expertise Beginner, expert, slow learner, fast learner Type of Client Domain knowledge, decision power End user access No end user available, end user participates in requirements elicitation, end user participates in usability tests Technological climate ( technology enablers ) Geographical distribution Project duration Rate of change 6

7 Client Type Domain Knowledge Decision Power High Low High Local King Client Pseudo Client Low Proxy Client No Client 7

8 End User Access Clients and end users usually do not have the same interests Clients are interested in an early delivery date as much functionality as possible low cost End users are interested in a familiar user interface an easy to learn user interface a system that supports their specific task well If the project success depends on the usability of the product, then end users should be included in the project usability tests should be conducted with the end users. 8

9 Project Environment Participants expertise Beginner, expert, slow learner, fast learner Type of Client Domain knowledge, decision power End user access No end user available, end user participates in requirements elicitation, end user participates in usability tests Technological climate ( technology enablers ) Geographical distribution Project duration Rate of change 9

10 Technological climate Depending on the requirements expressed by the client, a project may be constrained in the technological components it has to use. Examples: A project needs to improve a legacy system It deals with well-known and mature technology but the technology might be out of date A project develops a first-of-a-kind prototype based on a new technology enabler Examples: RFID, GPS Usually has to deal with preliminary versions of components and immature technology GPS in a mobile phone 10

11 Geographical Distribution Single room projects: Participants in a single room Reasons for distributed projects: Organization may have resulted from the merger Organization is a consortium, located in different geographical locations Part of the organization must be collocated with client Geographical distribution has advantages and disadvantages: Promise of low cost labor Increases the availability of skill May take advantage of different time zones Slows down communication and decision making Lowers awareness among teams Leads to loss of information between sites High communication cost. 11

12 Methodology Issues Methodologies provide general principles and strategies for selecting methods and tools in a given project environment Key questions for which methodologies provide guidance: How much involvement of the customer? How much planning? How much reuse? How much modeling before coding? How much process? How much control and monitoring? 12

13 How much Planning does a Project Manager need? Two styles of navigation [Gladwin 1964] European navigation: Current Location and Desired Location Planned Route Route Deviation and Route Correction Polynesian navigation 13

14 European Navigation (Plan-based) Planned Route Lima (Current Location) Auckland (Desired Location) Actual Route Event: Course deviation. Action: Course correction 14

15 Pros and Cons of Plan-based Thinking Plus Very useful to kick off a software project Useful also if the outcome is predictable or if no major change occurs Con: Of limited value to control the project when the outcome is unpredictable when unexpected events occur that change the project environment, tools or methods Examples of unexpected events: Appearance of new technology unknown at project start A visionary scenario turns out to be unimplementable Company is merged with another one during the project. 15

16 Polynesian Navigation (Situation-based) We need a new place for living. Let s go to Auckland Lima (Current location) Event: Birds seen Action: Follow the birds Tahiti (Empty island, great place for Living) 16

17 Situated action Context-dependent action [Suchman 1990 xxx] Selection of action depends on the type of event, the situation and the skill of the developer European Navigation is context independent Event: Course deviation in the morning Action: Course correction towards planned route Event: Course deviation in the evening Action: Course correction towards planned route Polynesian Navigation is context dependent Event: Birds seen, Context: Morning Action: Sail opposite to the direction of the birds Event: Birds seen, Context: Evening Action: Sail in the direction of the birds. 17

18 Pros and Cons of Situation-based Planning Pro: Very useful when the outcome is unpredictable Small effort during the planning phase Fast reaction to changes in the requirements Risks are minimized by short iterations Con: Real-time communication (preferable face-to-face) produces very little written documentation Key project knowledge is only in the heads of a few people 18

19 Methodology Issues Methodologies provide guidance, general principles and strategies for selecting methods and tools in a given project environment. Key questions for which methodologies provide guidance: How much involvement of the customer How much planning? How much reuse? How much modeling? How much process? How much control and monitoring? 19

20 Problems with linear Models Concept Exploration Process System Allocation Process Requirements Process Each edge describes 2 types of dependencies - Temporal dependency: must be finished before - Logical dependency: The API depends on the subsystem decomposition Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process 20

21 Waterfall Modell The Waterfall Model is a Dinosaur Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Each edge describes 2 types of dependencies Temporal dependency: must be finished before Logical dependency The API depends on the subsystem decomposition Verification & Validation Process Installation Process Operation & Support Process 21

22 red yellow green blue red blue yellow green blue 22

23 red yellow green blue red blue yellow green blue 23

24 Controlling Software Development How do we control software development? Two opinions: Through organizational maturity (Watts Humphrey) Defined process, Capability Maturity Model (CMM) Through agility (Ken Schwaber) Large parts of software development is empirical in nature; they cannot be modeled with a defined process There is a difference between defined and empirical process Result: Two models Defined process control model Empirical process control model. 24

25 Example of a Defined Process Control Model: CMM A software development process is mature if the development activities are well defined and if management has some control over the quality, budget and schedule of the project Process maturity is described with a set of maturity levels and the associated measurements (metrics) to manage the process Assumption: With increasing maturity the risk of project failure decreases CMM: Capability Maturity Model (Software Engineering Institute, SEI, Watts Humphrey 1985) 25

26 CMM levels Process maturity is described with a set of maturity levels and associated metrics to manage the process Idea: With increasing maturity the risk of failure decreases. 1. Initial Level also called ad hoc or chaotic 2. Repeatable Level Process depends on individuals ("champions") 3. Defined Level Process is institutionalized (sanctioned by management) 4. Managed Level Activities are measured and provide feedback for resource allocation (process itself does not change) 5. Optimizing Level Process allows feedback of information to change process itself 26

27 Key Process Areas To achieve a specific level of maturity, the organization must demonstrate that it addresses the key process areas for that level: There are no key process areas for Level 1 KPA Level 2: Basic software project management practice (e.g SPMP 1058) KPA Level 3: Infrastructure for single software life cycle model KPA Level 4: Quantitative understanding of process and deliverables KPA Level 5: Keep track of technology and process changes. 27

28 Pros and Cons of Process Maturity Benefits: Increased control of projects Predictability of project cost and schedule Objective evaluations of changes in techniques, tools and methodologies Predictability of the effect of a change on project cost or schedule Problems: Need to watch a lot ( Big brother, big sister ) Overhead to capture, store and analyse the required information. 28

29 Example of a Empirical Process Control Model: Scrum Original definition (from Rugby): A Scrum is a way to restart the game after an interruption, The forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them Definition used in agile Project Management: Scrum is a technique To manage and control software and product development with rapidly changing requirements Based on improved communication and maximizing cooperation. 29

30 Why Scrum? Traditional methods are like relay races Agile methods are like rugby 30

31 Practicing a Scrum Real Scrums 31

32 Testudo: Battle Formation used by the Romans 32

33 Scrum as Methodology Involvement of the customer Onsite customer Planning Checklists and incremental daily plans Reuse Checklists from previous projects Modeling Models may or may not be used Process Iterative, incremental process Control and Monitoring Daily meetings. 33

34 Overview of Scrum Scrum Master Daily Scrum meeting Potentially shippable Product Increment Adaptiert von 34

35 Scrum is a special case of issue-based modeling I1:Open Product Backlog SD.I1:Open I2:Open I3:Open Imp.I1:Open Sprint Backlog 35

36 Components of Scrum Scrum Roles Scrum Master, Scrum Team, Product Owner Scrum Activities Sprint Planning Meeting Kickoff Meeting Sprint (~~ Iteration in a Unified Process) Daily Scrum Meeting Sprint Review Meeting Scrum Artifacts Product Backlog, Sprint Backlog Burndown Charts 36

37 Managing a Software Project with Scrum Two Lists Project Backlog: Issues for the whole project Sprint Backlog: Issues for one iteration( sprint ) Four Types of Meetings Kickoff Meeting: At the beginning of a project Sprint Planning Meeting: List of prioritized features Daily Scrum: Informal status meeting, about 15 min Sprint Review Meeting: Demonstration of features to management and customer Two Activities to manage the Artifacts Establish the Project Backlog: List of requirements from stakeholders (developers, manager and customer) Establish the Sprint Backlog: List of issues to be addressed in current iteration 37

38 Scrum Artifacts Product Backlog Sprint Backlog Measuring project progress: Burn down Charts 38

39 Product Backlog Requirements for a system, expressed as a prioritized list of Backlog Items Is managed and owned by a Product Owner Spreadsheet (typically) Usually created during the Project Kickoff Meeting Can be changed and re-prioritized before each Sprint. 39

40 Estimation of Product Backlog Items Establishes team s velocity (how much effort a Team can handle in one Sprint) Units of complexity Size-category: L, M, S ( T-Shirt size ) Story points Work days/work hours Methods of estimation: Expert Review Creating a Work Breakdown Structure (WBS) Planning Poker (next week) 40

41 Sprint Backlog A subset of Product Backlog Items, which defines the work to be done in a Sprint Is created ONLY by Team members Each item has it s own status Should be updated every day. 41

42 Sprint Backlog No more then 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list Product owner is not allowed to do it. 42

43 Measuring Progress In Scrum The Scrum master is concerned about Sprint progress: How is the team doing toward meeting their Sprint goal? Release progress: Will the release be on time with the quality and functionality desired? Product progress: Are we in time for delivering the product? Visualisation of product development progress in a graphical curve 3 types of Visualisations Sprint progress: Sprint burn down chart Release progres: Release burn down chart Product progress: Product burn down chart 43

44 Burn Down Charts A burn down chart shows for the remaining estimated amount of work at a given point in time The project end date can be determined by a trend-line through the curve Deviations from the original project end date can thus be recognized and dealt with (improved risk management). X-axis: Time (in days) Y-axis: Remaining effort (in hours) 44

45 Advantage of Burn Down Charts Addresses the issue that many unexpected changes occur during project time Minimal effort to create the curve and keep it up-to-date Even less effort to look at it. 45

46 Sprint Burn Down Chart Shows on a daily basis the remaining hours needed to finish the tasks in the sprint backlog The remaining hours are based on estimates established during the spring planning meeting and revised during the daily scrum meeting Ideally the curve should be monotonically decreasing and cross the x-axis at the end of the sprint In reality, it is not at always decreasing The curve slope can even go back up. 46

47 Release Burn Down Chart Visualizes the progress towards a release X-axis: Sprints Y-axis: hours needed for the release Answers the project management question: Can the release take place at the planned milestone? 47

48 Product Burn Down Chart The big picture view of project s progress Created at the end of a sprint in the sprint review meeting Helps in the decision whether items should be removed from the product backlog to keep the original deadline. Each column shows the estimates for the work needed for the items in the product backlog, i.e., the speed of the teams emptying the product backlog. Quelle:

49 Additional Readings Watts Humphrey Managing the Software Process, Addison Wesley, 1989 A Discipline for Software Engineering, Addison Wesley, 1995 Introduction to the Personal Software Process, Addison Wesley, 1997 Introduction to the Team Software Process, Addison Wesley, 2000 Ken Schwaber and Mike Beedle Agile Software Development with Scrum, Prentice Hall, 2002 Mike Cohen Agile Estimation and Planning, Prentice Hall,

50 Summary Traditional software project management focuses on the maturity of a development process can be assessed using a process maturity model, such as the SEI s CMMI. Agile project management focuses on Empirical process control model Changing requirements are the norm Controlling conflicting interests and needs Very simple process with clearly defined rules Self-organizing teams, where each team member carries a lot of responsibility No extensive documentation Possibility for undisciplined hacking. 50