390 likes | 613 Views
Agile Software Development. An Alternate Approach. Umar K. Munroe MSCS Candidate Union College 1/9/2004. Topics of Discussion. Why an alternate approach Overview of Agile Software Development Agile Processes Limitations of Existing Agile Processes Adoption & Future in Industry.
E N D
Agile Software Development An Alternate Approach Umar K. Munroe MSCS Candidate Union College 1/9/2004
Topics of Discussion • Why an alternate approach • Overview of Agile Software Development • Agile Processes • Limitations of Existing Agile Processes • Adoption & Future in Industry
Why an alternate software development approach? • Traditional Approaches Slow & Rigid • Highly structured • Detailed process scripts • Required Artifacts (i.e. documents)
Why an alternate software development approach? • Internet & mobile technology increase demand for software development to • to be faster • more responsive to change • Traditional methods aren’t exactly working well • 13,522 IT projects (Standish Group, 2002) • 34% on-time, on-budget, sufficient functionality • 51% late, over-budget, less functionality • 15% fail
Agile Software Development • Quick development • Responsive to changing requirements • Simple, straightforward process • Frequent customer involvement and feedback • Guide development • Iterative, incremental development • Provides flexibility, responsiveness
Agile Alliance • In 2001, software industry experts formed the Agile Alliance • Goals: • Outline values and principles of agile software development • Promote agile software development in industry • http://www.agilealliance.org
Value #1: Individuals and interactions over process and tools • “A good process will not save the project from failure if the team doesn’t have strong players, but a bad process can make even the strongest of players ineffective.” Robert C. Martin • people and their relationships most important to a successful project
Value #1: Individuals and interactions over process and tools • Team • motivated • good programmers (not necessarily most talented) • excellent communication skills • Tools and environment built around team, not vice versa
Value #2: Working software over comprehensive documentation • Documentation produced only when necessary • Short – one or two dozen pages at most • Less time • Salient – describing the overall design rationale and only high level structures in the system • Details likely to change • Primary goal is working software • Demonstrated to customer frequently • Measure of progress
Value #3: Customer collaboration over contract negotiation • "A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed." Robert C. Martin • Contracts govern the working relationship between developers and customer • Customer is intimately involved • Guide development
Value #4: Responding to change over following the plan • Change is expected • Planning Strategy (iterative) • a detailed plan over the next 2 weeks • a very rough plan for the next 3 months • an extremely crude plan beyond 3 months • Minimize time wasted planning too far into the future
Agile Processes • Typically, • Less structured • Practices and rules • Selected Agile Processes • eXtreme Programming (XP) • Scrum • Dynamic Systems Development Method (DSDM)
eXtreme Programming (XP) • Most famous and documented agile process • Rules & practices • Developed by Kent Beck mid 1990’s • More info: • http://www.extremeprogramming.org
XP: Concepts/Practices • Customer Team Member • Highly accessible (on-site) • User Stories over detailed requirements • Describe functionality • Reduces unnecessary upfront restrictions • Simple Design • Quick, easy, sufficient
XP: Concepts/Practices • Test Driven Development • Tests written first, code written to make tests pass • Automated • Acceptance Tests • Verify user stories • Written before implementation • Short Cycles • 2-3 month releases • 2 week Iterations
XP: Concepts/Practices • Pair Programming (2 people, 1 computer) • Generate production code • Transfer Knowledge • Better Quality Faster development • Collective Ownership • Team knowledgeable in all aspects of project • Open Workspace • Easy access for conversation • Limits team size (<10 people)
XP: Concepts/Practices • Continuous Integration • Refactoring • tiny transformations to improve the structure of the code without changing its behavior • continuous • Metaphor • Provides “big picture” of the system
XP: Concepts/Practices • Sustainable Pace • 40 hr week • Planning Game • Plan made at the start of each iteration and release • Customer decides which user stories to implement next
Scrum • Management approach using existing processes and practices • empirical approach based in control systems theory • Developed (mid 90’s) & maintained by Advanced Development Methods (ADM, Inc) http://www.controlchaos.com • Training and certification available
Scrum: Key Concepts/Practices • Product Backlog • Defines everything needed in the final product • Goals, Resources • Constantly updated • Sprint (Cycles) • ~30 days • Production of an executable product increment • Requirements relatively frozen during Sprint
Scrum: Key Concepts/Practices • Sprint Planning Meeting • Goals and functionality of sprint • Decide an implementation approach • Sprint Backlog • Items specific to the Sprint from the Product Backlog • Small teams (5 to 9 people)
Scrum: Key Concepts/Practices • Daily Scrum Meeting • ~15 minutes • 3 questions addressed by each team member • What did you do since the last meeting? • Any obstacles or issues? • What will you do before the next meeting? • Sprint Review Meeting • Demonstrate implemented functionality • Make decisions as to the next sprint
Dynamic Systems Development Method (DSDM) • framework developed in the early 1990's for rapid application development (RAD) • Driving Principle: • Time and Resources are fixed • Functionality is flexible • Very popular in Europe • Maintained by the DSDM Consortium • http://www.dsdm.org
DSDM: Key Concepts/Practices • MoSCoW Prioritization • Must Haves critical to success • o • Should Haves important but not critical • Could Haves nice to have • o • Won't Have will not be implemented
DSDM: Key Concepts/Practices • TimeBoxing • Project end date is fixed • Schedule broken into fixed 2-6 week blocks of time (time box) • Assigned requirements of varying priorities • Complete highest priority within the time box
DSDM: Key Concepts/Practices • Prototyping • Demonstrate business process • Evaluate user interaction • Determine Performance/Capability • Demonstrate proof of concept
DSDM: Lifecycle • Feasibility Study • Is DSDM appropriate? • Outline Plan • Business Study • Analyze requirements • Recommended technical approach • Plan potential prototypes
DSDM: Lifecycle • Functional Model Iteration • Build on requirements • Prototype functionality • Design and Build Iteration • Prototype design • Refine prototypes into production • Implementation • Transition from development to operation • Provide Training
Other Agile Processes • Feature Driven Development (FDD) • Framework with features • Crystal Methodologies • Processes based on size and criticality • Adaptive Systems Development (ASD) • Large, complex systems
Limitations of Existing Agile Processes • Limited support for large & distributed development teams • Communication breakdowns • Limited support for code reusability • Project specific • Limited support for large, complex software • May require significant up front design and planning • Incremental delivery may not be valuable • Unproven
Agile Adoption • Adoption is slow but appears increasing • In March 2002, the Giga Group estimated • ~10% of corporate IT groups are using agile processes • 2/3 are exploring use for future projects
Future of Agile Software Development • Processes still evolving i.e.) XP with Scrum • Won’t eliminate traditional approaches • Traditional approaches still valuable • Here to stay? The new standard? • Only time will tell…
Summary: Agile Software Development • Quick and Responsive development • Iterative, incremental • Ample Customer Involvement • Different Processes available • Alternative to Traditional Methods