adopting technical practices 2013

39
Stories of adopting technical practices Steven Mak Saturday, 27 July, 13

Upload: steven-mak

Post on 08-May-2015

2.568 views

Category:

Technology


1 download

TRANSCRIPT

  • 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: [email protected] 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 dont 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 xing? 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 6. 6 Sonar Saturday, 27 July, 13 7. 7 What does this mean? Saturday, 27 July, 13 8. Longitudinal study 8http://almossawi.com/refox/prose/ Anything happened during some point in time? Project deadline? Fireghting? Policy change? Saturday, 27 July, 13 9. Dont 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. Denition 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 Denition 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-claried 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 renement 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 Workow Specication pyramid 24 RuleClarity Stability Specication 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 Denition 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 34. 34 RED GREEN REFACTOR Saturday, 27 July, 13 35. 35 Going Internet doesnt mean we cant do it face to face Saturday, 27 July, 13 36. Lets make it whole day! (in Taipei too) 36 Saturday, 27 July, 13 37. Code Retreat 37 Same kata throughout the group, typically Conways 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 Dont use else Wrap all primitives, strings, and even lists One dot per line Dont abbreviate names No more than two instance variable per class Dont 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: [email protected] Web: www.odd-e.com Twitter: stevenmak Saturday, 27 July, 13