Интеграция Open Source-систем для управления разработкой ПО — различия между версиями

Текущая версия на 14:25, 21 июля 2019

Стас Фомин

Заместитель директора по информационным технологиям / stas@custis.ru

• «Интеграция Open Source-систем для управления разработкой ПО»^[1]

Аннотация

Мы представляем наш опыт по интеграции бесплатных систем с открытыми исходными кодами для полноценного управления процессом разработки программного обеспечения. Обсуждаются методы решения следующих задач:

• управление изменениями (change management);
• управление и коммуникация в проекте (project management, workflows and collaborative activities);
• регистрация ошибок и проблем (defect and issue tracking);
• управление знаниями (knowledge management);
• управление требованиями и тестированием (test-case and requirements management).

Для решения перечисленных задач разработано множество программных средств и систем, от простых и бесплатных, до дорогих коммерческих «тяжеловесов». Но ещё несколько лет назад, достойное решение этих задач требовало существенных инвестиций либо в коммерческие продукты, либо в «изобретение велосипедов», т.е. разработку программных решений собственными силами. Для небольших развивающихся компаний это приводило к недостаточному качеству или к высокой стоимости «входного билета» в отрасль. К счастью, в последние годы развитие open-source систем привело к тому, что можно решить вышеперечисленные задачи практически бесплатно, потратив лишь небольшое время на их изучение. Причем открытость исходных кодов делает легкой адаптацию систем под любую принятую в компании методологию разработки, а широкая распространенность этих систем способствует выработке и распространении в сообществе правильных практик использования. Мы, в течение нескольких лет успешно используем в нашем agile-процессе разработки и технической поддержке ПО, такие продукты как Bugzilla, Mediawiki, CVS, Subversion, Bonsai, причем с минимальной доработкой программного кода. Ключом к их использованию является не доработка, а понимание того, как «накрыть» заявленные задачи этими системами или их аналогами, и этим знанием мы бы хотели поделиться с сообществом разработчиков.

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

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

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

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

«Да, продукт XXX — негибкий и сложный. Зато он уже на рынке с 1990 года, и реализует концепции лучших экспертов опубликованных еще в 1980-х годах, и придерживается десятков международных стандартов 1970-x. Он используется в таких компаниях монстрах как YYY, и конечно, за 20 лет разработки продукт инкорпорировал в себя, в виде десятков фаз, регламентов и проверок, все best practices этих знаменитых компаний. Да, нам будет сложно его внедрить, не все сотрудники и заказчики переживут его внедрение, но остальные, благодаря этому продукту перестанут допускать ошибки — мы более чем умные, мы не будем тратить время на хождение по граблям и даже на изучение ошибок других — мы просто купим с этим продуктом возможность их избежать. Производство станет эффективным и предсказуемым, а компания станет процветать».

Такой способ мышления, увы, распространенный во многих современных областях жизнедеятельности, демонстрирует один из примеров так называемого карго-культа^[2]. И хотя конечно можно назвать примеры, когда следование карго-культу приводило к положительному результату (так заинтересовавшиеся этим феноменом американские антропологи всё же привезли шоколад на Фиджи), такой подход нельзя назвать пристойным для специалиста с естественнонаучным образованием. Даже отвлекаясь от этой магической метафоры, просто отметим очевидный факт, что любые сложные долгоживущие системы несут в себе не только успешные практики, но и законсервированные мемы-вирусы ошибок, реликты никому уже давно не нужных возможностей. И как-либо исправить ситуацию, если система негибкая и нет доступа к исходным кодам, нельзя никак.

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

Наш подход

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

Таким образом, мы эволюционно пришли к минимальной модели информационных объектов процесса разработки ПО и соответствующему минимально-оптимальному набору open-source систем для ведения этих объектов. Выбранные системы, мы, именно благодаря открытости исходного кода, легко интегрировали между собой, адаптировав их под сложившиеся у нас гибкие (agile^[3]) методологии разработки ПО. Еще одно преимущество open-source, кроме бесплатности использования и возможности легкой адаптации, состоит в том, что такие системы при своей эволюции быстро учитывают актуальные мнения большого сообщества разработчиков, и тем самым, происходит глобальная трансляция успешных практик.

