ОСОБЕННОСТИ ИСПОЛЬЗОВАНИЯ СИСТЕМ КОНТРОЛЯ ВЕРСИЙ И УПРАВЛЕНИЯ СОВМЕСТНОЙ РАЗРАБОТКИ В ОТДЕЛЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

21 мая 4:49

Введение

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

К сожалению, универсального решения пока не найдено. Прежде всего, большинство концепций предполагают слишком формализованные процессы. Эта формализация, вероятно, оправдана в обществах, где разработка программного обеспечения не является бизнесом, а ИТ – отдел является сервисным подразделением, эффективность которого практически не влияет на прибыльность организации. Но для софтверных компаний чрезмерная формализация выражается в ненужных отчетах и ​​процессах («часы», сбор данных для метрик, которые необходимы только для «контроля» и т. д.) [3].

На наш взгляд, это подавляет инициативу и снижает производительность труда. Кроме того, существует деструктивная демотивация сотрудников: самые влиятельные программисты и аналитики просто отказываются работать в таких условиях (или требуют вознаграждения в супермаркете), в то время как другие склонны молча саботировать «бюрократию». Во – вторых, описания самих методологий не отвечают на вопрос, какую систему автоматизации использовать для управления разработкой [2, С.15].

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

В результате поиска эффективных методов коллективной разработки программного обеспечения, которые с одной стороны обеспечивают прозрачность и управляемость, а с другой  –  минимальные накладные расходы, мы придумали минимальную модель информационных объектов в процессе разработки и соответствующий набор Системы с открытым исходным кодом для хранения этих объектов. Благодаря открытию исходного кода выбранные системы были интегрированы друг с другом и адаптированы к методам гибкой разработки, разработанным компанией. Долгое время мы обнаружили, что наши подходы очень близки к подходу Scrum, и мы перешли к нему, используя домашние методы, основанные на творческой переоценке принципов экстремального программирования и упрощенном ориентированном на клиента управлении проектами (разработка итеративного макета в приоритетных областях заказчика) [4].

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

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

 

Основная классификация возникающих информационных объектов в процессе разработки и сопровождения таможенных информационных систем может быть представлена ​​в виде модели, показанной на рис. 1 [2].

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