extreme programming modified : embrace requirements engineering practices
DESCRIPTION
IEEE Joint International Conference on Requirements Engineering 9-13 September 2002, Essen, Germany. Extreme Programming Modified : Embrace Requirements Engineering Practices. J . Nawrocki , M. Jasinski, B. Walter, A.Wojciechowski Poznan University of Technology, Poznan, Poland. - PowerPoint PPT PresentationTRANSCRIPT
Extreme Programming ModifiedExtreme Programming Modified::Embrace Requirements Engineering PracticesEmbrace Requirements Engineering Practices
J. Nawrocki, M. Jasinski, B. Walter, A.WojciechowskiPoznan University of Technology, Poznan, Poland
IEEE Joint International Conference onRequirements Engineering
9-13 September 2002, Essen, Germany
IntroductionIntroduction
Tom DeMarcoTom DeMarco
"XP is the most important movement in our field today."
Extreme ProgrammingExtreme Programming (XP) (XP) = =
a lightweight (agile) a lightweight (agile)
software development methodologysoftware development methodology
IntroductionIntroduction
Interesting practices of XPInteresting practices of XP: :
• strong customer orientationstrong customer orientation
• increments & short releasesincrements & short releases
• test-first codingtest-first coding
• planning gameplanning game etc. etc.
IntroductionIntroduction
WeaknessesWeaknesses of XP of XP: :
• lack of documentationlack of documentation
• one (on-site) customerone (on-site) customer
• too short planning perspectivetoo short planning perspective
How to solve those problemsand preserve agility?
ContentsContents
1. Introduction
2. Reconciling XP with documentation3. Multiple customer representatives
4. Modifying the XP lifecycle
5. Early evaluation results
6. Conclusions
Reconciling XP with documentationReconciling XP with documentation
Travel light.Travel light.
Documen-tationDocumen
-tation
Developer
I’ve changed my mind.Let’s go that way.
Customer
Reconciling XP with documentationReconciling XP with documentation
Travel light.Travel light.What you need is justWhat you need is just code and test cases code and test cases. .
I’ve changed my mind.
Customer
code +tests
No problem.
IEEE
Standard 830
UML
Reconciling XP with documentationReconciling XP with documentation
Oral communication is preferred as „Oral communication is preferred as „the written the written and e-mail communications (..) are error-proneand e-mail communications (..) are error-prone”.”.
Why did I decide to ..
Travel light.Travel light.What you need is justWhat you need is just code and test cases code and test cases. .
Error
But people sometimes forget!
Reconciling XP with documentationReconciling XP with documentation
To be agile does not mean that you have to To be agile does not mean that you have to throw away the (requirements) documentation.throw away the (requirements) documentation.
I’ve changed my mind.
Customer
Documen-tation
No problem.
Reconciling XP with documentationReconciling XP with documentation
To be agile does not mean that you have to To be agile does not mean that you have to throw away the (requirements) documentation.throw away the (requirements) documentation.
Documen-tation
No problem.
Developer
I’ve changed my mind.
Customer
Reconciling XP with documentationReconciling XP with documentation
To be agile does not mean that you have to To be agile does not mean that you have to throw away the requirements documentation.throw away the requirements documentation.
XP roles:• Customer• Developer• Coach• Tracker• Tester
In XP tester „is responsible for helping the customer choose and write functional tests”.
-- Kent Beck
Tester-analyst (product manager)is responsible for writing and managing usage scenarios, requirements, and acceptance tests.
Tools: Rational RequisitePro, Rational Robot, xUnit
ContentsContents
1. Introduction
2. Reconciling XP with documentation
3. Multiple customer representatives4. Modifying the XP lifecycle
5. Early evaluation results
6. Conclusions
Weaknesses of XPWeaknesses of XP
If there are many it is assumed they speak one voice.
One on-site customerOne on-site customer
We need a new car. No! We needa new furniture.
Sometimes they don’t.
Multiple customer representativesMultiple customer representatives
Original Planning Game
Effort, risk, velocity
More
colors 9 hours
Writes user stories
More
colors
Chooses scope
More
colors
More
func.
9 h6 h
Multiple customer representativesMultiple customer representatives
Modified Planning Game
Effort, risk, velocity
More
colors 9 hours
They write user stories
More
colors
More
colors
How to choose the scope?
More
colors
More
func.
9 h6 h
Multiple customer representativesMultiple customer representatives
Modified Planning Game
How to choose the scope?
More
colors
More
func.
9 h6 h
20 hours for you ..
Big boss Customers
ContentsContents
1. Introduction
2. Reconciling XP with documentation
3. Multiple customer representatives
4. Modifying the XP lifecycle5. Early evaluation results
6. Conclusions
Modifying the XP LifecycleModifying the XP Lifecycle
One release is sometimes not enough.SShort planning perspective (one release)hort planning perspective (one release)
Utility Technical risk
A spike solution
Design for today, not for tomorrow.Design for today, not for tomorrow.
Modifying the XP LifecycleModifying the XP Lifecycle
One release is sometimes not enough.SShort planning perspective (one release)hort planning perspective (one release)
Utility Technical risk
Design for today, not for tomorrow.Design for today, not for tomorrow.
Modifying the XP LifecycleModifying the XP Lifecycle
0. Initial Project Statement (subject, stakeholders etc.)
1. Usage scenarios (problems + visions)
2. Requirements specification
3. Project presentation & selection of developers
4. Project planning (and risk exploration)
5. Release 1 (2 iterations, each takes 3 weeks)
6. Release 2 (2 iterations)
ContentsContents
1. Introduction
2. Reconciling XP with documentation
3. Multiple customer representatives
4. Modifying the XP lifecycle
5. Early evaluation results6. Conclusions
Software Development Studio – A team structureSoftware Development Studio – A team structure
Project Manager and Analyst
4th yearProject Manager and Analyst
4th year
Quality Manager and Facilitator
5th yearQuality Manager and Facilitator
5th year
Designing, coding, testing,
writing documentation
3rd year
Designing, coding, testing,
writing documentation
3rd year
Experiment at PUTExperiment at PUT
Software Development Studio 2000/01
CMM Level 2 eXtremme Programming
Experiment at PUTExperiment at PUT
Software Development Studio 2001/02
Modified eXtremme Programming
Sommerville-Sawyer ModelSommerville-Sawyer Model
Defined
> 85 Basic & > 40 Interm. + Adv.
Defined
> 85 Basic & > 40 Interm. + Adv.Repeatable
> 55 Basic
Repeatable
> 55 BasicInitial
< 55 Basic
Initial
< 55 Basic
3 – obligatory2 – frequently used1 – sometimes0 – never
Score:RE PracticesBasic• ...• ...
Interm.• ...• ...
Advanced• ...• ...
Basic Int+Adv
TJam 69 31Harpo 71 32Predictor 70 30Kex 68 35EdTool 71 27ASM 64 29
Sommerville-Sawyer ModelSommerville-Sawyer Model
Defined
> 85 Basic & > 40 Interm. + Adv.
Defined
> 85 Basic & > 40 Interm. + Adv.Repeatable
> 55 Basic
Repeatable
> 55 BasicInitial
< 55 Basic
Initial
< 55 Basic
3 – obligatory2 – frequently used1 – sometimes0 – never
Score:
SummarySummary
Tester-analyst is responsible for Tester-analyst is responsible for documenting and managing documenting and managing requirements.requirements.
Modified Planning Game tries to Modified Planning Game tries to solve conflicts between multiple solve conflicts between multiple customers.customers.
Modified life-cycle emphasises Modified life-cycle emphasises requirements engineering and risk requirements engineering and risk management.management.
There is a need for user trainingThere is a need for user training.. Early results are promising.Early results are promising.
QuestionsQuestions??