Practices of an agile developer
Upcoming SlideShare
Loading in...5
×
 

Practices of an agile developer

on

  • 642 views

This presentation was used in "Agile workshop for FPT Aptech Hanoi students" in December 2012.

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.

Statistics

Views

Total Views
642
Views on SlideShare
642
Embed Views
0

Actions

Likes
3
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Practices of an agile developer Practices of an agile developer Presentation Transcript

  • Practicesof anAgile Developer From Good to Great TanDT@fpt.edu.vn Agile Workshop at FPT-Aptech Hanoi, 24-28/9/2012
  • 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
  • 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
  • Expert Competent Proficient Bruce Lee – Master of Kungfu Advanced Beginner NoviceLearnt Wing Chun @ 13 Image: http://goo.gl/1RzEE4
  • Văn ôn Võ luyện @ Dojo (Võ đường)10.000 hours of practicing Image: VOV, CNN 5
  • Sequential vs. overlapping Sequential development Overlapping developmentSource: “The New New Product Development Game” by Takeuchiand Nonaka. Harvard Business Review, January 1986. 6
  • 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
  • FDD XPScrum Agile Lean Software AgileDevelopment UP 8
  • 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. AgileAlliance.org 9
  • 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.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
  • Fast delivery Iteration … Time 11
  • Practices process SHU HA RIFollow rules until sink in Reflect on rules Forget the rules Look for exceptions, Beaks the rules 12
  • 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
  • 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
  • Listen to the users• Let them do acceptance testing• “It’s a bug” : Every complaint holds a truth. => There is no ‘stupid user’. 15
  • Mocking|Prototyping• Easy• Saving time & $• Prompt Feedback• Understanding Requirement from end users Image: Alistapart.com, ACU.edu.au, Conorogohagan 16
  • Tools, whatever you choose … Balsamiq … Paper Pencil 17
  • Pair-Programming He drives Tactics FocusedHe navigatesStrategies Focused 1 pair, 1 PC, 1 problem, 1 goal Image: wikipedia 18
  • 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
  • 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
  • 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
  • Communication tools• Whiteboard• Sticky note• Email• Version control• Wiki• Blog• Task management tools• Issue trackers 22
  • 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
  • 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
  • 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
  • Cost of bugs 26
  • Technical DebtLack of building Business pressuresloosely coupledcomponents Lack of process or Lack of test understandingParallel DelayedDevelopment Refactoring 27
  • 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
  • Design4Test Design Testable Test Test Implement 29
  • Design for Functional Testing• Very basic strategies: – Error guessing – Equivalence partitioning – Boundary-value analysis –Data Flow Testing –Explanatory Testing 30
  • 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
  • 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
  • Robustness TestingRobustness testing has the desirable property that it forces attention onexception handling 33
  • Worst-Case Testing 34
  • 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
  • Data Flow Testing This method examines the full flows of execution, set verification points to critical nodes for testing.What is Conditional Complexity? 36
  • Explanatory Testing Which “Justin” do you want to appear first? 37
  • 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
  • Strive for Simplicity 39
  • 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
  • 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
  • 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
  • Simplistic vs. Simplicity Ignorance AwarenessInattention Knowledge Laziness Spirit of helping Deception Honesty, SincerityEasy for us Easy for them From Garry Reynold’s 43
  • 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
  • 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
  • Refactoring for simplicity Discussed in Next section … 46
  • 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
  • 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
  • “Continuous” Architecting Sprint #1: without layeringPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 49
  • “Continuous” Architecting Sprint #2: refactoring to layersPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 50
  • “Continuous” Architecting Sprint #3: architecting “on the go”Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 51
  • Day 3 TODOREFACTORING  Refactoring for better code  Refactoring Dojo TO  Dojo RetrospectivesBETTER CODE  Review the final translation  Closing Retrospectives and Remarks 52
  • Refactoring• For simpler design• For maintenanceupgrade later• MustHave task in your DoneDefinition checklist• Invest in patterns and best practices 53
  • 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
  • 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
  • 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
  • Retrospectives Bridge Image: Rachel Davies & Liz Sedley 57
  • Be PlanAct Do BETTER always Check 58
  • 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