Since not every reader may be familiar with every method, here are short descriptions of the ones in the article:Īgile with scrum: The term “agile” is ambiguous and there are many flavors of agile. The author has a proprietary method for mathematically adjusting application sizes to a fixed size in order to facilitate side-by-side comparisons.) (Note that the actual applications being compared ranged from about 800 function points in size to 1,300. There are unfortunately too many methodologies to consider all of them, so a subset of 10 methods will be shown, all of which are fairly widely used in the United States. In this article the basic assumptions will be these:īy holding size, languages, complexity, and team experience at constant levels it is easier to examine the impacts of the methodologies themselves. Since the number of combinations is far too large to consider every one, this article will make simplifying assumptions in order to focus primarily on the methodologies, and not on all of the other factors. Size plateau of application (small, medium, large)Īpplication complexity (low, average, high)
Agile scrum app software#
Let us consider the major factors that are known to have an impact on software project results: However that is difficult because of combinatorial complexity. The blind man who touched the tusk thought an elephant was like a spear the blind man who touched the tail thought an elephant was like a rope.) Combinations of Factors that Affect Software ProjectsĪn ideal solution would be to evaluate a variety of methods across a variety of sizes and types of software. The blind man who touched the side thought an elephant was like a wall. (In the original parable the blind man who touched the trunk thought an elephant was like a snake. Different methods have the highest speed, the highest quality, and the lowest total cost of ownership. When software methodologies are evaluated the results bring to mind the ancient Buddhist parable of the blind men and the elephant. Many companies do not even attempt to evaluate alternative methods, but merely adopt the most popular method of the day, whether or not it is suitable for the kinds of software they build. Unfortunately due to lack of quantified data and comparisons among methodologies, selecting a software development method is more like joining a cult than a technical decision. How is it possible to select the best methodology for specific projects? Is one methodology enough, or should companies utilize several based on the kinds of projects they need to develop? Some methods work best for small applications and small teams others work well for large systems and large teams some work well for complex embedded applications some work well for high-speed web development some work well for high-security military applications. The existence of more than 55 software development methods, each with loyal adherents, is a strong message that none of the 55 is capable of handling all sizes and kinds of software applications.
Agile scrum app plus#
Attend in-person QCon London (April 4-6, 2022) or online QCon Plus (May 10-20, 2022). Uncover emerging trends and practices from domain experts. The predictions use the author’s proprietary Software Risk Master™ tool which can model all 55 software development methodologies. The data itself comes from studies with a number of clients who collectively use a wide variety of software methods. Some of the development methods include the traditional waterfall approach, various flavors of agile, the Rational Unified Process (RUP), the Team Software Process (TSP), V-Model development, Microsoft Solutions Framework, the Structured Analysis and Design Technique (SADT), Evolutionary Development (EVO), Extreme Programming (XP), PRINCE2, Merise, model-based development, and many more. There are about 55 named software development methods in use, and an even larger number of hybrids. This article uses several standard metrics including function points, defect removal efficiency (DRE), Cost of Quality (COQ), and Total Cost of Ownership (TCO) to compare a sample of contemporary software development methods. Many companies do not even attempt to evaluate methods, but merely adopt the most popular, which today constitute the many faces of agile.
In general selecting a software development methodology has more in common with joining a cult than it does with making a technical decision.
0 kommentar(er)
