Привет, Хабр. Меня зовут Григорий, я работаю специалистом по тестированию программного обеспечения на банковском проекте от компании Clevertec. Недавно методика планирования на нашем проекте изменилась. И жизнь команды тоже:) Что получится, если объединить «Тетрис» и Kanban, расскажу в этой статье.

Как мы пришли к планированию «Тетрисом»

Раньше мы работали по классической методике планирования задач — Kanban, и в принципе это было удобно. Но в целом ИТ‑команда банка живет по «Тетрису». Пришло время внедрить его и на нашем проекте.

Зачем это сделано? В банке принято, что специалисты на пару спринтов меняются проектами и так знакомятся с новыми задачами и людьми. Во‑первых, чтобы поддерживать взаимозаменяемость. Во‑вторых, чтобы не было выгорания, застоев и регресса из‑за долгой работы на одном проекте. Нам нужно было унифицировать свою систему планирования с большинством, чтобы разработчик, тестировщик, аналитик, который попадает в нашу команду по обмену, не тратил время на изучение ее особенностей. У нас это получилось. Но немного по‑своему.

Что такое «Тетрис» или как он работает у нас на проекте

Классический «Тетрис» – это инструмент среднесрочного или долгосрочного планирования, который не подходит для работы по спринтам. Но нам они были необходимы. 

Во-первых, команда привыкла работать по небольшим итерациям. 

Во-вторых, у нас юзер-ориентированный продукт, который нужно оптимизировать. Поэтому мы проводим ретро, обсуждаем доработки и трудности, с которыми встречаются пользователи. 

Мы смогли адаптировали «Тетрис» под реалии нашей команды и, как мне кажется, получилось неплохо.

Вот чем наш внутрикомандный «Тетрис» отличается от классического и внутрибанковского:

1) Первое и основное — это декомпозиция. Например, у нас есть задача, которая займёт много времени на разработку, аналитику и тестирование. Мы делим её на равные части, чтобы каждый спринт выполнять по кусочкам и не останавливать работу команды или подключать дополнительный человеческий ресурс для ускорения.

Разделение помогает правильно оценить работу. Заказчик знает срок, когда он получит готовый продукт, с минимальной погрешностью.

2) Построение задач. Допустим, у нас есть задача сделать форму регистрации. Если бы мы работали по классической модели, то это была бы Идея, к которой создают задачи на аналитику, разработку и другое. В «Тетрисе» к основной задаче создаются Sub‑tasks на различные этапы. В этой схеме не нужно по окончанию аналитики или разработки пересылать задачу на тестировщика, чтобы он проверил работу и при необходимости завёл Sub‑tasks на доработку или исправление багов. Все Sub‑tasks хранятся в одной задаче.

Так выглядит классический Kanban. Задачи расположены по статусам на доске, с ними работает команда.

«Тетрис» выглядит как блоки с основными задачами во главе. В выпадающем списке мы видим все задачи и статусы по ним, а также можем проследить жизненный цикл задачи, текущий статус и многое другое.

3) Оценка работы команды. В классическом «Тетрисе» оценка идёт в «Майках», а в Kanban — в Story Points. Но «Тетрис» — гибкая методология, поэтому на нашем проекте оставили оценку в Story Points.

Мы оцениваем не задачи, а Sub‑tasks к ним: на разработку, аналитику, тестирование, исправление багов и другое. По итогу спринта Story Points суммируются — и мы видим, сколько ушло на работу над задачей.

На нашем проекте оценка работы происходит по задачам, которые ушли в поставку на продуктовый стенд. Story Points помогают подсчитать эффективность работы команды за прошедший спринт.

Как мы оцениваем задачи

После поступления задачи от заказчика в команде происходит груминг с первичным разбором, декомпозицией и оценкой.

Оцениваем задачи в Story points по такому принципу:

