At many interviews, you’ll probably be asked about methodologies. This is not the most important or difficult question, but having a cheat sheet would be nice. In this article, we will try to convey what a development methodology is and compare them. A software development methodology is a process used to develop a particular product, that is, it is one way to organize development by a team of developers. There are many different development models, each of which defines its own approach. It can't be said that anyone of them should be used for every project. The right approach depends entirely on the situation. I intend to consider three of them in greater detail.
WaterfallThe waterfall methodology is one of the oldest and involves a strictly sequential implementation: each stage must be completed before the next one begins. In other words, a transition to the next stage means that the work of the previous stage is 100% complete. The picture shows how it works: first, we analyze the problem (document tasks, discuss challenges), then we design (project's structure takes shape at this stage), and then we code and test. Returning to previous stages is not allowed. This approach is recommended for small projects where the requirements are known in advance and unlikely to change. Advantages:
- Complete and consistent documentation at each stage
- Ease of use
- Stable requirements
- Budgets and deadlines are predefined
- A large amount of documentation
- Not very flexible
- The client can't see a demo version of the product
- No option to move backward
ScrumScrum is a software development methodology that divides the entire process into iterations. At the end of each interation, the team is ready to provide a demo version of the product. The picture shows that the team proceeds through all stages of development in parallel, making it possible to have a finished part of the project at the end of each iteration. I will try to briefly explain the essence of the methodology using simple words, but there is a lot of terminology. I think the most important thing is to understand the essence. You'll remember the terminology with experience. All development is divided into sprints (often 2-3 weeks). There is a backlog (list of tasks) for the entire development period and for each separate sprint. Each task has its own story point (difficulty rating). Each participant in the process has a role:
- The scrum team consists of the professionals (developers, testers, designers) working on a project.
- The scrum master is the person who makes sure that the principles of scrum are respected.
- The product owner is the customer.
- Stand-up – This is a short meeting, held every day, in which all team members take part. Each participant answers 3 questions: What did I do? What will I do? And what blocking issues are there?
- Planning meeting – This meeting is held at the beginning of the sprint. The tasks that must be performed in the next sprint are identified at this meeting.
- Retrospective - This meeting is held at the end of the sprint and its purpose is to identify what was done well and what could be improved.
- The customer can see results during the development process
- Daily monitoring of the development process
- Ability to make adjustments during development
- Established communications with all team members
- A small amount of documentation
- Difficult to assess labor and other costs required for development
- Difficult to identify bottlenecks before development starts
- The need to involve everyone in the work of other team members.
KanbanKanban is a method based on visualizing the progress made in completing the team's tasks. The main idea is to reduce the number of tasks that are currently being performed (in the "In Progress" column). In scrum, the team is focused on successfully completing sprints. In Kanban, the task occupies the preeminent position. This is good for projects in the maintenance stage, where the basic functionality has already been implemented, and minimal improvements and bug fixing remain. In Kanban, tasks are assigned individually. A task goes through all the stages on the board, independent of other tasks, and once it is completed it can be shown to the customer. A Kanban board consists of columns, each of which represents a separate development process. Some columns (for example, "In Progress") limit the number of tasks they can hold. This helps to quickly and easily find problem areas in the distribution of tasks. The picture shows an example of just such a board. The number of columns and their names can vary. I will present the most common:
- To Do – The list of tasks that must be done
- In Progress – Tasks currently being worked on
- Code Review – Tasks that are done and have been submitted for review
- In Testing – Tasks ready for testing
- Done – Finished tasks
- Ease of use
- Visibility (helps locate bottlenecks, simplifies understanding)
- High team involvement in the process itself
- Highly flexible development
- An unstable task list
- Difficult to apply to long-term projects
- Lack of hard deadlines