Flowchart for choosing the best software development methodology

From the sandbox

Introduction

How to choose a methodology? Often, when it is necessary to make a decision about choosing a methodology, there is too much heterogeneous information in your head and it is hard to understand what exactly is best for the project. In this article, I present a flowchart of choosing the best methodology as a hint to draw attention to some of the most important aspects.

First of all, I want to note that there is no universal set of conditions for all situations when choosing a particular methodology. In each case, you should focus on the specifics of your project. The considered flowchart will only outline the main aspects and allow you to recall the features of the main methodologies. In no case do I urge to treat it as the only correct guide for choosing a methodology. Moreover, it is not worth extending it to such complex projects as the creation of an operating system, aircraft avionics, and simulation of nuclear reactions.

Secondly, choosing a methodology does not need to blindly follow it. Often it is necessary to “finish” it by adapting it to your project. Something can be thrown out, something can be added from other methodologies, and something can be added. For example, no one bothers you to use such practices as pair programming in a waterfall model, if it will benefit you. On Habré there is an excellent article on the adaptation of Scrum and Kanban to a specific project, which well illustrates this principle.

In the next chapter, I will very briefly talk about the methodologies and models of the life cycle mentioned in the article for those who hear about them for the first time. You can read more about each of them on Wikipedia. If you already know them, then you can safely proceed to Chapter 2: “Analysis of the flowchart”.

1. Brief Description

Life cycle model is a general description of how the development process takes place.

Methodology - a more detailed set of rules, practices and principles, as a way to implement a particular model. For example, the Scrum methodology implements an iterative development model.

A process framework - roughly speaking, this is a methodology that contains a large number of rules, but in which it is not necessary to use all of them, but you can choose only what you need and build your development process. They include special applications that allow you to view and edit the rules. Examples: RUP, EssUp.

Cascade model(or model of a waterfall, Waterfall) - is characterized by the fact that the stages of development, such as: analysis, design, implementation, testing, go one after another. It allows you to quickly create a system, without additional overhead costs for organizing the development process. However, it only works when the requirements are stable and do not change during development, as we immediately describe all the requirements, and then immediately design the entire system.

V-model- Invented in Germany and the USA, as a way to improve the cascade model for use in government projects. V-Model has the specifics of projects for government agencies: fixed requirements, cost and time. The difference is that the analysis and design phase is associated with the testing phase. For example, during the analysis of requirements, testing approaches are simultaneously studied, during the design of the system architecture, high-level test plans and test scenarios are developed, during the design of system components, methods for testing components and their interactions are studied, test scripts are created, utilities are written to assist in testing, instructions, scripts etc. All this helps to better understand the requirements and design the system. However, here, as well as in the cascade model, it is undesirable for the requirements to change during development.

Spiral model - focused on projects in which there are serious risks. Development is presented in the form of a spiral. Each turn of the spiral is an iteration. A spiral coil consists of four stages: planning, risk analysis, development, and customer assessment. At the end of each iteration, it is decided whether to continue the project. A characteristic feature is that at the stage of risk analysis prototypes, concepts, models are created that are designed to resolve the risk at an early stage. The farther the spiral movement, the more product development and less prototypes and concepts. A typical application of this model is research projects. It is a very expensive model, and is not justified in systems where the risks are negligible.

Iterative model- focused on projects where requirements may change during development. The project consists of iterations (from 1-2 to 6 weeks). Each iteration can include a stage of analysis, design, implementation, testing. It has a large overhead for organizing the process than the cascade model, however, the cost of fixing the error depending on the duration of the project is not so high. The following methodologies implement an iterative model: Scrum, XP, partly Kanban.

Scrum Methodology(Scrum) - an iteration is called a sprint. The team consists of 3 roles: the product owner (customer representative), the scrum master (monitors the process), the rest of the team. Sprint starts with a planning meeting, when the team selects and distributes tasks for iteration, forming a sprint backlog. The sprint ends with a sprint review where a product demonstration is held and a sprint retrospective rally to discuss improvements. 15-minute scrum meetings are held daily.