1 — спайк (просто что‑то узнать без правок в коде), правка в конфигах
2 — незначительные исправления в коде
3 — небольшая задача на 2–3 дня. Легка в понимании, нет рисков при реализации
5 — задачка средняя, на полспринта. Есть возможные риски, которые придется решать в рамках задачи (необходимо декомпозировать на более мелкие подзадачи в 1–3 SP).
8 — большая задача, которая может занять весь спринт, но за спринт ее можно успеть сделать (необходимо декомпозировать на более мелкие подзадачи в 1–3 SP).
13 — очень большая и не совсем понятная задача. Необходимо декомпозировать на более мелкие, так как в спринт скорее всего не уместится (необходимо декомпозировать на более мелкие подзадачи в 1–3 SP).

А теперь оценим впечатления от работы по усовершенствованному «Тетрису»

Чтобы дать объективную картину, я поговорил с другими ребятами из своей команды: Алексей — фронтенд‑разработчик, Алексей — бэкенд‑разработчик, и Ольга — системный аналитик. Вот так мы видим наше планирование.

Положительные стороны

• Как тестировщику мне очень удобно наблюдать за статусами всех задач на доске. Я почти не открываю задачи, чтобы читать комментарии разработчиков или нюансы. В Kanban я бы смотрел связанные задачи и не видел, какое подразделение ей занимается.

• Очень удобная оценка: оцениваешь Sub‑task и после выполнения подзадачи её оценка идёт в оценку основной.

Алексей, фронтенд‑разработчик

• Разделение задачи на сабтаски помогает адекватнее её декомпозировать и уже потом дать приемлемую оценку каждому кусочку. И в целом, благодаря более долгосрочному планированию, ты понимаешь, чем будешь заниматься не только в ближайший спринт.

Алексей, бэкенд-разработчик

• Есть конкретный план, который должен быть выполнен в течение спринта, и никакими дополнительными задачами, которые встают поперёк текущих тасок, тебя не отвлекают. Например, до Тетриса, если ты ещё не доделал таску, и вдруг приходила более срочная, то нужно было тратить время на «переключение контекста», что замедляло разработку.

• Теперь не нужно перекидываться одной и той же таской между разработчиком и тестировщиком. Тетрис говорит нам, что для каждого нового найденного бага (либо доработки) со стороны аналитики должна создаваться новая сабтаска, которая тестируется отдельно от основной. Это избавляет нас от путаницы, а так же проще отвечать на вопросы «Чем ты сейчас занят?».

Ольга, системный аналитик

• Прозрачно и ясно кто чем занимается в рамках задачи, на каком этапе происходит блок, и когда можно отдать в разработку следующее ТЗ.

Поле для улучшений

То, что ушло в продакшен = оценка команды за спринт 

Например, мы сделали функциональность, но из-за количества багов не успели исправить её за спринт и ничего не выпустили на прод. Поэтому оценка работы команды в этот спринт равна нулю. А в следующем спринте оценка превысит ожидаемый результат из-за выполненных целей нового спринта и закрытия старых.

Ольга, системный аналитик

Не всегда доработки, сделанные за 2 недели, могут быть выкачены в прод без дальнейшего развития функционала. И вот в рамках спринта декомпозиция, задача выполнена, а на проде ничего нет. Но мы не можем взять задачу (даже горящую) и выпустить ее в спринт, когда список целей уже заполнен.

Алексей, бэкенд-разработчик

Из трудностей — оценка задач в так называемых «story points». У разных разработчиков, в зависимости от опыта и скиллов, подходов, может быть разная оценка абстрактного понятия sp. С одной стороны, это позволяет нам увидеть примерные сроки выполнения тасок, но с другой стороны, когда нужно проанализировать результат спринта по sp, вывод о работоспособности команды/отдельного человека может быть сделан необъективно.

Но, как говорит аналитик Ольга, «со временем приходит озарение, сколько стори‑поинтов может вместиться в спринт. Ведь стори‑поинты — это не совсем про дни».

Мне кажется, что наш пример планирования — это живая иллюстрация того, как работают гибкие методологии разработки. Все неудобное можно сделать удобным, главное — подобрать инструмент)

Расскажите, с какими трудностями планирования сталкиваетесь каждый день. Поддержим друг друга в комментах.