Интеграция систем управления разработкой

Для решения задач управления изменениями (change management), управления и коммуникации в проекте (project management, workflows and collaborative activities), регистрации ошибок и проблем (defect and issue tracking), управления знаниями (knowledge management), управления требованиями и тестированием (test-case and requirements management) разработано множество программных средств и систем, от простых и бесплатных до сложных и дорогих коммерческих «тяжеловесов». Решение этих задач на достойном уровне до недавнего времени требовало существенных инвестиций, что было затруднительно для небольших развивающихся компаний. Системы с открытым кодом изменили ситуацию, причем доступность кодов сделала возможной адаптацию систем под любую принятую в компании методологию разработки. В течение нескольких лет в компании CustIS с минимальной доработкой программного кода используются такие продукты, как трекер проблем Bugzilla, wiki-система Mediawiki, системы контроля версий CVS и Subversion совместно с системой мониторинга SCM-репозиториев (Software Configuration Management) Bonsai. Ключом к их применению является не доработка, а понимание того, как «накрыть» заявленные задачи этими системами или их аналогами.

Постановка задачи

На сегодняшний день написано множество книг о том, как управлять людьми и задачами, программным кодом и оборудованием, как строить общение с заказчиками или субподрядчиками. Имеется немало трудов от экспертов-гуру, а также целый ряд сертифицирующих методологий и стандартов, таких как ITIL, PMBOK, SWEBOK, RUP, CMMI и т.п. К сожалению, универсального решения до сих пор не найдено.

Во-первых, в большинстве концепций предлагаются чрезмерно формализованные процессы. Такая формализация, возможно, и оправданна в корпорациях, где бизнесом не является разработка программного обеспечения, а ИТ-отдел представляет собой обслуживающее подразделение, эффективность которого практически не влияет на прибыльность организации. Но для компаний–разработчиков программного обеспечения чрезмерная формализация, выражающаяся в ненужных отчетах и процессах («почасовки», сбор данных для метрик, которые нужны только для «галочки», и т.п.), по нашему мнению, подавляет инициативу и снижает производительность труда. Более того, происходит разрушительная демотивация сотрудников — наиболее сильные программисты и аналитики просто отказываются работать в таких условиях (либо требуют сверхрыночных компенсаций), а остальные склонны к тихому саботажу «бюрократии». Наиболее одиозные практики, такие как регламентация внешнего вида для программистов или зависимость зарплат от автоматически вычисляемых метрик производительности (например, число измененных строчек кода), хоть и подстегивают дисциплину, но быстро становятся притчей во языцех в профессиональном сообществе, надолго отпугивая от компании творческих кандидатов. Разумеется, внедрение и сертификация признанной методологии вполне может дать положительный экономический эффект, например доступ к выгодному контракту или дешевому кредиту, но надо четко представлять границы ее применимости и понимать, что эффект может быть и отрицательным.

Во-вторых, сами по себе описания методологий не дают ответа на вопрос, какую систему автоматизации использовать для управления разработкой. Конечно, на рынке есть мощные коммерческие продукты, претендующие на полный цикл автоматизации в соответствии с какой-либо методологией, но они дороги, и, даже будучи автоматизированными, чрезмерно формализованные процессы неудобны. Отдельно хотелось бы предостеречь аудиторию от такого рода рассуждений: «Продукт XXX негибкий и сложный, зато он на рынке уже десять лет, реализует концепции лучших экспертов-классиков, поддерживает десяток международных стандартов и используется в таких компаниях–монстрах, как YYY, инкорпорировав в себя их лучший опыт. Да, его будет сложно внедрить, не все сотрудники и заказчики переживут внедрение, но остальные благодаря этому продукту перестанут допускать ошибки — мы просто купим с этим продуктом возможность их избежать». Такой способ мышления, увы, распространен во многих современных областях жизнедеятельности, демонстрирует один из примеров так называемого карго-культа*. Любые сложные, долго живущие системы несут в себе не только успешные практики, но и законсервированные вирусы ошибок, реликты никому уже давно не нужных возможностей. И эту ситуацию нельзя исправить, если система негибкая и нет доступа к ее исходным кодам.

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

Другой путь