Extreme Programming Methodology(XP) - consists of 12 practices: pair programming, development through testing, refactoring, simple architecture, collective code ownership, continuous integration, customer on the team, frequent releases, planning game, 40-hour work week, coding standards, system metaphor . Be sure to use all 12 practices.

The Kanban Methodology is a pipeline of tasks. It has only 3 rules: visualization of the development process using a kanban board, a limit on the number of tasks at each stage, continuous measurement of team performance and improvement.

RAD Methodology(Rapid Application Development) - focused on the rapid development of the application, iteratively, with the simplest architecture, minimum process costs, making the most of ready-made components and powerful tools. Has a limitation on the duration of the project - 60-90 days. I like the analogy with semi-finished patties. So, RAD - when you need to quickly mold a pie of ready-made components.

2. Analysis of the flowchart

Startups are characterized by the fact that there, especially in the initial period, everything is built on enthusiasm. Not always people work 8 hours a day. If they impose some kind of methodology and put in a certain framework, then either all the enthusiasm will fade away, or no one will follow the rules. For example, it’s rather silly to expect a startup initiator to come to a scrum rally in the morning in the morning after a stormy night of coding. In the future, when everything stabilizes, you can move on to the use of an appropriate methodology.

Each project has risks. However, in this case, the risks are so serious that it is not known in advance whether the system can be implemented at all. If such risks are present, then most likely you will begin development with prototypes, concepts, models, etc. to find out the fundamental possibility of what was conceived. In this case, the spiral model is the most optimal model for you. A typical example of the application of this model is research projects. But the use of this model is not limited only to research projects.

A real-life example in the retail industry: we needed to develop a mobile application that was supposed to actively interact with certain equipment via Bluetooth. These were readers of various cards, various types of printers and barcode scanners. We did not know if this was even possible on a mobile platform. Therefore, we started with prototypes and concepts in which we tried to find out the fundamental possibility of interacting with equipment and the existing limitations. Then we met with the customer, demonstrated what happened and discussed workarounds for what we could not implement.

If in your case there are no such serious risks, then the following question arises: will the requirements change. If your requirements are well known in advance, and you are sure that the customer will not make any significant changes during the development process, then you should choose a cascading development model. I recommend choosing a cascade model when the project has a short duration. In the case of clear and unchanging requirements, coupled with a short duration, the cascade model in comparison with the iterative model will give less overhead for the process. At the whole stage of the programmer’s implementation, nothing will distract from writing code: neither the need to urgently fix bugs from the previous iteration, nor the endless rallies and releases.

However, in the case of lengthy projects, the cascade model will not work well. Despite the fact that there are no risks of changing requirements, there are technical risks. For example, if you developed an incorrect architecture, chose the wrong technologies and tools, did not calculate the required performance, etc., with a high degree of probability you will know about it at the end, and there may be no time for correction. The longer the project lasts, the higher the cost of fixing the error. If at the initial stage refactoring and cardinal code changes are easy, then at the end of the project, doing this is pretty “painful”.

An example from practice: we needed to implement a mobile application that would do exactly the same thing as the same application for a desktop computer. Thus, the requirements were known and unchanged throughout the project.

The next question is whether the requirements are complex. The question is again ambiguous and depends on the project. When you start a project, it is sometimes useful at the stage of analysis and design to think about how you will test. This can help to identify potential problems earlier and better implement the architecture, work out the requirements, etc. When the requirements are complex, it is recommended that you carefully think through all the test scenarios, and at the stage of analysis and design, develop testing approaches, test plans and test cases. In this case, the V-Model, which is a kind of cascade model, comes to our aid.

Application of V-Model where the requirements are quite simple will lead to the fact that the system will be more expensive. Moreover, the V-Model is criticized for the fact that it generates a lot of documentation and bureaucracy and serves in reality not to create high-quality software that satisfies the customer, but to prove at the end of the project that the system works as it was originally required, instead of really developing what he needed.

A formalized approach is that all the processes of the application life cycle are regulated in detail. This is necessary in complex large projects with a large team.

An example is the systems on which people's lives depend: medicine, transport, energy. Typically, such systems are developed in accordance with industry standards, repeatedly tested, subject to licensing. Easy methodologies in such systems do not work. As you know, live communication in them is preferable to documentation, but, for example, if your application will be tested several times by different teams, it is better if this process is carefully documented. If there are dozens of people in the team, then no product owner (customer representative for Scrum terminology) will be able to constantly explain the requirements to them all.