Наш взгляд на основную классификацию информационных сущностей, возникающих в процессе разработки и поддержки заказных информационных систем, представлен на Рис. 1.

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

Рис.1. Информационные объекты в разработке ПО

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

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

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

Мы пришли к следующей схеме (см. Рис. 2) покрытия проблемных зон, показанных на Рис. 1, выбранными нами системами-решениями^[4]. Сразу оговоримся, наш выбор может быть далеко не самым оптимальным на текущий момент, сейчас для каждой выбранной нами системы есть платные и бесплатные аналоги, возможно превосходящие качеством, но у нас это работает, схема жизненна, и можно взять её за основу и экспериментировать, заменяя отдельные компоненты более модными или удобными. Пунктирным квадратом обозначена зона систем с веб-интерфейсом, где однонаправленные стрелки — возможность гипертекстовых переходов между соответствующими объектами в этих системах. Двунаправленными стрелками показана более сложная интеграция, связанная с перегрузкой данных. Далее, мы расскажем о каждой из этих систем.

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

Bugzilla — учет задач, ошибок и просто заявок

Bugzilla — «система контроля ошибок», разработанная «The Mozilla Organization». Может также использоваться как: система учета/контроля/регистрации заданий (дел, заявок, инцидентов и т. п.).

Ключевым понятием системы является баг^[5]

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

• Структурные атрибуты: «Классификация», «Продукт», «Компонент». Часть классификаций и продуктов предназначены для получения запросов от заказчиков, и соответствуют производимым программным продуктам, часть — проектным командам и предназначена для регистрации заданий на разработку, часть — инфраструктурным подразделениям для обслуживания внутренних заявок.
• Атрибуты жизненного цикла: «Статус», «Решение».
• Текстовые: описание, аннотация, комментарии по проблеме и «доска заметок» (whiteboard).
• Серьезность проблемы: «приоритет» и «важность», а также «крайний срок» (deadline).
• Временные: «версия», где возникла проблема, «веха», когда её планируется исправить.
• Состояние: статус проблемы и ее решение, если она решена.
• Тэговая классификация и расширение состояний: ключевые слова, флаги.
• Вложения (attachments) и внешние ссылки.
• Учет времени: первоначальная оценка сложности задачи, текущая оценка, затраченное время, сопровождаемое комментарием.
• С каждым багом связаны несколько пользователей, каждый из которых имеет одну или несколько ролей, смысл и функция которых понятна из названия: «ответственный», «инициатор», «контроллер» или «наблюдатель».

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

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

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

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

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

Рис.4. Почтовое и RSS-оповещение

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

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

Рис.5. Анализ базы Bugzilla через локальные OLAP-кубы

По результатам нескольких лет эксплуатации мы сделали некоторое количество доработок: дополнительные атрибуты, защита от потери ответственности за баг, RSS-ленты, интерфейс ввода массовых трудозатрат, клонирование багов и некоторые другие, но в целом, это очень небольшие доработки, с характерным объемом порядка ста строчек кода каждая. Сделана интеграция с MediaWiki и Bonsai (см. Рис. 8), позволяющая от любого бага перейти к статье-спутнику в вики-системе, где происходит постановка задачи или лежит сухая «выжимка» знаний из (возможно сотни) комментариев по данному багу. Аналогично, в один клик осуществляется поиск изменений в программном коде, связанных с данным багом. В дополнение к собственным агрегированным отчетам Bugzilla, мы сделали систему генерации локальных многомерных OLAP-кубов, которые очень компактны и удобны для просмотра через MS Excel^[6] (см. Рис. 5). Эти OLAP-кубы вместе с стандартными web-отчетами Bugzilla вполне реализуют концепцию «приборных панелей проектов» (project dashboard).

MediaWiki: Корпоративная CMS и база знаний

«Вики» или «ВикиВики» это:

• Выражение, означающее «быстро»/«ненапряжно» на Гавайском языке.
• Принципы ведения вебконтента, заключающиеся в простой языке разметки, совместном редактирование многими пользователями, мгновенной публикации изменений и версионности, упрощенной системе построения гиперссылок.

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

Статьи в вики представлены плоским текстом^[7], имеющим множество преимуществ перед бинарными форматами документов для текстовых процессоров:

