Don’t panic about the different views,take your time and read it for sure it would make your life simple.
Many people will correctly say that agile software development conforms to the values and principles of the Agile Alliance (AA).
1. Iteration 0: Project Initiation
The first week or so of an agile project is often referred to as “Iteration 0” (or “Cycle 0”). Your goal during this period is to initiate the project by:
Garnering initial support and funding for the project. This may have been already achieved via your portfolio management efforts, but realistically at some point somebody is going to ask what are we going to get, how much is it going to cost, and how long is it going to take. You need to be able to provide reasonable, although potentially evolving, answers to these questions if you’re going to get permission to work on the project. You may need to justify your project via a feasibility study.
Actively working with stakeholders to initially model the scope of the system. As you see in Figure 2, during Iteration 0 agilists will do some initial requirements modeling with their stakeholders to identify the initial, albeit high-level, requirements for the system. To promote active stakeholder participation you should use inclusive tools, such as index cards and white boards to do this modeling – our goal is to understand the problem and solution domain, not to create mounds of documentation. The details of these requirements are modeled on a just in time (JIT) basis in model storming sessions during the development cycles.
Starting to build the team. Although your team will evolve over time, at the beginning of a development project you will need to start identifying key team members and start bringing them onto the team. At this point you will want to have at least one or two senior developers, the project coach/manager, and one or more stakeholder representatives.
Modeling an initial architecture for the system. Early in the project you need to have at least a general idea of how you’re going to build the system. Is it a mainframe COBOL application? A .Net application? J2EE? Something else? As you see in Figure 2, the developers on the project will get together in a room, often around a whiteboard, discuss and then sketch out a potential architecture for the system. This architecture will likely evolve over time, it will not be very detailed yet (it just needs to be good enough for now), and very little documentation (if any) needs to be written. The goal is to identify an architectural strategy, not write mounds of documentation. You will work through the design details later during development cycles in model storming sessions and via TDD.
Setting up the environment. You need workstations, development tools, a work area, … for the team. You don’t need access to all of these resources right away, although at the start of the project you will need most of them.
Even today morning I had a talk from one of my collegaue in regards to the AMDD ,but it wasn’t much about what real AMDD was about. Basically I am often asked by my group members to facilitate workshops overviewing the ideas presented in the Agile Manifesto and agile techniques such as Test-Driven Design (TDD), database refactoring, and agile change management.
One issue that many people seem to struggle with is how all of these ideas fit together, and invariably I found myself sketching a picture which overviews a generic lifecycle for agile software development projects. This lifecycle is captured in Figure 1, which is comprised of four phases: Iteration 0, Development, Release/End Game, and Production. Although many agile developers may balk at the idea of phases, perhaps Gary Evan’s analogy of development seasons may be a bit more palatable, the fact is that it’s been recognized that processes such as Extreme Programming (XP) and Agile Unified Process (AUP) do in fact have phases (for diagrams, see XP lifecycle and AUP lifecycle respectively). Furthermore, the Agile MSF calls its phases/seasons “tracks”.
2. Development Iterations
During development iterations agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders, as overviewed in Figure 3
We achieve this by:
Collaborating closely with both our stakeholders and with other developers. We do this to reduce risk through tightening the feedback cycle and by improving communication via closer collaboration.
Implementing functionality in priority order. We allow our stakeholders to change the requirements to meet their exact needs as they see fit. The stakeholders are given complete control over the scope, budget, and schedule – they get what they want and spend as much as they want for as long as they’re willing to do so.
Analyzing and designing. We analyze individual requirements by model storming on a just-in-time (JIT) basis for a few minutes before spending several hours or days implementing the requirement. Guided by our architecture models, often hand-sketched diagrams, we take a highly-collaborative, test-driven design (TDD) approach to development (see Figure 4) where we iteratively write a test and then write just enough production code to fulfill that test. Sometimes, particularly for complex requirements or for design issues requiring significant forethought, we will model just a bit ahead to ensure that the developers don’t need to wait for information.
Ensuring quality. Agilists are firm believers in following guidance such as coding conventions and modeling style guidelines. Furthermore, we refactor our application code and/or our database schema as required to ensure that we have the best design possible.
Regularly delivering working software. At the end of each development cycle/iteration you should have a partial, working system to show people. Better yet, you should be able to deploy this software into a pre-production testing/QA sandbox for system integration testing. The sooner, and more often, you can do such testing the better.
Testing, testing, and yes, testing. As you can see in Figure 5 agilists do a significant amount of testing throughout development. As part of development we do confirmatory testing, a combination of developer testing and agile acceptance testing. In many ways confirmatory testing is the agile equivalent of “testing against the specification” because it confirms that the software which we’ve built to date works according to the intent of our stakeholders as we understand it today. This isn’t the complete testing picture: Because we are producing working software on a regular basis, at least at the end of each iteration, we’re in a position to deliver that working software to an independent test team for investigative testing. Investigative testing is done by test professionals who are good at finding defects which the developers have missed. These defects might pertain to usability or integration problems, sometimes they pertain to requirements which we missed or simply haven’t implemented yet, and sometimes they pertain to things we simply didn’t think to test for.
During the release iteration(s), also known as the “end game”, we transition the system into production. Not that for complex systems the end game may prove to be several iterations, although if you’ve done system and user testing during development (as indicated by Figure 3) this likely won’t be the case. As you can see in Figure 6, there are several important aspects to this effort:
Final testing of the system. Final system and acceptance testing should be performed at this point, although as I pointed out earlier the majority of testing should be done during development iterations. You may choose to pilot/beta test your system with a subset of the eventual end users. See the Full Lifecycle Object-Oriented Testing (FLOOT) method for more thoughts on testing.
Rework. There is no value testing the system if you don’t plan to act on the defects that you find. You may not address all defects, but you should expect to fix some of them.
Finalization of any system and user documentation. Some documentation may have been written during development cycles, but it typically isn’t finalized until the system release itself has been finalized to avoid unnecessary rework Note that documentation is treated like any other requirement: it should be costed, prioritized, and created only if stakeholders are willing to invest in it. Agilists believe that if stakeholders are smart enough to earn the money then they must also be smart enough to spend it appropriately.
Training. We train end users, operations staff, and support staff to work effectively with our system.
Deploy the system. See my article entitled System Deployment Tips and Techniques.
The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems.
This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time