Некоторое время назад передо мной встал выбор инструмента для управления небольшими проектами по SCRUM-методологии. У меня был довольно большой опыт использования различных инструментов включая Jira, Asana, Trello и проч., но ни один из них не подходил в полной мере для моего проекта: какой-то был чересчур монструозен, а какому-то недоставало важных для меня фич. В итоге пришлось изобретать инструмент самому, на базе Google Sheets.
Требования, предъявляемые мною к инструменту, были таковы:
Требования отчасти были продиктованы тем, что в данном проекте я совмещал две роли: продакт- и проджект-менеджера, поэтому хотелось чтобы затраты времени на управление командой были минимальные, для того чтобы оставалось время на продакт-менеджмент.
В итоге удалось создать действительно удобный и удовлетворяющий моим требованиям инструмент, который выдержал проверку временем, пережил несколько модификаций и теперь готов к тому, чтобы рассказать о нем общественности. Полагаю, что кому-то он вполне может оказаться полезным.
Общий вид инструмента представлен на скриншоте:
Цифрами обозначены следующие основные области:
Как говорилось выше, одним из требований к инструменту был минимализм, однако, шаблон сделан с таким расчетом, чтобы можно было добавлять дополнительные столбцы (например, столбец со ссылкой на документ с описанием юзер-стори) и при этом ничего не ломалось.
Ниже описаны основные шаги использования инструмента, все скриншоты кликабельны.
Открываем девственно чистый шаблон и начинаем заполнять его задачами и юзер-сторями. В итоге лист примет примерно такой вид:
Приоритезация бэклога осуществляется путем упорядочивания задач выше или ниже в списке. И тут надо отметить важный момент: Google Sheets, в отличие от MS Excel поддерживает перетаскивание строк таблицы обычным драг-н-дропом: просто хватаешься мышкой за номер строки и перемещаешь ее куда нужно. При этом она не затирает другие строки, а встает между ними. Без этой фичи ничего бы не получилось.
Перед началом планинга задаем параметры спринта: указываем количество дней (поле sprint days), а также указываем рабочие дни спринта в заголовке таблицы. Изначально была идея сделать так, чтобы даты проставлялись автоматически, однако, в итоге пришел к выводу, что проще заполнять это вручную и не париться с обработкой государственных праздников, корпоративных мероприятий и т.д.
На планинге мы оцениваем и декомпозируем задачи, назначаем их на исполнителей и перетаскиваем их в бэклог спринта, где контролируем загрузку каждого исполнителя.
Тут необходимо сделать пару пояснений:
В конце рабочего дня каждый разработчик проставляет количество оставшихся часов по каждой из своих задач. Когда задача выполнена — ставиться ноль. На основе этих данных строиться burndown chart. На мой взгляд, это оптимальный вид отчетности: не требует много времени и позволяет значительно более точно оценивать прогресс выполнения спринта по сравнению с тем, когда burndown строится по закрытым задачам.
Также хотел бы обратить внимание на удобство контроля актуальности данных: достаточно одного взгляда, чтобы понять, по каким задачам разработчики проставили часы, а по каким забыли.
Когда спринт завершился, мы приступаем к планированию нового спринта. Для этого:
После чего повторяем все те действия, которые были описаны в разделе «Планинг».
Подход с копированием листов позволяет минимизировать ручной труд и сохранить историю всех предыдущих спринтов: иногда бывает полезно посмотреть, что у нас происходило пару спринтов назад.
А как же тестирование? — спросите вы. Тестирование было организовано следующим образом: мы просто создавали еще один чистый лист, куда заносили все найденные баги. А дальше мы их либо фиксили в рамках текущего спринта, либо вносили их в бэклог проекта и планировали их выполнение наряду с обычными задачами в следующих спринтах.
Скачать шаблон можно тут. Он полностью готов к использованию: просто сохраняете копию и начинаете пользоваться.
На всякий случай: разумеется, я не призываю все бросить и переходить на управление проектами при помощи Google Sheets. Однако жизнь — штука разнообразная, и вполне возможно что кому-то предстоит встреча с проектом, для которого данный инструмент окажется оптимальным выбором.
Требования, предъявляемые мною к инструменту, были таковы:
- Низкие временные затраты на использование: ввод новой задачи, приоритезация бэклога или изменение статуса задачи должно занимать минимальное количество времени.
- Низкий порог вхождения для всех участников процесса.
- Наглядность и минимализм: хотелось на одном экране видеть и бэклог, и задачи спринта, и текущий прогресс. И при этом не видеть ничего лишнего.
- Построение burndown chart, причем по часам (remaining work), а не по закрытым задачам.
- Возможность четкого и удобного контроля: все ли часы проставлены, все ли статусы проапдейчены.
Требования отчасти были продиктованы тем, что в данном проекте я совмещал две роли: продакт- и проджект-менеджера, поэтому хотелось чтобы затраты времени на управление командой были минимальные, для того чтобы оставалось время на продакт-менеджмент.
В итоге удалось создать действительно удобный и удовлетворяющий моим требованиям инструмент, который выдержал проверку временем, пережил несколько модификаций и теперь готов к тому, чтобы рассказать о нем общественности. Полагаю, что кому-то он вполне может оказаться полезным.
Общий вид
Общий вид инструмента представлен на скриншоте:
Цифрами обозначены следующие основные области:
- Бэклог продукта
- Бэклог спринта
- Оставшиеся часы (remaining work) по задачам
- Диаграмма сгорания часов (burndown chart)
Как говорилось выше, одним из требований к инструменту был минимализм, однако, шаблон сделан с таким расчетом, чтобы можно было добавлять дополнительные столбцы (например, столбец со ссылкой на документ с описанием юзер-стори) и при этом ничего не ломалось.
Как этим пользоваться
Ниже описаны основные шаги использования инструмента, все скриншоты кликабельны.
Старт проекта. Наполняем бэклог
Открываем девственно чистый шаблон и начинаем заполнять его задачами и юзер-сторями. В итоге лист примет примерно такой вид:
Приоритезация бэклога осуществляется путем упорядочивания задач выше или ниже в списке. И тут надо отметить важный момент: Google Sheets, в отличие от MS Excel поддерживает перетаскивание строк таблицы обычным драг-н-дропом: просто хватаешься мышкой за номер строки и перемещаешь ее куда нужно. При этом она не затирает другие строки, а встает между ними. Без этой фичи ничего бы не получилось.
Планинг
Перед началом планинга задаем параметры спринта: указываем количество дней (поле sprint days), а также указываем рабочие дни спринта в заголовке таблицы. Изначально была идея сделать так, чтобы даты проставлялись автоматически, однако, в итоге пришел к выводу, что проще заполнять это вручную и не париться с обработкой государственных праздников, корпоративных мероприятий и т.д.
На планинге мы оцениваем и декомпозируем задачи, назначаем их на исполнителей и перетаскиваем их в бэклог спринта, где контролируем загрузку каждого исполнителя.
Тут необходимо сделать пару пояснений:
- Декомпозиция задач осуществляется через соглашение о наименовании, когда задача и подзадача разделяются знаком двоеточие: "Задача: подзадача".
Был реализован вариант шаблона, где под иерархию был выделен специальный столбец, куда из выпадающего списка (формировался автоматически из бэклога) можно было выбрать корневую задачу, но практика показала, что такое усложнение излишне.
- Разумеется, для контроля загрузки исполнителей можно было бы сделать отдельный красивый график, но не хотелось загромождать интерфейс графиком, который нужен лишь один раз за спринт. Поэтому я остановился на варианте, показанном на скриншоте — он оказался вполне удобным. Если задач и разработчиков много, их можно выбрать при помощи фильтра чтобы было удобнее выделять мышкой.
Выполнение спринта и ежедневная отчетность
В конце рабочего дня каждый разработчик проставляет количество оставшихся часов по каждой из своих задач. Когда задача выполнена — ставиться ноль. На основе этих данных строиться burndown chart. На мой взгляд, это оптимальный вид отчетности: не требует много времени и позволяет значительно более точно оценивать прогресс выполнения спринта по сравнению с тем, когда burndown строится по закрытым задачам.
Также хотел бы обратить внимание на удобство контроля актуальности данных: достаточно одного взгляда, чтобы понять, по каким задачам разработчики проставили часы, а по каким забыли.
Планирование нового спринта
Когда спринт завершился, мы приступаем к планированию нового спринта. Для этого:
- Создаем копию листа с только что завершившимся спринтом
- Удаляем из него все выполненные задачи
- У незавершенных задач переносим количество оставшихся часов из последнего дня спринта в столбец day 0.
После чего повторяем все те действия, которые были описаны в разделе «Планинг».
Подход с копированием листов позволяет минимизировать ручной труд и сохранить историю всех предыдущих спринтов: иногда бывает полезно посмотреть, что у нас происходило пару спринтов назад.
О тестировании
А как же тестирование? — спросите вы. Тестирование было организовано следующим образом: мы просто создавали еще один чистый лист, куда заносили все найденные баги. А дальше мы их либо фиксили в рамках текущего спринта, либо вносили их в бэклог проекта и планировали их выполнение наряду с обычными задачами в следующих спринтах.
Вместо заключения
Скачать шаблон можно тут. Он полностью готов к использованию: просто сохраняете копию и начинаете пользоваться.
На всякий случай: разумеется, я не призываю все бросить и переходить на управление проектами при помощи Google Sheets. Однако жизнь — штука разнообразная, и вполне возможно что кому-то предстоит встреча с проектом, для которого данный инструмент окажется оптимальным выбором.
