Использование системы управления задачами TrackStudio в российском подразделении компании Top Dog Developments
Сергей ИГНАТОВ
Компания Top Dog Developments
Наша компания Top Dog Developments занимается разработкой программного обеспечения для туристических агентств и операторов. С момента открытия российского подразделения (2005 г.) у нас осуществляется разработка двух крупных проектов, над каждым из которых работает отдельная команда (7–8 человек). Для поддержания процесса разработки в качестве системы управления задачами и учёта времени первоначально использовалось решение Bugzilla. Долгое время оно вполне нас удовлетворяло, но по мере роста проектов, усложнения процессов разработки внутри компании и процессов связи с внешними организациями стали повышаться и наши требования, которым Bugzilla уже не соответствовала.
Так, например, Bugzilla обеспечивала только плоскую структуру задач. Иными словами — отсутствует возможность работы с подзадачами, что затрудняло планирование задач и отслеживание затраченного времени. Для эмулирования подзадач приходилось использовать отдельные задачи, помеченные специальным ключевым словом, и зависимости между ними. Затраченное время в рамках иерархии подсчитывалось SQL-скриптами.
Периодически возникало желание добавить новые типы полей (custom fields) для описания дополнительных характеристик.
В первое время Bugzilla применялась только внутри нашего филиала, затем доступ к ней открыли для других подразделений компании. Предполагается, что в будущем с системой управления задачами смогут работать некоторые из наших клиентов. Естественно, что часть содержащихся в ней данных внешним пользователям не нужна, а часть вообще является сугубо внутренней информацией, которая не должна иметь выход наружу. Таким образом, возникает необходимость ограничения прав доступа как к проектам (задачам), так и к отдельным полям задач для разных групп пользователей.
С целью упростить процесс взаимодействия с внешними пользователями была бы также полезной возможность создавать задачи и вести процесс переписки с помощью электронной почты.
Для выборки нужных срезов информации приходилось писать SQL-запросы к базе данных Bugzilla. А хотелось бы иметь возможность работать с системой через некое специализированное API — как для выборки данных, так и для манипуляции ими.
После выхода третьей версии Bugzilla мы посмотрели список её новых возможностей. Некоторые вещи понравились (XML-RPC Interface, File/Modify Bugs By Email), однако отсутствие иерархичности и правил доступа к данным, слабая реализация пользовательских полей (custom fields) побудили обратить внимание на другие системы, с тем чтобы выбрать наиболее подходящую нам.
С точки зрения вышеописанных требований мы рассматривали Trac, JIRA, TrackStudio и FogBugz. По совокупности характеристик наилучшей системой для нас оказалась TrackStudio. Помимо соответствия нашим требованиям понравились также: формирование собственных workflow, возможность создания триггеров, скрипты для пользовательских полей, система уведомлений об изменениях, настройка языка интерфейса индивидуально для пользователей. Правда, фильтрация задач, несмотря на свою гибкость, не вполне нас удовлетворила — в той же Bugzilla искать задачи было проще, но это был фактор второстепенной важности.
В конечном счёте остановились на TrackStudio (см. «БиК» № 9 за 2008 г.). К настоящему моменту используем систему уже полгода и в целом довольны сделанным выбором.
Несколько слов о применении средств планирования работы в нашей организации. Два года назад решили перевести процесс планирования на «научную» основу и внедрить в работу специализированную систему — чтобы строить диаграммы Ганта, учитывать зависимости, разбрасывать задачи по людям, чтобы можно было сдвигать задачи во времени и т. д. Рассмотрели несколько подобных систем, в итоге остановились на MS Project. Создали в ней план на несколько месяцев и работали с ним (с развитием, правками) примерно 8 месяцев. Процесс поддержания плана в актуальном состоянии оказался очень трудоёмким для нас, так как постоянно появлялись новые задачи, изменялись приоритеты старых. Кроме того, первоначально было много ошибок во временн€ых оценках (в основном из-за недостатка информации). Частое изменение плана отнимало много времени. В итоге решили, что для нас такой способ планирования является не слишком продуктивным, и отказались от него. В настоящее время обычно планы у нас краткосрочные (2–3 месяца), что обусловлено частой нацеленностью на настройку под конкретных клиентов, и для них вполне достаточно функциональности TrackStudio.
При переходе с Bugzilla мы не стали делать автоматический импорт списка задач, так как решили изменить рабочие процессы — настроить workflow, пользовательские поля, иерархию проектов (модулей) и пр. В этом случае простого переноса было бы недостаточно, поэтому постепенно просто вручную переносили задачи в TrackStudio при планировании на ближайшее будущее.
Систему установили на Suse 10.2, в виде war-файла под JBoss 4.2. Выбор JBoss обусловлен тем, что мы имеем опыт работы с ним, и расширения для TrackStudio, если они понадобятся, будем разрабатывать для работы именно под JBoss. В качестве СУБД используем PostgreSQL 8.3.
Конфигурация включает в себя группы пользователей, набор процессов и категорий задач и некоторые другие объекты.
Группы пользователей
Разработчики. Имеют основные права по работе с задачами, исключая перевод в состояния «Проверено» и «Закрыто».
Тестировщики. Имеют право перевода в состояния «Проверено» и «Переоткрыто».
Менеджеры. Имеют все права, за исключением администраторских. Этой группе также доступен ряд специальных подзадач, не видимых для всех остальных групп пользователей.
Внешние пользователи. Имеют право просматривать задачи в основных проектах и создавать (редактировать) задачи в нескольких определённых ветках проектов. Некоторые поля задач и типы сообщений скрыты от этой группы пользователей.
Типы workflow и категорий
Folder (каталог). Может содержать проекты и каталоги.
Project (проект). Может содержать модули.
Module (модуль). Подпроект, некий компонент системы. Может содержать модули и задачи.
Task (задача). Может содержать подзадачи и переоткрытия задач.
Reopen. Переоткрытие задачи.
Каталог, проект и модуль — это простейшие workflow c единственным состоянием.
Task (родительская задача)
Состояния:
Типы сообщений:
Task может иметь один из приоритетов: низкий, средний, высокий. Имеет следующие дополнительные пользовательские поля:
Также имеются два вычисляемых строковых поля для фильтров. В эти поля помещаются ключевые слова (символы) в зависимости от выполнения некоторых условий. Одно поле кэшируемое (является ли задача саппортовой), второе — некэшируемое (запланирована ли задача на текущую неделю).
Reopen (переоткрытие)
Состояния:
Типы сообщений:
Reopen может иметь один из трёх приоритетов: низкий, средний, высокий. Дополнительные пользовательские поля у Reopen:
Применение триггеров и скриптов
Скрипты используются для следующих целей:
Основные цели, для достижения которых мы используем TrackStudio, следующие:
Общий список проектов и планирование
На данный момент в TrackStudio ведём три проекта: два — собственно разрабатываемые нами продукты и один — администраторский (технический), относящийся к работам по поддержке инфраструктуры, а именно функционированию сети, серверов (СУБД, SVN, CVS, email) и т. д. у нас в офисе и в других подразделениях.
Каждый проект состоит из ряда модулей, представляющих собой компоненты разрабатываемых систем.
Все новые задачи заносим в TrackStudio в соответствующие проекты (модули). По мере возможности стараемся сразу же давать временн€ые оценки, либо задачи оцениваются при формировании планов работы. Как правило, ответственным за задачу устанавливается разработчик, которому она будет поручена. Если изначально неясно, кто будет ею заниматься, то ответственным устанавливается менеджер, а позже он поручает работу конкретному человеку.
Точное календарное планирование обычно ведём не более чем на одну-две ближайшие недели — у таких задач заполняем поле Deadline. Задачам, запланированным на конкретную неделю, в специальное пользовательское поле прописывается идентификатор этой недели. Таким образом, можно выбрать задачи, запланированные до конкретного срока или на конкретную неделю.
При завершении текущей задачи разработчик просматривает задачи, запланированные на него (т. е. в которых он указан ответственным), и выбирает ту, которая должна быть завершена к более раннему сроку или является наиболее важной. Предпочтение отдаётся исправлению ошибок в ранее сделанных задачах.
Если над задачей параллельно работают несколько человек, то реально ответственным за неё всё равно является кто-то один, он и указан как Handler, остальные включаются в список Carbon Copy данной задачи. Если несколько человек работают последовательно, то ответственным устанавливается тот, кто работает в данный момент.
После выполнения задачи разработчик переводит её в состояние Resolved, что для тестировщика является признаком необходимости проверить корректность реализации задачи. Если найдены ошибки или недоработки, то задача переводится в состояние Reopened и возвращается разработчику. Если всё в порядке, то задача переходит в состояние Verified и поступает на утверждение менеджеру, который может или закрыть её, или вернуть на доработку.
Пока мы никак не разделяем задачи по версиям, в которых они должны быть реализованы, но в будущем, вероятно, станем создавать отдельные ветки для версий и размещать задачи именно в них.
Для всех категорий (workflow) задач настроена рассылка уведомлений. Уведомления рассылаются:
Учёт заявок на доработку от заказчиков
К нам ежедневно поступают письма от заказчиков с задачами, которые мы называем саппортовыми, — сообщения об ошибках, просьбы сконфигурировать систему, импортировать какие-то данные, добавить функциональность и т. д. Первоначально менеджеры просматривали эти письма и в случае необходимости создавали задачи. После перехода на TrackStudio мы настроили автоматический импорт писем, и теперь задачи создаются в специальных ветках проектов. Внешние пользователи шлют письма на разные почтовые ящики (в зависимости от проекта), с которых они пересылаются на ящик, проверяемый TrackStudio. При этом в теме письма добавляется специальный префикс, по которому TrackStudio определяет, где именно должна быть создана задача. Для ответов автору задачи можно создать сообщение типа Message to external Initiator, которое приведёт к автоматической отправке письма.
Пока таких писем относительно немного, автоматический импорт облегчает процесс. В будущем писем станет больше, и тогда, возможно, придётся отказаться от такого способа.
Отслеживание некоторых характеристик работы программистов
С целью повышения качества выполнения задач мы решили упростить сбор обратной связи по допущенным ошибкам и недоработкам в виде количества переоткрытий задачи, серьёзности (важности) ошибок и времени, потраченного на исправление. Количество переоткрытий и затраченное время можно вычислить скриптом, анализируя сообщения в задаче, но в этом случае не будет учитываться серьёзность ошибок. Поэтому ввели отдельную категорию — Reopen (переоткрытая задача). По сути это та же Task (родительская задача), но урезанная до необходимой минимальной функциональности: имя задачи, её описание, бюджет, затраченное время и дополнительное поле, где прописывается серьёзность ошибки (оно заполняется тестировщиком или менеджером). В родительской задаче ввели три соответствующих пользовательских поля, вычисляемых скриптами: Reopens Quantity, Reopens Time и Reopens Severity.
При создании подзадачи типа Reopen родительская задача автоматически (триггером) переводится в состояние Reopened. Чтобы все переоткрытия осуществлялись именно таким способом, для категории Task мы запретили явное создание сообщения Reopen через веб-интерфейс: при формировании этого сообщения проверяется префикс в его комментарии, который автоматически подставляется при создании подзадачи типа Reopen. Иными словами, если прописать такой же префикс при создании сообщения Reopen в родительской задаче, то оно будет обработано, — для нас это допустимое поведение, так как целью такого ограничения является не полное запрещение, а поддержка оговорённых процессов разработки.
Для контроля адекватности даваемых разработчиками временн€ых оценок и затраченного времени помимо собственно их оценки (Budgeted time) задача также оценивается другим (более опытным) разработчиком (менеджером), и его временн€ая оценка сохраняется в поле Customer Estimated (оценка клиентом). Это поле доступно для просмотра и редактирования только менеджерам и используется не всегда и не для всех задач, а только для критичных или для контроля работы конкретного разработчика, обычно новичка.