Introduction to Agile Software Development Matt Henson Mt

  • Slides: 33
Download presentation
Introduction to Agile Software Development Matt Henson Mt. Baker PMI

Introduction to Agile Software Development Matt Henson Mt. Baker PMI

Agenda § About the Speaker § Software Development Process § Review of Traditional/Waterfall §

Agenda § About the Speaker § Software Development Process § Review of Traditional/Waterfall § Introduction to Agile § Example Agile Project Breakdown § Common myths and misconceptions 2 Mt. Baker PMI

Who am I? § IT Professional § BS in Computer Science; MBA § ~25

Who am I? § IT Professional § BS in Computer Science; MBA § ~25 years of IT experience in Healthcare (Acute Care and Insurance) § Experienced in the following roles: Developer, System Administrator, DBA, PC/Network Support, IT Management, Project Management § Certified PMP § Currently working as “Lead Environment Coordinator” for The Regence Group § IT Infrastructure Project Management § Strategic Environment Management across the project portfolio 3 Mt. Baker PMI

Software Development Process § A software development process is a structure imposed on the

Software Development Process § A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. • Courtesy of Wikipedia 4 Mt. Baker PMI

Waterfall Development Process § The waterfall model is a sequential development process, in which

Waterfall Development Process § The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The first formal description of the waterfall model is often cited to be an article published by Winston W. Royce in 1970 although Royce did not use the term "waterfall" in this article. • Courtesy of Wikipedia 5 Mt. Baker PMI

Traditional Software Development Also called “Waterfall” • Courtesy of Wikipedia 6 Mt. Baker PMI

Traditional Software Development Also called “Waterfall” • Courtesy of Wikipedia 6 Mt. Baker PMI

Waterfall Principles § Basic principles of the waterfall model are: § Project is divided

Waterfall Principles § Basic principles of the waterfall model are: § Project is divided into sequential phases, with some overlap and splash-back acceptable between phases. § Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time. § Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase. • Courtesy of Wikipedia 7 Mt. Baker PMI

Waterfall Manifesto 8 Mt. Baker PMI

Waterfall Manifesto 8 Mt. Baker PMI

Some interesting facts … 1995 : The CHAOS Report ** § Type 1 :

Some interesting facts … 1995 : The CHAOS Report ** § Type 1 : Project Success § § Type 2 : Project Challenged § § On time on budget, all features are delivered (16. 2%) Completed and operational but over budget, fewer features than specified (52. 7%) Type 3 : Project Impaired § Cancelled at some stage (31. 1%) **Tom Clancy 1995 | The Standish Group International 9 Mt. Baker PMI

Dilbert on Software Development Projects 10 Mt. Baker PMI

Dilbert on Software Development Projects 10 Mt. Baker PMI

11 Mt. Baker PMI

11 Mt. Baker PMI

The Results Please… Waterfall Development is often ineffective § Customers unhappy / Perceive lack

The Results Please… Waterfall Development is often ineffective § Customers unhappy / Perceive lack of quality § Requirement Changes are dealt through risk avoidance strategy § § Resist requirement change § Eliminating change means decreased business satisfaction (aka “quality”) This has led to evolutions in the way we approach software development 12 Mt. Baker PMI

Introducing Agile A brave new way of developing software § Don’t avoid risk, take

Introducing Agile A brave new way of developing software § Don’t avoid risk, take it as unavoidable and accept it; Manage It! § Requirement Changes are dealt through risk acceptance strategy 13 Mt. Baker PMI

Evolution of Agile is evolutionary not revolutionary The context of developing software is changing

Evolution of Agile is evolutionary not revolutionary The context of developing software is changing § § Technology driven business innovation § Dynamic Market conditions § Decreased Time to Market § Decreased Requirement Stability What does it mean for software development? § § Pushes Traditional IT out of the “comfort zone”, but into a focus on “what’s next” 14 Mt. Baker PMI

Definition of Agile § Agile software development refers to a group of software development

Definition of Agile § Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. • Courtesy of Wikipedia 15 Mt. Baker PMI

Agile Manifesto We are uncovering better ways of developing software by doing it and

Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 16 Mt. Baker PMI

Different Types of Agile XP = Extreme Programming; DSDM = Dynamic Systems Development Method

Different Types of Agile XP = Extreme Programming; DSDM = Dynamic Systems Development Method FDD = Feature Driven Development Mt. Baker PMI 17

Principles Behind Agile Manifesto § Our highest priority is to satisfy the customer through

Principles Behind Agile Manifesto § Our highest priority is to satisfy the customer through early and continuous delivery of valuable software § Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage § Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale 18 Mt. Baker PMI

Principles Behind Agile Manifesto § Business people and developers must work together daily throughout

Principles Behind Agile Manifesto § Business people and developers must work together daily throughout the project § Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done § The most efficient and effective method of conveying information to and within a development team is face-to-face conversation § Working software is the primary measure of progress 19 Mt. Baker PMI

Principles Behind Agile Manifesto § Agile processes promote sustainable development. The sponsors, developers, and

Principles Behind Agile Manifesto § Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely § Continuous attention to technical excellence and good design enhances agility § Simplicity--the art of maximizing the amount of work not done--is essential. § The best architectures, requirements, and designs emerge from self-organizing teams. § At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 20 Mt. Baker PMI

Risk Management thru Iterative Development § Minimize risk by developing software in short timeboxes,

