Flexing your Agile Muscle - Agile Technical Concepts Explained
•
3 gostaram•2,616 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Flexing your Agile Muscle - Agile Technical Concepts Explained
Semelhante a Flexing your Agile Muscle - Agile Technical Concepts Explained (20)
Mais de Sandy Mamoli
Mais de Sandy Mamoli (12)
Último
Último (20)
Flexing your Agile Muscle - Agile Technical Concepts Explained
- 1. Agile Technical Practices Sandy Mamoli @smamol www.nomad8.com
- 2. user stories acceptance testing unit testing TDD refactoring load testing coding standards whole team collective code ownership pair 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)
- 7. 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
- 8. How does it work?
- 9. Incrementing one bit at a time 1 2 3 4 5 © Jeff Patton, all rights reserved, www.AgileProductDesign.com
- 10. Vertical slices - feedback & innovation © Johnathan Rasmussen, The Agile Samurai
- 12. Build important things first
- 15. Agile Quality
- 16. Cost of bugs
- 17. 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
- 18. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
- 19. The dev’s view exploratory testing acceptance testing unit testing
- 20. User Stories
- 21. “incrementing” builds one bit at a time 1 2 3 4 5 © Jeff Patton, all rights reserved, www.AgileProductDesign.com
- 22. 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
- 23. 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
- 24. Agile Acceptance Testing
- 25. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
- 26. Acceptance tests • Check that the implementation matches the intent • Focus on shared understanding by developers, testers and business people • End to end
- 27. Scenarios • Create a new private album • Make a public album private • Make a private album public <vertical slices through the acceptance criteria>
- 28. 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
- 29. Examples Given ... <something we accept to be true> When ...<indicates the event in a scenario> Then ...<indicates the expected outcome>
- 32. <Melomel API>
- 33. Cucumber • Features • Scenarios • Steps • Cucumber command
- 36. cucumber: example Features
- 37. cucumber: example Scenarios
- 38. cucumber: example Steps
- 39. cucumber: example Cucumber command
- 40. cucumber: example Cucumber command
- 41. cucumber: example Cucumber command
- 42. Good practices • Hide unnecessary detail • Make tests independent • Don’t test absolutely everything
- 43. 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
- 44. 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
- 45. Make tests independent • Maintenance • Where did it fail? • Parallelise
- 46. Don’t test absolutely everything GUI Tests Acceptance Tests Unit Tests
- 47. Why I like ATDD • Ensures the intent is well understood • Ensures the implementation matches the intent • Ensures the implementation keeps matching the intent
- 49. Unit testing
- 50. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
- 51. 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
- 52. Unit tests/TDD • FlexUnit • MXUnit
- 54. Agile Testing Quadrants Agile Acceptance Test Functional Test Story Test Unit Tests
- 55. As often as possible to get early and instant feedback
- 56. Deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
- 57. Agile deployment pipeline Deployment pipeline: Jez Humble, www.continuousdelivery.com
- 58. 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
- 59. Continuous integration is a practice not a tool • Commit regularly (at least once a day) • Fix any broken build immediately • Write automated tests
- 60. Deployment pipeline: Acceptance test stage • Verify acceptance criteria have been met • Verify business value • Run in parallel • Refactor
- 61. 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
- 62. Recommended reading + +
- 63. Call to action • Work on Melomel & Cucumber • Participate in CI projects (Jenkins) • Steal from Ruby on Rails :-)
- 64. Contact me Sandy Mamoli @smamol sandy@nomad8.com
Notas do Editor
- - 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&#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: -> 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&#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 => 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&#x2019;s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
- - speaks everybody&#x2019;s language, involves whole team\n- Advantages\n- Then wrapup repeat\n
- \n
- - code facing\n
- - Code facing\n
- - good frameworks exist - won&#x2019;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&#x2019;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