Any defender of the techniques, methodologies and metrics tool v3 agile argue that a system is too heavy, both in its implementation, and in its maintenance processes. I would corroborate, but not demonized.
I'm used to being in this world of computers are believed true "tenets of faith," which carry their own "religious wars." Examples might be: Proprietary vs. Open Source Software, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs. Netbeans, and we could go with a long list. Instead of finding the best solution, or universal solutions, I propose to make an intensive analysis, and answer certain questions. Generally, there is a solution worth "for everything." The question that finally we can throw more light is: "what is going to use?". That is, try to find the solution that best suits our specific problem or scenario. Metrics
v3 vs Agile methodologies are not an exception. I after having used both, I have an opinion. I would use Metrica v3 in the circumstances which I shall report:
- extremely large projects where it is important enough to have a specified functional analysis.
- Projects involving multiple teams, where communication is not always easy.
- Projects with potential to have a high staff turnover.
- Projects commissioned by clients who are not quite clear what they want, not what they expect.
- Projects with unstable initial conditions, with changes potentially high-impact, and large deviations in the timing of a project.
- Projects implemented by programmers very "junior."
- Projects that v3 metric is non-functional requirement of the client (usually government).
Many of these circumstances are reflected in the Chaos Report as causes of most failures in software development projects, and can be alleviated significantly by Metric.
is true that every change in the Functional Requirements (FRQ), for example, may mean you have to make changes in one or more, information requirements (IRQ), Constraints and Business Rules (CRC), in Case use, and even in the Data Model, and keep this often tedious and time consuming, but also provides:
- Some requirements are stable.
- A detailed project specification, which can reach the separation on many simple tasks.
- An analysis of the client must validate, and that is the "contract" for both developers and the customer.
- Traceability to tell us the impact and costs involved in a change request.
Instead, it is true that for projects that are not under the circumstances I have outlined above, the agile techniques, or an adaptation of these (depending on the project, expertise and equipment, client) can give us better results.
0 comments:
Post a Comment