Risk Management thru Iterative Development § Minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks § Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation 21 Mt. Baker PMI

Common Agile Terms/Concepts § JAD Sessions (Joint Application Design) § Story. Card (method for

Common Agile Terms/Concepts § JAD Sessions (Joint Application Design) § Story. Card (method for documenting high-level requirements) § Use Cases (method for documenting detail-level requirements) § Sprint/Iteration (1 -4 week period used to focus on specific deliverables) § Scrum (daily meetings among project team, focused on the following: § What was accomplished yesterday? § What is planned for today? § What are my current challenges? Need help resolving? 22 Mt. Baker PMI

Example Iterations Plan 23 Mt. Baker PMI

Example Iterations Plan 23 Mt. Baker PMI

Example Iterations (2 -3 week cycles) Initiation: Insurance Subscriber/Member Application § Develop initial list

Example Iterations (2 -3 week cycles) Initiation: Insurance Subscriber/Member Application § Develop initial list of Requirements/Break into Story Cards: § Login: Login to the Application § Register: Register New User § Mem. Inq: Membership Inquiry § Clm. Inq: Claims Inquiry § ID Card: Request for Member ID Card § Display. PHR: Display Personal Health Record § Edit. PHR: Edit Personal Health Record § Chat: Online Support Chat 24 Mt. Baker PMI

Example Iterations (continued) Iteration 1: § Elaboration: Delineate Story Cards: Login, Register, Chat §

Example Iterations (continued) Iteration 1: § Elaboration: Delineate Story Cards: Login, Register, Chat § Construction: Draft Initial Architecture/Identify Infrastructure Iteration 2: § Elaboration: Delineate Story Cards: Mem. Inq, ID Card, Clm. Inq § Construction: Do Proof of Concept for Online Support Chat § Construction: Begin Dev Infrastructure Iteration 3: § Elaboration: Delineate Story Cards: Display. PHR, Edit. PHR, Chat § Construction: Development on Story Cards: Login, Register § Construction: Finish Dev/Begin Test Infrastructure 25 Mt. Baker PMI

Example Iterations (continued) Iteration 4: § Test: Validation of Story Cards : Login, Register

Example Iterations (continued) Iteration 4: § Test: Validation of Story Cards : Login, Register § Construction: Dev on Story Cards: Mem. Inq, Chat § Construction: Finish Test/Begin PROD Infrastructure Iteration 5: § Test: Validation of Story Cards: Mem. Inq, Chat § Construction: Dev on Story Cards: Edit. PHR, Clm. Inq § Construction: Finish PROD Infrastructure Iteration 6: § Test: Validation of Story Cards : Edit. PHR, Clm. Inq § Construction: Dev on Story Cards: IDCard, Display. PHR § Construction: Bug fixes 26 Mt. Baker PMI

Example Iterations (continued) Iteration 7: § Test: Validation of Story Cards : IDCard, Display.

Example Iterations (continued) Iteration 7: § Test: Validation of Story Cards : IDCard, Display. PHR, Bug Fixes § Test: Data Preparation for User Acceptance Testing § Construction: Bug Fixes Iteration 8: § Test: Begin User Acceptance Testing § Test: Begin Performance Testing Iteration 9: § Test: Complete User Acceptance Testing § Construction: Bug Fixes for Production Issues § Transition: Go-Live w/ Application 27 Mt. Baker PMI

Myths & Misconceptions Agile _____ § Is a silver bullet § Will solve my

Myths & Misconceptions Agile _____ § Is a silver bullet § Will solve my resource issues § Has no planning/ documentation/architecture/ <insert peeve> § Is a license to hack § Creates quality issues § Is undisciplined § Doesn’t build on my previous experience / expertise § Is not proven § Is not being used by industry leaders 28 Mt. Baker PMI

Myths & Misconceptions § Agile methods are sometimes characterized as being at the opposite

Myths & Misconceptions § Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies § § This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined“ A more accurate distinction is to say that methods exist on a continuum from “Agile/Adaptive" to “Waterfall/Predictive” 29 Mt. Baker PMI

Myths & Misconceptions § Adaptive methods focus on adapting quickly to changing realities §

Myths & Misconceptions § Adaptive methods focus on adapting quickly to changing realities § § § When the needs of a project change, an Agile team changes as well An Agile team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an Agile method will be about what will happen on that date An Agile team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an Agile team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. 30 Mt. Baker PMI

Myths & Misconceptions § Waterfall methods, in contrast, focus on planning the future in

Myths & Misconceptions § Waterfall methods, in contrast, focus on planning the future in detail § A Waterfall team can report exactly what features and tasks are planned for the entire length of the development process § The plan is typically optimized for the original destination and changing direction cause completed work to be thrown away and done over differently § Waterfall teams have difficulty changing direction 31 Mt. Baker PMI

Myths & Misconceptions § Agile methods vs Capability Maturity Model (CMM) § CMM/CMMi is

Myths & Misconceptions § Agile methods vs Capability Maturity Model (CMM) § CMM/CMMi is NOT a method or a process model § It is a reference process benchmark § CMM/CMMi don’t prescribe what process (for developing software that is) to use § Agile Software Development process can be benchmarked on CMM/CMMi models § Initial, Managed, Defined, Quantitatively Managed & Optimizing 32 Mt. Baker PMI

Questions? Thank You!

Questions? Thank You!