eXtreme Programming In Action Radoslav Nemchev Nemetschek OOD

1. eXtreme Programming In ActionRadoslav NemchevNemetschek OOD eXtreme programming - principles & practices

2. XP in action • Choose the project • Involve the customer • Involve the team • Apply the practices • Automate eXtreme programming - principles & practices

3. Choose the project • Not too big • Not too small • Not too important • Not too unimportant eXtreme programming - principles & practices

4. Involve the Customer How to make him work the XP way? Who is the customer? eXtreme programming - principles & practices

5. Involve the team • Guarantee them immunity • Give them time • Strictly control the practices application • Let them see the benefits by themselves • Provide communication – stand-up meetings, open workspace,… • Shared understanding and responsibility for the system – System Metaphor eXtreme programming - principles & practices

6. Apply the practices • Introducing all practices at once, or just one practice at a time? Answer: Adopt one practice at a time. • What the order should be? Answer: Follow the natural order – from CR oriented through design to testing and coding. eXtreme programming - principles & practices

7. Customer on-site • Customer or Developer on-site? • Get the user stories • Make him determine priorities – high business value first • Get him to give you immediate and frequent feedback • Involve him into specification of functional acceptance tests eXtreme programming - principles & practices

8. Planning game • How to plan? • Create and prioritize user stories - customer • Estimate difficulties - developers • Select stories for next release - customer • Split stories into tasks - developers • Plan the tasks for the next iteration - customer/developers eXtreme programming - principles & practices

9. My program is all or nothing! Wrong! Inside every large program there are lots of little programs trying to get out. Make them into small releases. Make as many iterations as possible per release Keep good track of progress Deliver business value to the customer fast Gives sense of accomplishment to the team Keep the team focused Small Releases eXtreme programming - principles & practices

10. Test-Driven development Design a test that will fail Compile it and check that it fails Write just enough code to make the test run Design evolves from tests The benefit must be higher than the cost Testing slows you down? Apply same quality standards for test and code Tests ARE documentation Automate Test First eXtreme programming - principles & practices

11. Collaborators of the unit under test are: Trustworthy Implicit usage Object Mother Pattern Substituted in the test Stubs Self-shunt pattern Mock objects Isolation Testing eXtreme programming - principles & practices

12. NUnit • Unit tests framework • Write tests • Execute tests • Assert results • Show tests failure/success • Keep the bar green • http://nunit.org/default.htm eXtreme programming - principles & practices

13. NUnit test example eXtreme programming - principles & practices

14. Write test that will fail eXtreme programming - principles & practices

15. Write just the code that makes the test pass eXtreme programming - principles & practices

16. Why refactor? Nobody does it quite right the first time To improve design To simplify code To ease future changes in the code When do we refactor? Continuously When code or test smells Automation Refactoring eXtreme programming - principles & practices

17. C# Refactory • Integrated tool for Visual Studio • Simplifies code refactoring • Performs automatic code metrics collection • http://www.xtreme-simplicity.net/ eXtreme programming - principles & practices

18. Integration into MS Visual Studio eXtreme programming - principles & practices

19. Code metrics collection eXtreme programming - principles & practices

20. Refactoring with C# Refactory eXtreme programming - principles & practices

21. Member reference finder eXtreme programming - principles & practices

22. How to achieve this? Evolutionary design – design evolves while coding and refactoring If you don’t need it now, you won’t need it ever -develop only functionality that is required Satisfy tests in the simplest possible way Refactoring as soon as the tests run And again – keep it as simple as possible! Simple design eXtreme programming - principles & practices

23. What? Everybody is involved, everybody is interested Everybody understands and is responsible for: Base architecture Whole system How? Don’t separate the team into designers and coders Change pairs often System Metaphor eXtreme programming - principles & practices

24. Why? 2 > 1 Two programmers will understand the code Keeps programmers focused When do it? XP says always Is it possible in real life? Is it really necessary all the time? Pair programming eXtreme programming - principles & practices

25. You can’t put it off forever. Better do it all the time Spare yourself the Big Bang disaster Keep the tests working 100% during the integration Use a dedicated integrated machine Keep the build time low Automate through scripts, tools, etc… Continuous Integration eXtreme programming - principles & practices

26. This is not my object! WRONG! Use version control system – CVS, VSS, … You brake it, you fix it Collective Code Ownership eXtreme programming - principles & practices

27. MS Visual Source Safe • Automates Continuous Integration and Collective Code Ownership • Provides version tracking • Integrates with MS Visual Studio eXtreme programming - principles & practices

28. I can always read my own code. Wait, it’s all my code! Let the team setup coding standards prior to coding and agree on them Force coding standards application, no exceptions Keep it simple Coding Standards eXtreme programming - principles & practices

29. Tired people make mistakes Tired people tend to overlook things like testing, refactoring, etc. Work at maximum concentration 8 hours per day 6 PM – you are tired, go home Don’t work more than 1 consecutive week of overtime 40 hour week eXtreme programming - principles & practices