Agile Requirement Management - July 2007

Agile Requirements Management 李默 [email_address]

Why Requirement Management?

71% Projects failed due to poor requirements management - CIO Magazine, 2006

Requirements Management is important.

How people manage requirements?

Documents!

Software requirements is a communication problem. Mike Cohn: User Stories Applied Chapter 1, Paragraph 1

Document is only one of many communication methods…

What is agile requirements management?

People, Process and Tools

People , Process and Tools

Individuals and interactions over processes and tools Agile manifesto, 2001

end-users or consumers demand in the marketplace End-User

business or customers product or service for users Business

with the those responsible for making it happen Implementer

Business End-User Implementer Business End-User Implementer

Business End-User Implementer

adversarial

Effective Communication

who is responsible for facilitating effective communications Business Analyst

Business End-User Implementer Business Analyst

BA as an Interpreter …

Prototypes with BA’s help

then agreement or shared understanding

BA as a Facilitator ..

“ We are agreed then ? ”

“ A i-ya !”

“ We are agreed then ! ”

Happy! 

How does the agreement become true?

QuickStart Release 1 Release 2 Release 3 Requirements Analysis & Management

Why QuickStart?

Lack of executive management support
Lack of user involvement
Lack of experienced project managers
Lack of clear business objectives
Bad scope management
Lack of standard infrastructure
Lack of firm basic requirements
Lack of formal methodology
Lack of reliable estimates
Lack of skilled staff
Why projects fail? Chaos Report

QuickStart The right people, at a right time, in a right place, do a right thing.

Who is involved?

Customer

Development Team

Analyst

What to do?

Business Objectives

Financial Models

Process Models CUSTOMER Commence filling out application form Receives form by email GPCC 1 RM Receives PDF form to complete by email Approve Add linked entities Receive readers and card Overnight batch GPCC 2 Add customers Move to ?? Folder. Archive PDF Login Receives form by email Telephone call to ID&V Change email subject line to Rcvd,copy to directory Uploads pdf form to BIB Approve Complete bespoke .xls user spreadsheet Set-up support

Functional decompositions

Lo-fi Prototypes

Master Requirements List As a… I want to… So that…

Release Plan April May June July August September October November Iteration zero Development Public holiday weeks Testing “ Managing contacts & sharing alerts” “ Reporting” “ Relationships & Publications” “ News, Blackberry” Working off-line & app. maintenance”

How we do it?

Requirements sit in a Business Context Implementation Business Process Business Strategy Business Objectives Financial Case Task Level Requirements Planning Level Requirements Role and Goal Specific Processes Overarching Process

Mental model Test Refine

Context vs. Validation Business Objectives Financial Case Task Level Requirements Planning Level Requirements Role and Goal Specific Processes Overarching Process

QuickStart Practicalities

Workshops Drive much of the process - particularly at the early stages

Small group analysis Not everything is susceptible to analysis in the workshop context - particularly at greater levels of detail

Work shadowing & observations Often the best way to rapidly gain an understanding of the current context is simply to go and look

Existing analysis & usage data Provides good context - though this is no replacement for having the right team

Usability testing There’s no substitute for end-user input

They are not new things, but we do things differently

Week One

Week Two

Week Three

Principles

Collaborative and inclusive

Time-boxed and rapid

Iterative and feedback driven (embracing change)

Centered around tangible models (visualization)

Business value / implementation cost focused

The goal of QuickStart is:

Analyze just enough requirements for the upcoming Development

QuickStart Release 1 Release 2 Release 3 Analysis & Requirements Management

Estimated prioritized master requirements list

User Stories are placeholders

Analyze detailed requirements just before the iteration which will implement them

Eliminate Waste

Delay Commitment (flow value from demand)

Lean Thinking

Continues Requirements Analysis and Management Iteration 1 Iteration 2 Iteration 3

Business Analysis Process
Iteration Kick-off
Iteration Planning
Iteration Closure
Development Support
Iteration N

To better support the Development?

Story Cards and Wall … are the major weapons

Easy to created or destroyed , re-arranged or grouped , and gathered or stored

Spreadsheet is good for generating reports but requires lots of manual work

if the team is distributed or needs more automation

Individuals and interactions over processes and tools Agile manifesto, 2001

How projects succeed?

业务分析师李默 Contact Me: mli@thoughtworks.com Agile China Group: http://groups.google.com/group/agilechina

http://blog.nona.name	58
http://liuxingmatt.blogspot.com	13
http://www.slideshare.net	10
http://feeds.feedburner.com	7
http://limo.redsaga.com	4
http://cache.baidu.com	2
http://feeds2.feedburner.com	1
http://cc.bingj.com	1

Agile Requirement Management - July 2007

by icecloud on May 06, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

8 Embeds 96

Statistics

Agile Requirement Management - July 2007 — Presentation Transcript