Narisa Tech Talk 7 - 29 Aug 2009 At Microsoft Thailand CRC Tower, Wireless Road Bangkok, Thailand

1. Agile Software Development in
Practice – A Developer
Perspective
Weerasak Witthawaskul
Mr. Sweet Corn
29 August 2009

2. Companies' Most Important Assets
Employees = You
Current Treatments
More workload /
documentation
= More stresses, High
turnover, Low quality
work
Happy, talented,
empowered, passionate
employees = productive

3. To Agile, or Not to Agile

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

5. Pick 3 out of 4
Deadline
Scope Budget
Quality

6. Agile Practices
 User Stories
 Iteration Planning Meeting
 Daily Stand-up Meeting
 Retrospective
 TDD
 Refactoring
 Continuous Integration

7. User Story Stack

8. Scrum in Theory

9. Scrum in Practice

10. Card Wall
Ready In Dev In BA In QA Ready for
for Dev Business

11. Release and Iteration Plannings
Daily Standup
Release 1 Planning
IPM 1
End of Iteration 1
Retrospective
IPM 2 End of Iteration 2
Retrospective
Release 2 Planning
IPM 3 End of Iteration 3
Release 1 Retrospective
IPM 4
IPM = Iteration Planning Meeting

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

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

14. Measurements
 Frequent releases of working software
 Iteration Velocity
 Repeated Defects
 Team productivity / morale / happiness

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

16. XP is for...

17. eXtreme Programming (XP)
Move People 100%
CRC Around
Cards Unit
Change We Tests
Simple Pair Need
Help Passed
Design
Complex
Problem Run All Unit
Failed Tests
Unit New Unit
Next Task Create Test Pair Tests
Or Failed Programming Continuous
a Unit Integration
Acceptance Test Passed New
Test Unit Functionality
Simple Complex
Code Code
Refactor Acceptance
Mercilessly Test
Passed
Copyright 200 J. D. Wells
Collective Code Ownership

18. Pair Programming
 Pairing Matrix
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
 Ping Pong Programming

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

20. Three Rules of TDD Fight Club

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

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

23. Test Double
 Use Stubs / Mocks
 Stubbing things you
don't want to test but
are necessary
 Mocking things you
expect some
behaviors
 Examples?

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

25. 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() { … }

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

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

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

29. Demo – ATM Withdrawal
Scenario 1: Account is in credit Scenario 2: Account is overdrawn past
the overdraft limit
Given the account is in credit
Given the account is overdrawn
And the card is valid And the card is valid
And the dispenser contains cash When the customer requests cash
Then ensure a rejection message is
When the customer requests cash displayed
Then ensure the account is debited And ensure cash is not dispensed
And ensure the card is returned
And ensure cash is dispensed
And ensure the card is returned

30. Spec-first Design – User/BA pairing

31. BA / Dev Pairing
Dev Pairing

32. Test / Code / Test Cycle
Dev done when we see all dots
With nested option, test result
becomes documentation

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

34. Continuous Integration
Builder Server 2
Builder Server 1
VCS
Check-in

35. Tools
 User Stories
 Index cards
 User Story Tracking – Card Wall
 Whiteboard
 Mingle
 VCS
 Subversion / Git
 Bug Tracking
 Jira / Bugzilla

36. Testing Libraries / Tools
 Mockito – Java
 rSpec DSL – Ruby
 Selenium/Watir – Web
UAT

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

38. Keep Learning
 Self Study – Keep up with technololgy
 Software Craftmanship: Apprenticing
 Higher Education

39. Towards Agile Manifesto – Thai Edition

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