• Редактируется в любом текстовом редакторе.
• Минимальный «вес» при хранении и пересылке по сети.
• Возможность автоматически определять изменения, что обеспечивает совместное редактирование, определение авторства каждой строчки, автоматическое разрешение конфликтов, экономное хранение истории и удобство для автоматической обработки.

Конечно, идея хранить документы в плоском тексте, с использованием некоторого языка разметки далеко не нова. Известны и достаточно широко распространены такие языки разметки текстовых документов, как SGML Docbook, HTML/XHTML, LaTeX. Однако они сложны для изучения (много элементов, нетривиальный синтаксис), в них возможны трудноуловимые ошибки. И если работников софтверной компании (разработчиков, технических писателей, аналитиков, тестировщиков, менеджеров) еще можно обучить этим технологиям, то почти всех представителей заказчика это просто пугает.

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

Теперь рассмотрим преимущества правки и публикации «по месту»:

• Для практически всех языков разметки, кроме HTML, нет WYSIWYG-программ просмотра — необходима конвертация в DVI, PostScript, PDF, RTF или тот же HTML, что обычно требует существенного времени.
• Публикация по месту позволяет вносить правки в процессе чтения материала (не нужно искать исходные тексты).
• Немедленная публикация позволяет сразу же проверить внесенные правки.

Следующий момент — облегчение построения гиперссылок. Стандартные языки разметки (TeX, LaTeX, SGML) разделяют идентификаторы и названия структурных блоков (секций, глав, разделов), что способствует строгой целостности, но затрудняет само внесение ссылки.

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

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

В результате, наблюдаются следующие позитивные моменты:

• Совместное редактирование влечет совместную ответственность за качество текста.
• Вырабатывается культура обсуждений и поиска правильного решения.
• «Эффект взбивания сливок» — легкость редактирования, к тому же любым участником, ведет к многократным итерациям, что улучшает качество текста.
• Легкость порождения статей способствует фиксации больших объемов знаний («главное — начать»).

Как мы уже говорили, в нашей компании мы применяем вики-системы на основе MediaWiki. Разумеется, в них мы держим исключительно внутреннюю уникальную информацию, не дублируя знания доступные в интернете (пусть их там поддерживает в актуальности кто-нибудь другой): описания внутренних технологий, регламентов, инструкций, «FAQ»-списки, библиотека, личные странички сотрудников с квалификационными профилями и т. п (см. Рис. 6).

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

У нас несколько вики-систем, в частности, для каждого заказчика мы заводим отдельную вики-систему, где совместно с заказчиком формулируем постановки задач и иные требования и даже ведем часть документации. Мы реализовали некоторое количество доработок к MediaWiki, сильно облегчающих нам жизнь (см. ), большая часть которых — системы публикации нетривиальных объектов по текстовым описаниям: автоматическое построение графов (Graphviz), столбчатые и ленточные диаграммы, синтаксическая раскраска кода, математика в TeX/LaTeX.

Рис.7. Некоторые наши доработки к MediaWiki

Также реализованы голосования, массовое редактирование статей, подписка на статью других пользователей, репликация статей между вики-системами, экспорт и импорт из офисных редакторов. Для «оффлайн»-пользователей (например сотрудник с ноутбуком в командировке) сделана локальная (portable) инсталляция MediaWiki.

