Agile Inspired Risk Mitigation Techniques for Software Development Projects

Transcription

1 Agile Inspired Risk Mitigation Techniques for Software Development Projects Presented at GTISLIG, Toronto November 15 th 2007 Michael Bica, Sogard Inc. 1

2 Roadmap I. Risks Heuristics Risks & Estimation II. Project Management vs. SDLC III. Agile Methodologies Manifesto Principles Brief Descriptions of Some Agile Methodologies IV. Risks vs. Agile Techniques V. Risks vs. Organization Types VI. Putting It All Together 2

3 A Few Questions Who is involved in software development projects? Familiarity with agile methodologies? Is there a prescribed methodology in your organization? Waterfall Rational Unified Process (RUP) Agile Other 3

4 I. Software Development Risks 4

5 What Is a Risk? Merriam-Webster Risk = Possibility of Loss or Injury This evening Risk = Any factor, situation or event that may affect the outcome of a project in a negative way 5

6 Success vs. Failure Success = project is on time, on budget and delivers all the required functionality Failure = project is late, over budget, not meeting requirements, or project has been cancelled 6

7 Heuristic Studies 7

8 Chaos Report Source - Standish Group Issued in 1995 Interviewed 365 senior managers Covered approximately 8500 projects Project outcome (resolution) types Project Succeeded completed on time, on budget, with all features as initially specified (16.2%) Project Was Challenged completed and operational, but over budget, over time estimate or did not meet initial scope (52.7%) Project Was Cancelled (31.1%) 8

9 Chaos Report - Overruns Cost & Time Overruns No Projects [%] 37.50% 35.00% 32.50% 30.00% 27.50% 25.00% 22.50% 20.00% 17.50% 15.00% 12.50% 10.00% 7.50% 5.00% 2.50% 0.00% < 20% 21 50% % % % > 400% Cost Schedule Overrun Amount [%] 9

10 Chaos Report - Success Factors User Involvement Executive Management Support Clear Statement of Requirements Proper Planning Realistic Expectations Smaller Project Milestones Competent Staff Ownership Clear Vision and Objectives Hard-working, focused staff 10

11 Chaos Report - Challenging Factors Lack of User Input Incomplete Requirements & Specifications Changing Requirements & Specifications Lack of Executive Support Technology Incompetence Lack of Resources Unrealistic Expectations Unclear Objectives Unrealistic Time Frames New Technologies 11

12 Chaos Report - Cancellation Factors Incomplete Requirements & Specifications Lack of User Involvement Lack of Resources Unrealistic Expectations Lack of Executive Support Changing Requirements & Specifications Lack of Planning Didn't Need It Any Longer Lack of IT Management Technology Illiteracy 12

13 Waltzing with Bears Tom De Marco, Timothy Lister Waltzing with Bears Managing Risks on Software Projects Core software development risks Schedule flaw Requirements inflation Specification breakdown Team Turnover Team Under-performance 13

14 Risks and Estimation 14

15 Estimation Process Estimation Types Bottom up Top down Bottom Up Done by the team Depends on team self knowledge and maturity Hard to challenge Top down Historical - works for similar projects Parametric can incorporate variance factors 15

16 Parametric Estimation Algorithm based, proprietary or public One of the best known public tools COCOMO Estimates the effort, cost, schedule and team needed to build a given software project Model first published by Barry Bohem in Software Engineering Economics, Prentice-Hall (1981) for waterfall approach The current model COCOMOII available since 2000 can estimate both waterfall and RUP 16

17 COCOMO II Inputs and Outputs Inputs SLOC single lines of code Function Points quantifying the information processing functionality associated with major external data input, output, internal file types, and external interfaces Outputs Effort Schedule Cost Team structure, size Note: See Appendix 2 for more details on Function Points 17

18 Scaling Factors Estimation algorithm uses scaling factors scaling factors to include effect of risks on project outcome Precedentness Has the team done it before (technology, business domain)? Requirements Flexibility Can development team influence requirements? Architecture Risk Resolution Has the architecture addressed all the required quality attributes (response time, capacity, availability, security)? Team Cohesion Has the team worked together before? Project Management Maturity 18

19 Scaling Factors (2 of 3) Scaling factors can be assigned 6 values: VLO, LO N H, VH, XVH The selection of scale drivers is based on the rationale that they are a significant source of exponential variation on a project s effort or productivity. Each scaling factor affects the project outcome independent of the others 19

