Practices of an

Agile Developer

From Good to Great

TanDT@fpt.edu.vn 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

• Email

• 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