Отдельно хотелось бы отметить доработку, расширяющую «базу знаний» до практически полноценной системы дистанционного обучения — система проверочных тестов (см. ). Мы обнаружили, что для надежной передачи знаний, даже вроде с виду простых, как инструкция или регламент на пару страниц, необходимо дополнять текст проверочными вопросами-тестами. В первую очередь, конечно, это необходимо самому читателю, чтобы проверить, правильно ли он понял прочитанное. Но также может использоваться для внутренних сертификаций («курсы молодого бойца» и т. п.). Разработка тестов очень трудоемка, и мы, конечно, не дублируем доступные в интернете для дистанционного обучения курсы, благо в последнее время таких становиться все больше (см. например, http://www.intuit.ru/).

OmniFind

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

Bonsai

Bonsai (http://bonsai.mozilla.org/) — веб-система доступа к репозитариям CVS, разработанная изначально для поддержки продуктов проекта Mozilla, но теперь общедоступная и open-source. Его средство «Query Tool» позволяет осуществлять поиск по содержимому репозитария (включая отдельные изменения), используя фильтр по множеству атрибутов. Выбранные результаты могут быть отсортированы и просмотрены в браузере в различных режимах: просто содержимое файла; раскрашенные и подсвеченные изменения для каждой версии (см. Рис. 8); аннотированный исходный текст, где каждая строка указана с её автором и в какой версии она появилась, а также комментарий к этой версии. Также на Рис. 8 показано, как по ссылке «Look for Bug in CVS» происходит выборка всех изменений в репозитарии, связанных с этим багом (все CVS-коммиты^[8] проверяются на привязку к багам), и наоборот, по ссылке с каждого изменения можно перейти из Bonsai на соответствующий баг в Bugzilla.

Рис.8. Bonsai — переход от бага к коду и обратно

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

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

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

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

Как мы уже говорили, описанные нами инструменты возможно уже не оптимальны, в частности, для старта с «чистого листа» с минимальными затратами разумно использовать появившиеся open-source комплекты (трекер+вики+SCM):

Trac

http://trac.edgewall.org/

Redmine

http://www.redmine.org/

CVSTrac

http://cvstrac.org/

RoundUp

http://roundup.sourceforge.net/

Аналогов (как бесплатных, так и коммерческих) трекеров, вики-систем, и SCM по отдельности сейчас появилось великое множество, и чтобы не перечислять их здесь, мы рекомендуем посетить регулярно обновляемые статьи:

• http://en.wikipedia.org/wiki/Comparison_of_wiki_software
• http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
• http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Заключение

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

За бортом нашего обзора осталось немало других, интересных и используемых нами open-source инструментов поддержки разработки и тестирования, таких, как CruiseControl для поддержки технологии Continuous Integration, системы юнит-тестов, средства эффективного документирования и многое другое. Надеюсь, мы сможем рассказать о них в другой раз.

Примечания

1. ↑ Статья написана в 2007, к конференции SECR-2007, опубликована с сокращениями в «Открытые системы», февраль 2008
2. ↑ Карго-культ возник на островах Меланезии после Второй Мировой войны, когда туземцы, чтобы вернуть американские транспортные самолёты, привозившие во время войны прочную одежду и вкусную еду, выстроили из соломы и глины макеты аэродромов и самолетов, и изо всех сил копировали видимое им поведение аэродромной обслуги — по полям-аэродромам бродили туземцы-сигнальщики «заманивающие» самолёты жестами, на соломенных вышках сидели туземцы-«радисты» в наушниках из глины и с надписями «USA» на спине.
3. ↑ Да, ранее это были некие «безымянные» методики, основанные на творческом переосмыслении принципов экстремального программирования и упрощенного клиент-ориентированного проектного управления (итерационное развитие макета по приоритетным направлениям заказчика). Но в последний год, обнаружив, что наши подходы очень близки к SCRUM, мы переходим именно на этот принцип. Известность и модность SCRUM облегчает нам привлечение и разработчиков и заказчиков, да и упрощает взаимодействие между ними. Впрочем, применение SCRUM выходит за рамки данной темы, и здесь не рассматривается, а всё сказанное будет вполне применимо к любой гибкой модели организации разработки ПО.
4. ↑ OmniFind не является open-source-системой, но он совершенно бесплатен, и допускает некоторую адаптацию, вполне достаточную для наших целей. К моменту его выбора, других бесплатных поисковиков-аналогов, понимающих русскую морфологию, не было.
5. ↑ Bug обычно стандартное обозначение для программной ошибки, однако выбор названия чисто условный — систему можно настроить так, чтобы использовать вместо слова «Bug» более общий термин, например «Issue» или «Problem». Но мы привыкли и не стали менять.
6. ↑ Да, конечно MS Excel нельзя отнести к open-source или бесплатным средствам, однако на данный момент он очень распространен, а функциональность и удобство просмотра локальных OLAP-кубов вполне оправдывает его стоимость.
7. ↑ Символьный текст без форматирования, разбитый на строки небольшой длины.
8. ↑ Commit — иногда checkin, операция фиксации локальных правок в репозитарии.

Дополнения

• Слайды выступления с докладом по этой теме на SECR-2007.
• Свободное программное обеспечение
• Библиотека свободного софта

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».