Creating change from within - DevReach 2012
•
0 j'aime•557 vues
Session from DevReach 2012 on how to facilitate change in a waterfall organization.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Creating change from within - DevReach 2012
Similaire à Creating change from within - DevReach 2012 (20)
Plus de Dror Helper
Plus de Dror Helper (20)
Dernier
Dernier (20)
Creating change from within - DevReach 2012
- 1. Create change from within – the Agile Developer’s story Dror Helper | Better Place
- 2. About.Me • Software Developer 9+ years • Team’s technical lead • TDD/Unit testing enthusiast • Some SCRUM/Kanban background • Blogger – http://blog.drorhelper.com www.devreach.com
- 3. The problem with Agile We don’t have time It would never work in this I don’t want to do this! project www.devreach.com
- 4. What can one person do? www.devreach.com
- 5. My team 2010 • One manager + 3 developers • Unit tests – more or less • Iteration tracking ? • Manual deployment • Code reviews www.devreach.com
- 6. My 1st week on the job www.devreach.com
- 8. Step #1 - Analysis • Took two days to fix 40% of tests • Find what are the main issues – and focus on them – Not readable – Using logic inside test – Testing too much – Hand rolled mocks – Scenarios hiding as unit tests – Highly coupled code www.devreach.com
- 9. Step #2 – CI Server Build Server What’s new? Commit There you go Source Control www.devreach.com Build Agents
- 10. Step #3 - Teach the team www.devreach.com
- 11. Communicate! • Email • Phone call • Face to face • Presentation • Code reviews • Pair programming • Daily meetings www.devreach.com
- 12. The power of code reviews
- 13. Immediate steps • MSTest • Write new test before fixing bug • Fix existing tests when implementing new features • Delete obsolete tests www.devreach.com
- 14. Change is iterative • Hard to perform big changes overnight • Small incremental changes www.devreach.com
- 15. Today • More than 5000 tests • Good code coverage • Most features are developed using TDD • CI server run all tests on commit • Nightly builds • Change code without fear www.devreach.com
- 16. DECIDING WHAT TO CHANGE www.devreach.com
- 17. Passion is a must! • Become champion • Need to convince co-workers • Survive the road www.devreach.com
- 18. The cost of change Participants Maintenance Effort (Time) Cost of Change Emotional Cost (Money) Value Previous investment www.devreach.com
- 22. Post it + wall www.devreach.com
- 25. Be pragmatic • Every action should have a purpose • If it doesn’t work – change it! • Names are not important – just what you do • Practices can be adapted for the team Know where to draw the line www.devreach.com
- 26. TFS + Work item manager www.devreach.com
- 27. What to when change fails? Understand why it failed Wait and see Choose a different path Cut your losses www.devreach.com
- 29. The right attitude • Be positive • Don’t tell them what to so - suggest improvements • Don’t force – convince • Be ready to change if proven wrong www.devreach.com
- 30. Don’t be “that guy” www.devreach.com
- 31. Enlist help Because You cannot do it all by yourself www.devreach.com
- 32. Journey not a destination www.devreach.com
- 33. Thank you! @dhelper http://blog.drorhelper.com/ http://www.linkedin.com/in/drorhelper Dror Helper | Better Place
Notes de l'éditeur
- Teach best practices – in the right contextTrack progressFind common issuesAlso pair programming – although I found that managers are more likely to
- Impossible to convince
- We had nothing
- Show then let them decideJust do it!