20 Scaling Factors Influence on Effort Scaling Factors Influence on Effort Variance (%) Precedentness Dev. Flexibility Architecture Team Coehision Process Maturity VLO LO NOM HI VHI XHI 20

21 Cumulative Effect of Scaling Factors Best vs. Worst Case Scenario (%) Effort Time VLO LO NOM HI VHI XHI 21

22 Additional Factors Contributing factors to a project s schedule and effort Project outcome is affected by Product attributes Platform attributes Personnel attributes Project attributes Note: See Appendix 1 for more details on COCOMO II 22

23 II. Project Management & SDLC 23

24 Project Management vs. Engineering Process Project Management is a generic discipline, applicable to any engineering domain Different engineering processes can be managed with a common Project Management Framework (PMF) Engineering domains require different activities For example, any software development project includes some form of: a) Requirements Gathering, b) Design, c) Coding d) Testing and e) Deploying in production For software development, the engineering process has been labeled SDLC 24

25 Many SDLCs Waterfall and Rational Unified Process (RUP) are two of the best known SDLCs Newer SDLCs have been bundled under the Agile umbrella, e.g.: SCRUM Extreme Programming (XP) Feature Driven Development Lean Development All methodologies employ same activity types The SDLCs differ in the scheduling of these activities 25

26 Waterfall Requirements Gathering Analysis & Design Coding Testing Release Time Assumes: Linear development phases Predictable development activities Immutable requirements Perfectionism These assumptions are too strong, because: Requirements change Technologies change, most activities are new Teams change 26

27 Rational Unified Process (1 of 3) RUP is a process framework, focused on software development Provides a generic, flexible, iterative life cycle described by the RUP Chart: 4 phased and 9 disciplines Provides guidance in terms of Roles described in terms of competencies, responsibilities Activities to be performed during each phase Tools to be employed Artifacts to be produced 27

28 Rational Unified Process (2 of 3) RUP phases & their goals Inception determine project scope, business case Elaboration refine requirements, establish architecture, mitigate most technical risks Construction build the system up to deployment point in limited environment ( beta testing ) Transition finish product and deploy in production 28

29 Rational Unified Process (3 of 3) RUP disciplines & phases where most effort spent Business Modeling - Inception Requirements - Elaboration Analysis & Design Elaboration, Construction Implementation - Construction Test - Construction Deployment Construction, Transition Configuration & Change Management - All Project Management - All Environment - All 29

30 Iterative Development & Incremental Releases Iterations end with potentially releasable code Iterations are demonstrated to the client Iterations are feature driven May have parallel activity streams Requirements Development Testing UAT Defect fixes 30

31 Iteration Example Design ( N) Code ( N) Detail Requirements (N+1) Integrate (N) User Acceptance Testing ( N-1) Test (N) Package (N) 31

32 III. Review of Agile Methodologies 32

33 Agile Manifesto 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 That is, while there is value in the items on the right, we value the items on the left more. 33

34 Principles of the Agile Manifesto (1 of 3) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. 34

35 Principles of the Agile Manifesto (2 of 3) Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-toface conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. 35

36 Principles of the Agile Manifesto (3 of 3) Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 36

37 Pre Manifesto Agile Methodologies SCRUM Ken Schwaber Extreme Programming Kent Beck Feature Driven Development - Jeff De Luca Crystal Clear - Alistair Cockburn Adaptive Software Development Jim Highsmith DSDM DSDM Consortium Lean Development - Mary and Tom Poppendieck. 37

38 SCRUM (1 of 2) Scrum Master manages the team, interacts with project sponsor Product Backlog An evolving, prioritized queue of product features Owned by Product Owner Contains the requirements for the system or product being developed by the project Sprint a 30 day development iteration, includes all software development activities, results in executable code, potentially releaseble, which is demonstrated to the client 38

39 SCRUM (2 of 2) Sprint Goal - functionality from the Product Backlog that the team commits to implement during the Sprint Sprint Backlog - what work will have to be performed in order to reach the sprint goal (team determined) Daily Scrum 15 min. standing meeting with team members, covering What I've done yesterday, What I'm doing today, and What is holding me back Notes: Features assigned to the current Sprint are immutable Progress is measured through Effort Remaining 39

40 XP (Extreme Programming) Fine scale feedback Pair Programming Planning Game Test First Whole team Continuous process Continuous Integration Design Improvement Small Releases Shared understanding Coding Standards Collective Code Ownership Simple Design Programmer welfare Sustainable Pace 40

