Download as PDF, PPTX
Uploaded byDUONG Trong Tan
Practices of an agile developer
The document is an agenda for an agile workshop focused on improving developer skills through practices like Test-Driven Development (TDD), pair programming, and collaborative coding. It emphasizes the principles of the Agile Manifesto, outlines methods for delivering quality software, including feedback and refactoring techniques, and discusses the importance of simplicity in design and code. The workshop aims to enhance developer effectiveness and ensure better collaboration to meet customer needs.
More Related Content
![[IGC 2017] 라이엇게임즈 유석문 - 게임 개발의 Agile Best Practices](https://cdn.slidesharecdn.com/ss_thumbnails/igc2017inpptriotgames-170905032242-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Practices of an agile developer
Practices of an agile developer
- 1. Practices of an Agile Developer From Good to Great [email protected] Agile Workshop at FPT-Aptech Hanoi, 24-28/9/2012
- 2. Agenda • WhatWhy isagile • 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. TODO Introduction Mastery level WhatWhy Agile Developers? Day 1 Working in Pair Customer collaboration BEGINNING 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. Expert Competent Proficient Bruce Lee – Master of Kungfu Advanced Beginner Novice Learnt Wing Chun @ 13 Image: http://goo.gl/1RzEE4
- 5. Văn ôn Võluyện @ Dojo (Võ đường) 10.000 hours of practicing Image: VOV, CNN 5
- 6. Sequential vs. overlapping Sequential development Overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. 6
- 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. FDD XP Scrum Agile Lean Software Agile Development UP 8
- 9. Agile Manifesto We areuncovering better ways of developing software by doing it and helping others do it. Through this 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. AgileAlliance.org 9
- 10. 1. Our highestpriority 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 customer's 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 and Principles within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. http://agilemanifesto.org 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. Fast delivery Iteration … Time 11
- 12. Practices process SHU HA RI Follow rules until sink in Reflect on rules Forget the rules Look for exceptions, Beaks the rules 12
- 13. Development Flow $ $ Collaboration: PO DevTeam PO UI Mocking Design Draft Code the Refactoring Steps: 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 here Artifacts: 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. 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. Listen to theusers • Let them do acceptance testing • “It’s a bug” : Every complaint holds a truth. => There is no ‘stupid user’. 15
- 16. Mocking |Prototyping • Easy • Savingtime & $ • Prompt Feedback • Understanding Requirement from end users Image: Alistapart.com, ACU.edu.au, Conorogohagan 16
- 17. Tools, whatever youchoose … Balsamiq … Paper Pencil 17
- 18. Pair-Programming He drives Tactics Focused He navigates Strategies Focused 1 pair, 1 PC, 1 problem, 1 goal Image: wikipedia 18
- 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. Program Intently andExpressively • 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. 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. Communication tools • Whiteboard • Sticky note • Email • Version control • Wiki • Blog • Task management tools • Issue trackers 22
- 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. 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. 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. Cost of bugs 26
- 27. Technical Debt Lack ofbuilding Business pressures loosely coupled components Lack of process or Lack of test understanding Parallel Delayed Development Refactoring 27
- 28. Test-Driven Development • Youdon’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. Design4Test Design Testable Test Test Implement 29
- 30. Design for FunctionalTesting • Very basic strategies: – Error guessing – Equivalence partitioning – Boundary-value analysis –Data Flow Testing –Explanatory Testing 30
- 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. 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. Robustness Testing Robustness testinghas the desirable property that it forces attention on exception handling 33
- 34.
- 35. Robust Worst-Case Testing Ifthe function under test were to be of the greatest importance we could use a method named Robust Worst- Case testing which as the name suggests draws it attributes from Robust and Worst-Case testing. Blake Neate 35
- 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. Explanatory Testing Which “Justin” do you want to appear first? 37
- 38. Error Guessing • Adhoc 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.
- 40. Design is thekey, 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. 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. Simplicity Rationale behind Simple Design • "Do the Simplest Thing that Could Possibly Work“ • "You Aren't 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. Simplistic vs. Simplicity Ignorance Awareness Inattention Knowledge Laziness Spirit of helping Deception Honesty, Sincerity Easy for us Easy for them From Garry Reynold’s 43
- 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. 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. Refactoring for simplicity Discussed in Next section … 46
- 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. Evolution of Models Product Items burnt Backlog Items burnt updated story V1 V2 V1 com.myapp.Models IDo IDo C1 C1 com.myapp.Views M1 M2 M1 com.myapp.Controllers Initial Architecture Model1 Model 2 Sprint 0 Sprint 1 Sprint 2 48
- 49. “Continuous” Architecting Sprint #1: without layering Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 49
- 50. “Continuous” Architecting Sprint #2: refactoring to layers Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 50
- 51. “Continuous” Architecting Sprint #3: architecting “on the go” Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 51
- 52. Day 3 TODO REFACTORING Refactoring for better code Refactoring Dojo TO Dojo Retrospectives BETTER CODE Review the final translation Closing Retrospectives and Remarks 52
- 53. Refactoring • For simplerdesign • For maintenanceupgrade later • MustHave task in your DoneDefinition checklist • Invest in patterns and best practices 53
- 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. Refactoring Techniques • Forabstraction – 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. Code Review • Veryefficient 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. Retrospectives Bridge Image: Rachel Davies & Liz Sedley 57
- 58. Be Plan Act Do BETTER always Check 58
- 59. References and Resources •Venkat Subramaniam & Andy Hunt, Practices of an Agile Developer • Peter Norvig, “Teach Yourself Programming in Ten Years” (http://norvig.com/21-days.html) • http://www.extremeprogramming.org/ • http://xprogramming.com/index.php • http://xp123.com/ • James Shore, “The Art of Agile Development” (http://jamesshore.com/Agile-Book/ ) • Martin Fowler, Is Design Dead? (http://martinfowler.com/articles/designDead.html ) • Martin Fowler, http://refactoring.com/ 59