Agile Software Development in Practice – A Developer Perspective

Weerasak Witthawaskul

Mr. Sweet Corn

29 August 2009

Companies' Most Important Assets

Employees = You

Current TreatmentsMore workload / documentation= More stresses, High turnover, Low quality work

Happy, talented, empowered, passionate employees = productive

To Agile, or Not to Agile

What? You are still not an agile developer?

Agile will make you more, if not most, productive Don't do things that do

not help make working software

No more repeated bugs

Agile is about organizational transformation Try Scrum for project management Try XP for design, develop and test

Pick 3 out of 4

Deadline

BudgetScope

Quality

Agile Practices

User Stories Iteration Planning Meeting Daily Stand-up Meeting Retrospective TDD Refactoring Continuous Integration

User Story Stack

Scrum in Theory

Scrum in Practice

Card Wall

Ready for Dev

In Dev In BA In QA Ready for Business

Release and Iteration Plannings

Release 1 PlanningIPM 1

End of Iteration 1Retrospective

IPM 2 End of Iteration 2Retrospective

Release 2 PlanningIPM 3

Release 1

End of Iteration 3Retrospective

IPM 4IPM = Iteration Planning Meeting

Daily Standup

Iteration Planning

Review vision and roadmap Review development status from previous

iterations Demo of previous iterations Review team availability & capacity Review product backlog & select items for

iteration Identify tasks & estimates Commit

Productive Scrum

Time management is crucial All roles must be identified

Business / PM / BA / Tech Lead / Dev / QA

Onsite team is most desirable Be concise and direct Trust that everybody does the best job possible

given context and timeframe Daily or on-demand group huddle Use simplest tools possible

Measurements

Frequent releases of working software Iteration Velocity Repeated Defects Team productivity / morale / happiness

Eternal Engineering Sunshine of the Spotless Minds

We tend to overengineer design... Lets do the Strategy pattern when there is only one

algorithm Lets use the Observer pattern when there is only

one observable and one observer Lets use this because in the future... I have beautiful diagrams of the system; don't

change it Aim for 100% test coverage

XP is for...

eXtreme Programming (XP)

Createa UnitTest

PairProgramming

CRCCards

Move PeopleAround

ContinuousIntegration

100%Unit

TestsPassed

AcceptanceTest

Passed

RefactorMercilessly

Copyright 200 J. D. Wells

SimpleDesign Complex

ProblemFailedUnitTest

PassedUnit

ChangePair

WeNeedHelp

New UnitTests

NewFunctionality

Run All UnitTests

SimpleCode

ComplexCode

Next TaskOr FailedAcceptanceTest

Collective Code Ownership

Pair Programming

Developer Dev A Dev B Dev C Dev D

Dev A Monday Tuesday Wednesday

Dev B Monday Wednesday Thursday

Dev C Tuesday Wednesday Friday

Dev D Wednesday Thursday Friday

Pairing Matrix

Ping Pong Programming

Test Driven Development

New Project Help you shape your design from the caller point of

view Set of tests (test suite) become assets

Reengineering Project Help you understand existing implementation by

writing test coverage of existing code Ensure that your refactored code and new code do

not break tests

Three Rules of TDD Fight Club

Three Rules of Fight Club TDD

You are not allowed to write any production code unless it is to make a failing unit test pass.

You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Typical Coding Understand user accpetance criterias in

each user story Write functional tests for each criteria

They will fail

For each functional test Write unit tests for controllers Think about what should be in controllers, what

should be abstracted into models Write unit tests for models Write code to make tests pass

Test Double

Use Stubs / Mocks Stubbing things you

don't want to test but are necessary

Mocking things you expect some behaviors

Examples?

Level of Tests Unit tests

One class; stubs the rest

Functional tests Groups of classes; use fixtures as test data

External tests External service dependencies; may fail if

external services are unavailable

Integration tests; User acceptance tests End-to-end tests Webapp tests from web browser

Testing Styles

Assertion is so '90s

assert_equals(”must be empty”, message, ””)

Behavior Drien Design (BDD)

message.should == ””

Test name prefixed is for grandpa

void testMessageMustBeEmpty() { … }

Use annotation

[test]

void messageMustBeEmpty() { … }

BDD

We describe something that it must behave …

describe ”user login” do

it ”must not allow user login without password” do

… password.should_not be_nil ...

end

it ”checks password from the user id” do

… user.valid?(password).should == true ...

end

end

BDD and User Stories

Story n

As a …stakeholder...

I want to …goal...

so that …reason/business value... Scenario m

Given …context...

When ...event...

Then ...expectation...

From User Story to Implementation Demo

Story 1Title: Customer withdraws cashAs a customer,I want to withdraw cash from an ATM,so that I don’t have to wait in line at the bank.

Demo – ATM WithdrawalScenario 1: Account is in credit

Given the account is in credit

And the card is valid

And the dispenser contains cash

When the customer requests cash

Then ensure the account is debited

And ensure cash is dispensed

And ensure the card is returned

Scenario 2: Account is overdrawn past the overdraft limit

Given the account is overdrawn

And the card is valid

When the customer requests cash

Then ensure a rejection message is displayed

And ensure cash is not dispensed

And ensure the card is returned

Spec-first Design – User/BA pairing

BA / Dev Pairing

Dev Pairing

Test / Code / Test Cycle

Dev done when we see all dots

With nested option, test result becomes documentation

Checkin Messages as Documents

Instead of svn ci -m ”fixing bugs”

Try svn ci -m ”[jira 1234] Boat/Pok – Checked null

pointers of cart.items before accessing each item”

Why? svn log | grep -i -C 3 pok | less svn log | grep -i -C 3 cart | less Bug tracking tool integration

Continuous Integration

VCS

Builder Server 1

Builder Server 2

Check-in

Tools

User Stories Index cards

User Story Tracking – Card Wall Whiteboard Mingle

VCS Subversion / Git

Bug Tracking Jira / Bugzilla

Testing Libraries / Tools

Mockito – Java

rSpec DSL – Ruby Selenium/Watir – Web

UAT

Presentation Summary

No more excuse not to do agile If you can't go full-stream agile, consider

gradually applying agile practices Self-discipline, don't do shortcuts, i.e. always

test first. You will thank yourself later. There is no 'i' in Teamwork; develop soft skills

to work effectively with others

Keep Learning

Self Study – Keep up with technololgy Software Craftmanship: Apprenticing Higher Education

Towards Agile Manifesto – Thai Edition

Now You Have Questions

Time to Ask! Agile 2009 http://www.agile2009.org/ Martin Fowler Bliki http://martinfowler.com/bliki/ Agile Consulting

http://agileconsulting.blogspot.com/ Planet ThoughtWorks

http://blogs.thoughtworks.com/