Ευέλικτες μέθοδοι διοίκησης

The Agile SDLC follows a pre-determined sequence of specific development phases.

The Agile SDLC is divided into small work phases, called “iterations” which incrementally/iteratively build versions of the final system.

Development iterations in agile SDLC take place after the completion of the requirements definition and the system design.

The software module resulted from an iteration has not to be integrated in the full system. 

The Agile SDLC delivers software to customers at specific milestones.

When following the Agile SDLC, a working version of software is delivered at the end of the project.

When following the Agile SDLC, a working version of software is delivered very frequently.

The Agile SDLC achieves early and continuous delivery of software to customers.

The Agile SDLC is always effective for large-scale projects.

The Agile SDLC is always effective for projects requiring a large number of developers.

The Agile SDLC sets as primary project aim the business return on investment.

The Agile SDLC sets as primary project aim the customer satisfaction.

Developer satisfaction is a minor concern in agile projects. 

The Agile SDLC offers adaptability to market needs. 

The Agile SDLC achieves fast time-to-market. 

In agile projects, achieving fast time-to-market is more important concern than achieving high quality of the final product.

Each agile team member is responsible to report his/her work to other team members.

All agile team members are responsible to keep an uninterrupted pace of development work.  

The agile team is only composed of developers with high technical expertise.

The agile team members often rely on other experts, outside the team, in order to perform their work.

In projects following a conventional SDLC (e.g., Waterfall), testing the code can be performed early in the project life-cycle.

In projects following a conventional SDLC (e.g., Waterfall), the requirement model engineered at the design and implementation phases might not necessarily correspond to the actual features needed to be implemented.

The Agile SDLC allows customers to delay their decisions about their requirements.

The Agile SDLC avoids ‘up-front’ requirements elicitation from the customers/end-users.

The frequent release of software in Agile SDLC allows customers to provide feedback to refine the requirements implemented earlier before the current release.

In Agile SDLC, the stakeholders are given the opportunity to revise the business factors at the beginning of each iteration to include additional features into the system according to the business return on investment.

In projects following a conventional SDLC (e.g., Waterfall), the development teams often try to obtain every detailed requirement during the early phases of the development process. Then the development teams would start the design phase, followed by the coding phase.

The Agile SDLC is not an appropriate choice for exploratory projects in which requirements are unknown/unstable and new technology is required to be tested/evaluated.