• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Software Development in Practice - A Developer Perspective
 

Agile Software Development in Practice - A Developer Perspective

on

  • 7,178 views

Narisa Tech Talk 7 - 29 Aug 2009

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

Statistics

Views

Total Views
7,178
Views on SlideShare
5,654
Embed Views
1,524

Actions

Likes
8
Downloads
265
Comments
1

9 Embeds 1,524

http://weerasak.com 832
http://www.agile66.com 672
http://www.slideshare.net 8
http://webcache.googleusercontent.com 6
http://www.linkedin.com 2
http://74.125.153.132 1
http://aroi.in.th 1
http://www.docshut.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Software Development in Practice - A Developer Perspective Agile Software Development in Practice - A Developer Perspective Presentation Transcript

    • Agile Software Development in Practice – A Developer Perspective Weerasak Witthawaskul Mr. Sweet Corn 29 August 2009
    • Companies' Most Important Assets Employees = You Current Treatments More 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 Scope Budget 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 In Dev In BA In QA Ready for for Dev Business
    • 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
    • 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) 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
    • 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
    • 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 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.
    • 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
    • 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 Builder Server 2 Builder Server 1 VCS 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/