1 / 13

Taking a Waterfall Project Agile

Taking a Waterfall Project Agile. Establishment of an Agile Project. REF: Paul Geberth. GCSS-J Project Manager. What Is Agile. Agile vs. Waterfall: Waterfall based in: Long phases. Heavy investment on big up front design . Lacks flexibility.

Download Presentation

Taking a Waterfall Project 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. Taking a Waterfall Project Agile Establishment of an Agile Project REF: Paul Geberth GCSS-J Project Manager

  2. What Is Agile • Agile vs. Waterfall: • Waterfall based in: • Long phases. • Heavy investment on big up front design. • Lacks flexibility. • Customers want the ability have new capabilities within a few months: • Agile is highly responsive to change. • Rapid/focused release cycles. • Customer (stakeholder) daily involvement is key.

  3. Why go Agile – Waterfall Model Waterfall Life-Cycle cartoon by Geoff Harris "Everything is going great, our risks have been identified, our customer is in complete agreement. System testing should be a breeze".

  4. Why go Agile – Waterfall Model Waterfall Life-Cycle cartoon by Geoff Harris

  5. Why go Agile – Waterfall Model • Global Combat Support System (GCSS-J ) executing as a Waterfall styled program: • Well defined schedule with firm milestone dates. • Loosely defined requirements. • Milestones and deliveries followed the typical Waterfall methodology: • It quickly became apparent that waterfall was • NOT the correct answer for us !

  6. What is Agile http://en.wikipedia.org/wiki/Agile_software_development

  7. Why go Agile – Continuous Integration Transition • Continuous Integration is a software development practice where members of a team integrate their work frequently. Each person usually integrates at least daily - leading to multiple integrations per day. Because of high integration frequency, every integration has to be verified by an automated build to detect integration errors as quickly as possible, which prevents errors from snowballing.

  8. Why go Agile Increasing productivity, Reducing time to market, Reducing software defects. By monitoring build status in near real time, we ensured that a broken build could be fixed quickly. This resulted in always having a working system on daily basis. Automate Detect build detects any modifications, automatically tries to build the software and execute tests. Remote developers checking code in/out from Source control Source Control Upon notification of a build failure, developers responsible for the offending code fix the broken build, generally within the same day. Sends email notifications of build success or failure to developers.

  9. Establishment of an Agile Project • A survey done by VersionOne on companies practicing the Agile development approach showed that 55% of respondents reported 25% or greater improvement in productivity • In another survey, Microsoft researchers found out that using TDD alone led to 2-4 times increase in software quality at cost of 20%-35% more time. • The Logistics Decision Support System (LDSS), is developing a complete, integrated logistics decision support system for the Army’s Future Combat System by implemented Continuous Integration and Test Driven Development, and what we learned and gained from practicing these two Agile techniques.

  10. Practicing Test-Driven Development • An automated build server can detect trivial compilation errors, but it can not detect runtime bugs. • The important of Test Driven Development is writing unit tests and integration tests (not after the fact) to detect runtime bugs early on. • One of the biggest challenges is components to be developed form a huge web of inter-dependencies, which makes it impossible to predict which inter-dependencies are going to be the development bottlenecks. • Utilized the Dependency Injection design pattern. We sought to establish a level of abstraction via public interfaces and to remove dependencies on components by supplying a plug-in architecture.

  11. Practicing Test-Driven Development

  12. Managing Integration Complexity via Dependency Injection • Finding and fixing bugs in a large software system is very time-consuming. This complexity usually leads to an integration nightmare in terms of cost and schedule. • By gradually introducing integration dependencies via Dependency Injection along the course of software development, we were able to focus effort efficiently on finding and fixing bugs. • First of all, we started with layered system designs, we constructed mock layers so that development teams could use these mock layers for writing automated integration tests. • As we developed and tested more components, we started replacing mock components with real implementation components and writing more automated integration tests. This approach allowed us to gradually build up the system with thoroughly tested and integrated components.

  13. Benefits of Agile • Working software is the primary measure of progress. • 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. • Business people and developers must work together daily throughout the project. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

More Related