agile software development in practice - a developer perspective
DESCRIPTION
Narisa Tech Talk 7 - 29 Aug 2009At Microsoft ThailandCRC Tower, Wireless RoadBangkok, ThailandTRANSCRIPT
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/