В результате поиска эффективных методов коллективной разработки ПО, обеспечивающих, с одной стороны, прозрачность и управляемость, а с другой — минимальные накладные расходы, мы пришли к минимальной модели информационных объектов процесса разработки и соответствующему оптимальному набору систем категории Open Source для ведения этих объектов. Выбранные системы, благодаря открытости исходного кода, были интегрированы между собой и адаптированы под сложившиеся в компании «гибкие» (agile) методики разработки. Давно используя самодельные методики, основанные на творческом переосмыслении принципов экстремального программирования и упрощенного клиент-ориентированного проектного управления (итерационное развитие макета по приоритетным направлениям заказчика), мы обнаружили, что наши подходы очень близки к подходу Scrum, и перешли на него. Известность и «модность» Scrum облегчает нам привлечение и разработчиков и заказчиков, упрощая взаимодействие между ними.

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

Рис. 1.  Информационные объекты в разработке программного обеспечения

Основную классификацию информационных сущностей, возникающих в процессе разработки и поддержки заказных информационных систем, можно представить в виде модели, показанной на рис. 1. В трех различных по цвету зонах сгруппированы информационные объекты, схожие по атрибутам и методам работы с ними. Зоны пересекаются, например, документация к программным продуктам относится как к производимым артефактам, так и к базе знаний. На пересечении «зоны знаний» и «зоны проблем» лежит история решения какой-либо задачи. Выбор информационных систем, в соответствии с этим подходом, с одной стороны требует полного покрытия этих проблемных зон, а с другой — минимизации количества конкурирующих информационных систем в каждой из этих зон.

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

Системы должны обеспечивать максимальную производительность при коллективной работе, пусть даже в ущерб некоторым отдельным удобствам — обязательно должно быть «лекарство от страха» в виде поддержки версионности и истории изменений. Отсюда, например, следует выбор систем контроля версий с возможностью параллельной работы без монопольных блокировок и с автоматическим слиянием изменений, а также максимально возможная замена текстовых процессоров документов в бинарных форматах на системы групповой работы с документами в плоских текстовых разметках, таких как SGML Docbook, XHTML, XML, LaTeX и др.

Кроме этого, необходима максимальная прозрачность и удобство наблюдения за процессами, что означает возможность быстро находить и отслеживать информационные объекты и их взаимосвязи через Web-интерфейс, получая ответы на вопросы типа «что сделано по такому делу?», «какой код был изменен для исправления такой-то ошибки?», «где история обсуждения постановки этой задачи и сколько времени потрачено на ее решение?», не говоря уже о простом текстовом поиске ответов на вопросы «где лежат ключи от офиса?» и «что делать, если возникла ошибка 0x8040459 в модуле PM-BLACK-BOX?».

Рис. 2. Покрытие проблемных зон системами-решениями

Для себя мы выбрали представленную на рис. 2 схему покрытия проблемных зон, показанных на рис. 1. Сразу оговоримся: наш выбор, может быть, сегодня уже и не оптимален — для каждой выбранной нами системы имеются коммерческие и бесплатные аналоги, возможно превосходящие качеством, но у нас данная схема работает, ее можно взять за основу, заменяя отдельные компоненты более удобными. Пунктирным квадратом обозначена зона систем с Web-интерфейсом, где однонаправленные стрелки означают возможность гипертекстовых переходов между соответствующими объектами в этих системах. Двунаправленными стрелками показана более сложная интеграция, связанная с перегрузкой данных. Еще стоит признать, что OmniFind не является системой open-source, но она совершенно бесплатна и допускает некоторую адаптацию, вполне достаточную для наших целей, да и к моменту ее выбора других бесплатных поисковиков-аналогов, понимающих русскую морфологию, еще не было.

Учет задач, ошибок и заявок

Bugzilla — система контроля ошибок, разработанная при поддержке The Mozilla Foundation, которая может использоваться как система учета/контроля/регистрации заданий (дел, заявок, инцидентов и т.п.). Ключевым понятием системы является баг (Bug) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баг — это стандартное обозначение для программной ошибки, однако выбор названия совершенно условный — систему можно настроить так, чтобы использовать вместо слова Bug более общий термин, скажем, Issue или Problem.

Назначение системы — регистрация и предоставление заинтересованным лицам полной информации о проблеме, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещения. Каждый баг имеет набор атрибутов, работа с которыми является основными сценариями использования Bugzilla.

• Структурные атрибуты: «Классификация», «Продукт», «Компонент». Часть классификаций и продуктов предназначена для получения запросов от заказчиков и соответствует производимым программным продуктам, часть нужна проектным командам для регистрации заданий на разработку, часть используется инфраструктурными подразделениями для обслуживания внутренних заявок.
• Атрибуты жизненного цикла: «Статус», «Решение».
• Текстовые: описание, аннотация, комментарии по проблеме и «Доска заметок».
• Серьезность проблемы: «Приоритет» и «Важность», а также «Крайний срок».
• Временные: «Версия», где возникла проблема, «Веха», когда ее планируется исправить.
• Состояние: статус проблемы и ее решение, если она решена.
• Теговая классификация и расширение состояний: ключевые слова, флаги.
• Вложения и внешние ссылки.
• Учет времени: первоначальная оценка сложности задачи, текущая оценка, затраченное время, сопровождаемое комментарием.
• С каждым багом связаны несколько пользователей, каждый из них имеет одну или несколько ролей, смысл и функция которых понятна из названия: «Ответственный», «Инициатор», «Контролер» или «Наблюдатель».

