Creating change from within - Agile Practitioners 2012
•Télécharger en tant que PPTX, PDF•
0 j'aime•421 vues
Faced with management that do not care about "being agile" what can a single developer do? Quite a lot! Every developer has the power to improve the organization he works in in small iterative steps – and I can show you how. If you want to make the change and don't know where to start – look no further, in this session I'll share my experience and show a few tips and tricks I learnt. As well as discuss the do and don'ts that can make all the. - How to be agile developer in a waterfall company. - Influencing people without formal authority. - Using the right practices that makes the difference - How to avoid alienating people - Discovering your allies - Know when to fight and when to "retreat" and cut your losses - Making a change without disrupting the daily routine - What being an agile evangelist is all about
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
Similaire à Creating change from within - Agile Practitioners 2012
Similaire à Creating change from within - Agile Practitioners 2012 (20)
Plus de Dror Helper
Plus de Dror Helper (20)
Dernier
Dernier (20)
Creating change from within - Agile Practitioners 2012
- 1. Creating change from within The Agile Developer story By Dror Helper
- 2. About.Me • Software Developer 9+ years • Team’s technical lead • TDD/Unit testing enthusiast • Some SCRUM/Kanban background • Blogger – http://blog.drorhelper.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
- 4. So what can a single person do?
- 5. Let me tell you about the last year and a half
- 6. The cast Manager Developer Developer Consultant Me
- 7. Team’s methodology • Unit tests – more or less • Iteration tracking? • Manual deploy builds – from developer’s PC • Code reviews
- 8. My 1 st week on the job
- 10. Analysis • Took two days to fix 40% of tests and make all of the test run • Find what are the main issues – and focus on them o Not readable o Using logic inside test o Testing too much o Hand rolled mocks o Scenarios hiding as unit tests o Highly coupled code
- 11. Teach the team And decide on next steps
- 12. CI server Build Server What’s new? Commit There you go Source Control Build Agents
- 13. Immediate steps • Using MSTest • Write test before fixing bug • Fix existing tests when implementing new features • Delete obsolete tests
- 14. Code reviews
- 15. Then came mocking • Hard to explain at the beginning • Instead show them! o Free tools – low cost upfront o Commercial products • Get rid of existing hand-rolled mocks
- 16. And excuses • “I didn’t have enough time so I didn’t write a test” • Crisis mode • I cannot test it – so I won’t… • There’s no need to test everything • It’s much better to have one big test • Remember not to be discouraged
- 17. Today • More than 3000 tests • Good code coverage • Most features are developed using TDD • CI server run all tests on commit • Change code without fear
- 18. How to decide what to do?
- 19. Total cost of change Participants Maintenance Effort (Time) Cost of Change Emotional Cost Value (Money) Previous investment
- 20. The most difficult task Replace existing tool or Hard! methodology
- 21. Your knowledge What Subject domain you Gap know
- 23. In the beginning
- 24. Post-it + wall
- 25. Excel in shared folder
- 26. TFS + Work item manager
- 27. Tips and tricks
- 28. The power of code reviews
- 29. Effective Code reviews • Advise don’t force • Review the code not the person • It’s ok to discuss the good things as well • You should get reviewed as well! • After a while team members can review each other
- 30. Have 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 • Don’t be “that guy”
- 31. Communicate! • Email • Phone call • Face to face • Presentation • Coder reviews • Pair programming • Daily meetings
- 33. Enlist Help Because You cannot do it all by yourself
- 34. Change is iterative • Hard to perform big changes overnight • Small incremental changes • Teach the team about the “boy scout rule”.
- 35. 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 • Don’t be a strict task master Know where to draw the line
- 36. Journey not a destination
- 37. Aftermath
- 39. The end? • TDD & unit tests • CI server • Code reviews before commit • Automatic deployment • Task board and iterations • Better estimations • Faster time to deploy
- 40. Thank you
Notes de l'éditeur
- We’ve started with sticky notes
- Several lessons for the whole teamHow to write better testsMocking frameworksWhat is TDDAgree with the whole team on the next tasks
- Now all of the tests must passNew tests have to runNew code have to be tested
- We’ve started with sticky notes
- We had nothing
- Pros:High visibilityEasy to use and maintainCons:Statistics are not automatically createdNeed to go into the room
- Pros:Can access from anywhereCan be sent in emailCons:Only one editor at a timeNeed to add statisticsNot automatic
- Teach best practices – in the right contextTrack progressFind common issuesAlso pair programming – although I found that managers are more likely to
- Don’t force – convinceIt’s ok to be wrong
- Choose you short and long term goalsHave patienceDon’t burn out