Your SlideShare is downloading. ×
Flexing your Agile Muscle - Agile Technical Concepts Explained
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Flexing your Agile Muscle - Agile Technical Concepts Explained

4,991
views

Published on

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 …

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.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,991
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
46
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • - Debating with myself - agile or not\n- come from Agile space\n- good technical practices, increase quality & 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-> 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 -> accept reality, manage change, flexibility - without ending up in chaos\n- Here’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: -> no known bugs -> airplane disasters \n=> tech. practices help us \n\n
  • \n
  • \n
  • - requirements bugs\n- code bugs\n
  • - only waterfall numbers - not for Agile => 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 -> AND, BUT\n\n
  • - Template for examples\n- Given: not a pre-condition, true => e.g. given i have $20 in my account, given monday is a holiday\n\n
  • - wouldn’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 => anyone using?\n- BDD in a Nutshell\n-> mainly from the RoR world, Java, .Net => Flex, CF (www.cukes.info)\n\n
  • - Melomel =>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 -> 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’s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
  • - speaks everybody’s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
  • \n
  • - code facing\n
  • - Code facing\n
  • - good frameworks exist - won’t focus to much on it\n
  • - To get the full benefit => 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=> 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 & capacity\n- coverage: no numbers; commit stage fail if coverage or quality increases (warnings)\n- if it breaks: team’s highest priority to fix it!!\n
  • - Small increments\n- Team agreement\n=> 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 => AIR, ColdFusion\n
  • \n
  • Transcript

    • 1. Agile Technical Practices Sandy Mamoli @smamol www.nomad8.com
    • 2. user storiesacceptance testing unit testing TDD refactoring load testingcoding standards whole team collective code ownershippair programming continuous integration
    • 3. Quality• Overview of Agile• Agile Acceptance Testing• Deployment pipeline (CI)
    • 4. Agile
    • 5. What is Agile?• Software development framework• Based on adaptive planning• Used since 1995 (Scrum)
    • 6. Responding to change Features: 6 months As Defined In Changed Form Not Wanted Anymore In Changed Form Not Wanted Anymore As DefinedStandish  Group,  Chaos  Report
    • 7. How does it work?
    • 8. Incrementing one bit at a time 1 2 3 4 5© Jeff Patton, all rights reserved, www.AgileProductDesign.com
    • 9. Vertical slices - feedback & innovation© Johnathan Rasmussen, The Agile Samurai
    • 10. Working, shippable software
    • 11. Build important things first
    • 12. Technical excellence
    • 13. Continuous improvement
    • 14. Agile Quality
    • 15. Cost of bugs
    • 16. A more scientific way of saying this ... >150 150.0 112.5 75.0 50x 37.5 20x 5x 10x 1x 0Source: Standish Group Reqs Design Code DevT AccT Ops
    • 17. Agile Testing QuadrantsAgile Acceptance TestFunctional TestStory TestUnit Tests
    • 18. The dev’s view exploratory testing acceptance testing unit testing
    • 19. User Stories
    • 20. “incrementing” builds one bit at a time 1 2 3 4 5© Jeff Patton, all rights reserved, www.AgileProductDesign.com
    • 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. Acceptance(Criteria1. I can set the privacy of photo albums2. I can see my private albums3. My private albums are not visible to others
    • 23. Agile Acceptance Testing
    • 24. Agile Testing QuadrantsAgile Acceptance TestFunctional TestStory TestUnit Tests
    • 25. Acceptance tests• Check that the implementation matches the intent• Focus on shared understanding by developers, testers and business people• End to end
    • 26. Scenarios • Create a new private album • Make a public album private • Make a private album public<vertical slices through the acceptance criteria>
    • 27. ExamplesGiven I create an album named “My holiday”When I choose to make it privateThen I can see the album “My holiday”But Kai cannot see the album
    • 28. ExamplesGiven ... <something we accept to be true>When ...<indicates the event in a scenario>Then ...<indicates the expected outcome>
    • 29. <Melomel API>
    • 30. Cucumber• Features• Scenarios• Steps• Cucumber command
    • 31. cucumber: example
    • 32. cucumber: example Features
    • 33. cucumber: example Scenarios
    • 34. cucumber: example Steps
    • 35. cucumber: example Cucumber command
    • 36. cucumber: example Cucumber command
    • 37. cucumber: example Cucumber command
    • 38. Good practices• Hide unnecessary detail• Make tests independent• Don’t test absolutely everything
    • 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. 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. Make tests independent • Maintenance • Where did it fail? • Parallelise
    • 42. Don’t test absolutely everything GUI Tests Acceptance Tests Unit Tests
    • 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. Living documentation
    • 45. Unit testing
    • 46. Agile Testing QuadrantsAgile Acceptance TestFunctional TestStory TestUnit Tests
    • 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. Unit tests/TDD• FlexUnit• MXUnit
    • 49. Deployment Pipeline
    • 50. Agile Testing QuadrantsAgile Acceptance TestFunctional TestStory TestUnit Tests
    • 51. As often as possible to getearly and instant feedback
    • 52. Deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
    • 53. Agile deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
    • 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. Continuous integration is a practice not a tool• Commit regularly (at least once a day)• Fix any broken build immediately• Write automated tests
    • 56. Deployment pipeline: Acceptance test stage• Verify acceptance criteria have been met• Verify business value • Run in parallel • Refactor
    • 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. Recommended reading + +
    • 59. Call to action• Work on Melomel & Cucumber• Participate in CI projects (Jenkins)• Steal from Ruby on Rails :-)
    • 60. Contact me Sandy Mamoli @smamol sandy@nomad8.com