Moving away from legacy code (AgileCymru)
•
5 gostaram•2,814 visualizações
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.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Moving away from legacy code (AgileCymru)
Semelhante a Moving away from legacy code (AgileCymru) (20)
Mais de Konstantin Kudryashov
Último
Último (20)
Moving away from legacy code (AgileCymru)
- 1. Moving away from legacy code with BDD
- 2. BDD Practice Manager Creator of Behat - Cucumber for PHP Software Engineer turned Stakeholder whisperer Konstantin Kudryashov @everzet
- 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
- 5. How most teams see their next project
- 7. our next project their actual next project
- 8. Agile, TDD, BDD, etc… // TODO: refactor later
- 9. Is it really that bad?
- 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. // TODO: refactor later
- 12. // TODO: refactor later
- 13. // TODO: refactor later
- 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. You deliver value Just not as effectively as you could
- 16. Great value + Awful code = Great product yesterday
- 17. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow
- 18. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow No value + Any code = Awful product anytime
- 19. Great value + Awful code = Great product yesterday No value + Any code = Awful product anytime
- 20. Great value + Awful code = Great product yesterday Great value + Great code = Great product tomorrow
- 21. // TODO: refactor laterAgile, TDD, BDD, etc…
- 24. learning
- 26. learning • Agile • XP • BDD trash bin else
- 27. learning • Agile • XP • BDD trash bin else
- 28. learning • Agile • XP • BDD trash bin else
- 29. Working system
- 30. 1 year later…
- 32. how come?
- 33. learning • Agile • XP • BDD trash bin else
- 34. learning • Agile • XP • BDD trash bin else
- 35. legacylegacy
- 36. legacylegacy
- 41. shiny new £A + £B U my features!!! legacylegacy
- 42. shiny new £ U my features!!! £A + £B my opportunities!!! legacylegacy
- 43. shiny new £ U my features!!! £10,000/m £A + £B my opportunities!!! legacylegacy
- 44. shiny new £ U my features!!! £10,000/m £10,000*x £A + £B my opportunities!!! legacylegacy
- 45. shiny new £ U my features!!! £A + £B my opportunities!!! legacylegacy
- 46. £A + £B £ U my features!!! shiny new my opportunities!!! legacylegacy
- 47. shiny new £A + £B + £C my opportunities!!! £ U my features!!! legacylegacy
- 48. my opportunities!!! £ shiny new £A + £B + £C*? my opportunities!!! £ U my features!!! legacylegacy my opportunities!!! £ my opportunities!!! £
- 49. it does not work! Well, not always...
- 50. Why do legacy projects suck?
- 52. How do we balance the cost of change?
- 55. Cost Time cost of change cost of ownership
- 57. take ownership only when you need to support change
- 58. … Of change where?
- 61. Innovation Predictability Constant change, never ideal Rarest change, good is good enough
- 62. 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?
- 63. “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
- 64. 1. Where is this product going? Impact Mapping
- 65. – 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.”
- 66. 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?
- 68. MVP
- 69. Product Backlog
- 71. In order to buy more products As a customer I need to have a product autocompletion in the search field
- 72. 2. Which features are going to change? Value Prioritisation
- 73. In order to maintain my shopping history As a site visitor I need to be able to register on this site
- 74. In order to maintain my shopping history As a site visitor I need to be able to register on this site benefit actor
- 75. SELECT s.* FROM backlog as s ORDER BY s.role, s.benefit LIMIT 25
- 76. 3. How are these features going to change? Example (3 Amigos) workshops
- 77. Three layers of a User-Story • Business rule(s) • Communication • Acceptance criteria
- 78. Three layers of a User-Story • Business rule(s) • Communication in Examples • Acceptance criteria
- 79. 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. 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. 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
- 82. 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
- 83. 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
- 84. 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
- 85. 4. How to support that change?
- 86. 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$
- 87. Step#1: Identify change area
- 88. Step#2: Identify old logic
- 89. 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?
- 90. 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
- 91. 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
- 92. @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
- 93. 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
- 94. Step#5: Make a change 1. Automate new scenarios 2. Make scenarios green by applying BDD loops
- 96. Working system
- 97. 1 year later…
- 98. Same ashtrays, better system
- 99. Stop dreaming of a greater code Find a way to deliver a greater value
- 100. We do that for clients And help others to do it http:// .com
- 101. Thank you! @everzet