Agile requirements
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile requirements

on

  • 667 views

Presentation done at the Winnipeg Agile UG

Presentation done at the Winnipeg Agile UG

Statistics

Views

Total Views
667
Views on SlideShare
667
Embed Views
0

Actions

Likes
1
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile requirements Presentation Transcript

  • 1. AMIR BARYLKO AGILE REQUIREMENTSAmir Barylko MavenThought Inc.
  • 2. HIGH QUALITY REQUIREMENTS Goal Techniques Complexity Planning Common IssuesAmir Barylko MavenThought Inc.
  • 3. WHAT’S THE GOAL? • (good question)Amir Barylko MavenThought Inc.
  • 4. TECHNIQUES • Verbally • Use Cases • Prototyping • User StoriesAmir Barylko MavenThought Inc.
  • 5. COMPLEXITY • Task Breakdown • Story points • Planning poker • Throw a dice?Amir Barylko MavenThought Inc.
  • 6. PLANNING • Gantt Chart • Sprints for releases • Continuos release •A mix of thoseAmir Barylko MavenThought Inc.
  • 7. COMMON PROBLEMS • (Your input here)Amir Barylko MavenThought Inc.
  • 8. NARROWING THE GAP Acceptance Criteria First Benefits Roles Outside In Approach Runnable featuresAmir Barylko MavenThought Inc.
  • 9. ACCEPTANCE CRITERIA • Write the expected criteria before the implementation starts • Developers will implement the feature until the criteria is satisfied • QA will validate against the same criteriaAmir Barylko MavenThought Inc.
  • 10. BENEFITS • Discover the feature • Testing all the way • Traceability • Quality every step of the processAmir Barylko MavenThought Inc.
  • 11. ROLES • Who writes the feature? • Who implements the feature? • Who validates the feature? • What’s the role of QA, PM, etc?Amir Barylko MavenThought Inc.
  • 12. OUTSIDE IN APPROACHAmir Barylko MavenThought Inc.
  • 13. RUNNABLE FEATURES • Features describe functionality • What if we could run them? • Then features would validate functionality • Becoming live documentationAmir Barylko MavenThought Inc.
  • 14. ACCEPTANCE CASES A common language Features Scenarios Styles BenefitsAmir Barylko MavenThought Inc.
  • 15. GHERKIN DSL • Business readable DSL • Flush out requirements • Documentation • Automated testing • Used by Cucumber, SpecFlow, jBehaveAmir Barylko MavenThought Inc.
  • 16. FEATURES Keyword Feature: Listing projects As a user Free text! I Want to see the list of projects So I can choose one to see the details Scenario: List all projects (steps here to implement scenario) Scenario: No projects are available (steps here to implement scenario)Amir Barylko MavenThought Inc.
  • 17. SCENARIOS Scenario: List all projects Given Im logged in Step 1 And I have (some data loaded) Step 2 When I (do some action) Step 3 Then I (should see expected results) Step 4Amir Barylko MavenThought Inc.
  • 18. SCENARIOS • Each feature file can have multiple scenarios • Each scenario can contain multiple steps • Keywords: • Given When Then • And Not ButAmir Barylko MavenThought Inc.
  • 19. Post-It EXCERCISE & Sharpie! •Write a story and •scenarios for a user loginAmir Barylko MavenThought Inc.
  • 20. GUIDELINES & GOALS Too Vague Too Imperative Descriptive Style Complexity PlanningAmir Barylko MavenThought Inc.
  • 21. TOO VAGUE Scenario: Perfect world Given the application is setup When I want to use some projects Then I should be able to load data And have a great user experience but no bugs should appearAmir Barylko MavenThought Inc.
  • 22. TOO IMPERATIVE Scenario: Redirect user to originally requested page Given a User "dave" exists with password "secret" And I am not logged in When I navigate to the home page Then I am redirected to the login form When I fill in "Username" with "dave" And I fill in "Password" with "secret" And I press "Login"Amir Barylko MavenThought Inc.
  • 23. DESCRIPTIVE STYLE Scenario: List all projects Given Im logged in And I have some projects stored When I list the projects Then I should see all of themAmir Barylko MavenThought Inc.
  • 24. DISCOVER COMPLEXITY • How many scenarios per feature? • The more scenarios the more complex • The more steps the more complex • If scenarios are unclear, then is time to rethink the featureAmir Barylko MavenThought Inc.
  • 25. DISCOVER FUNCTIONALITY • When is the right time to write scenarios? • During Inception? • During Analysis? • During Development? • During QA?Amir Barylko MavenThought Inc.
  • 26. SCENARIO ORDER • What happens with dependencies? • How do I use data if I haven’t implemented that feature? • Can devs work independently in different scenarios?Amir Barylko MavenThought Inc.
  • 27. Post-It VOTING APP & Sharpie! •In teams •Choose top three user stories •Write scenarios •Share with the other teamsAmir Barylko MavenThought Inc.
  • 28. RUNNABLE SCENARIOS Tools Implementation Unit Tests Integration Tests Acceptance TestsAmir Barylko MavenThought Inc.
  • 29. TOOLS GALORE • Lots of tools available that use Gherkin: • Cucumber / rSpec • jBehave • Specflow • Scalatest • etcAmir Barylko MavenThought Inc.
  • 30. WHERE SHOULD THEY GO? •Acceptance tests? •Integration tests? •Unit tests?Amir Barylko MavenThought Inc.
  • 31. ACCEPTANCE TEST •Black box testing •Crossing all layers •Should cover all scenarios •External subsystems may be mockedAmir Barylko MavenThought Inc.
  • 32. INTEGRATION TEST •More than one class •Still some parts can be mocked •Partial functionality of subsystemAmir Barylko MavenThought Inc.
  • 33. UNIT TEST • Test for a class or method • No external dependencies • Small • ClearAmir Barylko MavenThought Inc.
  • 34. TDD • First write a test that fails (RED) • Write code to make it pass (GREEN) • Check if code can be improved (REFACTOR) • Start again until it’s doneAmir Barylko MavenThought Inc.
  • 35. WHEN TDD IS NOT ENOUGH •Legacy Code •Refactoring is not viable •Verify functionality across layers •Validate feature end to endAmir Barylko MavenThought Inc.
  • 36. DEMOAmir Barylko MavenThought Inc.
  • 37. SUMMARY Benefits Challenges What’s next?Amir Barylko MavenThought Inc.
  • 38. BENEFITS • Easier planning • Putsthe whole team on the same page • Discoversfunctionality and complexity • Simplifies QA process • No particular skill • Narrows the gap required between expectations and actual • Easy Adoption implementationAmir Barylko MavenThought Inc.
  • 39. CHALLENGES • Different approach • The roles get blurred • Team effort • Others?Amir Barylko MavenThought Inc.
  • 40. WHAT’S NEXT • Take one concept that you are not implementing • You have until next meeting to put it to work • Register challenges, issues and results • Share that next sessionAmir Barylko MavenThought Inc.
  • 41. QUESTIONS?Amir Barylko MavenThought Inc.
  • 42. RESOURCES • Contact me: amir@barylko.com, @abarylko • Download: http://www.orthocoders.com/presentationsAmir Barylko MavenThought Inc.
  • 43. RESOURCES II • jBehave: http://jbehave.org • Cucumber: http://cukes.info • ScalaTest: http://scalatest.org • Selenium: http://seleniumhq.org • jDave: http://jdave.org • EasyB: http://easyb.orgAmir Barylko MavenThought Inc.