Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…
На первый взгляд кажется что здесь черт ногу сломит. Но когда ты поработаешь в этой системе, то понимаешь, что все грамотно и четко продумано. Система обладает колосальнейшими возможностями, просто кастомизируется и легко встраивается в процесс разработки веб проектов.
Скажу честно как все было… Надеюсь руководство меня не побьет и не уволит. Работать в компанию я пришел молодым и не опытным руководителем проектов. Быстро освоил весь производственный процесс и целиком в него влился. Стал руководить проектами: выявлять потребности заказчика, переводить все это на язык веба и формировать задания для разработчиков.
Компания росла и развивалась. Проекты становились все больше и сложнее, а вот организационные процессы при работе над проектами оставались неизменным. Все было донельзя просто — все задачи ставились устно или же отправлялись списком по e-mail техническому директору, а он уже перераспределял задачи программистам. А в связи с тем, что производство было удаленным (часть разработчиков находилось в другом городе), то технический директор переформулировал задачи и отправлял их уже непосредственно программистам.
В итоге мы столкнулись со следующими проблемами:
Какие цели мы преследовали:
Багзила изначально заточена под разработку программного обеспечения и регистрации ошибок. Мы не стали переименовывать названия, принятые в багзиле по умолчанию и установили, что:
Внедрение системы проходило в несколько этапов:
А расскажу я об этапе 3 и о том как правильно настроить багзилу, чтобы в нее можно было пустить сторонних разработчиков, менеджеров и клиентов. Но при этом запретить сторонним разработчикам видеть уже поставленные ошибки по проекту и вообще не иметь доступ к проектам компании.
Долгое время мы использовали багтрекер только внутри компании, и не задумывались над разграничением прав доступа к проектам. Были админы, которые могли заводить новые проекты и новых пользователей. И были пользователи, которые могли ставить задачи, редактировать их и проставлять статус выполнения.
Так как багзила в основном используется для поддержки Open Source проектов, то в ней по умолчанию действует принцип — что не запрещено в явном виде — то разрешено (т.е. так настроены настройки по умолчанию). Т.е. при создании новой задачи или проекта — он автоматически становится виден всем.
Перед нами стояло две основные задачи:
Разграничение прав на уже созданные проекты:
Кстати, нет необходимости каждому программисту или дизайнеру присваивать каждый раз группу проекта, над которой он будет работать. Если в качестве исполнителя задача поставлена не него, то он будет видеть конкретную задачу по данному проекту.
Для этого надо убедиться, что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «strict_isolation» выбран как «Выкл.» Таким образом над одним проектом смогут работать различные исполнители и не видеть задач друг друга, в то время как менеджер будет видеть полную картину проекта.
Теперь давай посмотрим, как сделать так, чтобы новые создаваемые проекты и ошибки/задачи, создаваемые к ним, были по умолчанию недоступны никому.
И вот по истечению 2,5 лет я могу сказать что решение в пользу BugZilla было принято верным. Сейчас без этой системы не могут обойтись ни менеджеры, ни сами разработчики, ни клиенты. Сейчас это один из основных инструментов при работе над проектами. В любой момент можно сделать срез по выбранному разработчику и посмотреть что у него стоит в работе. Тем самым планировать загрузку разработчиков и очередность решения задач.
Олег Демьянов
Руководитель отдела веб-разработки
компании «Твинс»
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…
На первый взгляд кажется что здесь черт ногу сломит. Но когда ты поработаешь в этой системе, то понимаешь, что все грамотно и четко продумано. Система обладает колосальнейшими возможностями, просто кастомизируется и легко встраивается в процесс разработки веб проектов.
Преамбула
Скажу честно как все было… Надеюсь руководство меня не побьет и не уволит. Работать в компанию я пришел молодым и не опытным руководителем проектов. Быстро освоил весь производственный процесс и целиком в него влился. Стал руководить проектами: выявлять потребности заказчика, переводить все это на язык веба и формировать задания для разработчиков.
Компания росла и развивалась. Проекты становились все больше и сложнее, а вот организационные процессы при работе над проектами оставались неизменным. Все было донельзя просто — все задачи ставились устно или же отправлялись списком по e-mail техническому директору, а он уже перераспределял задачи программистам. А в связи с тем, что производство было удаленным (часть разработчиков находилось в другом городе), то технический директор переформулировал задачи и отправлял их уже непосредственно программистам.
В итоге мы столкнулись со следующими проблемами:
- Не было реального понимания что сейчас находится в работе, какие задачи выполняются, что делается и что вообще сделано
- Невозможно было получить обратную связь.
- Если вдруг кто-то заболевал или увольнялся приходилось восстанавливать огромную цепочку писем и выяснять: что было в работе, на каком этапе, что сделано.
- Процесс согласования и выяснения дополнительных требований к задаче занимал много времени.
- Мелкие задачи очень часто откладывались на потом и вовсе забывались.
- Проверка выполненных задач так же была неэффективной. Результат о выполнении приходил через несколько часов.
- Историю изменения вносимых корректив и доработок собрать воедино было просто нереально.
Выбор системы багтрекинга
Какие цели мы преследовали:
- Сократить цепочку прохождения задачи от инициатора задачи (менеджера до конечного исполнителя).
- При этом все уточняющие вопросы при необходимости должны обсуждаться напрямую между исполнителем и инициатором задачи
- В любой момент получить срез по состоянию выполненных и текущих работ
- Сохранить историю работы над проектом, включая все работы и доработки
- Контролировать время работы над проектом
- Расставлять приоритеты задачам
- Производить анализ данных по проектам
Багзила изначально заточена под разработку программного обеспечения и регистрации ошибок. Мы не стали переименовывать названия, принятые в багзиле по умолчанию и установили, что:
- Продукт — это проект
- Раздел — включает в себя проекты. Мы поделили проекты по логическим группам: в работе, завершенные, на поддержке, продвижение.
- Компонент — это этап: концепция, дизайн, верстка, программирование
- Ошибка — это задача или баг.
- В нее стали заносится не только ошибки по проектам, но и ставить задачи по работе: задачи по дизайну, верстке, наполнению и т.д. Т.е. все рабочие процессы фиксируются в BugZilla
- Система контроля отработанного времени для исполнителей. Время работы над задачей фиксируется в BugZilla. В конце каждого месяца делается срез отработанного времени и с учетом этого начисляется заработная плата (это ввели уже позже).
- Система отчетов для клиентов, работа над проектами которых идет по гибким методологиям. Они всегда могут войти в систему, посмотреть что делается. Поставить новую задачу или изменить приоритеты, а так же дать необходимые комментарии на возникшие вопросы по тем или иным задачам.
Разграничение прав доступа к проектам
Внедрение системы проходило в несколько этапов:
- Внедрение системы среди ограниченного числа сотрудников и отлаживание взаимодействия
- Вовлечение всех сотрудников на всех этапах производственного процесса
- Доступ к системе сторонних разработчиков и клиентов
А расскажу я об этапе 3 и о том как правильно настроить багзилу, чтобы в нее можно было пустить сторонних разработчиков, менеджеров и клиентов. Но при этом запретить сторонним разработчикам видеть уже поставленные ошибки по проекту и вообще не иметь доступ к проектам компании.
Долгое время мы использовали багтрекер только внутри компании, и не задумывались над разграничением прав доступа к проектам. Были админы, которые могли заводить новые проекты и новых пользователей. И были пользователи, которые могли ставить задачи, редактировать их и проставлять статус выполнения.
Так как багзила в основном используется для поддержки Open Source проектов, то в ней по умолчанию действует принцип — что не запрещено в явном виде — то разрешено (т.е. так настроены настройки по умолчанию). Т.е. при создании новой задачи или проекта — он автоматически становится виден всем.
Перед нами стояло две основные задачи:
- Разграничить доступ к проектам и задачам которые уже созданы.
- При создании нового проекта автоматически запретить к нему доступ всем заведенным в системе пользователям. Позволить администраторам выбирать кому данный проект будет доступен.
Разграничение прав на уже созданные проекты:
- Так как у нас проектная разработка, то под каждый новый проект заведен соответствующий продукт в багтрекере.
- Каждому проекту мы создали группы, совпадающую с названием проекта. Делается это в разделе «Администирование» -> «Группы» — «Создать группу»
- В свойствах каждого проекта производим настройку доступа («Администрирование» -> «Продукты» -> Выбираем продукт -> «Права доступа по группам»)
- Выставляем доступ по группам для продукта. Для того чтобы ошибки данного проекта были доступны только членам созданной группы выставляем параметры как показано на рисунке: для «Группы»-> «Включено», «Остальные» -> «Запрещено». Для остальных групп везде ставим «Запрещено», «Запрещено».
- Соответсвующим пользователям в разделе «Администрирование» -> «Пользователи» выбираем нужного пользователя и в столбце с группами под названием «Включен в группы» назначаем соответствующую группу (проект), все задачи по которому пользователь должен видеть.
- Так же давайте запретим пользователям видеть все продукты в поиске, доступ к которым запрещен. Для этого убедимся что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «useentrygroupdefault» выбран как «Вкл.»
- Теперь необходимо ранее заведенные ошибки, связанные с проектом, так же связаться с соответсвующей группой и таким образом закрыть их от постороннего взора:
— Переходим к поиску
— Выбираем продукт
— Отбираем все ошибки по нему (новые, закрытые, выполненные и т.д.)
— Выбираем групповое редактирование
— Выделить все
— В самом конце выбираем «Добавить ошибки в эту группу» — название нашей созданной группы под проект
— Сохранить
Кстати, нет необходимости каждому программисту или дизайнеру присваивать каждый раз группу проекта, над которой он будет работать. Если в качестве исполнителя задача поставлена не него, то он будет видеть конкретную задачу по данному проекту.
Для этого надо убедиться, что в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «strict_isolation» выбран как «Выкл.» Таким образом над одним проектом смогут работать различные исполнители и не видеть задач друг друга, в то время как менеджер будет видеть полную картину проекта.
Теперь давай посмотрим, как сделать так, чтобы новые создаваемые проекты и ошибки/задачи, создаваемые к ним, были по умолчанию недоступны никому.
- Установим в настройках системы «Администрирование» -> «Настройка системы» -> раздел «Групповые права доступа» -> параметр «makeproductgroups» выбран как «Вкл.»
- Теперь при создании нового продукта к нему автоматически будет создаваться группа.
- Вот и все. Теперь при создании ошибок к данному проекту они будут доступны только тем пользователям, которым назначена группа данного проекта.
Заключение
И вот по истечению 2,5 лет я могу сказать что решение в пользу BugZilla было принято верным. Сейчас без этой системы не могут обойтись ни менеджеры, ни сами разработчики, ни клиенты. Сейчас это один из основных инструментов при работе над проектами. В любой момент можно сделать срез по выбранному разработчику и посмотреть что у него стоит в работе. Тем самым планировать загрузку разработчиков и очередность решения задач.
Олег Демьянов
Руководитель отдела веб-разработки
компании «Твинс»