SCM // 3. Отслеживание запросов на изменение

Продолжаю цикл заметок об основах управления конфигурацией программных средств.В этой заметке речь пойдет о том, что большинство называют bugtracking systems. Мы посмотрим на этот класс задач и инструментов с более обобщенной точки зрения.

Отслеживание запросов на изменение

Для начала, как вообще возникают изменения на проекте? Вариантов всего несколько:

• создается новая функциональность продукта;
• функциональность или внутренняя структура изменяются в ходе плановых доработок (например, рефакторинга);
• исправляются найденные ошибки.

Первые два вида иногда объединяются. Однако чаще всего он отделяются друг от друга – просто потому, что это действительно разные вещи. Конечно, бывает, что для исправления ошибки нужно сделать рефакторинг или же написание функциональности устраняет некоторые проблемы. Но в этих случаях всё сводится к тому, какой процесс работы над изменениями, и какая терминология приняты в рамках проекта.

Изменяться может любой рабочий продукт – это могут быть как исходные коды, так и требования, тесты – в общем, всё то, что перечислялось в предыдущих материалах. Важно, что это всё изменяется и надо производимые изменения контролировать.

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

Итак, есть потребность в изменениях, и есть тот, кто эту потребность озвучит. Остается начать движение. Началом движения является подача запроса на изменение. Запрос на изменение – это предложение об усовершенствовании продукта, выраженное в виде записи в системе отслеживания запросов на изменения. В англоязычных источниках такие запросы называются change request (CR). Встречается также термин problem or change request (PCR). В дальнейшем будем использовать аббревиатуру CR (читается «сиар»).

В свою очередь, система отслеживания запросов на изменения – это программная среда, позволяющая производить учет предложений на изменения продукта и управление ответственностью за них. Ключевые слова во всей цепочке терминов – запрос, изменение, и отслеживание ответственности. В русскоязычных источниках часто используется термин «система отслеживания ошибок». В англоязычной литературе встречаются change request management system, bugtracking system, issue tracking system.

Как правило, хранилищем в подобных системах выступает БД, где один CR – это одна запись (чаще — связанный набор записей) в ней. CR после заведения имеет следующую обязательную информацию:

• кто завел запись (submitter);
• краткое название записи (subject);
• использованная версия изменяемой системы;
• подробное описание запроса или проблемы.

Также может быть добавлена просто полезная информация (она может быть объявлена как обязательная, в зависимости от принятого процесса разработки):

• описание ожидаемого поведения системы (для ошибок);
• конфигурация ПО и аппаратной части;
• фрагменты журнала работы системы («логи»).

Далее весь жизненный цикл записи – это последовательное назначение ответственного на разных этапах работы и добавление информации, необходимой для решения задачи. Как правило, устройство систем отслеживания можно свести к двум моделям:

• конечный автомат (finite state-machine, или машина состояний), где каждое состояние характеризуется своим набором полей;
• запись, у которой по ходу работы меняют содержимое имеющихся полей и к которой добавляют комментарии.

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

Посмотрим на типовой сценарий. Запись заведена, нужно начинать работать. Однако никакие изменения не должны вноситься бесконтрольно. Поэтому перед началом работы нужно получить одобрение менеджмента, который отвечает за функциональность, затронутую запросом на изменение. Роль менеджмента выполняет Configuration Control Board (группа контроля конфигурации) – группа, обладающая в рамках проекта правами на управление изменениями в рамках проекта. Также иногда используется термин Change Control Board и сокращение CCB.

Простой сценарий

Для дальнейшей работы возьмем систему отслеживания в виде машины состояний – так будет более наглядно. Набор состояний на схеме 1 – минимально необходимый, он может быть расширен до большего размера и разбит на нескольких шаблонов жизненных циклов. Этот набор возьмем для дальнейшего описания.

Схема 1. Жизненный цикл запроса на изменение

Первое состояние, в которое попадает любая запись, начальное. На приложенной схеме это New. На этом этапе создатель записи вносит все начальные данные, требуемые проектным процессом разработки. Далее CR попадает в поле зрения CCB. Оно принимает решение, кому из разработчиков отдать проблему для решения.

