Требования, предъявляемые мною к инструменту, были таковы:
- Низкие временные затраты на использование: ввод новой задачи, приоритезация бэклога или изменение статуса задачи должно занимать минимальное количество времени.
- Низкий порог вхождения для всех участников процесса.
- Наглядность и минимализм: хотелось на одном экране видеть и бэклог, и задачи спринта, и текущий прогресс. И при этом не видеть ничего лишнего.
- Построение burndown chart, причем по часам (remaining work), а не по закрытым задачам.
- Возможность четкого и удобного контроля: все ли часы проставлены, все ли статусы проапдейчены.
Требования отчасти были продиктованы тем, что в данном проекте я совмещал две роли: продакт- и проджект-менеджера, поэтому хотелось чтобы затраты времени на управление командой были минимальные, для того чтобы оставалось время на продакт-менеджмент.
В итоге удалось создать действительно удобный и удовлетворяющий моим требованиям инструмент, который выдержал проверку временем, пережил несколько модификаций и теперь готов к тому, чтобы рассказать о нем общественности. Полагаю, что кому-то он вполне может оказаться полезным.
Общий вид
Общий вид инструмента представлен на скриншоте:
Цифрами обозначены следующие основные области:
- Бэклог продукта
- Бэклог спринта
- Оставшиеся часы (remaining work) по задачам
- Диаграмма сгорания часов (burndown chart)
Как говорилось выше, одним из требований к инструменту был минимализм, однако, шаблон сделан с таким расчетом, чтобы можно было добавлять дополнительные столбцы (например, столбец со ссылкой на документ с описанием юзер-стори) и при этом ничего не ломалось.
Как этим пользоваться
Ниже описаны основные шаги использования инструмента, все скриншоты кликабельны.
Старт проекта. Наполняем бэклог
Открываем девственно чистый шаблон и начинаем заполнять его задачами и юзер-сторями. В итоге лист примет примерно такой вид:
Приоритезация бэклога осуществляется путем упорядочивания задач выше или ниже в списке. И тут надо отметить важный момент: Google Sheets, в отличие от MS Excel поддерживает перетаскивание строк таблицы обычным драг-н-дропом: просто хватаешься мышкой за номер строки и перемещаешь ее куда нужно. При этом она не затирает другие строки, а встает между ними. Без этой фичи ничего бы не получилось.
Планинг
Перед началом планинга задаем параметры спринта: указываем количество дней (поле sprint days), а также указываем рабочие дни спринта в заголовке таблицы. Изначально была идея сделать так, чтобы даты проставлялись автоматически, однако, в итоге пришел к выводу, что проще заполнять это вручную и не париться с обработкой государственных праздников, корпоративных мероприятий и т.д.
На планинге мы оцениваем и декомпозируем задачи, назначаем их на исполнителей и перетаскиваем их в бэклог спринта, где контролируем загрузку каждого исполнителя.
Тут необходимо сделать пару пояснений:
- Декомпозиция задач осуществляется через соглашение о наименовании, когда задача и подзадача разделяются знаком двоеточие: "Задача: подзадача".
Был реализован вариант шаблона, где под иерархию был выделен специальный столбец, куда из выпадающего списка (формировался автоматически из бэклога) можно было выбрать корневую задачу, но практика показала, что такое усложнение излишне.
- Разумеется, для контроля загрузки исполнителей можно было бы сделать отдельный красивый график, но не хотелось загромождать интерфейс графиком, который нужен лишь один раз за спринт. Поэтому я остановился на варианте, показанном на скриншоте — он оказался вполне удобным. Если задач и разработчиков много, их можно выбрать при помощи фильтра чтобы было удобнее выделять мышкой.
Выполнение спринта и ежедневная отчетность
В конце рабочего дня каждый разработчик проставляет количество оставшихся часов по каждой из своих задач. Когда задача выполнена — ставиться ноль. На основе этих данных строиться burndown chart. На мой взгляд, это оптимальный вид отчетности: не требует много времени и позволяет значительно более точно оценивать прогресс выполнения спринта по сравнению с тем, когда burndown строится по закрытым задачам.
Также хотел бы обратить внимание на удобство контроля актуальности данных: достаточно одного взгляда, чтобы понять, по каким задачам разработчики проставили часы, а по каким забыли.
Планирование нового спринта
Когда спринт завершился, мы приступаем к планированию нового спринта. Для этого:
- Создаем копию листа с только что завершившимся спринтом
- Удаляем из него все выполненные задачи
- У незавершенных задач переносим количество оставшихся часов из последнего дня спринта в столбец day 0.
После чего повторяем все те действия, которые были описаны в разделе «Планинг».
Подход с копированием листов позволяет минимизировать ручной труд и сохранить историю всех предыдущих спринтов: иногда бывает полезно посмотреть, что у нас происходило пару спринтов назад.
О тестировании
А как же тестирование? — спросите вы. Тестирование было организовано следующим образом: мы просто создавали еще один чистый лист, куда заносили все найденные баги. А дальше мы их либо фиксили в рамках текущего спринта, либо вносили их в бэклог проекта и планировали их выполнение наряду с обычными задачами в следующих спринтах.
Вместо заключения
Скачать шаблон можно тут. Он полностью готов к использованию: просто сохраняете копию и начинаете пользоваться.
На всякий случай: разумеется, я не призываю все бросить и переходить на управление проектами при помощи Google Sheets. Однако жизнь — штука разнообразная, и вполне возможно что кому-то предстоит встреча с проектом, для которого данный инструмент окажется оптимальным выбором.
Комментарии (20)
igorek_bg
16.08.2019 09:08+1Google Sheets, в отличие от MS Excel поддерживает перетаскивание строк таблицы обычным драг-н-дропом: просто хватаешься мышкой за номер строки и перемещаешь ее куда нужно.
В Excel это есть. Нужно зажать клавишу Shift при перетаскивании.
Aquahawk
16.08.2019 10:41Всё хорошо. Были у нас для геймдизайна таблички. Около 100 листов и около 150-200 строк и формулы с фильтрациями туда сюда меж листами. В какой-то момент это всё легло, перестало нормально обновляться, что-то меняешь, а хрень которая должна обновиться через 10 формул по цепочке не обновляется. Пришли к закономерному выводу что для хоть сколько-то больших таблиц нужна нормальная бд и нормальный код который это процессит.
Merrynose Автор
16.08.2019 10:54Как раз в этом проекте у меня тоже была геймдизайнерская таблица для расчета баланса. Сначала делал ее в гугл-таблицах, но очень быстро она стала умирать по производительности, ровно так, как вы описываете. В результате перенес в Эксель — тот тянул нормально, но у меня, конечно, меньше 100 листов было.
В общем, это все к выбору оптимального инструмента под конкретную задачу.Aquahawk
16.08.2019 11:02В моём проекте сейчас в таксктрекере уже 23 тыс задач. И я хотел бы больше, их мелкие неудобно создавать и отслеживать. Я к тому что на любом крупном проекте и таски и баланс и всё что угодно вылезет из гугл доков.
Для средних туду листов я сейчас пользуюсь плагином To Do Tasks
Картинка с todo листа
Merrynose Автор
16.08.2019 13:10Безусловно, большой проект требует серьезных инструментов.
А почему вы не пользуетесь классической связкой Jira + Confluence? В Jira — иерархическое дерево задач, а документация в — в Confluence. Они удобно друг с другом интегрируются, в Confluence видны статусы задач из Jira и тд.Aquahawk
16.08.2019 14:30Они чудовищно интегрируются, я пробовал. jira.atlassian.com/browse/JRASERVER-4446 и что меня печалит, там десятки таких задач в которых тысячи подписавшихся и письмо от менеджмента о том почему они не хотят это делать. И тянется это уже второй десяток лет
Merrynose Автор
16.08.2019 15:33А чем вас интеграция не устраивает? В Jire ставите линку на страницу в Confluence, а в статье (при желании) — линку на задачу в Jira. При этом линки схлопываются до айдишника задачи, сразу виден ее статус и тд. Сам Confluence очень удобен для ведения документации, этакая иерархическая вики.
Насчет «Sub-issues should be able to contain their own sub-issues» — я посмотрел внимательно на ваш скриншот, действительно, если все нюасны проекта раскидывать по иерархии, то трех уровней которые предоставляет Джира, вам будет явно недостаточно. Но можно часть сущеностей реализовать через теги или компоненты. Возможно, это будет даже удобнее в ряде случаев.
Nidere
16.08.2019 16:45Если человек пытается напихать сабтаски в сабтаски, он делает что-то неправильно.
Скорее всего это попытка воткнуть мета-информацию (типы, категории, etc) в иерархию задач, что контрпродуктивно.
Не стоит забывать, что Атлассиан делают продукт для Agile и, в частности, Scrum разработки, а она не подразумевает подобной вложенности.
Ktulhy
17.08.2019 11:23А сколько часов вы потратили на данный инструмент и почему бы не поставить себе YouTrack, который умеет это делать из коробки?
Merrynose Автор
18.08.2019 11:22Потратил не очень много, думаю, часов восемь на первый запуск, а дальше какие-то минимальные правки уже в процессе эксплуатации.
Про YouTrack я не знал, если честно. Но, дело не только в том, умеет ли из коробки или нет. Jira тоже все это умеет из коробки, но она настолько монстроузная, что ее использование для небольших проектов совершенно не оправдано.
da411d
17.08.2019 16:29Круто!
Как раз искал инструмент под себя, пока всё "не то". С гугл таблицами дружу уже давно. Обязательно попробую ваш инструмент. Спасибо)
maxim_ge
Интересный вариант. Несколько неожиданно, что нужно вводить остатки по часам, а не потраченные часы. С чем связан такой способ учета прогресса?
vyatsek
Так просто удобнее смотреть.
Раньше делал подобное только просто в экселе, т.к. там есть макросы и задачи с нулевым сотатком можно «серить». Так же в экселе можно группировать и делать агрегацию по группе. Непонятно при чем тут скрам, но система учета вполне себе практична.
QDeathNick
В googlesheet тоже есть «макросы» и можно как угодно «серить»
Merrynose Автор
Именно так. Если посмореть на скриншоты, то можно увидеть что цифра «0» отображается серым цветом.
da411d
Это разве не "условное форматирование"?
Merrynose Автор
Да, вы совершенно правы. Это условное форматирование.
Merrynose Автор
Если совсем кратко, то потому, что меня в большей степени волнует, когда задача будет выполнена, а не сколько на нее времени было потрачено.
Если более развернуто, то тут есть интересный психологический момент, благодаря которому такой способ учёта более эффективен, чем учет потраченных часов.
Давайте представим, что мы организовали учёт времени потраченных часов. У нас есть задача, оцененная в 40 часов и разработчик каждый день на нее списывает по 8 часов. И вот на утро пятого дня вы видите, что на задачу было потрачено 32 часа. Означает ли это, что к вечеру он закроет эту задачу? Разумеется, нет. Он может списать на нее еще 8 часов, и еще 8 часов, а задача так и не будет выполнена (допустим, возникли какие-либо сложности).
Более того, если мы в середине этой задчи подойдем и спросим разработчика о ходе работ, то скорее всего мы услышим, что "все идет по плану, все под контролем", а проблема с задержкой сроков вылезет лишь в день сдачи задачи.
Совсем другое дело, когда мы просим ввести количество оставшихся часов. Во1, разработчику приходится задуматься о своем прогрессе и оценить оставшуюся трудоемкость, во2, ввод оставшихся часов это что-то вроде обещания, данного самому себе, что также стимулирует закончить работу в срок.
Но, кстати говоря, этот подход не является чем-то революционным: его поддерживают и Jira, и DevOs и даже MS Project Server. Все это можно настроить в свойствах проекта.
da411d
Тоже пользуюсь этим приемом. В спортзале мне проще обратный отсчет)