IBM Software Group Agile Requirements Best Practices Robin Bater Community of Practice Architect Stockholm, Oct 15 th SAST 2010 IBM Corporation
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.
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 - http://www.ddj.com/architect/191800169 (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
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.
The Eclipse Way
XP
OpenUP Influence RUP XP AMDD Scrum Eclipse Way RUP RUP DSDM
IBM Practices for Agile Delivery
Iterative Development
Release Planning
Shared Vision
Develop Technical Vision (task)
User Story-Driven Development
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
IBM agility@scale 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
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
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
Release V2 Requirement Review & Approval
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
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
Feature Requirement Stakeholder 59 revisions
Scenario Document Product Manager 18 Revisions
Process Sketch Architect 6 Revisions
User interface example Stakeholder 5 Revisions
Use Case Diagram Developer 4 Revisions
Frame List User Interface Designer 81 Revisions
Rich Client User Interface Designer 19 Revisions
Web Client User Interface Designer 8 Revisions
Document User Interface Designer 52 Revisions
Document User Interface Designer 19 Revisions
Document Developer 2 Revisions
Development demo - Developer
Usability feedback User Interface Designer
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.
http://jazz.net/community/feedback/