practices of an agile developer
DESCRIPTION
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.TRANSCRIPT
Practices of an
Agile Developer
From Good to Great
[email protected] Agile Workshop at FPT-Aptech Hanoi, 24-28/9/2012
Agenda
• What\Why is agile development?
• Mastery Level
• Pair-Programming
• Mocking and Feedback
• Incremental building
• Collaborative coding
• Developer Testing with TDD
• Incremental and testable design
• Coding Dojo
• Refactoring techniques
• Refactoring Dojo
• Dojo Initiative at FAT Centers
2
BEGINNING
AGILITY
Day 1
TODO
Introduction
Mastery level
What\Why Agile Developers?
Working in Pair
Customer collaboration
Mocking and Feedback
Pair Programing
Communication in Code
Code in Increment
Review and Retrospectives
Introduce the next session, and
the translation work
3
Bruce Lee – Master of Kungfu
Novice
Advanced Beginner
Proficient
Competent Expert
Image: http://goo.gl/1RzEE
Learnt Wing Chun @ 13
4
Văn ôn Võ luyện @ Dojo (Võ đường)
Image: VOV, CNN
10.000 hours of practicing
5
Sequential vs. overlapping
Source: “The New New Product Development Game” by Takeuchi
and Nonaka. Harvard Business Review, January 1986.
Sequential development
Overlapping development
6
Why agile?
7
Charts: 1. The CHAOS Manifestor, The Standish Group 2012 2. Methodologies popularity, Forrester Research, 2010
3x SUCCESS RATE
Agile
Benefits students: Great framework & tools
for learning
Improve skills better
Better Employability
Master software
development
8
Agile
XP
Scrum
Lean
Software Development
Agile UP
FDD
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
9
That is, while there is value in the items on the right, we value the items on the left more.
AgileAlliance.org
12 Principles
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.
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
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
http://agilemanifesto.org
Fast delivery
11
Time
…
Iteration
Practices process
SHU Follow rules until sink in
HA Reflect on rules
Look for exceptions,
Beaks the rules
RI Forget the rules
12
Development Flow
Requirement Analysis
UI Mocking
•Customer discussion
Design Draft
•Design Discussion
Code the skeleton to
test the design
Coding in team
Refactoring and
Refinement
Build the increment
$
DevTeam PO
Collaboration:
Steps:
Artifacts: As a super user,
I want to …
A
B
IDo
Interface IDo{
//TODO …
}
Class A{
//TODO …
}
Class B:IDo{
//TODO …
}
Note: 1. TDD|BDD|AMDD can be used or not
2. Images are for illustration only
Interface IDo{
//TODO …
}
Class A{
method1(){
//Mr. A codes here
}
}
Class B:IDo{
method1(){
//Mrs. B codes here
}
}
Class C{
}
$
PO
13
Feedback
14
• 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”
Listen to the users
15
• Let them do
acceptance testing
• “It’s a bug” : Every complaint holds a
truth.
=> There is no ‘stupid user’.
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
Pencil Paper
…
17
Pair-Programming
1 pair, 1 PC, 1 problem, 1 goal
Image: wikipedia
He drives Tactics Focused
He navigates Strategies Focused
18
Pair Programming
19
• Better communication
• Increased discipline
• Better code
• Resilient flow
• Improved morale
• Collective code ownership
• Mentoring
• Team cohesion
•Driver doesn’t see the big picture
• The Driver should “step a way from the keyboard”
• The Navigator tends to use pattern-matching problem solving technique
Program Intently and Expressively
20
• Code should provide high-level of:
– readability and
– understandability.
public void MakeCoffee() {
lock(this) { // ... operation }
}
private object makeCoffeeLock = new object(); public void MakeCoffee() {
lock(makeCoffeeLock) { // ... operation }
}
Communication in Code
21
• 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
Communication tools
22
• Whiteboard
• Sticky note
• Version control
• Wiki
• Blog
• Task management tools
• Issue trackers
Trade-off and Simplicity
23
• “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
Keep it releasable
24
• 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
BUILT
QUALITY
IN
Day 2
TODO
What\Why is developer testing?
TDD and test strategies
JUnit
Simple design
Coding Dojo
What did we do?
Review and Retrospectives
25
Cost of bugs
26
Technical Debt
27
Business pressures
Lack of process or understanding
Lack of building loosely coupled components
Lack of test
Parallel Development
Delayed Refactoring
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
Test
Implement
Test
29
Testable
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
32
The values used to test the extremities are : • Min ------------------------------------ - Minimal • Min+ ------------------------------------ - Just above Minimal • Nom ------------------------------------ - Average • Max- ------------------------------------ - Just below Maximum • Max ------------------------------------ - Maximum
Robustness Testing
33
Robustness testing has the desirable property that it forces attention on exception handling
Worst-Case Testing
34
Robust Worst-Case Testing
35
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
Data Flow Testing
36
This method examines the full flows of execution, set verification points to critical nodes for testing.
What is Conditional Complexity?
Explanatory Testing
37
Which “Justin” do you want to appear first?
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
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 processes
• Program evolves the design changes
• Not “code and fix” tactics
Evo
lve
41
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
Simplistic
Ignorance
Inattention
Laziness
Deception
Easy for us
Simplicity
Awareness
Knowledge
Spirit of helping
Honesty, Sincerity
Easy for them
43
From Garry Reynold’s
vs.
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 Models
48
com.myapp.Models
com.myapp.Views
com.myapp.Controllers
Sprint 0
updated story
V1
M1
IDo C1
V1
M1
IDo C1
V2
M2
Sprint 1 Sprint 2
Product
Backlog
Items burnt
Items burnt
Initial Architecture Model1 Model 2
“Continuous” Architecting Sprint #1: without layering
49
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
“Continuous” Architecting Sprint #2: refactoring to layers
50
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
“Continuous” Architecting Sprint #3: architecting “on the go”
51
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
REFACTORING TO
BETTER CODE
Day 3 TODO
Refactoring for better code
Refactoring Dojo
Dojo Retrospectives
Review the final translation
Closing Retrospectives and
Remarks
52
Refactoring
• For simpler design
• For maintenance\upgrade later
• MustHave task in your DoneDefinition
checklist
• Invest in patterns and best practices
53
Refactoring
54
• 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
Refactoring Techniques
55
• 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
Code Review
56
• Very efficient in finding
problems
• “Bug-prevention”
• Styles:
– The all-nighter
– The pick-up game
– Pair programming
Receipt • Can you read and understand the
code? • Are there any obvious errors? • Will the code have any undesirable
effect on other parts of the application?
• Is there any duplication of code (within this section of code itself or with other parts of the system)?
• Are there any reasonable improvements or refactorings that can improve it?
Retrospectives Bridge
Image: Rachel Davies & Liz Sedley
57
Be
BETTER always
58
Plan
Do
Check
Act
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