Agile Requirements Best Practices

Transcription

1 IBM Software Group Agile Requirements Best Practices Robin Bater Community of Practice Architect Stockholm, Oct 15 th SAST 2010 IBM Corporation

2 Topic Agilists know that any investment in detailed documentation early in a project will be wasted when the requirements inevitably change. Instead, the fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details along the way.

3 Agile: A Developing Trend Agile Adoption Rates [1] A March 2006 survey of 4232 IT professionals shows: 65 % work in organizations that have adopted one or more Agile development techniques According to same survey, the effect that Agile approaches have on productivity: [1] 41 % work in organizations that have adopted one or more Agile methodologies 60 % report increased productivity 66 % report increased quality 58 % report improved stakeholder satisfaction Large and successful companies practice Agile. In addition to IBM (which is practicing Agile in pockets), a partial list of companies using Agile include: [1] Scott Ambler Survey Says: Agile Works in Practice Dr Dobb s Portal - (August, 2006) Microsoft, Google, Motorola, Philips, Yahoo, Nokia, Siemens, Symantec, Sun, Allstate You do not do Agile, you are Agile Scaling Software Agility Dean Leffingwell

4 What Is Agile Development Quality first. Test is done by developers. Teams builds software. People not cogs in a machinery. Self organization. Minimize waste, no intermediate stockpiles of requirements, design, etc. that grow old. Collaboration. Just In Time. Just enough documentation and process. Rapid feedback and response. Continuous integration. Iterations deliver useful code that allows meaningful feedback from end user. Continuously improve your process, retrospectives. One extended team. Customers and developers are all equally vested in success. Integrated development tools to enable effective collaboration. Adaptive planning. Plan the entire project at a high level, provide detailed plans only for next iteration. Agile is a relative term. Your context determines which concrete practices are appropriate.

5 The Eclipse Way

6 XP

7 OpenUP Influence RUP XP AMDD Scrum Eclipse Way RUP RUP DSDM

8 IBM Practices for Agile Delivery

9 Iterative Development

10 Release Planning

11 Shared Vision

12 Develop Technical Vision (task)

13 User Story-Driven Development

14 Drinking Our Own Champagne Evolution of the RRC V2 Review and Approval feature 1. Stakeholder describes the feature 2. Product manager then describes the business scenario and related requirements 3. Architect defines the workflow 4. User Interface designers then developed mockups increasingly realistic versions identified "how it's really going to work 5. Development team developed incremental solutions 6. User Interface designers used milestone drivers to obtain feedback from the stakeholders

15 IBM TM our team self-assessment Team size Compliance requirement Under 10 developers 1000 s of developers Low risk Critical, Audited Geographical distribution Co-located Global Enterprise discipline Project focus Enterprise focus Disciplined Agile Delivery Domain Complexity Straight -forward Intricate/ Emerging Organization distribution (outsourcing, partnerships) Collaborative Contractual Organizational complexity Technical complexity Flexible Rigid Homogenous Heterogeneous, Legacy

16 The Product Backlog and Future functionality Product Backlog Stakeholder Requests Vision Document Defects, Change User Stories, Use-Case Model Supplementary Specification Requests Scenarios Design Specifications User Documentation Specifications 16

17 Releases IBM Software Backlog (ifix, FixPack) and Release themes artifacts are mapped to the various iteration plans ifix ifix 001 ifix 002 FixPack FixPack 1 Release M1 M2 M3 M4 M5 M6

18 Release V2 Requirement Review & Approval

19 Iterations IBM Software 17-Nov 16-Jan 17-Mar 16-May 15-Jul 13-Sep 12-Nov Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Final SVT Ship Ready Milestone overlap: planning for the next iteration begins during SVT Duration varies Each milestone includes Planning, Requirements, Design and Test Each milestone is consumable

20 Review and Approval overview 17-Nov 16-Jan 17-Mar 16-May 15-Jul 13-Sep 12-Nov Review and Approval Process R&A document example Iterative R&A Scenario Iterative R&A process Use Case for R&A Use Case Details for R&A Review and Approval Create Review Review Editor (Edit) UI specs R&A Service Design Virtual Design Rich Client Virtual Design Web Client Views and actions for Reviewers Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Final SVT Ship Ready development demo

21 Feature Requirement Stakeholder 59 revisions

22 Scenario Document Product Manager 18 Revisions

23 Process Sketch Architect 6 Revisions

24 User interface example Stakeholder 5 Revisions

25 Use Case Diagram Developer 4 Revisions

26 Frame List User Interface Designer 81 Revisions

27 Rich Client User Interface Designer 19 Revisions

28 Web Client User Interface Designer 8 Revisions

29 Document User Interface Designer 52 Revisions

30 Document User Interface Designer 19 Revisions

31 Document Developer 2 Revisions

32 Development demo - Developer

33 Usability feedback User Interface Designer

34

35 Key benefits experienced by the team Increased the range and depth of stakeholder participation Elicited more and better feedback before code was written In requirements In feature design Less churn / rework Converged faster on the right requirements Identified gaps and clarified misunderstandings more quickly Better productivity through lower cost, higher value communication Developers and testers communicated better among themselves, especially across component teams.

36