0
Рейтинг
WebCanape
Приводим клиентов малому бизнесу. Быстро и много.
6 мая 2010

BugZilla как система постановки задач и контроля работы. Реальный опыт использования

Блог компании WebCanape
Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

На первый взгляд кажется что здесь черт ногу сломит. Но когда ты поработаешь в этой системе, то понимаешь, что все грамотно и четко продумано. Система обладает колосальнейшими возможностями, просто кастомизируется и легко встраивается в процесс разработки веб проектов.

Преамбула


Скажу честно как все было… Надеюсь руководство меня не побьет и не уволит. Работать в компанию я пришел молодым и не опытным руководителем проектов. Быстро освоил весь производственный процесс и целиком в него влился. Стал руководить проектами: выявлять потребности заказчика, переводить все это на язык веба и формировать задания для разработчиков.

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

В итоге мы столкнулись со следующими проблемами:
  • Не было реального понимания что сейчас находится в работе, какие задачи выполняются, что делается и что вообще сделано
  • Невозможно было получить обратную связь.
  • Если вдруг кто-то заболевал или увольнялся приходилось восстанавливать огромную цепочку писем и выяснять: что было в работе, на каком этапе, что сделано.
  • Процесс согласования и выяснения дополнительных требований к задаче занимал много времени.
  • Мелкие задачи очень часто откладывались на потом и вовсе забывались.
  • Проверка выполненных задач так же была неэффективной. Результат о выполнении приходил через несколько часов.
  • Историю изменения вносимых корректив и доработок собрать воедино было просто нереально.
Так больше работать было нельзя. И мы решили, что пора переходить на более высокий уровень работы над проектами.

Выбор системы багтрекинга


Какие цели мы преследовали:
  • Сократить цепочку прохождения задачи от инициатора задачи (менеджера до конечного исполнителя).
  • При этом все уточняющие вопросы при необходимости должны обсуждаться напрямую между исполнителем и инициатором задачи
  • В любой момент получить срез по состоянию выполненных и текущих работ
  • Сохранить историю работы над проектом, включая все работы и доработки
  • Контролировать время работы над проектом
  • Расставлять приоритеты задачам
  • Производить анализ данных по проектам
Мы долго искали и выбирали систему. В итоге остановились на бесплатном и довольно известном багтрекере BugZilla.

Багзила изначально заточена под разработку программного обеспечения и регистрации ошибок. Мы не стали переименовывать названия, принятые в багзиле по умолчанию и установили, что:
  • Продукт — это проект
  • Раздел — включает в себя проекты. Мы поделили проекты по логическим группам: в работе, завершенные, на поддержке, продвижение.
  • Компонент — это этап: концепция, дизайн, верстка, программирование
  • Ошибка — это задача или баг.
Систему мы стали использовать намного шире:
  • В нее стали заносится не только ошибки по проектам, но и ставить задачи по работе: задачи по дизайну, верстке, наполнению и т.д. Т.е. все рабочие процессы фиксируются в BugZilla
  • Система контроля отработанного времени для исполнителей. Время работы над задачей фиксируется в BugZilla. В конце каждого месяца делается срез отработанного времени и с учетом этого начисляется заработная плата (это ввели уже позже).
  • Система отчетов для клиентов, работа над проектами которых идет по гибким методологиям. Они всегда могут войти в систему, посмотреть что делается. Поставить новую задачу или изменить приоритеты, а так же дать необходимые комментарии на возникшие вопросы по тем или иным задачам.
Сокращая число промежуточных исполнителей между постановкой задачи и ее исполнением мы увеличили скорость обработки пользовательских запросов в десятки раз, тем самым повысили лояльность клиентов и разгрузили менеджеров от лишней работы.

Разграничение прав доступа к проектам


Внедрение системы проходило в несколько этапов:
  1. Внедрение системы среди ограниченного числа сотрудников и отлаживание взаимодействия
  2. Вовлечение всех сотрудников на всех этапах производственного процесса
  3. Доступ к системе сторонних разработчиков и клиентов
Про первый и второй шаг рассказывать не буду. Информации по первоначальной настройке и работе с багзилой полно (если же читателям хабра будет все-таки интересно как мы это делали, то пишите пожелания в комментариях — напишу).

