Привет, Хабр. Меня зовут Григорий, я работаю специалистом по тестированию программного обеспечения на банковском проекте от компании Clevertec. Недавно методика планирования на нашем проекте изменилась. И жизнь команды тоже:) Что получится, если объединить «Тетрис» и Kanban, расскажу в этой статье.
Как мы пришли к планированию «Тетрисом»
Раньше мы работали по классической методике планирования задач — Kanban, и в принципе это было удобно. Но в целом ИТ‑команда банка живет по «Тетрису». Пришло время внедрить его и на нашем проекте.
Зачем это сделано? В банке принято, что специалисты на пару спринтов меняются проектами и так знакомятся с новыми задачами и людьми. Во‑первых, чтобы поддерживать взаимозаменяемость. Во‑вторых, чтобы не было выгорания, застоев и регресса из‑за долгой работы на одном проекте. Нам нужно было унифицировать свою систему планирования с большинством, чтобы разработчик, тестировщик, аналитик, который попадает в нашу команду по обмену, не тратил время на изучение ее особенностей. У нас это получилось. Но немного по‑своему.
Что такое «Тетрис» или как он работает у нас на проекте
Классический «Тетрис» – это инструмент среднесрочного или долгосрочного планирования, который не подходит для работы по спринтам. Но нам они были необходимы.
Во-первых, команда привыкла работать по небольшим итерациям.
Во-вторых, у нас юзер-ориентированный продукт, который нужно оптимизировать. Поэтому мы проводим ретро, обсуждаем доработки и трудности, с которыми встречаются пользователи.
Мы смогли адаптировали «Тетрис» под реалии нашей команды и, как мне кажется, получилось неплохо.
Вот чем наш внутрикомандный «Тетрис» отличается от классического и внутрибанковского:
1) Первое и основное — это декомпозиция. Например, у нас есть задача, которая займёт много времени на разработку, аналитику и тестирование. Мы делим её на равные части, чтобы каждый спринт выполнять по кусочкам и не останавливать работу команды или подключать дополнительный человеческий ресурс для ускорения.
Разделение помогает правильно оценить работу. Заказчик знает срок, когда он получит готовый продукт, с минимальной погрешностью.
2) Построение задач. Допустим, у нас есть задача сделать форму регистрации. Если бы мы работали по классической модели, то это была бы Идея, к которой создают задачи на аналитику, разработку и другое. В «Тетрисе» к основной задаче создаются Sub‑tasks на различные этапы. В этой схеме не нужно по окончанию аналитики или разработки пересылать задачу на тестировщика, чтобы он проверил работу и при необходимости завёл Sub‑tasks на доработку или исправление багов. Все Sub‑tasks хранятся в одной задаче.
Так выглядит классический Kanban. Задачи расположены по статусам на доске, с ними работает команда.
«Тетрис» выглядит как блоки с основными задачами во главе. В выпадающем списке мы видим все задачи и статусы по ним, а также можем проследить жизненный цикл задачи, текущий статус и многое другое.
3) Оценка работы команды. В классическом «Тетрисе» оценка идёт в «Майках», а в Kanban — в Story Points. Но «Тетрис» — гибкая методология, поэтому на нашем проекте оставили оценку в Story Points.
Мы оцениваем не задачи, а Sub‑tasks к ним: на разработку, аналитику, тестирование, исправление багов и другое. По итогу спринта Story Points суммируются — и мы видим, сколько ушло на работу над задачей.
На нашем проекте оценка работы происходит по задачам, которые ушли в поставку на продуктовый стенд. Story Points помогают подсчитать эффективность работы команды за прошедший спринт.
Классический Kanban | Классический Тетрис | Тетрис на нашем проекте | |
Оценка задач | Story points | «Майки» | Story points |
Работа с задачами | В основном Tasks | Есть основная задача и к ней создаются Sub-tasks | Есть основная задача и к ней создаются 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, вывод о работоспособности команды/отдельного человека может быть сделан необъективно.
Но, как говорит аналитик Ольга, «со временем приходит озарение, сколько стори‑поинтов может вместиться в спринт. Ведь стори‑поинты — это не совсем про дни».
Мне кажется, что наш пример планирования — это живая иллюстрация того, как работают гибкие методологии разработки. Все неудобное можно сделать удобным, главное — подобрать инструмент)
Расскажите, с какими трудностями планирования сталкиваетесь каждый день. Поддержим друг друга в комментах.
