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.
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
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
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
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
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
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
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
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
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
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
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