1 / 47

A Pragmatic Approach to Agile Development

A Pragmatic Approach to Agile Development. John Scumniotales Vice President, Product Management. Visualize. Define. Design. Develop. Deploy. Build. Test. Application Development Distilled. New application requests. Strategic. New applications. Enhancement requests.

gary
Télécharger la présentation

A Pragmatic Approach to Agile Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Pragmatic Approach to Agile Development John Scumniotales Vice President, Product Management

  2. Visualize Define Design Develop Deploy Build Test Application Development Distilled New application requests Strategic New applications Enhancement requests Improved applications Issues Fixed applications Killed applications Defects Tactical Managed software artifacts Repeatable processes Predicable project execution

  3. Visualize Define Design Develop Deploy Build Test Application Development Distilled New application requests Strategic New applications … we need to do this as efficiently as possible to maximize the value we can return to the business … Enhancement requests Improved applications Issues Fixed applications Killed applications Defects Tactical … so all this process stuff is just a means to an end, NOT the end in and of itself! Managed software artifacts Repeatable processes Predicable project execution

  4. System Requirements Analysis Requirements Analysis Preliminary Design Products Detailed Design Code and Unit Testing Rework Integration & Acceptance Testing Installation and Turnover The Waterfall Chart W.W. Royce, 1970 Operation and Maintenance Traditional methodologies • Document driven • Hand-offs between stove-piped groups • Manage scope creep, resist new requirements • Late changes at high cost • Poor stabilization predictability

  5. Agile Origins - The need for speed • In the early 90s, Object-orientation and Rapid application development environments emerged • Smalltalk, then Java and C# • Environments enabled rapid development, prototyping, and refactoring • Design embodied in the code • Development could far out pace planning and testing processes • We either slow development down, or figure out how to keep pace • And then came the internet bubble and internet time

  6. Emergence of agile approaches • Traditional software development approaches • Waterfall • Spiral • Incremental • Most assume that requirements are known and locked prior to design and development • Controlling change is desirable • Agile has emerged in environments where this was not possible or appropriate • Change is encouraged

  7. Agile methodologies • Adaptive Software Development (ASD) • Crystal • Dynamic Systems Development Method (DSDM) • Extreme Programming (XP) • Feature-Driven Development (FDD) • Scrum • Rational Unified Process (RUP) • Test-Driven Development • …

  8. http://agilemanifesto.org/ What is “agile development”? An umbrella term that describes software development methodologies that share some/all of the following characteristics

  9. Are you agile? • Cross-functional teams that include the customer (or their proxy), development, test, and others • Automated and unattended build, test, and reporting that runs at least every night • Incremental approach that produces production quality capabilities at regular intervals • Test-driven development that puts quality first

  10. The Agile Team • Cross-functional • All disciplines required to produce the product are on the team • Involved from conception to launch • Equal treatment and respect for all • Roles • Project Manager / ScrumMaster • Product Owner • Developers • Testers • Writers • …

  11. Release Commit Demo Demo Demo Demo RTM An agile development approach Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  12. Release Commit Demo Demo Demo Demo RTM An agile development approach Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  13. Conception • Initiated through ITIL/CAB, PMO or ad-hoc processes • Internally generated requests • Customer driven • Market driven • Describe what your doing and why your doing it • Customer need and/or market assessment • Business case • High-level use cases and requirements • MRD-level information • Level of formality will vary based on value/cost of the request • Typically involves formal approval processes • Evangelize project (post-approval) to stake-holders, customers, and prospects

  14. Release Commit Demo Demo Demo Demo RTM An agile development process Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  15. Release Commit Demo Demo Demo Demo RTM An agile development process Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  16. Definition and Construction – “Sprint 0” • High-level planning and estimation • High-level backlog created from Conception deliverables • Backlog is reviewed and evaluated for achievability • When to use a Sprint 0? • Long multi-release development cycle • Significant post production activities need to be planned • e.g. Marketing launch

  17. Definition and Construction – “Sprint 0” • Each backlog item is prioritized and estimated • High-level estimates (+/- 50% accuracy) • Resource capacity plan is developed for the project • Effort is compared to resource capacity and an initial burndown is projected • At the completion of Sprint 0, a Sprint review is performed for final project approval and kick-off of the next Sprint

  18. Example Project Backlog

  19. Example Project Backlog

  20. Example Project Backlog

  21. Example Project Backlog

  22. Resource Capacity and Allocations

  23. The Project Burndown

  24. Incremental Planning • Incremental planning starts now • Feature content, release targets, capacity are continuously reviewed/discussed/debated by the project leads • Project Leads: ScrumMaster/Project Manager, dev & test leads, product owner • This is where the term Scrum came from • At times, the process can be brutal, but in the end a try can be scored

  25. Release Commit Demo Demo Demo Demo RTM An Agile Development Process Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  26. Kicking-off a Sprint • Product Owner and team leads identify backlog items for the sprint • The backlog items are elaborated • User Stories • Interaction design / screen flows • Feature content, release targets, capacity are re-calibrated by the project leads • Sprint is kicked-off with a team meeting to review and discuss goals

  27. Identify Sprint Backlog Items

  28. Identify Sprint Backlog Items

  29. User Stories are elaborated

  30. Interaction Design / Screen flows

  31. Sprinting - Managing the work • User Stories drive development and testing • Developers use the to determine what to build • Testers use them to determine what to test • User Stories are be broken down into tasks • Task work remaining is determined by whomever owns the task • Refines User Story work remaining and increases overall accuracy of the burndown • Therefore, the more user stories that are implemented the more confidence we have with the target project completion • Progress, status and impediments are discussed in the daily stand-up

  32. Define User Story tasks

  33. The Developer Inbox

  34. Sprinting – The Daily Stand-up • Team meeting every day at the same time in the same place • Everyone attends – Development, Test, Product Owner • Pigs and chickens • Led by the ScrumMaster (Project Manager) • <15mins • Each member quickly reviews new accomplishments, next tasks, and raises any impediments • Impediments resolved offline! • Whiteboards – the more the better

  35. Test-driven development • Initial goal: “Get something built and get it into maintenance mode” • Jeff McKenna • The eXtreme approach – Test first development • Tests are written by developers before the code • Serve as software design • Used to validate the implementation • Minimally, tests should be delivered with the code • Overtime, a significant suite of unit and component level tests is created • (1000s of individual tests) • Open source test harnesses rock • NUnit (Java), JUnit (C#) for component and unit testing • Selenium for web UI testing

  36. What happened to Architecture & Design? • Architecture and design can evolve • Modern (RAD) environments enable designs to be rapidly realized in code • Refactoring features enable exploration of alternative approaches • Test-automation enables rapid application regression testing • Mini-specs for high-risk, complex features • The architectural spike (Kent Beck) • But… these artifacts are disposed of as soon as we have operational code

  37. Test + Automation = Courage • Implementing unattended automated builds and testing are critical success factors • Ideally, the application is completely rebuilt from source every night … • … and, UI, component, unit tests are run … • … and, a report is generated and broadcast with test results • The build NEVER fails • With 1000+ tests supporting the team, design and even architectural changes can be made and immediately validated

  38. What about traditional SQA? • Absolutely essential! • They are imbedded in the team • Test Plans built during initial scoping stages (Sprint 0) • Test Cases derived directly from the User Stories • Manual test cases executed during the sprint as features are developed • Also contribute to UI and code-level test automation

  39. You gotta have rhythm! Nested levels of agile rhythm Releases Sprints Feature Drops Automation Cycles

  40. The Sprint Demo Meeting • Held at the completion of every sprint • Closes the previous sprint, kicks-off the next sprint • For the just completed sprint • Demonstration of delivered features by the devs or testers who built them • Review results and discuss any changes to planed scope • For the sprint about to start • Review planned features • Review project burndown • Ready to release? • Are the key features ready? • Product quality/stability?

  41. Release Commit Demo Demo Demo Demo RTM An agile development approach Ongoing business and strategy activities Sprint 0 Sprint 1 Sprints 2 through N-3 Sprint N-2 Sprint N-1 Sprint N Conception Definition & Construction Launch High-level planning Requirements Elaboration Development & Test

  42. Are you agile? • Cross-functional teams that include the customer (or their proxy), development, test, and others • Automated and unattended build, test, and reporting that runs at least every night • Incremental approach that produces production quality capabilities at regular intervals • Test-driven development that puts quality first

  43. Characteristics of agile teams • Customer focused • Customer (or their proxy) on the team • Embrace customer-driven changes • High-quality software • Test-first development • Paired programming • Maniacal focus on getting product built • Not on producing artifacts • Early continuous delivery • Verbal communication over documentation • Cross-functional teams • Incremental development • Deliver production quality code • High visibility and predictability • Rhythm and pace • Continuous builds • Automation obsession

  44. Agile adoption challenges • Large distributed development teams • Outsourced projects • Organizational change management • Situations where the customer is not a directly involved with product development • Shrink-wrap products with thousands of customers

  45. How to institute agile in your shop • Get Help! • If you don’t have agile experience, get an expert • Start small • Find a reasonably sized project with limited external dependencies • Get 360 degree buy-in • Your boss, piers, and subordinates • Initial successes will help • If your environment is stable, predictable and controlled, then why bother • In the end, success will depend on the people

  46. Serena Agile Product Support • Currently Available • TeamTrack accelerator for Agile/Scrum development • Agile/Scrum project management support in Mariner 6.2 • Future • Agile support for the enterprise • Cross-product agile workflows • More accelerator and feature content for agile development teams

  47. Thank You!

More Related