Practices of an agile developer


Published on

This presentation was used in "Agile workshop for FPT Aptech Hanoi students" in December 2012.
This doc covers most of core practices of an agile developer.

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Practices of an agile developer

  1. 1. Practicesof anAgile Developer From Good to Great Agile Workshop at FPT-Aptech Hanoi, 24-28/9/2012
  2. 2. Agenda• WhatWhy is agile • Developer Testing development? with TDD• Mastery Level • Incremental and• Pair-Programming testable design• Mocking and • Coding Dojo Feedback • Refactoring• Incremental building techniques• Collaborative coding • Refactoring Dojo • Dojo Initiative at FAT Centers 2
  3. 3. TODO  Introduction  Mastery level  WhatWhy Agile Developers? Day 1  Working in Pair  Customer collaborationBEGINNING  Mocking and Feedback  Pair Programing  Communication in Code AGILITY  Code in Increment  Review and Retrospectives  Introduce the next session, and the translation work 3
  4. 4. Expert Competent Proficient Bruce Lee – Master of Kungfu Advanced Beginner NoviceLearnt Wing Chun @ 13 Image:
  5. 5. Văn ôn Võ luyện @ Dojo (Võ đường)10.000 hours of practicing Image: VOV, CNN 5
  6. 6. Sequential vs. overlapping Sequential development Overlapping developmentSource: “The New New Product Development Game” by Takeuchiand Nonaka. Harvard Business Review, January 1986. 6
  7. 7. Why agile? Agile Benefits students:3x SUCCESS RATE  Great framework & tools for learning  Improve skills better  Better Employability  Master software development Charts: 1. The CHAOS Manifestor, The Standish Group 2012 2. Methodologies popularity, Forrester Research, 2010 7
  8. 8. FDD XPScrum Agile Lean Software AgileDevelopment UP 8
  9. 9. Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Throughthis work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 9
  10. 10. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.12 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to andPrinciples within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 10
  11. 11. Fast delivery Iteration … Time 11
  12. 12. Practices process SHU HA RIFollow rules until sink in Reflect on rules Forget the rules Look for exceptions, Beaks the rules 12
  13. 13. Development Flow $ $Collaboration: PO DevTeam PO UI Mocking Design Draft Code the RefactoringSteps: Requirement •Customer •Design skeleton to Coding in and Build the Analysis discussion Discussion test the team increment Refinement design Interface IDo{ //TODO … A Interface IDo{ } //TODO … Class A{ IDo } method1(){ As a super user, Class A{ //Mr. A codes hereArtifacts: I want to … //TODO … } } B } Class B:IDo{ Class B:IDo{ //TODO … method1(){ } //Mrs. B codes here } } Note: 1. TDD|BDD|AMDD can be used or not Class C{ 2. Images are for illustration only } 13
  14. 14. Feedback• For transparency & adaptability• Should be CONSTANT• Sources: – System • Using testing, coding – Users • During requirement discussion, demo, sprint review – Team • During code, test, design and “chit chat” 14
  15. 15. Listen to the users• Let them do acceptance testing• “It’s a bug” : Every complaint holds a truth. => There is no ‘stupid user’. 15
  16. 16. Mocking|Prototyping• Easy• Saving time & $• Prompt Feedback• Understanding Requirement from end users Image:,, Conorogohagan 16
  17. 17. Tools, whatever you choose … Balsamiq … Paper Pencil 17
  18. 18. Pair-Programming He drives Tactics FocusedHe navigatesStrategies Focused 1 pair, 1 PC, 1 problem, 1 goal Image: wikipedia 18
  19. 19. Pair Programming• Better communication •Driver• Increased discipline doesn’t see the big picture• Better code • The Driver should “step a• Resilient flow way from the keyboard”• Improved morale• Collective code • The Navigator tends to use pattern- ownership matching problem• Mentoring solving technique• Team cohesion 19
  20. 20. Program Intently and Expressively • Code should provide high-level of: – readability and – understandability. private object makeCoffeeLock = new object();public void MakeCoffee(){ public void MakeCoffee() lock(this) { { lock(makeCoffeeLock) // ... operation { } // ... operation} } } 20
  21. 21. Communication in Code• Use standard comments for communication, avoid misunderstanding and create “developer manual”• Document code using well chosen, meaningful names.• Use comments to describe its purpose and constraints.• BUT Don’t use commenting as a substitute for good code.• Use tools for help: RDoc, javadoc, and ndoc, IDEs 21
  22. 22. Communication tools• Whiteboard• Sticky note• Email• Version control• Wiki• Blog• Task management tools• Issue trackers 22
  23. 23. Trade-off and Simplicity• “There is no best solution”• Code incrementally, not a “big bang” – Use of TODO + skeleton before code• Keep It Simple, Stupid! but not simplistic• Write High-Cohesive, Low-Coupled Code – Efficient Use of Design Patterns 23
  24. 24. Keep it releasable• Use version control for sharing code and builds – integrate early and often – Tools: SVN, CVS, Git• Commit “potentially shippable code” to contribute the “potentially shippable product”.• Automate build and deployment early – Preparing scripts, manuals, settings etc. – Tools: Ant, Maven, Hudson 24
  25. 25. Day 2 BUILT TODO  WhatWhy is developer testing?QUALITY  TDD and test strategies  JUnit  Simple design IN  Coding Dojo  What did we do?  Review and Retrospectives 25
  26. 26. Cost of bugs 26
  27. 27. Technical DebtLack of building Business pressuresloosely coupledcomponents Lack of process or Lack of test understandingParallel DelayedDevelopment Refactoring 27
  28. 28. Test-Driven Development• You don’t start programming until you have designed your tests!• Strategy – Make it Fail • No code without a failing test – Make it Work • As simply as possible – Make it Better • Refactor(code, design, test, documentation) – Believe in testing 28
  29. 29. Design4Test Design Testable Test Test Implement 29
  30. 30. Design for Functional Testing• Very basic strategies: – Error guessing – Equivalence partitioning – Boundary-value analysis –Data Flow Testing –Explanatory Testing 30
  31. 31. Equivalence Classes• Purpose: reduce the number of test cases by not considering all possible inputs• Equivalence partitioning – One representative of class of inputs/outputs is equivalent to all members of the class – Minimize the number of test cases• Testing based on equivalence partitioning is a step process – Identify the equivalence classes (EC) – Identify the test cases 31
  32. 32. Boundary Value Analysis The values used to test the extremities are : • Min ------------------------------------ - Minimal • Min+ ------------------------------------ - Just above Minimal • Nom ------------------------------------ - Average • Max- ------------------------------------ - Just below Maximum • Max ------------------------------------ - Maximum 32
  33. 33. Robustness TestingRobustness testing has the desirable property that it forces attention onexception handling 33
  34. 34. Worst-Case Testing 34
  35. 35. Robust Worst-Case TestingIf the function under test wereto be of the greatestimportance we could use amethod named Robust Worst-Case testing which as thename suggests draws itattributes from Robust andWorst-Case testing.Blake Neate 35
  36. 36. Data Flow Testing This method examines the full flows of execution, set verification points to critical nodes for testing.What is Conditional Complexity? 36
  37. 37. Explanatory Testing Which “Justin” do you want to appear first? 37
  38. 38. Error Guessing• Ad hoc approach – Use intuition and experience to derive tests – “This usually screws things up so let’s try this.”• Make a list of possible errors or error-prone situations: – Empty/null lists/strings – Zero instances/occurrences – Blanks/null chars in strings – Negative numbers / zero – Garbage chars/input – All coded exceptions 38
  39. 39. Strive for Simplicity 39
  40. 40. Design is the key, Planned Design is not …• Takeuchi & Nonaka: overlapping is better than sequential Not efficient: • Time consuming • No backward • No “better idea” on the go But how to do this kind of overlapping development? 40
  41. 41. What is Simple Design?• Design grows as implementation – Complete design NOT required. Just enough, GO!• Part of programming Evolve processes• Program evolves the design changes• Not “code and fix” tactics 41
  42. 42. Simplicity Rationale behind Simple Design• "Do the Simplest Thing that Could Possibly Work“• "You Arent Going to Need It“• Invest in patterns• Simple system 1. Runs all the Tests 2. Reveals all the intention 3. No duplication 4. Fewest number of classes or methods 42
  43. 43. Simplistic vs. Simplicity Ignorance AwarenessInattention Knowledge Laziness Spirit of helping Deception Honesty, SincerityEasy for us Easy for them From Garry Reynold’s 43
  44. 44. Design for Communication• Draw design stuffs for discussion within your team – Just enough for clarifying solutions• Only use diagrams that you can keep up to date without noticeable pain• Keep diagrams visible – Post to wall or board – Encourage people to edit• Pay attention to whether people are using them, if not throw them away. 44
  45. 45. Design for Construction• “Working software is the primary measure of progress”• Your design will be realized into a working item, so: – Design should be code-able in team • separation, interfacing, collaboration between components – Design should be testable – “Architect must code!” 45
  46. 46. Refactoring for simplicity Discussed in Next section … 46
  47. 47. How about Architecture?• PO works with DevTeam to specify – Technologies used – Frameworks used – Initial Architecture• Before Sprint 1 – @User Story Writing workshop – @ Initial Requirement Envisioning and Initial Architecture Envisioning 47
  48. 48. Evolution of ModelsProduct Items burntBacklog Items burnt updated story V1 V2 V1com.myapp.Models IDo IDo C1 C1 com.myapp.Views M1 M2 M1 com.myapp.ControllersInitial Architecture Model1 Model 2 Sprint 0 Sprint 1 Sprint 2 48
  49. 49. “Continuous” Architecting Sprint #1: without layeringPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 49
  50. 50. “Continuous” Architecting Sprint #2: refactoring to layersPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 50
  51. 51. “Continuous” Architecting Sprint #3: architecting “on the go”Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 51
  52. 52. Day 3 TODOREFACTORING  Refactoring for better code  Refactoring Dojo TO  Dojo RetrospectivesBETTER CODE  Review the final translation  Closing Retrospectives and Remarks 52
  53. 53. Refactoring• For simpler design• For maintenanceupgrade later• MustHave task in your DoneDefinition checklist• Invest in patterns and best practices 53
  54. 54. Refactoring• You practice “code a bit, fix a little” => result in dirty code & bad design.• Refactoring helps in restructure or design your code to make it better. – what does “better” mean?• Minimize “Technical Debt” for yourself• Keep in mind: – Maintainability – Extensibility – High Cohesion – Low Coupling 54
  55. 55. Refactoring Techniques• For abstraction – Encapsulate Field – Generalize Type – Replace type-checking code with State/Strategy – Replace conditional with polymorphism• For breaking code apart – Extract Method, turn part of a larger method into a new method – Extract Class• For improving code standard – Move Method or Move Field – Rename Method or Rename Field – Pull Up, move to a superclass – Push Down, move to a subclass 55
  56. 56. Code Review• Very efficient in finding Receipt problems • Can you read and understand the code?• “Bug-prevention” • Are there any obvious errors? • Will the code have any undesirable• Styles: effect on other parts of the application? – The all-nighter • Is there any duplication of code (within this section of code itself – The pick-up game or with other parts of the system)? – Pair programming • Are there any reasonable improvements or refactorings that can improve it? 56
  57. 57. Retrospectives Bridge Image: Rachel Davies & Liz Sedley 57
  58. 58. Be PlanAct Do BETTER always Check 58
  59. 59. References and Resources• Venkat Subramaniam & Andy Hunt, Practices of an Agile Developer• Peter Norvig, “Teach Yourself Programming in Ten Years”(•••• James Shore, “The Art of Agile Development” ( )• Martin Fowler, Is Design Dead? ( )• Martin Fowler, 59