Please kindly introduce the Agile Methodology.
Agile development methodology wiki illustrates how Agile is the opposite of traditional waterfall projects where you make a detailed plan and implement the plan. Making detailed plans is an efficient way of approaching projects when it is clear what the end product.
When you are not, you need to accept it will take multiple iterations to create the desired end product. That is where Agile methodology has a clear advantage over traditional project management. Agile accepts there will be changes and pro-actively accepts this in their methodologies.
Agile is not a new concept and can be traced back to 1957, in the early 1990’s a number of software development methodologies were being used by software teams. The Agile Development Methodology four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
When and why should we use Waterfall and Agile Methodologies?
Although Agile presents some appealing benefits, it’s not the perfect development methodology for all software product initiatives.
The outcome and timeline are less predictable. Agile uses an iterative approach to software development which allows the product owner the opportunity to be flexible with the project scope and timeline. This means at the project onset the end date and scope may not be known and scope creep is possible.
The customer (product owner) must invest time in the project: A key element of Agile development is the participation of the product owner in the project. The product owner is a member of the agile team and must be prepared to devote the time necessary to ensure the team has the information necessary to build the product.
Documentation is not a deliverable of Agile. In a regulated verticals, such as healthcare, documentation is required. Documentation is not produced during an Agile software development project.
A trust relationship must exist between members of the team. It takes time to build trust amongst team members if delivering a product using an Agile methodology is a first time experience for your organization. Product managers and the rest of the team need to work closely together when working using Agile and so building that trust to deliver is crucial.
Re-work is inevitable with Agile. Things change all the time when developing using an Agile methodology, so expect that code will need to be refactored.
It’s a well-defined methodology that has been used in all business verticals. It’s a tried and true methodology that is pretty straightforward and expectations are clear.
The methodology defines what you are building to a very detailed level at the beginning of the process. This makes setting deliverable dates, start/end dates, milestone planning, as well as the team’s ability to track progress much easier.
Developers and testers can focus on writing code and writing test cases. They don’t have to work with stakeholders to determine what the product requirements are.
What the team is going to deliver is more predictable. Because the product requirements are documented and approved prior to the beginning of development, there is a commitment to deliver a specific set of features which makes the final product more predictable.
Why should we use the Delphi Panel for measuring and sizing the software package?
The Delphi Technique can be an especially useful research methodology when there is no true or knowable answer, such as decision-making, policy, or long-range forecasting. A wide range of opinions can be included, which can be useful in cases where relying on a single expert would lead to bias.
The Delphi technique was recommended as the method of choice when:
Do'stlaringiz bilan baham: |