Successfully reported this slideshow.
Your SlideShare is downloading. ×

Flexing your Agile Muscle - Agile Technical Concepts Explained

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 64 Ad

Flexing your Agile Muscle - Agile Technical Concepts Explained

Download to read offline

Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.

Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.

This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.

Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.

Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.

This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Flexing your Agile Muscle - Agile Technical Concepts Explained (20)

Advertisement

Recently uploaded (20)

Advertisement

Flexing your Agile Muscle - Agile Technical Concepts Explained

  1. 1. Agile Technical Practices Sandy Mamoli @smamol www.nomad8.com
  2. 2. user stories acceptance testing unit testing TDD refactoring load testing coding standards whole team collective code ownership pair programming continuous integration
  3. 3. Quality • Overview of Agile • Agile Acceptance Testing • Deployment pipeline (CI)
  4. 4. Agile
  5. 5. What is Agile? • Software development framework • Based on adaptive planning • Used since 1995 (Scrum)
  6. 6. Responding to change Features: 6 months As Defined In Changed Form Not Wanted Anymore In Changed Form Not Wanted Anymore As Defined Standish  Group,  Chaos  Report
  7. 7. How does it work?
  8. 8. Incrementing one bit at a time 1 2 3 4 5 © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  9. 9. Vertical slices - feedback & innovation © Johnathan Rasmussen, The Agile Samurai
  10. 10. Working, shippable software
  11. 11. Build important things first
  12. 12. Technical excellence
  13. 13. Continuous improvement
  14. 14. Agile Quality
  15. 15. Cost of bugs
  16. 16. A more scientific way of saying this ... >150 150.0 112.5 75.0 50x 37.5 20x 5x 10x 1x 0 Source: Standish Group Reqs Design Code DevT AccT Ops
  17. 17. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
  18. 18. The dev’s view exploratory testing acceptance testing unit testing
  19. 19. User Stories
  20. 20. “incrementing” builds one bit at a time 1 2 3 4 5 © Jeff Patton, all rights reserved, www.AgileProductDesign.com
  21. 21. Story&ID:& Priority: high Photo album privacy Size: Descrip/on: 13 As&a&... photographer I&want&to&... make some photo albums private So&that&... I can have a backup of my personal photos online
  22. 22. Acceptance(Criteria 1. I can set the privacy of photo albums 2. I can see my private albums 3. My private albums are not visible to others
  23. 23. Agile Acceptance Testing
  24. 24. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
  25. 25. Acceptance tests • Check that the implementation matches the intent • Focus on shared understanding by developers, testers and business people • End to end
  26. 26. Scenarios • Create a new private album • Make a public album private • Make a private album public <vertical slices through the acceptance criteria>
  27. 27. Examples Given I create an album named “My holiday” When I choose to make it private Then I can see the album “My holiday” But Kai cannot see the album
  28. 28. Examples Given ... <something we accept to be true> When ...<indicates the event in a scenario> Then ...<indicates the expected outcome>
  29. 29. <Melomel API>
  30. 30. Cucumber • Features • Scenarios • Steps • Cucumber command
  31. 31. cucumber: example
  32. 32. cucumber: example Features
  33. 33. cucumber: example Scenarios
  34. 34. cucumber: example Steps
  35. 35. cucumber: example Cucumber command
  36. 36. cucumber: example Cucumber command
  37. 37. cucumber: example Cucumber command
  38. 38. Good practices • Hide unnecessary detail • Make tests independent • Don’t test absolutely everything
  39. 39. Declarative vs. imperative style Scenario: transfer money (imperative)   Given I have $100 in checking   And I have $20 in savings   When I go to the transfer form   And I select "Checking" from "Source Account"   And I select "Savings" from "Target Account"   And I fill in "Amount" with "15"   And I press "Execute Transfer"   Then I should see that I have $85 in checking   And I should see that I have $35 in savings
  40. 40. Declarative vs. imperative style Scenario: transfer money (declarative)   Given I have $100 in checking   And I have $20 in savings   When I transfer $15 from checking to savings   Then I should have $85 in checking  
  41. 41. Make tests independent • Maintenance • Where did it fail? • Parallelise
  42. 42. Don’t test absolutely everything GUI Tests Acceptance Tests Unit Tests
  43. 43. Why I like ATDD • Ensures the intent is well understood • Ensures the implementation matches the intent • Ensures the implementation keeps matching the intent
  44. 44. Living documentation
  45. 45. Unit testing
  46. 46. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
  47. 47. Unit tests • Check that the program behaves as the developer thinks it should • Tend to be focussed on the structural (internal) quality of the code • Hard for testers and business people to understand
  48. 48. Unit tests/TDD • FlexUnit • MXUnit
  49. 49. Deployment Pipeline
  50. 50. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
  51. 51. As often as possible to get early and instant feedback
  52. 52. Deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
  53. 53. Agile deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
  54. 54. Deployment pipeline: Commit stage • Create deployable artifacts • Or fail fast and notify the team • Triggered by CI server • 5 minutes or less to run • Jenkins, TeamCity, etc
  55. 55. Continuous integration is a practice not a tool • Commit regularly (at least once a day) • Fix any broken build immediately • Write automated tests
  56. 56. Deployment pipeline: Acceptance test stage • Verify acceptance criteria have been met • Verify business value • Run in parallel • Refactor
  57. 57. How to get started • Create a walking skeleton with placeholders • Automate the build and deploy process • Automate unit tests and code analysis • Automate acceptance tests • Evolve the pipeline
  58. 58. Recommended reading + +
  59. 59. Call to action • Work on Melomel & Cucumber • Participate in CI projects (Jenkins) • Steal from Ruby on Rails :-)
  60. 60. Contact me Sandy Mamoli @smamol sandy@nomad8.com