В Bugzilla возможен только один вид зависимостей: «баг X зависит от решения бага Y» и нет разделения структурных зависимостей типа: «проблема X подразделяется на проблемы X1, X2, X3» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде «баг X зависит от решения багов X1, X2, X3».

В системе есть мощный интерфейс формирования запросов, запросы можно сохранять, а выбранные баги можно просматривать различным образом: в виде настраиваемого списка, агрегированного OLAP-среза или в виде графа зависимостей (рис. 3).

Рис. 3. Виды отчетов и представлений в Bugzilla

По событиям в каждом баге система формирует почтовые извещения для ассоциированных с багом пользователей, можно также видеть рабочий журнал комментариев по любому выбранному множеству багов, держа таким образом «руку на пульсе» и контролируя любые проблемные секторы в рамках своих полномочий. Мы используем Bugzilla не как узкоспециализированный баг-трекер, а как универсальный регистратор объектов из «зоны проблем» (рис. 1), который для разных сценариев автоматизирует работу в согласии с различными методиками, обеспечивая эффективное распараллеливание операций и асинхронное взаимодействие сотрудников.

Внутренние инфраструктурные проблемы типа: «сломался компьютер», «зависает программа», «нужно купить билет на самолет» после регистрации рассматриваются, попадают в соответствующие очереди задач и сферы ответственности. Иными словами, решаются с учетом рекомендаций ITIL/ITSM по управлению проблемами и инцидентами. Здесь же реализуется разделение сфер ответственности с возможной эскалацией, обратная связь и управление рисками.

С точки зрения Scrum-команд разработки баг — это Scrum Task. Заказчики формируют поток багов-ошибок и багов-запросов на доработку, которые могут сопровождаться ассоциированными wiki-статьями, где собственно и происходит обсуждение и выработка технических заданий (SCRUM backlog, XP user story). По багам-ошибкам во «внешних» продуктах Bugzilla формируются блокирующие их баги во «внутренних», недоступных заказчику продуктах разработчиков, где все проблемы успешно решаются, изолируя заказчика от технических деталей и внутренних переговоров разработчиков.

По результатам нескольких лет эксплуатации были сделаны доработки: введены дополнительные атрибуты, реализована защита от потери ответственности за баг, появились RSS-ленты, сделан интерфейс ввода массовых трудозатрат, включено клонирование багов и ряд других небольших доработок. Проведена также интеграция с MediaWiki и Bonsai, позволяющая от любого бага перейти к статье-спутнику в wiki-системе, где происходит постановка задачи или лежит сухая «выжимка» знаний из, возможно, сотни комментариев по данному багу. В один клик осуществляется и поиск в программном коде изменений, связанных с данным багом. В дополнение к собственным агрегированным отчетам Bugzilla была создана система генерации локальных многомерных OLAP-кубов, которые вместе со стандартными Web-отчетами Bugzilla вполне реализуют концепцию «приборных панелей проектов» (project dashboard).

MediaWiki: корпоративная система и база знаний

MediaWiki — это самая распространенная wiki-система. Благодаря проекту «Википедия», реализованному на основе MediaWiki, здесь почти ничего не нужно объяснять, ибо вероятность того, что этот текст прочтет человек, не знающий, что такое «Википедия», пренебрежимо мала. Сам же проект «Википедия» доказал, что wiki-системы, и в частности MediaWiki, отлично подходят для организации баз знаний неограниченного масштаба.

Документы в wiki хранятся в виде плоского текста с использованием некоторого языка разметки. Текст можно править «по месту» в процессе чтения материала и немедленно публиковать. Следующий момент — облегченная схема построения гиперссылок. В wiki-системе соблюдается цепочка Идентификаторы=Названия=Заголовки и используется адаптивная линковка, заключающаяся в перенаправлениях и даже «опережающих» ссылках на несуществующие еще статьи.

Наконец, wiki-система обеспечивает централизованное хранение, что для большинства пользователей удобнее работы со множеством файлов размеченной (HTML, XML, LaTeX, SGML) документации. Не требуется одновременно знать и файловую структуру проекта, и идентификаторы разделов (для ссылок) и иметь систему синхронизации изменений от различных пользователей.

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

