Download
mark duvall @ usc november 2011 n.
Skip this Video
Loading SlideShow in 5 Seconds..
agile software development PowerPoint Presentation
Download Presentation
agile software development

agile software development

408 Views Download Presentation
Download Presentation

agile software development

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. mark duvall @ USC, november 2011 agile software development

  2. agile bio • practicing agile development since 2002 • csm x 4, cspo x 2 • contracted ken schwaber • taught agile to 100s • agile alliance, acm, ieee • mike cohn disciple • delivered dozens of projects w/agile • been through 100s of sprints

  3. references • mike cohn, http://www.mountaingoatsoftware.com/ • agile alliance, http://www.agilealliance.org/ • scrum alliance, http://scrumalliance.org/ • crisp blog, http://blog.crisp.se/

  4. a great time to be in software development • agile development is a well established practice • agile adoption is high • many companies practicing agile development • many companies are in agile transition

  5. preface • software anthropology • empowers the team • leverages collaboration • focus on organizing your work • continuously improve • adoption of best practices • creating a cadence

  6. software development • notoriously difficult to deliver • on-time • on-budget • quest for determinism • estimation models • formalized processes • organizations to manage process • documentation driven

  7. differences agile development non-agile development self managing team high bandwidth communication iterative evolutionary/iterative design test early collaboration Lightweight, tailorable process team & roles command & control document driven serial in nature big upfront design test late bureaucratic Heavy, rigid process team & roles

  8. waterfall system requirements system requirements specification software requirements specification marketing requirements document detailed requirements functional specification functional specification high level design document high level design detailed design document detailed design code code complete milestone test qa acceptance document delivery product launch

  9. scrum define plan design + code + test review user stories functional software iterate

  10. agile manifesto 2001 • individuals and interactions over processes and tools • working software over comprehensive documentation • customer collaboration over contract negotiation • responding to change over following a plan

  11. agile tenants • build software incrementally • deliver value quickly • commitment driven • self organizing and managing teams • continuous improvement • high bandwidth communications • evolutionary design • customer intimacy • success is functioning software • maintain a sustainable pace

  12. scrum • oopsla 1995, schwaber & southerland • lightweight process framework • ability to incorporate best practices • inspection and adaptation - error correction • iterate and refactor • time-boxes • collocated teams • quality never sacrificed for dates • shippable product quality at each sprint • definition of “done”

  13. done • code complete • all code checked into source code control (TFS) • all tests checked into source code control • passes coding standards (stylecop) • passes peer code review (team review) • passes static code analysis (ndepend) • builds on build server (tfs) • builds with no warnings in pre-build area (shelf set) • all unit test & test automation executes in dev/qa/pre-prod environments • all unit test pass • unit test code coverage is 65% • no priority 1 defects • no profiling issues (dotTrace) • documented • accepted by product owner

  14. scrum team • pigs (no chickens) • team size 7-12 pigs • cross functional • sm, po, dev, qa, ia, design • self managing • collocated

  15. roles • product owner • classically the product manager • maximizes roi of each sprint • manages the product backlog • scrum master • development manager or project manager • enforces process, insures process adherence • impediment removal • facilitates communications • scrum team • cross functional team that builds the product • maintains sprint backlog

  16. user stories • a feature description • as a <role>, i want <goal> so that <reason> • invest • independent • negotiable • valuable to users • estimate-able • small • testable

  17. product backlog • the new age requirement specification/mrd/prd • live repository of all project work • user stories • defects • managed by product owner • contributed to by anyone • prioritized • estimated • by scrum team • story points • subset moved to sprint backlog; every sprint

  18. scrum basic mechanics … Sprint Planning Daily Scrum Daily Scrum Sprint Review 2 Time-boxed meetings User Story Estimation Task Breakdown 2 Time-boxed meetings Demo Retrospective Daily Scrum Daily meeting Standup Same time, same place 15min time-box All Scrum team members Task movement Answer 3 questions Accomplished in last 24hrs Working on next 24hrs Impediments Review Burndown Sprint Backlog Demo PO demos each completed user story for acceptance Retrospective Scrum team does a post mortem on the sprint User Story Estimation Scrum team together estimates each user story (points) Task Breakdown Scrum team together creates tasks (hrs) for each user story Product Backlog New age MRD/PRD Live repository Product Owner Defining user stories Refines user stories Release planning

  19. flow

  20. sprint planning • first day of the sprint • product backlog - n hour time-boxed • backlog walkthrough • estimate and prioritize stories • sprint backlog - n hour time-boxed • list tasks for implementing stories • assign hours and resources

  21. estimation • story points • relativistic educated guessimate of effort • not directly correlated to time • non-linear numbers like fibonacci sequence • t-shirt sizing (xs,x,m,l,xl) • use for sprint planning (capacity) • epic • story too large to fit in a sprint • broken down into smaller stories

  22. estimation process • product backlog estimation • discuss of each story • planning poker - team • until backlog empty or time-box expires • prioritize – by po • assign stories to sprint backlog • based on team’s velocity • assume initial velocity as 65% • assign tasks to sprint stories • <8 hour tasks • *assign owners • adjustments • move stories back if velocity is exceeded

  23. planning poker • iterative approach • adapted from delphi • entire scrum team participates • everyone has a deck of story point cards • user story discussion • everyone selects a card privately • cards are revealed • discuss outliers • re-estimate till convergence or timebox • http://www.planningpoker.com

  24. sprint backlog • repository of work for each sprint • user stories • broken down into tasks • task granularity 8-16hrs • managed by scrum team • updated daily, in real-time

  25. composition

  26. electronic task board

  27. physical task board

  28. daily scrum • daily meeting • same place, same time • time-boxed 15 minutes • standup • $1 for being late • no one can interrupt the current speaker • keep details post daily scrum • 3 questions • what did you accomplish in the last 24 hrs? • what are you going to work on in the next 24hrs? • any impediments? • review burndowns post scrum

  29. daily scrum

  30. burndown chart

  31. sprint review • last day of the sprint • demo - n hour time-boxed • demonstrate sprint accomplishments • story acceptance walk through • log defects for next sprint • retrospective - n hour time-boxed • what went right? • what went wrong? • what can we do to improve?

  32. best practices • relativistic estimation • evolutionary design • vertical slices • continuous integration • test early, test often • high flow • eliminate waste • fail quickly • shorter sprints • test driven development • pair programming • peer code review • information radiators

  33. scrum anti-patterns • “manager” estimates work • developers not doing their own task breakdowns • untrackable sprints • no customer value in sprint • partially complete sprints • story or task creep in sprint backlog • no definition of “done” • working on tasks not in the sprint backlog • qa under utilized • testable software completed late in the sprint • lack of peer accountability or commitment • impediments not immediately addressed • floating timeboxes

  34. continuous integration • build automation system • builds are triggered by source code check-ins • unit tests are executed as part of each build • tests are executed in the context of a profiler • static code analysis • each build is versioned • each build is deployed • test automation scripts execute

  35. real world agile web development • site development team composition • 6 developers • 2 qa engineers • 1 ia • 1 designer • 1 scrum master • 1 product owner

  36. site development wireframing & user stories graphic design/site layout development • established cadence • 1 week sprints • cascading deliverables • 5 weeks of ia & design • 6 weeks of development • ~390 us, ~4000 tasks • velocity: 69-79%

  37. development environment • rally for agile lifecycle management • product backlog • sprint backlog • project boards • burndowns & metrics • microsoft shop • c#, .net framework 4.0 • asp.netmvc 3.0 • castle windsor di • endeca search engine • cruisecontrol.net • subversion • ndepends • nunit, selenium

  38. page template inventory • n page types • home • department • brand • browse • search results • best selling • special, gift, • promotion • collection • sku • cart / account • help and other static content

  39. page decomposition • page elements • header • footer • left navigation • right spine • body

  40. page element decomposition • header (user controls) • main image • primary navigation • secondary navigation • search • minicart • account/sign in • breadcrumbs

  41. sashimi slices • vertical sliver • presentation tier • mvc user controls • business logic/application tier • injected via di • rules for content acquisition/filtering/sorting • page rules • seo, microformats, analytics, remarketing • data tier • content retrieval

  42. release planning • 4hr timebox • release 1 • minimal deliverable feature set • release 2 • defects • international shipping • reporting • release 3 • site enhancements

  43. sprint planning • 2hr timebox • consume 2-4 page types per sprint • address higher risk stories first • critical tasks addressed first

  44. sprint review • 2hr timebox • capture defects add to product backlog • retrospective • iterate until product backlog is empty

  45. what’s next • it’s all about flow • kanban • managing wip • value streams

  46. questions