Editor's Notes

  • - Debating with myself - agile or not\n- come from Agile space\n- good technical practices, increase quality &amp; software health \n- whether agile or not great benefits - if agile even more important \n\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • - WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
  • \n
  • - Who? Experience?\n
  • \n
  • - recommended development methodology for UK government projects \n-&gt; rapidly emerging standard for organisations providing critical business functionality\n\n
  • - half life\n- rate of change (1980s 10 - 1990s 5 - 2000 1-2 - 2005 (3 - 6 months), \n- process to accommodate rate of change without ending in chaos\n\n
  • - to accommodate this rate of change we need to find a framework \n -&gt; accept reality, manage change, flexibility - without ending up in chaos\n- Here&amp;#x2019;s how it works\n
  • - Mona Lisa - da Vinci\n
  • - Mona Lisa - da Vinci\n
  • - Mona Lisa - da Vinci\n
  • - Mona Lisa - da Vinci\n
  • - Mona Lisa - da Vinci\n
  • - vertical slices, \n- innovation (resist change), feedback\n- misunderstood? bug?\nbuilding a car\n\n\n\n\n
  • - primary measure of progress = working software \n- NO DEFECTS\n- 1) Planning (90%), 2) Done/ROI\n
  • - functionality is implemented in order of business priority (balancing people and technical risk)\n- management of risk - run out of resources, feedback\n\n
  • - quality obsessed\n- DoD: -&gt; no known bugs -&gt; airplane disasters \n=&gt; tech. practices help us \n\n
  • \n
  • \n
  • - requirements bugs\n- code bugs\n
  • - only waterfall numbers - not for Agile =&gt; proves that testing earlier reduced the cost of fix\n- Why?\n
  • - Building the right thing - building the thing right\n
  • \n
  • - Step back and explain Agile requirements\n\n
  • \n\n\n
  • - Independently testable by user/business person\n\n
  • - define the boundaries - conditions of satisfaction\n- State an intent not a solution - Independent of implementation\n- Help a shared understanding\n
  • - focus on more\n
  • - focuses on user stories\n- 56% of all defects are requirements defects\n
  • - Does it do what we want?\n- Also called BDD, ATDD, Specification by Example\n
  • - How can we test? Define scenarios as vertical slices through the acceptance criteria\n\n
  • - Very useful as beginning with end in mind\n- It is okay to have more than one outcome in a scenario -&gt; AND, BUT\n\n
  • - Template for examples\n- Given: not a pre-condition, true =&gt; e.g. given i have $20 in my account, given monday is a holiday\n\n
  • - wouldn&amp;#x2019;t it be great if we could automate our tests?\n- of course we could test manually - would be a great achievement already - but ...\n- ESPECIALLY AGILE\n
  • - 1 of many free tools =&gt; anyone using?\n- BDD in a Nutshell\n-&gt; mainly from the RoR world, Java, .Net =&gt; Flex, CF (www.cukes.info)\n\n
  • - Melomel =&gt;Melomel is an API for accessing ActionScript objects in the Flash virtual machine through external languages. \n- Currently only available for Ruby but it is actively being expanded to other languages.\n\n
  • - 4 parts: Features/stories - steps - cucumber command\n- NEXT: example\n
  • \n
  • - Will guide you though full example - feature/scenario/example/steps/cucumber\n- Simple CRUD\n
  • - Feature files\n- Scenario headings \n- Happy path, 1 or 2 exception paths (if happened in the past, or risky)\n\n
  • - Declarative language (avoid click xyz, anything GUI specific) as much as possible \n- Keep implementation independent, keep understandable for non developers\n- Where do I hide the details? Connect the scenarios into code\n\n
  • - A step is a Given/When/Then/And/But expressed in code\n- Lots of steps come built in (click_link, visit url), possible to nest them\n\n\n
  • - The cucumber command runs all the *.feature files below the features directory\n- Cucumber is very helpful - generates stubs\n- Tags\n
  • - Once we have a file with a feature in it we can run it with the cucumber command\n- The cucumber command runs all the *.feature files below the features directory\n
  • - Tags\n
  • - details: avoid brittleness (GUI), keep understandable for everyone\n
  • - What do you think? They do +/-\n- Imperative: more composable -&gt; need fewer step definitions, less work at beginning\n- Declarative: less dependent on GUI, less verbose\n- Balance, taste which easier to read \n\n
  • \n
  • \n
  • - Maintenance, brittle - GUI most expensive, Unit least\n- Happy path, 1 or 2 edge cases - high risk, most common ones\n\n
  • - speaks everybody&amp;#x2019;s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
  • - speaks everybody&amp;#x2019;s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
  • \n
  • - code facing\n
  • - Code facing\n
  • - good frameworks exist - won&amp;#x2019;t focus to much on it\n
  • - To get the full benefit =&gt; need to run the tests - regular basis\n
  • - Tie all together - have automation need to run it to get value out of it\n\n
  • - Tie all together - have automation need to run it to get value out of it\n\n
  • - Tie all together - have automation need to run it to get value out of it\n\n
  • Re-iterate goals: small valuable chunks, low cycle time, hgh quality\n
  • - Jez Humble\n=&gt; release candidates\n- AUTOMATED releases!!!\n\n
  • - done for each user story (facebook etc)\n- same exit criteria, work in parallel\n- AUTOMATED releases!!!\n
  • - drill down into 3 automated parts: commit, acceptance, load &amp; capacity\n- coverage: no numbers; commit stage fail if coverage or quality increases (warnings)\n- if it breaks: team&amp;#x2019;s highest priority to fix it!!\n
  • - Small increments\n- Team agreement\n=&gt; send to other session\n\n
  • - CI server does this \n
  • - Start by having one or two of each type test and add to that\n- Unit: new code, every time a bug\n- Acceptance: Most common, if manually testing more than once automate\n- Stuff just talked about - tie back together\n
  • \n
  • - great community\n- missing frameworks: cucumber (AIR!) - melomel =&gt; AIR, ColdFusion\n
  • \n

×