Agile Software Development in
Practice – A Developer
Perspective

                Weerasak Witthawaskul
                  ...
Companies' Most Important Assets

Employees = You
Current Treatments
  More workload /
  documentation
  = More stresses, ...
To Agile, or Not to Agile
What? You are still not an agile
            developer?
                           Agile will make you
                  ...
Pick 3 out of 4

        Deadline



Scope                 Budget



        Quality
Agile Practices

   User Stories
   Iteration Planning Meeting
   Daily Stand-up Meeting
   Retrospective
   TDD
   ...
User Story Stack
Scrum in Theory
Scrum in Practice
Card Wall
 Ready    In Dev     In BA     In QA   Ready for
for Dev                                Business
Release and Iteration Plannings
                           Daily Standup




Release 1 Planning
IPM 1
         End of Iter...
Iteration Planning
   Review vision and roadmap
   Review development status from previous
    iterations
   Demo of pr...
Productive Scrum

   Time management is crucial
   All roles must be identified
       Business / PM / BA / Tech Lead /...
Measurements
   Frequent releases of working software
   Iteration Velocity
   Repeated Defects
   Team productivity /...
Eternal Engineering Sunshine of
      the Spotless Minds
   We tend to overengineer design...
       Lets do the Strateg...
XP is for...
eXtreme Programming (XP)
                                      Move People                                   100%
        ...
Pair Programming

   Pairing Matrix
       Developer    Dev A       Dev B       Dev C       Dev D


       Dev A         ...
Test Driven Development

   New Project
       Help you shape your design from the caller point of
        view
       ...
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 un...
Typical Coding
   Understand user accpetance criterias in
    each user story
   Write functional tests for each criteri...
Test Double

         Use Stubs / Mocks
         Stubbing things you
          don't want to test but
          are nece...
Level of Tests
   Unit tests
       One class; stubs the rest
   Functional tests
       Groups of classes; use fixtur...
Testing Styles
   Assertion is so '90s
      assert_equals(”must be empty”, message, ””)
   Behavior Drien Design (BDD)
...
BDD
   We describe something that it must behave …
    describe ”user login” do
      it ”must not allow user login witho...
BDD and User Stories

   Story n
    As a …stakeholder...
    I want to …goal...
    so that …reason/business value...
  ...
From User Story to Implementation Demo




     Story 1
     Title: Customer withdraws cash
     As a customer,
     I wan...
Demo – ATM Withdrawal
Scenario 1: Account is in credit     Scenario 2: Account is overdrawn past
                         ...
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
              ...
Checkin Messages as Documents

   Instead of
       svn ci -m ”fixing bugs”
   Try
       svn ci -m ”[jira 1234] Boat/...
Continuous Integration
                              Builder Server 2

           Builder Server 1

 VCS




       Check-...
Tools
   User Stories
       Index cards
   User Story Tracking – Card Wall
       Whiteboard
       Mingle
   VCS
 ...
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 app...
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://mart...
Upcoming SlideShare
Loading in...5
×

Agile Software Development in Practice - A Developer Perspective

5,407

Published on

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

Published in: Technology, Business
1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,407
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
283
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

Agile Software Development in Practice - A Developer Perspective

  1. 1. Agile Software Development in Practice – A Developer Perspective Weerasak Witthawaskul Mr. Sweet Corn 29 August 2009
  2. 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. 3. To Agile, or Not to Agile
  4. 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. 5. Pick 3 out of 4 Deadline Scope Budget Quality
  6. 6. Agile Practices  User Stories  Iteration Planning Meeting  Daily Stand-up Meeting  Retrospective  TDD  Refactoring  Continuous Integration
  7. 7. User Story Stack
  8. 8. Scrum in Theory
  9. 9. Scrum in Practice
  10. 10. Card Wall Ready In Dev In BA In QA Ready for for Dev Business
  11. 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. 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. 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. 14. Measurements  Frequent releases of working software  Iteration Velocity  Repeated Defects  Team productivity / morale / happiness
  15. 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. 16. XP is for...
  17. 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. 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. 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. 20. Three Rules of TDD Fight Club
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Spec-first Design – User/BA pairing
  31. 31. BA / Dev Pairing Dev Pairing
  32. 32. Test / Code / Test Cycle Dev done when we see all dots With nested option, test result becomes documentation
  33. 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. 34. Continuous Integration Builder Server 2 Builder Server 1 VCS Check-in
  35. 35. Tools  User Stories  Index cards  User Story Tracking – Card Wall  Whiteboard  Mingle  VCS  Subversion / Git  Bug Tracking  Jira / Bugzilla
  36. 36. Testing Libraries / Tools  Mockito – Java  rSpec DSL – Ruby  Selenium/Watir – Web UAT
  37. 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. 38. Keep Learning  Self Study – Keep up with technololgy  Software Craftmanship: Apprenticing  Higher Education
  39. 39. Towards Agile Manifesto – Thai Edition
  40. 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/
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×