1. Extreme Hour Role-Playing The XP Process

2. What Is Extreme Programming? n User Stories:Function, Qualities, Priority, Scope. n Schedule:By negotiation. 1 week iteration. n Testing:Automate unit & functional tests Unit test before code n Pairing:Two heads, one keyboard Better quality, less bugs, faster! n Refactor: Simplest code, then simplest system n YAGNI:You Aren’t Going To Need It - minimize diagrams & documents n Communicate:Stand Up Meetings, CRC Carding, …

3. Why Is Extreme Programming? n Give management a steering wheel n Get feedback early & often n Minimize overtime & heroics n Keep deliverables deliverable n Eliminate neurotic process n Flatten cost-of-change curve n Maximize work flow & pride

4. Extreme Hour Vision: A Better Mousetrap n Our company refocuses as a pest control automation product group. n Our flagship will capture the high-end domestic segment of this well established market. n Accept this dramatic new vision. Plan, Schedule, Develop and Quality Assure our initial release. Project timeframe: One Hour !

5. Sixty Minute Project 10 Minutes User Stories & Spike Architecture 10 Minutes User Stories & Spike Architecture 10 Minutes estimate Priority & Scope 10 Minutes estimate Priority & Scope 10 Minutes 1st Commitment Schedule 10 Minutes 1st Commitment Schedule 10 Minutes Iteration 1 10 Minutes Iteration 1 10 Minutes 2nd Commitment Schedule 10 Minutes 2nd Commitment Schedule 10 Minutes Iteration 2 10 Minutes Iteration 2 Release! Release! n Timeframes Not To Scale

6. Dramatis Personae n Coach keeps process flowing n Tracker records and times everything n Customers specify but don’t estimate n QA runs acceptance tests n Developers estimate and implement n Rules: –If It Ain’t Drawn, It Ain’t Delivered. –If It Ain’t Written, It Ain’t Required. –QA can’t see what developers do till iteration’s end

7. 10 Minutes: User Stories, Test Fixtures, Spikes n Customers suggest Stories. Tracker helps write ‘em up. n QA quantifies relevant qualities per story. n Developers spike Architecture. n NB: 1 Pen for every 2 Engineers: Pairing! n Learn Ideal Time

8. 10 Minutes: Estimate Priority & Scope n Customers & Tracker sort Stories into 3 piles: n Must Have n Market Advantage n Really Cool n Then rank relative priorities within each pile. n Developers assign Ideal Minute costs to Stories based on Spike times. n Max story size 3 ideal minutes, or else split/clarify. n If developer estimates disagree, optimist wins. n QA reviews architecture & notes risks on stories.

9. 10 Minutes: Initial Commitment Schedule n Coach, Tracker, & Customers schedule stories for 2 Iterations. n Schedule priority & risk first. n Use “Load Factor 2” for Project Velocity n Yes, we want to see a blow-out n QA draws Acceptance Test fixtures.

10. 10 Minutes: Iteration 1 n QA writes down Acceptance Tests for each Story. n QA can’t see what developers draw until end of Iteration. n NB: In real XP, QA communicates with Developers & Customers. n Developers pair. Each pair picks 1 User Story & 1 pen. n First draw simplest thing that could possibly work. n Then Refactor drawing to make simplest system. n Customers + Tracker modify and reprioritize Iteration 2 Stories.

11. 10 Minutes: 2nd Commitment Schedule n Customers reveal new Stories & Developers estimate them. n QA “run” tests, Tracker notes bugs as stories n Customers prioritize bug vs. new stories n QA & Developers modify Acceptance Test Fixtures n Coach, Tracker & Customers schedule Second Iteration n Priority & Risk First n Use Measured Project Velocity

12. 10 Minutes: Iteration 2 n Developers pair. Each pair picks 1 User Story & 1 pen. n First draw simplest thing that could possibly work. n Then Refactor drawing to make simplest system. n Customers + Tracker modify and reprioritize Iteration 3 Stories. n QA writes down Acceptance Tests for each Story. n QA can’t see what developers draw until end of Iteration. n NB: In real XP, QA communicates with Developers & Customers.

13. Release! QA “runs” tests. Can we release? Do we need an iteration 3?