comparison of software development methods - Rup, XP, Scrum, Kanban Boar-board, Do what you want

Questions:

• What is kanban and what it eats
• What have agile

Kanban is not a methodology, it is an approach. It is based on simple ideas:

• Visualize workflow:
  • Break the work into pieces, write each of the items on the card and attach to the wall.
  • Sign the columns to see what stage each task is at.
• Limit WIP (approx. Work-in-progress translators - work in progress) - determine the possible number of unfinished points at each stage of the work process.
• Measure the lead time (average time to complete a single point, sometimes called “cycle time), optimize the process to minimize the time it takes to complete the task and make it as predictable as possible.

A tool is what is used as a means to complete a task or achieve a goal. Process is how you work. Scrum and Kanban are process tools that help you work more efficiently, telling you what to do to a certain degree. Java is also a tool, it simplifies computer programming.

As can be seen from the book, Kanban is more than flexible and adaptive. I will give the number of prescriptions:

1. Rup - more than 120
2. XP - 13
3. Scrum - 9
4. Kanban -3
5. Do what you want - 0

Scrum is more prescriptive than Kanban because it provides for things like iteration and cross-functional commands. Scrum prescribes 3 roles: Product Owner (responsible for product vision and priorities), Team (responsible for product implementation) and Scrum Master (eliminates obstacles in work and leads the Scrum process). Kanban does not prescribe any roles at all, the smaller the better! We need one Product Owner with the main task - setting priorities.

In Kanban, time-limited iterations are optional, you can release a release every Monday, or by implementing some new cool feature. On this topic in the book are excellent examples:

Team # 3 (event driven)

“We do the planning when we are finished. We make a release when there is minimal commercially valuable functionality (minimum marketable feature set - MMF), ready for release. We have a spontaneous discussion of quality when we encounter the same problem a second time. We also conduct more detailed retrospectives every fourth week. ”

When we talk about boards with stickers, we see the To Do column (from the Product Backlog), the In process column (Ongoing) and the Done task column. The difference between Kanban and Scrum is that in the Ongoing column there can be no more than n entries. In Scrum, work in progress is limited per unit time. In Kanban, work in progress is limited for each of the statuses.

Kanban allows you to edit the To Do column, while in Scrum we can put a new critical task only on the Product Backlog. That is, in kanban there is the principle “one is gone, one has come”. It is only necessary to monitor the equivalence of tasks for labor costs.

A kanban board may never be empty during a project, while a Scrum board must be cleaned after each sprint. A board in Kanban can be divided by function, and in Scrum, teams are cross-functional.

Tasks in Kanban do not necessarily break into a bunch of subtasks of the TC, in contrast to Scrum, there is no need to meet the completion of the sprint. In addition: Scrum prescribes prioritized Product Backlog; In Scrum, daily meetings are required; Burndown diagrams are required in Scrum. Both methodologies, in principle, allow working with two projects on one board.

Sample kanban board:

Sometimes it happens that after a long downtime, resources begin to appear, specialists, management supports and encourages change and innovation. At the same time, there are desires and ideas on how much you can improve, optimize and be a real support for the company's business. Of course, a lot can be done on the first breath, especially when the field is almost completely tilled. But later, the moment comes when IT infrastructure has grown enough and decisions for any changes and implementations are not made as quickly and easily as it was at the very beginning. The reason for that are the same implementations and innovations, now they need to be accompanied, supported, and despite the fact that the IT department has grown, there are not enough resources - we have a large, complex and functioning system. But what about the plans? How are those ideas? There are still a lot of them.

Now I want to tell you about the experiment with kanban-board, which gave an excellent result in the IT department is not an IT-company. Workflow with such a tool has become more controllable and manageable, the dependence of tasks relative to each specialist has become more transparent. Now you can always say with confidence that the department works at 100% and we are moving towards concrete results that are more likely to be achieved.

The initial state