41 Feature Driven Development Iterative and incremental Activities: Develop overall model Assemble feature list Plan by feature Design by feature Build by feature Best Practices: Domain Object Model Develop by Feature Individual code ownership Feature teams Inspections Regular Builds Visibility of progress 41

42 Lean Development Eliminate Waste extra features, requirements churn, crossing organizational boundaries Focus on Learning Build Quality In test driven development Defer Commitment take irreversible decisions at the latest responsible moment Deliver Fast Respect People Optimize the Whole 42

43 Agile Common Denominators Activities Test driven development Light on documentation Scheduling Iterative development Time bound Feature driven Full development cycle Incremental releases Requirements No gold plating Flexibility Early feed-back Defer implementation Team Small teams Co-location Daily status reports Communication Sustainable pace 43

44 Fuzzy Issues in the Agile Domain Estimation hard to do with just-in-time requirements Architecture Poor system architecture is a risk factor Feature Driven Development, SCRUM friendly XP requires YANGTNI (you are not going to need it) Scalability Small teams are a core factor in agility Proposed team size is ~ 10 developers For larger teams scalability not known Compressed schedules - requiring extensive parallel work - increase integration risks 44

45 IV. Risks & Agile Techniques 45

46 Requirements Risks: Incomplete requirements Uncontrolled requirement changes Scope creep Techniques: Flexibility in change control (e.g. Backlog) Defer implementation - iterative development Obtain early feed-back from users 46

47 Architecture Risks: Unproven architecture Brittle architecture Inconsistent architecture Techniques: Short, time bound iterations Continuos refactoring Test driven development 47

48 Team Risks: Team has not worked together before Lack of cohesion Lack of technical skill High turnover Techniques: Small team Co-located team Daily status reports Whole team design Pair programming, code reviews Sustainable pace 48

49 Communications Risks: Poor communication between client and team Poor communication inside team Techniques: Include client representatives and users on the team Daily status updates Co-located team members Smaller teams partition project 49

50 Schedule Risk: Underestimation Techniques: High level estimates Only next iteration is precisely estimated - Rolling wave estimation in PMBOK 50

51 V. Software Development Context 51

52 SD as Core Business Software assets are core products of the organization Typical examples: Microsoft, Corel Marketing group drives the product definition they are the clients of software development teams SD teams are fairly stable, well tuned together Technologies are well understood Development is focused on adding new features to the product Risk level low to medium 52

53 SD for Business Support Software is developed to support core business processes Typical examples: banking, insurance Business departments are clients of SD teams Development is focused to meet business needs for increased agility, better operational support, regulatory Two types of projects: Maintenance fairly stable teams, well understood technologies, lower risk New technologies most of the times the organization does not have very senior people available, architecture not proven, higher risk 53

54 SD as Consulting Consulting companies are brought in to deliver turn key projects when the client does not have the resources or the technological savvy to do it internally Most projects involve new technologies Teams are assembled from pools of resources Most of the time teams are low cohesion and high technical capabilities Client constrains may force projects into sub-optimal technical decisions Risk level medium to high 54

55 Project Manager Context PM works within organization's constrains Process Resources Location Tools, infrastructure, architecture Can influence requirements Can influence or control project schedule Can influence or control the team composition Controls project execution 55

56 VI. Putting it All Together 56

57 Requirements Flexibility Assume requirements are negotiable Offer same business functionality for less Cost is a strong argument Bundle requirements in features Easier to deliver releases earlier in project life-cycle Obtain early feed-back from users on requirements Screen mock-ups Functional prototypes 57

58 Iterative Development Feature driven Time bound duration of 2-6 weeks Complete team delivers fully tested deployable code Advantages: User-feedback on the actual product is elicited sooner, thus minimizing the possibility of requirement changes later in the life cycle of the project Team performance issues are identified early in the development cycle, thus minimizing delay risks 58

59 Incremental Releases Improves the project ROI by providing business value at an earlier stage (Minimum Marketable Features) Example: 1 Release 2 Releases 4 Releases Cost $1,000, Duration 12 months Benefits 600K savings/year Incremental no yes yes ROI 1 year -$1,000, $700, $550, year -$400, $100, $50, year $200, $500, $650,

60 Test-Driven Development Develop test cases before actual code is written Mandate all development team to employ test frameworks, such as JUnit for Java (long term benefit helps with regression testing as well) Audit the test results 60

61 Team Bring senior people on the team Build team with people you have previously worked with Co-locate development team Hijack a conference room for the duration of the project Great sponsorship support (they want the room back) Very short communication paths Very efficient for team building Sustainable pace 61