В wiki-системе на основе MediaWiki мы не дублируем знания, доступные в Сети, а держим исключительно внутреннюю уникальную информацию: описания внутренних технологий, регламентов, инструкций, FAQ-списки, библиотеку, личные странички сотрудников с квалификационными профилями и т.п. (рис. 4).

Рис. 4. Корпоративный портал на основе MediaWiki

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

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

OmniFind

Задача полнотекстового поиска с учетом русской морфологии пока выходит за возможности MediaWiki, к тому же есть много ресурсов и вне wiki (документация, своя и чужая, файловые документы и т.п.). Для решения этой задачи используется бесплатный поисковик по локальным Web-ресурсам и файлам IBM OmniFind Yahoo! Edition (omnifind.ibm.yahoo.net), использующий технологию Lucene для полнотекстовой индексации, поддерживающий морфологию русского языка.

Bonsai

Bonsai — Web-система доступа к репозиториям систем контроля версий CVS и Subversion, разработанная изначально для поддержки продуктов проекта Mozilla. Ее средство Query Tool позволяет осуществлять поиск по содержимому репозитория (включая отдельные изменения), используя фильтр по множеству атрибутов. Выбранные результаты могут быть отсортированы и просмотрены в браузере в различных режимах: просто содержимое файла; раскрашенные и подсвеченные изменения для каждой версии; аннотированный исходный текст, где каждая строка указана вместе с ее автором, версией ее появления и комментарием к этой версии. По ссылке Look for Bug in CVS происходит выборка всех изменений в репозитории, связанных с конкретным багом (все «CVS-коммиты», то есть операции фиксации локальных правок в центральном репозитории, проверяются на привязку к багам), и наоборот, по ссылке с каждого изменения можно перейти из Bonsai на соответствующий баг в Bugzilla.

Bonsai мы любим не только за это — с его помощью у нас также построена система автоматической генерации дистрибутивов обновлений программного обеспечения.

Системы контроля версий

В данный момент мы одновременно используем две системы контроля версий: CVS и SVN (Subversion). Для CVS накоплено много проектов, однако многие из них в настоящее время развиваются слабо, и их уже не имеет смысла переносить в SVN, а все новые, активно развивающиеся проекты, были перенесены под SVN. Для тех, кто выбирает систему контроля версий «с нуля», мы рекомендуем сразу использовать SVN. Дружеский графический интерфейс TortoiseSVN (также бесплатный и Open-Source) позволяет работать с Subversion даже сотрудникам обеспечивающих подразделений. А отсутствие «наследственных» болезней CVS (например, невозможность изменить файловую структуру без потери истории) позволяет исправить в репозитории все ошибки, допущенные неопытными сотрудниками.

Альтернативы

Упомянутые в статье инструменты, возможно, уже не оптимальны, в частности, для старта с «чистого листа» и с минимальными затратами разумнее использовать появившиеся комплекты (трекер+wiki+SCM) — Trac (trac.edgewall.org), Redmine (www.redmine.org), CVSTrac (cvstrac.org) и RoundUp (roundup.sourceforge.net). Аналогов (как бесплатных, так и коммерческих) трекеров, wiki-систем и SCM по отдельности сейчас появилось множество (en.wikipedia.org/wiki/Comparison_of_wiki_software, en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems, en.wikipedia.org/wiki/Comparison_of_revision_control_software).

***

Рассмотренный подход позволяет практически бесплатно автоматизировать коллективную работу в компании-разработчике, имеющей в штате до сотни человек включительно. Обеспечивается гибкость и независимость от методологий. В частности, на одном и том же наборе инструментов может идти и проектная работа, скажем, по методике SCRUM, и оперативная деятельность, например техническая поддержка в соответствии с рекомендациями ITIL. За рамками обзора осталось немало других интересных инструментов поддержки разработки и тестирования категории Open Source, таких как CruiseControl для поддержки технологии Continuous Integration, средства эффективного документирования и многое другое.

Станислав Фомин (stas@custis.ru) — заместитель директора по информационным технологиям, компания «Заказные ИнформСистемы» (Москва).

* Культ карго, или карго-культ (англ. cargo cult), также религия самолетопоклонников, или культ Даров небесных, — термин, которым называют группу религиозных движений на островах Меланезии. В культах карго верят, что западные товары (карго, англ. «груз») созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В культах карго проводятся ритуалы, похожие на действия белых людей, чтобы этих предметов стало больше.