Блог

Дмитрий Денисов
Заместитель директора по информационным технологиям

Что имеешь — храни...

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

«С этими айти час от часу не легче», — скажет на это среднестатистический бизнес-заказчик.

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

В чём разница между таск-трекером и базой знаний?

Если нам нужно покрасить стену, то сначала придётся купить краску, кисти, ведро и стремянку. Потом — притащить всё перечисленное к стене. Потом — установить стремянку с соблюдением техники безопасности. Взять краску с кистями, покрасить. Подождать, пока всё высохнет. Провести контроль качества. Если что-то плохо, докрасить или перекрасить. После успешного завершения — убрать стремянку и навести порядок на рабочем месте.

Всё перечисленное — подзадачи одной задачи. Усложним ситуацию, предположив, что в задаче участвует сразу несколько человек (один закупает, другой доставляет, третий красит, четвёртый проверяет качество), причём команда за короткий период времени красит много стен в разных местах города. Чтобы в них не запутаться, ничего не пропустить, сделать в правильном порядке (не убирать стремянку, пока не убедились, что всё покрашено хорошо), подойдёт например таск-трекер :)

База знаний же — это место, где написано не то, какие действия необходимо выполнить. А описан результат их выполнения, те самые требования. В нашем примере со стеной, в требованиях можно было бы написать, что стена должна быть небесно-голубого цвета, покрашена фактурной краской в два слоя, а сама краска должна быть огнестойкой.

Казалось бы, требования, благо если они написаны, можно прекрасно хранить и в задачах того же таск-трекера. Действительно, можно. Но неудобно.

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

Кроме этого, в таск-трекере, кроме задач на разработку какого-то нового функционала, заводится огромное количество задач на мелкое сопровождение и доработки. Они тоже будут постоянно путаться под ногами.

Еще одно: если функционал постоянно развивается, чтобы понять его актуальное состояние, придётся пройти по всем задачам, по которым в нём что-то изменялось. От самой первой, в которой первая реализация функционала, через все промежуточные («эту кнопку перекрасить», «этот попап подвинуть», «здесь убрать валидацию», «здесь изменить правила подсчёта» и т.д.), до самой последней. Вместо того, чтобы прочитать об актуальном состоянии функционала, не пытаясь разобраться во всех этапах развития, которые он прошёл.

К слову, в идеальном мире база знаний, она же система управления требованиями, прекрасно и почти бесшовно интегрируется с таск-трекером. Как, например, Atlassian Confluence с Atlassian Jira.

А как же Agile?

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

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

Поэтому всё сказанное применимо в первую очередь к достаточно большим продуктам с достаточно большой командой.