Thus, if you need a formalized approach, then your choice will be such methodologies as RUP, OpenUp, EssUp. Such methodologies are more than methodologies and it is more correct to call them process frameworks. They were originally created for an iterative model, however, they can also be used in the cascade model through modifications.

If we do not need a formalized approach, then we will use the so-called flexible methodologies. Speed or quality? In fact, a slightly more complex formulation is implied here: productivity or engineering?

Productivity is understood as the fastest process of adding functionality to the application. Engineering means a high level of development organization, innovative approaches and sophisticated techniques that can only be applied by an experienced team. I am talking about such extreme programming practices as development through testing, continuous integration, pair programming, etc. A feature of extreme programming is that you must use all 12 practices, only then the effect of them becomes maximum. If you do not use any practice, it will surely pull everyone else along with it. For example, if you refuse unit tests, then you will not be able to do frequent refactoring,

However, you can use extreme programming practices in other methodologies, moreover, it can be very useful. For example, you can use pair programming in Scrum to help newcomers quickly join the project. Thus, extreme programming can provide high quality due to a higher level of engineering, but when choosing this methodology, the project can turn out to be more expensive. Also, for successful application, a team that already has experience in using this methodology is required.

If you need maximum productivity, then there are also options. Scrum is focused on continuous process improvement. To do this, he has a retrospective rally, which is held at the end of the sprint. Also during the sprint review, it is discussed what has been done well, what is bad and what to improve. If you have an experienced team, a well-established process and you basically do not need improvements, then following the Scrum methodology will take away too much time from you that you could spend more profitably. For example, according to Scrum, if the sprint lasts 1 month, then a sprint review should take 4 hours and a sprint retrospective should take 3 hours. Plus, there is sprint planning lasting 8 hours and daily Scrum rallies of 15 minutes.

If you, for example, have an uncoordinated team, either using tried-and-true technologies or an unfamiliar scope of application for your application or all taken together, then choosing the Scrum methodology can be a great solution. When a new project begins, you can start using Scrum, and when the process becomes more streamlined, the architecture stabilizes, the need for continuous improvements disappears, then you can move on to another methodology, for example, Kanban.

If improvements are not needed and all that is needed is to concentrate on the tasks, then RAD or Kanban is good. RAD has much in common with agile methodologies, but it has a significant limitation on the duration of the project. Preferably no more than 60-90 days. Kanban is like some kind of continuous conveyor that can last forever. It works well on support projects, but poorly where complex architecture is required, as focused on the rapid addition of features to the application. By features we mean a piece of functionality that is visible to the user and directly solves some of his problem. For example, logging, optimization and scalability are not visible to the user, these are not features in Kanban terminology. But the new page, report, additional filters in the search are what the user sees and is a feature.

Sources:

1. Dr. Winston, W. Royce. Managing development of large software systems. 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. W Boehm, A spiral model of software development and enhancement. 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf
3. W Boehm. Spiral Development: Experience, Principles, and Refinements. 2000. http://www.sei.cmu.edu/reports/00sr008.pdf
4. S. Belousova, I. Bessonova, Ruggero Gilyarevsky. Introduction to software systems and their development. HSE. http://www.intuit.ru/studies/courses/3632/874/info
5. C. Schwaber, D. Sutherland. Scrum Hyde. Comprehensive Scrum Guide: Game Rules.
http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100
6. Rational Unified Process. Best Practices for Software. Development Teams. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Introduction to OpenUP. http://epf.eclipse.org/wikis/openup/
7. H. Kniberg, M. Skarin. Scrum and Kanban: Squeeze the maximum. InfoQ. 2010
8. C. Auer, R. Miller. Extreme programming. Setting processes. - SPb .: Peter: 2004
9. Extreme programming - reality and myths. skipy.ru/philosophy/xp.html
10. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, USA, 2003
11. James Christie. The seductive and dangerous V Model.
http://www.clarotesting.com/page11.htm
12. Adel Alshamrani. A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental / Iterative Model. http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model

Tags: