1 / 14

So what the heck is Agile?

So what the heck is Agile?. It came about as a response to the high failure rate of software projects (> 60%), where failure means late , over budget or incomplete People were looking for better ways to deliver software But why were most IT projects failing?. Traditional Software Projects.

phaynes
Télécharger la présentation

So what the heck is Agile?

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. So what the heck is Agile? • It came about as a response to the high failure rate of software projects (> 60%), where failure means late, over budget or incomplete • People were looking for better ways to deliver software • But why were most IT projects failing? AgileMan Consulting

  2. Traditional Software Projects • Typical projects have these phases: • Estimate size of project based on high level concept • Create full set of functional requirements • Create full set of internal / technical specifications • Write the code (the fun stuff!) • Test/QA the code (less fun but very important!) • Install the new code (cross fingers & hope for the best) • Each phase is discrete & usually requires official sign-off before next one can begin • Resembles a waterfall, with each “step” serialized AgileMan Consulting

  3. Why Hasn’t That Worked? • Specs are hard to get right ahead of time • Projects take months or years; markets can change weekly • Focus is on “meeting dates,” not satisfying customers • Software isn’t like manufacturing • It’s innovation, not replication • Good estimates are hard to come by! • A lot is learned in the doing AgileMan Consulting

  4. So… What, Then? • In the 1990s, Extreme Programming (XP), Scrum, Feature-Driven Development and other non-traditional approaches began emerging as people experimented • In 2001, representatives of each convened to look for commonalities between them • What did they find? AgileMan Consulting

  5. The Agile Manifesto • Some common principles were discovered • “We value: • People & interactions over Processes & tools • Customer collaboration over Contract negotiation • Responding to change over Following a plan • Working software over Comprehensive documentation” (read more @ www.agilemanifesto.org) • But what does any of that mean? AgileMan Consulting

  6. Agile: The 30,000 Foot View • Agile methodologies are all about: • Empowering & engaging people at all levels • Keeping the customer involved throughout • Allowing for flexibility • Delivering functionality incrementally (in short Iterations… sometimes as little as 1 week!) • Using short feedback loops to drive adaptation • How is that any different from traditional (“Waterfall”) software development? AgileMan Consulting

  7. Waterfall Product Delivery A B C AgileMan Consulting

  8. Agile Product Delivery A B C D AgileMan Consulting

  9. Waterfall: Large, upfront design & specifications Changes often result in waste (abandoned work) Everything arrives at end of project (hopefully!) Agile: “Just in time” design & specifications Changes are expected and typically don’t cause waste Features are delivered incrementally throughout project Side by Side Comparison AgileMan Consulting

  10. Waterfall: Customer involved at start & end of project only Mid-project demos expensive & often misleading Project status often unclear or inaccurate Agile: Customer involved throughout, feedback acted upon Working software arrives each Iteration as part of plan (no “Demoware”) Project status updated frequently & demonstrably Side by Side Comparison AgileMan Consulting

  11. Waterfall: Most testing occurs at end of project (near deadline) Testing typically done manually (in QA cycle at end of project) Stakeholders focus on adhering to plan Agile: Testing happens in every Iteration throughout project Emphasis placed on automating testing (so that it can be done throughout) Stakeholders focus on delivering customer value in priority order Side by Side Comparison AgileMan Consulting

  12. Waterfall: No time allocated in plan for process improvement Developers & testers are directed by management on what tasks to work on Agile: “Inspect & Adapt” is built into process & accounted for Team members are self-directed & encouraged to find better ways to work Side by Side Comparison AgileMan Consulting

  13. So How Does Agile Work? • Customer asks for something or builds a prioritized queue of requests • Agile team works with Customer to understand what’s really being asked for • Agile team sizes each request as it comes in • Agile team breaks top priority item(s) into small pieces that can be delivered in a short Iteration • Agile team produces those pieces, “done done done” (tested, documented, free of known defects) AgileMan Consulting

  14. So How Does Agile Work? • Customer tries out each piece as it comes, provides feedback • Partial functionality may / may not go into production • Scope of overall project will change as circumstances allow (or dictate) • If project is date-bound, customer gets as many high priority features as possible by end date • If project is feature-bound, customer gets full set of features by earliest possible date AgileMan Consulting

More Related