Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Moving away from legacy code (AgileCymru)

2,532 views

Published on

Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects?
Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD?
This talk will show you how to be successful even with the oldest legacy projects out there through the usage of Agile processes and tools like Impact Mapping, Feature Mapping, Example Workshop, Story and Spec BDDs.

Published in: Technology

Moving away from legacy code (AgileCymru)

  1. 1. Moving away from legacy code with BDD
  2. 2. BDD Practice Manager Creator of Behat - Cucumber for PHP Software Engineer turned Stakeholder whisperer Konstantin Kudryashov @everzet
  3. 3. This talk is about • Solving purely technical “TCIAM” problem using behaviour driven development practices and agile discovery processes • Planning a delivery strategy on the basis of change appreciation • Real-life experience
  4. 4. Legacy projects
  5. 5. How most teams see their next project
  6. 6. our next project
  7. 7. our next project their actual next project
  8. 8. Agile, TDD, BDD, etc… // TODO: refactor later
  9. 9. Is it really that bad?
  10. 10. If a project can afford a salary of an engineer concerned about the project state, then the project state is not that bad.
  11. 11. // TODO: refactor later
  12. 12. // TODO: refactor later
  13. 13. // TODO: refactor later
  14. 14. This world is full of brilliant projects that nobody is concerned about. Sadly, it’s often because there’s no one left to care.
  15. 15. You deliver value Just not as effectively as you could
  16. 16. Great value + Awful code = Great product yesterday
  17. 17. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow
  18. 18. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow No value + Any code = Awful product anytime
  19. 19. Great value + Awful code = Great product yesterday No value + Any code = Awful product anytime
  20. 20. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow
  21. 21. // TODO: refactor laterAgile, TDD, BDD, etc…
  22. 22. Rewrite all the things!
  23. 23. learning
  24. 24. learning trash bin else
  25. 25. learning • Agile • XP • BDD trash bin else
  26. 26. learning • Agile • XP • BDD trash bin else
  27. 27. learning • Agile • XP • BDD trash bin else
  28. 28. Working system
  29. 29. 1 year later…
  30. 30. nearly working system
  31. 31. how come?
  32. 32. learning • Agile • XP • BDD trash bin else
  33. 33. learning • Agile • XP • BDD trash bin else
  34. 34. legacylegacy
  35. 35. legacylegacy
  36. 36. shiny new legacylegacy
  37. 37. shiny new £A legacylegacy
  38. 38. U my features!!! shiny new £A legacylegacy
  39. 39. shiny new £A U my features!!! legacylegacy
  40. 40. shiny new £A + £B U my features!!! legacylegacy
  41. 41. shiny new £ U my features!!! £A + £B my opportunities!!! legacylegacy
  42. 42. shiny new £ U my features!!! £10,000/m £A + £B my opportunities!!! legacylegacy
  43. 43. shiny new £ U my features!!! £10,000/m £10,000*x £A + £B my opportunities!!! legacylegacy
  44. 44. shiny new £ U my features!!! £A + £B my opportunities!!! legacylegacy
  45. 45. £A + £B £ U my features!!! shiny new my opportunities!!! legacylegacy
  46. 46. shiny new £A + £B + £C my opportunities!!! £ U my features!!! legacylegacy
  47. 47. my opportunities!!! £ shiny new £A + £B + £C*? my opportunities!!! £ U my features!!! legacylegacy my opportunities!!! £ my opportunities!!! £
  48. 48. it does not work! Well, not always...
  49. 49. Why do legacy projects suck?
  50. 50. Cost Time cost of change
  51. 51. How do we balance the cost of change?
  52. 52. Cost Time cost of ownership
  53. 53. Cost Time cost of ownership
  54. 54. Cost Time cost of change cost of ownership
  55. 55. Cost Time rewrite
  56. 56. take ownership only when you need to support change
  57. 57. … Of change where?
  58. 58. Innovation Predictability
  59. 59. Innovation Predictability
  60. 60. Innovation Predictability Constant change, never ideal Rarest change, good is good enough
  61. 61. Questionnaire 1. Where is this product going? 2. Which features need to change? 3. How are they going to change? 4. How to support that change?
  62. 62. “BDD Pipeline” 1. Where is this product going? 2. Which features need to change? 3. How are they going to change? 4. How to support that change? • Impact Mapping • Value Prioritisation • Example (3 Amigos) Workshop • BDD layers
  63. 63. 1. Where is this product going? Impact Mapping
  64. 64. – Gojko Adzic “Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.”
  65. 65. Four levels of Impact Map 1. Why? are we doing all this (rewrite)? What is the goal we’re trying to achieve? 2. Who? will be impacted by it? 3. How? can they help us to achieve the goal? 4. What? can we do to support them?
  66. 66. MVP
  67. 67. Product Backlog
  68. 68. In order to buy more products As a customer I need to have a product autocompletion in the search field
  69. 69. 2. Which features are going to change? Value Prioritisation
  70. 70. In order to maintain my shopping history As a site visitor I need to be able to register on this site
  71. 71. In order to maintain my shopping history As a site visitor I need to be able to register on this site benefit actor
  72. 72. SELECT s.* FROM backlog as s ORDER BY s.role, s.benefit LIMIT 25
  73. 73. 3. How are these features going to change? Example (3 Amigos) workshops
  74. 74. Three layers of a User-Story • Business rule(s) • Communication • Acceptance criteria
  75. 75. Three layers of a User-Story • Business rule(s) • Communication in Examples • Acceptance criteria
  76. 76. In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  77. 77. Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  78. 78. Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  79. 79. Scenario: ... Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  80. 80. Scenario: ... Scenario: ... Scenario: ... Scenario: ... Scenario: ... Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  81. 81. Given a customer previously bought a black sweater from us And we currently have three black sweaters left in stock When customer returns the sweater for a refund Then we should have four black sweaters in stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  82. 82. 4. How to support that change?
  83. 83. Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock Given a customer previously bought a black sweater costing 15$ from us And we currently have three black sweaters left in stock When customer returns the sweater for a refund Then we should have four black sweaters in stock And customer account should be debited with 15$
  84. 84. Step#1: Identify change area
  85. 85. Step#2: Identify old logic
  86. 86. Step#3: Discuss old logic 1. What should this thing do 2. What if it suddenly stops doing it? 3. How would you know if it doesn't work? 4. How would you know if it does?
  87. 87. Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  88. 88. Scenario: Cost of refunded item should be returned to customer bank account Scenario: Cost of refunded item should be returned to customer PayPal account Scenario: Cost of refunded item should be returned to customer via in-shop credits Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  89. 89. @legacy Scenario: Cost of refunded item should be returned to customer bank account @legacy Scenario: Cost of refunded item should be returned to customer PayPal account @legacy Scenario: Cost of refunded item should be returned to customer via in-shop credits Scenario: Replaced items should be returned to stock Scenario: Refunded items should be returned to stock In order to keep track of stock As a store owner I want to add items back to stock when they are returned Feature: Returned items go back to stock
  90. 90. Step#4: Prepare for A change 1. Cover old behaviour in an end-to-end fashion 2. Make sure that scenarios/tests are green 3. Refactor code to make the lower testing possible 4. Convert scenarios/tests to lower level tests
  91. 91. Step#5: Make a change 1. Automate new scenarios 2. Make scenarios green by applying BDD loops
  92. 92. Stories Examples Describe Implement Design
  93. 93. Working system
  94. 94. 1 year later…
  95. 95. Same ashtrays, better system
  96. 96. Stop dreaming of a greater code Find a way to deliver a greater value
  97. 97. We do that for clients And help others to do it http:// .com
  98. 98. Thank you! @everzet

×