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.

1. Practices
of an
Agile Developer
From Good to Great
TanDT@fpt.edu.vn
Agile Workshop at FPT-Aptech Hanoi, 24-28/9/2012

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. 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 are uncovering 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 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 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 the users
• Let them do
acceptance testing
• “It’s a bug” :
Every complaint holds a
truth.
=> There is no ‘stupid user’.
15

16. Mocking
|Prototyping
• Easy
• Saving time & $
• Prompt
Feedback
• Understanding
Requirement
from end users
Image: Alistapart.com, ACU.edu.au, Conorogohagan 16

17. Tools, whatever you choose …
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 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. 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 of building Business pressures
loosely coupled
components Lack of process
or
Lack of test understanding
Parallel Delayed
Development Refactoring
27

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. Design4Test
Design Testable
Test Test
Implement
29

30. Design for Functional Testing
• 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 testing has the desirable property that it forces attention on
exception handling
33

34. Worst-Case Testing
34

35. Robust Worst-Case Testing
If the 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
• 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. Strive for Simplicity 39

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. 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 simpler design
• 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
• 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. 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. 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