1 / 13

Extreme Hour

Extreme Hour. Role-Playing The XP Process. What Is Extreme Programming?. User Stories: Function, Qualities, Priority, Scope. Schedule: By negotiation. 1 week iteration. Testing: Automate unit & functional tests Unit test before code Pairing: Two heads, one keyboard

philip-solis
Download Presentation

Extreme Hour

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Extreme Hour Role-Playing The XP Process

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

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

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

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

  6. Dramatis Personae • Coach keeps process flowing • Tracker records and times everything • Customers specify but don’t estimate • QA runs acceptance tests • Developers estimate and implement • 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. Customers suggest Stories. Tracker helps write ‘em up. QA quantifies relevant qualities per story. Developers spike Architecture. NB: 1 Pen for every 2 Engineers: Pairing! Learn Ideal Time 10 Minutes: User Stories, Test Fixtures, Spikes

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

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

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

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

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

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

More Related