Suppose we have several specialists of different directions and qualifications. We are faced with several large tasks or projects and our goal is to organize the process in such a way as to involve everyone with maximum efficiency, in accordance with its capabilities, as a specialist. It is also necessary to take into account that there is a constant routine, which with different frequency affects the employment of any employee.

The realities described above are our starting point. We proceed to the preparation ...

Design

At the first stage, each project should be divided into atomic components. Ideally, these tasks should be singled out and put in such a way that they can be performed without delving into the general essence of the issue. In addition, each task must be formed from start to finish with specific metrics and a designated end result.

Further, within each project, we place the dependence of each task on each other. To do this, we will enumerate each task and indicate from which other tasks it depends. The result will be a plan for the implementation of each project.

Example:

1. Создать виртуальную машину на ESXi #2, с параметрами Name: ServerABC, Guest: Ubuntu x64, RAM: 2 Gb, HDD: 20Gb Pre-allocated
2. (after: #1) Установить Ubuntu Server 12.04 x64 на виртуальный сервер ServerABC (ESXi #2); разбить HDD: root 2Gb, swap 2Gb, home все оставшееся; IP: 192.168.0.7; hostname: ABC.com; user: abc pass: abc
3. ...

The work on project development and its planning is easily performed by a profile specialist. After that, the project goes to the manager, and the specialists continue to carry out their current direct responsibilities.

Ticket Sticker

After preparation, we have in our hands several arrays of tasks, the fulfillment of which will lead us to the achievement of specific goals. We will use a kanban board as a visual control and management, and some kind of ticketing system (for example, trac) for tracking and detailed control.

Using these tools, we will prepare our projects for execution. In the ticket system for each project we will create a separate ticket in which we will place the prepared plan. Further, as work begins on each task, we will create sub-diploma to accompany its execution.

Since our plan has already been described in detail and placed on the ticket system (in the main project ticket), to visualize it on the board, it remains only to briefly rewrite each task on a sticker. Prepared stickers are placed on the board, grouping them by project.

Sticker example:

Action field

Preparation is finished and now we will consider a kanban-board, with which we will manage the development of events. In contrast to the "traditional" flow from left to right, in this stickers will go down the following stages, starting with the "pool":

• Poole is the largest place on the board where tasks are grouped by project. The area is deliberately not marked up on the plots, so that the projects occupy only the necessary space, since they themselves form an area of ​​a certain color. Moreover, the term “project” in the daily life of the IT department can often simply mean a big task that can be decomposed into subtasks.
• The queue is the nearest short-term plan for execution. In this section of the board are placed all the tasks scheduled for execution in the near future, and it is used mainly in the implementation of high-speed or priority projects. In practice, for most tasks, the section is skipped, and tasks from the pool go directly to the contractor.
• Execution - this stage is clearly divided into areas corresponding to a specific artist. Choosing a performer you need to take into account the fact that the solution of some tasks may take the same time, as with a highly qualified specialist, and with a beginner. But the goals of optimization of performance can be different, and just at this stage you can explicitly choose a strategy for achieving the goal. For example, we can pass less demanding qualifications and non-urgent tasks through novice specialists, giving them a chance for self-development. Naturally, urgent and important work should be directed to trained specialists. In general, there can be many strategies, but the most important thing is that we see in real time how the process is going on, and we can quickly adjust to the current working situation.
• Verification is the same as the previous stage is divided into performers, but is auxiliary and similar to the Quality Assurance process. Tasks are placed in it, for example, for receiving feedback from another specialist or for checking by a specialist who has the greatest competence. This stage can also be skipped if the project clearly provides for QA in a separate task or third-party verification is not required.
• Done - the final stage in which all completed stickers are collected in small booklets projects.

To clearly indicate the employment of specialists and the impossibility of their participation in work on the planned projects, you can use magnets of a certain color, such as red. It is also possible to designate a green magnet that a specialist is free and can participate in any project. Often, green magnets hang on specialists for whom at a certain point there is no suitable task, and we would very much like to take them as soon as such a task is found.

"Done"

PS Scrum and Kanban are not different approaches, Kanban is completely used for Scrum.