А расскажу я об этапе 3 и о том как правильно настроить багзилу, чтобы в нее можно было пустить сторонних разработчиков, менеджеров и клиентов. Но при этом запретить сторонним разработчикам видеть уже поставленные ошибки по проекту и вообще не иметь доступ к проектам компании.

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

Так как багзила в основном используется для поддержки Open Source проектов, то в ней по умолчанию действует принцип — что не запрещено в явном виде — то разрешено (т.е. так настроены настройки по умолчанию). Т.е. при создании новой задачи или проекта — он автоматически становится виден всем.

Перед нами стояло две основные задачи:
  1. Разграничить доступ к проектам и задачам которые уже созданы.
  2. При создании нового проекта автоматически запретить к нему доступ всем заведенным в системе пользователям. Позволить администраторам выбирать кому данный проект будет доступен.
Настроить разграничение можно разными способами, я расскажу как сделали это мы.

Разграничение прав на уже созданные проекты:
  1. Так как у нас проектная разработка, то под каждый новый проект заведен соответствующий продукт в багтрекере.
  2. Каждому проекту мы создали группы, совпадающую с названием проекта. Делается это в разделе «Администирование» -> «Группы» — «Создать группу»
  3. В свойствах каждого проекта производим настройку доступа («Администрирование» -> «Продукты» -> Выбираем продукт -> «Права доступа по группам»)
  4. Выставляем доступ по группам для продукта. Для того чтобы ошибки данного проекта были доступны только членам созданной группы выставляем параметры как показано на рисунке: для «Группы»-> «Включено», «Остальные» -> «Запрещено». Для остальных групп везде ставим «Запрещено», «Запрещено».
  5. Соответсвующим пользователям в разделе «Администрирование» -> «Пользователи» выбираем нужного пользователя и в столбце с группами под названием «Включен в группы» назначаем соответствующую группу (проект), все задачи по которому пользователь должен видеть.
  6. Так же давайте запретим пользователям видеть все продукты в поиске, доступ к которым запрещен. Для этого убедимся что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «useentrygroupdefault» выбран как «Вкл.»
  7. Теперь необходимо ранее заведенные ошибки, связанные с проектом, так же связаться с соответсвующей группой и таким образом закрыть их от постороннего взора:
    — Переходим к поиску
    — Выбираем продукт
    — Отбираем все ошибки по нему (новые, закрытые, выполненные и т.д.)
    — Выбираем групповое редактирование
    — Выделить все
    — В самом конце выбираем «Добавить ошибки в эту группу» — название нашей созданной группы под проект
    — Сохранить
Теперь рядом с каждой ошибкой у нас появился замочек. Это значить что данная ошибка будет видна только тем, кому разрешен доступ.

Кстати, нет необходимости каждому программисту или дизайнеру присваивать каждый раз группу проекта, над которой он будет работать. Если в качестве исполнителя задача поставлена не него, то он будет видеть конкретную задачу по данному проекту.
Для этого надо убедиться, что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «strict_isolation» выбран как «Выкл.» Таким образом над одним проектом смогут работать различные исполнители и не видеть задач друг друга, в то время как менеджер будет видеть полную картину проекта.

Теперь давай посмотрим, как сделать так, чтобы новые создаваемые проекты и ошибки/задачи, создаваемые к ним, были по умолчанию недоступны никому.
  1. Установим в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «makeproductgroups» выбран как «Вкл.»
  2. Теперь при создании нового продукта к нему автоматически будет создаваться группа.
  3. Вот и все. Теперь при создании ошибок к данному проекту они будут доступны только тем пользователям, которым назначена группа данного проекта.
Для того чтобы ошибка/задача стала доступна всем — необходимо в свойствах задачи снять параметр принадлежности группе.

Заключение


И вот по истечению 2,5 лет я могу сказать что решение в пользу BugZilla было принято верным. Сейчас без этой системы не могут обойтись ни менеджеры, ни сами разработчики, ни клиенты. Сейчас это один из основных инструментов при работе над проектами. В любой момент можно сделать срез по выбранному разработчику и посмотреть что у него стоит в работе. Тем самым планировать загрузку разработчиков и очередность решения задач.

Олег Демьянов
Руководитель отдела веб-разработки
компании «Твинс»
Теги:bugzillaпостановка задачконтрольошибкитаск менеджменттаск-менеджербагзилла
Хабы: Блог компании WebCanape
+54
24,3k 104
Комментарии 76
Похожие публикации
Лучшие публикации за сутки