Для того, что отдать CR в работу, запись переводится в следующее состояние – Assigned («приписано к ответственному»). Одновременно запись «назначается» на разработчика – т.е. он становится за неё ответственным.

Однако приписать задачу кому-то – ещё не означает, что задача сразу же начнет решаться. На одного разработчика ведь может быть назначено несколько задач – одна важней другой и все надо сделать ещё вчера. Поэтому когда разработчик на самом деле начинает заниматься задачей – он переводит запись в состояние Opened («работа начата»). CCB, отслеживающее работу, видит, что задача взята в оборот. Сама задача при этом, как правило, остается «приписанной» к разработчику.

По ходу работы ответственные могут меняться, в зависимости от того, кто владеет кодом, который влияет на описанное в CR поведение. Переназначения делает CCB. Кроме того, может выясниться, что проблема уже кем-то найдена и на неё был заведен свой CR. В этом случае проблема дуплицируется, т.е. закрывается и в соответствующем поле добавляется номере записи, которая была заведена ранее. С этого момента запись считается закрытой. Может также выясниться, что описанная проблема не является ошибкой в работе (т.е. это WAD, works as designed) или же запрошенная функциональность не может быть реализована в силу разных причин. В этом случае запись терминируется, т.е. закрывается с комментариями о том, почему работа над проблемой продолжена не будет.

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

• перевод в начальное состояние, если задача не решена;
• перевод в состояние Closed («закрыто»), если исправлена ошибка или работает новая функциональность, описанная в запросе.

После чего изменения интегрируются в основной код продукта. За это отвечает уже СМ-инженер проекта и на него заводится отдельная запись в системе.

О реализации и тонкой настройке

Кстати, стоит добавить, что системы отслеживания запросов на изменения также используются как системы назначения и отслеживания задач на проекте. Ведь любая задача, возникающая на проекте, требует отслеживания со стороны руководства. Да и результат большинства задач – это, опять же, какие-то изменения. Поэтому логично для всех целей использовать одну систему. Иногда системы отслеживания задач ещё называют общим термином help desk. Однако, смысл от этого не меняется — я их также причисляю к системам отслеживания запросов на изменение.

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

Моё мнение — надо выбирать системы, позволяющие гибко задавать цикл работ. Хотя бы для того, чтобы заложенная когда-то кем-то неведомым схема работы не стала для вашего проекта догмой. Со временем за её рамки трудно выйти из-за ограничений инструментария и проекту начинает становиться «тесно». Так что гибкая настройка — наш выбор!

Реализация систем отслеживание запросов на изменения – едва ли не любимейшее занятие программистов всего мира. Кто-то считает, что его система-то уж точно затмит все имеющиеся. Кто-то уверен, что в остальных чего-то не хватает из того, что надо ему. А кто-то просто делает это ради собственного удовольствия. Каждому – своё. Если кто не захочет изобретать своё двухколесное средство передвижения, может ознакомиться с существующим велопарком. Ну и подобрать бицикл, что лучше всего подходит для его задачи. К слову, автору довелось принять некоторое участие в разработке упомянутого в приведенном списке eTraxis. Его и порекомендую, пользуясь случаем.

А как же CM-инженеры?

Запросы на изменение отслеживать научились. Какова роль CM-инженеров проекта? На них лежит ответственность за:

• внедрение систем отслеживания в процесс разработки;
• разработку политик использования этих систем;
• отслеживание выполнения установленных правил.

Немало копий ломается над первой задачей — ведь систем много, и надо выбрать оптимальную. Есть у меня пара советов на этот случай, соответствующий материал даже написан… однако опубликован он будет чуть позже, следите за обновлениями :)

Ссылки для расширения кругозора

1. http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems — сравнение систем учета запросов на изменение.
2. eTraxis — система отслеживания запросов, в создании которой автор принимал активное участие.

В следующей части будет расказано о, пожалуй, самом важном проявлении практик SCM — контроле версий. Кстати, там снова будет затронуто отслеживание запросов на изменения — без него никуда.

P.S. На отдельной странице собраны ссылки на статьи по основам управления конфигурациями.