62 Further Reading Boehm, Barry; R. Turner - Balancing Agility and Discipline: A Guide for the Perplexed, 2004; Boston, MA; Addison-Wesley, 2004, ISBN

63 References [1] Boehm, Barry; R. Turner - Balancing Agility and Discipline: A Guide for the Perplexed, 2004; Boston, MA; Addison-Wesley, 2004, ISBN [2] Boehm, Barry- Software Cost Estimation with COCOMO II, Prentice Hall 2000, ISBN [3] DeMarco, Tom; Lister, Timothy Waltzing with Bears Managing Risk on Software Projects; Dorset House Publishing 2003, ISBN [4] Gramus, David; Herron, David Function Point Analysis: Measurement Practices for Successful Software Projects; Addison-Wesley 2000; ISBN [5] Highsmith, J.A. - Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, 2000, New York: Dorset House, ISBN [6] Highsmith, J.A. - Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004, ISBN [7] Beck, K. - Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999, ISBN [8] Schwaber, Ken Agile Project Management with Scrum, Microsoft Press, 2003, ISBN x [9] Schwaber, Ken; Beedle, Mike Agile Software Development with Scrum, Prentice Hall, 2002, ISBN

64 Questions? 64

65 Appendix 1. More About COCOMO II 65

66 Scale Driver Descriptions Scale Factor Very Low Low Nominal High Very High Extra High PRECEDENTNESS thoroughly unprecedented largely unprecedented somewhat unprecedented generally familiar largely familiar thoroughly familiar REQUIREMENTS FLEXIBILITY rigorous occasional relaxation some relaxation general conformity some conformity general goals ARCHITECTURE RISK RESOLUTION little (20%) some (40%) often (60%) generally (75%) mostly (90%) full (100%) TEAM COEHISION very difficult interactions some difficult interactions basically cooperative interactions largely cooperative highly cooperative seamless interactions PROJECT MATURITY Weighted average of "Yes" answers to CMM Maturity Questionnaire 66

67 Product Attributes Constraints and requirements placed upon the project to be developed Required software reliability (RELY) Database size (DATA) Documentation match to life-cycle needs (DOCU) Product complexity (CPLX) Required Reusability (RUSE) 67

68 Platform Attributes Limitations placed upon development effort by the hardware and operating system being used to run the project Execution time constraint (TIME) Main storage constraint (STOR) Platform volatility (PVOL) 68

69 Personnel Attributes Personnel attributes refer to the level of skills that are possessed by the personnel. The skills in question are general professional ability, programming ability, experience with the development environment and familiarity with the project s domain. Analyst capabilities (ACAP) Applications experience (APEX) Programmer capabilities (PCAP) Platform experience (PLEX) Programming language experience (LTEX) Personnel Continuity (PCON) 69

70 Project Attributes Project attributes refer to the constraints and conditions under which project development takes place. Use of software tools (TOOL) Multi-site Development (SITE) 70

71 Appendix 2. More about Function Points 71

72 What Are Function Points? Function Points measure a software project by quantifying the information processing functionality associated with major external data input, output, or file types. Five user function types need to be taken into account External Inputs (EI) External Outputs (EO) External Queries (EQ) Internal Logical Files (ILF) External Interface Files (EIF) 72

73 Function Point Descriptions Function Point Type Description External Inputs External Outputs External Queries Internal Logical Files External Interface Files Each unique user data or user control input type that (i) enters the external boundary of the software system being measured and (ii) adds or changes data in a logical internal file. Each unique user data or control output type that leaves the external boundary of the software system being measured. Each unique input-output combination, where an input causes and generates an immediate output. Each logical group of user data or control information in the software system. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system. Files passed or shared between software systems should be counted as external interface file types within each system. 73

74 Counting Function Points Presentation Tier (EI, EO, EQ) B2B Interface (EIF) Business Logic Persistence Tier (ILF) Database System Services (Framework) 74

75 Function Points Complexity There are three levels of complexity both for screens (EI, EO and EQ, respectively) as well as data storage (ILF) and external interfaces (EIF) No of File Types (Domain Types) Complexity of Data Elements No of Data Elements >15 <2 L L M 2 L M H >2 M H H No of Element Types (DB Tables) Complexity of ILF No of Data Elements >50 1 L L M 2-5 L M H >5 M H H 75

76 Counting Precision (Granularity) Factors to be considered: Cost Accuracy Counting types: Detailed: +-10% precision, not cost effective Average: +- 15% precision, somewhat cost effective High Level: +- 20% precision, very cost effective 76