Adopting technical practices 2013
4 likes3,480 views
Steven Mak shares stories and lessons from coaching teams in adopting agile practices. He emphasizes understanding the existing problems, preparing the team through training and coaching, establishing a definition of done, using examples and tests to define requirements, and practicing techniques like pair programming, coding dojos, and code katas. The goal is for teams to learn new skills through repeated practice in a low-pressure environment.
Adopting technical practices 2013
- 1. Stories of adopting technical practices Steven Mak Saturday, 27 July, 13
- 2. Who am I? •Agile, TDD Coaching, Ugly Code Cleaning Dude •I love coding - Java, C#, Javascript, C/ C++, PHP, Perl, and some weird ones •I speak English, Cantonese, and Mandarin 2 Odd-e Pte. Ltd. Steven Mak 麥天志 Agile Coach Hong Kong Email: steven@odd-e.com Web: www.odd-e.com Twitter: stevenmak Saturday, 27 July, 13
- 3. Disclaimer 3 If you hear any stories in this evening, they probably come from some customers I visit recently. No names will be revealed. But any resemblance to actual individuals or events are coincidental. :) 是日分享內容基於工作情節提 而成，如有雷同，實屬不幸 :) Saturday, 27 July, 13
- 4. Before you want to adopt agile practices... What is the problem? • Buggy software? • Schedule slip? • People don’t talk to each other? • Unhappy customers? • Deployment too scary? 4 Learn about these before trying to convince your boss Saturday, 27 July, 13
- 5. Where? • Code quality? • Time spent on bug fixing? • How do these go over a time period? • Interviews - Avoid hypothetical questions, e.g. “Would you like...” - Tell stories, “Tell us about the last time...” • See how others actually work - be careful with your subjective judgement 5 Saturday, 27 July, 13
- 7. 7 What does this mean? Saturday, 27 July, 13
- 8. Longitudinal study 8http://almossawi.com/firefox/prose/ Anything happened during some point in time? • Project deadline? • Firefighting? • Policy change? Saturday, 27 July, 13
- 9. Don’t forget your version control system 9 http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=16679 Saturday, 27 July, 13
- 10. More visualization: JUnit project 10http://dkandalov.github.io/code-history-mining/junit.html Files often commit together? Is there collective code ownership? Which part of the project have more attention? When commit happens? How frequent commit happens? Saturday, 27 July, 13
- 11. What kind of tests in place? 11 Saturday, 27 July, 13
- 12. Why do you want these tests? 12 Saturday, 27 July, 13
- 13. Before you start • Is the team prepare to learn? - Be very careful with busy teams - Do they cover this during retrospectives before? • Are the stakeholders aware of the teams learning new things? • Are there training in place? • Coaches help :) 13 Saturday, 27 July, 13
- 14. Buy-in from the Team • It takes time for the team to learn, allow time in their planning for learning • Any compelling reasons before they will commit to making on the extra work of writing automated tests? • Most team begins with: - Write tests for new code and any changes to existing code • Discuss with the team and see if they are committed to do this • Target of writing a few tests every day 14 Saturday, 27 July, 13
- 15. Lots of Coaching • No structure in place to decide when and with teams to work? • Internal coaches were asked to do normal development? • Not listening to internal coaches? • Coaching skills not appreciated and further developed? • Both internal and external coaching! 15 Saturday, 27 July, 13
- 16. Definition of Done 16 coded and reviewed unit tested documented packaged etc. Activities required for Potentially Shippable Product Increment Sprint Retro- spective Sprint Review Potentially (2-4 h) (1.5-3h) Saturday, 27 July, 13
- 17. Extending “done” 17 implement unit test analysis customer test customer doc performance test marketing material production pricing update manufacturing process current Definition on Done needed to be potentially shippable done undone goal: expand 2 year improvement goal 10 year improvement goal www.craiglarman.com www.odd-e.com Copyright © 2010 C.Larman & B. Vodde All rights reserved. Saturday, 27 July, 13
- 18. Sprint Planning 18 Sprint Planning Part 1 Product Backlog Product Owner 4htimebox Selected Product Backlog Items Sprint Planning Part 2 Sprint Backlog 4htimebox Product Owner Available Team Capabilities Business Conditions Technology Stability Previous Sprint Product Increment input Updated Product Backlog Clarify Requirements Initial Design and Plan output Sprint Goal Saturday, 27 July, 13
- 19. Making commitment • Part 1: - Product Owner decides on which requirements are selected - Team decides how much they can commit rather than assigned by Product Owner - Product Owner and Team collaborates instead of bargain - Product Owner prepares Product Backlog before Sprint Planning - Do not allow un-clarified requirements into the Sprint • Part 2: - Design more than planning - Focus on serious commitment rather than precise estimates - Avoid computers 19 Saturday, 27 July, 13
- 20. How likely are you keeping your promise? 20 No story done two days before the end of sprint? Stories all in progress and waiting for testing? Why testing only happens at the end? Saturday, 27 July, 13
- 21. Starting ATDD/SbE/BDD with product backlog refinement 21 Saturday, 27 July, 13
- 22. Use Examples 22 With 3 judges giving scores 4, 20, and 18, the displayed score should be 42. When the first 2 judges have given their scores, e.g. 10 and 5, the intermediate score of 15 should be displayed already. No scores displayed as a dash (–), not zero. Maximum score from a judge is 20 points! Saturday, 27 July, 13
- 23. Examples, Tests, and Spec 23 Examples Tests Requirements can become elaborate verify Saturday, 27 July, 13
- 24. Technical Activity Workflow Specification pyramid 24 RuleClarity Stability Specification Users can understand Automation Technical Saturday, 27 July, 13
- 25. Tools come after people and interaction • Cucumber • Robot Framework • Fitnesse 25 Saturday, 27 July, 13
- 26. Who wants writing unit tests for legacy code? 26 Saturday, 27 July, 13
- 27. 27 Pair Programming More Pair Programming Study: http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2010/0110/W_SW_PairProgramming.pdf Saturday, 27 July, 13
- 28. Recap... • Training • Coaching • Definition of Done • Budget time in planning • Test Code Coverage... with care • Pair Programming • Practice 28 Saturday, 27 July, 13
- 29. Practice makes prefect! 29 Saturday, 27 July, 13
- 30. Coding Dojo 30 Saturday, 27 July, 13
- 31. Coding Kata 31 “A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. “ “What makes a good practice session? You need time without interruptions, and a simple thing you want to try. You need to try it as many times as it takes, and be comfortable making mistakes. You need to look for feedback each time so you can work to improve. There needs to be no pressure: this is why it is hard to practice in a project environment.” • http://codekata.pragprog.com/ • http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue • http://www.projecteuler.net Saturday, 27 July, 13
- 32. It can be done over the Internet too! 32 Saturday, 27 July, 13
- 33. 33 Cyber Dojo www.cyber-dojo.com Saturday, 27 July, 13
- 35. 35 Going Internet doesn’t mean we can’t do it face to face Saturday, 27 July, 13
- 36. Let’s make it whole day! (in Taipei too) 36 Saturday, 27 July, 13
- 37. Code Retreat 37 • Same kata throughout the group, typically Conway’s game of life • Every pair is working at the same time • Switch pair often to enhance learning http://coderetreat.com/ Saturday, 27 July, 13
- 38. Example constraints 38 • Only one level of indentation per method • Don’t use “else” • Wrap all primitives, strings, and even lists • One dot per line • Don’t abbreviate names • No more than two instance variable per class • Don’t use setters, getters, or properties Saturday, 27 July, 13
- 39. Thank you for spending time with me this evening. More feedback can be sent to: 39 Odd-e Hong Kong Ltd. Steven Mak 麥天志 Agile Coach Hong Kong Email: steven@odd-e.com Web: www.odd-e.com Twitter: stevenmak Saturday, 27 July, 13