Dual Language Programs Defining Terms Defining Options Defining Results.
Defining Done
14
...and how will we ever know? Are we done yet? Determining Completion Criteria using Agile Methodologies
-
Upload
david-rogers -
Category
Business
-
view
613 -
download
2
description
How do we know... I mean, really _know_ when our project is finally _done_...? Particularly in this world of Agile Development practices, where the client can change his mind at any moment and add or remove things from the project, willy-nilly... What a mess! Welcome to (one of) the answers: Acceptance Criteria!
Transcript of Defining Done
...and how will we ever know?
Are we done yet?Determining Completion Criteria using Agile
Methodologies
What is “DONE”?
“Nothing ever gets done around here!”
“When are you going to be done with that?”
“That’s not how I wanted that done!”
“How can I tell when it’s done?”
What is “DONE”?
Determining completion is part of the specification of a task.
How do we write specifications?
User Stories!
More User Stories?!?
Each “User Story” describes a single aspect of the final product - a feature specification - in simple, easy to read language.
Feature specifications should also contain a number of “Acceptance Tests” that define the acceptable behavior of the feature.
Tests should not be overly complicated, just as Stories are not overly detailed, and can be added to as iterations progress.
When do we do this?
Before, during, and after programming the feature
Prior to an iteration, usually in the Sprint Planning session
Whenever the development team and client talk about the User Stories they’ve written
Do I have to write them?
Ideally written by the client, since they understand the desired behavior best.
Designed to expose the assumptions that the client is making about the software.
May need augmentation from the developers to address technical details omitted or overlooked.
NOT a replacement for Unit Testing!
This sounds familiar...
Work with the client to write Acceptance Tests for each User Story that describe the desired behavior before programming the feature.
You mean like...
Test-Driven Development!
Behavior-Driven Development!Death by Agile Buzzwords!
SCRUM!
Can I have an example?
A user can log in to the system and view her dashboard. If she’s a guest, she can register instead.• “username” must be an email address• “password” should be really secure• don’t create profiles for bad email addresses• users get three tries at the password• offer an automated password recovery
User Story Card
8 points
What does that mean?
The “username” field needs email validation
The “password” field needs a good “password strength” validation
Supplied email addresses must be confirmed through some process before a user profile is created
Possible pitfalls?
Another example please...
A user can pay for a course with a credit card.
• we only accept Visa, MC, Discover, and Amex... no “Diner’s Club” BS• before running the transaction:• check the card number and type• check the expiration date
• test for over-limit purchases
User Story Card
13 points
Okay, break that down...
Card types, numbers, and expiration dates must be validated before they are submitted to the payment gateway
Some card types will not be accepted by the system, regardless of their validity
Watch out for purchases that exceed the available limit on the card!
How do I program that?
Unit Testing is only a start. Test the minutiae of predictable misbehavior with good Unit Tests.
Behavior-Driven Tests are better, because the tests should correspond to the Acceptance Tests written by the client.
testing:* itShouldAcceptVisa(): pass!* itShouldAcceptMasterCard(): pass!* itShouldntAcceptDinersClub(): pass!
Where do I learn more?
User Stories Applied: For Agile Software Development by Mike Cohn (ISBN 0-321-20568-5)
Extreme Programming: Acceptance Testing
Acceptance Testing on wikipedia.org
http://www.slideshare.net/al_the_x
Who is this guy?
linkedin.com/in/althex
twitter.com/al_the_x
github.com/al-the-x
slideshare.net/al_the_x
