Введение
На сегодняшний день написано много книг о том, как управлять людьми и деятельностью, программным кодом и оборудованием для построения связи с клиентами или субподрядчиками. Существует много работ экспертов – гуру, а также ряд методологий и стандартов сертификации, таких как ITIL, PMBOK, SWEBOK, RUP, CMMI и т. д [1].
К сожалению, универсального решения пока не найдено. Прежде всего, большинство концепций предполагают слишком формализованные процессы. Эта формализация, вероятно, оправдана в обществах, где разработка программного обеспечения не является бизнесом, а ИТ – отдел является сервисным подразделением, эффективность которого практически не влияет на прибыльность организации. Но для софтверных компаний чрезмерная формализация выражается в ненужных отчетах и процессах («часы», сбор данных для метрик, которые необходимы только для «контроля» и т. д.) [3].
На наш взгляд, это подавляет инициативу и снижает производительность труда. Кроме того, существует деструктивная демотивация сотрудников: самые влиятельные программисты и аналитики просто отказываются работать в таких условиях (или требуют вознаграждения в супермаркете), в то время как другие склонны молча саботировать «бюрократию». Во – вторых, описания самих методологий не отвечают на вопрос, какую систему автоматизации использовать для управления разработкой [2, С.15].
Конечно, на рынке есть сильные коммерческие продукты, которые, согласно любой методологии, требуют полного цикла автоматизации, но они дороги и даже если они автоматизированы, слишком формализованные процессы не подходят.
В результате поиска эффективных методов коллективной разработки программного обеспечения, которые с одной стороны обеспечивают прозрачность и управляемость, а с другой – минимальные накладные расходы, мы придумали минимальную модель информационных объектов в процессе разработки и соответствующий набор Системы с открытым исходным кодом для хранения этих объектов. Благодаря открытию исходного кода выбранные системы были интегрированы друг с другом и адаптированы к методам гибкой разработки, разработанным компанией. Долгое время мы обнаружили, что наши подходы очень близки к подходу Scrum, и мы перешли к нему, используя домашние методы, основанные на творческой переоценке принципов экстремального программирования и упрощенном ориентированном на клиента управлении проектами (разработка итеративного макета в приоритетных областях заказчика) [4].
Слава и мода Scrum облегчают привлечение разработчиков и клиентов и упрощают их взаимодействие. Еще одним преимуществом открытого исходного кода является, в дополнение к бесплатному использованию и простой настройке, то, что эти системы быстро учитывают текущие мнения большого сообщества разработчиков при их разработке, таким образом, транслируя успешные практики по всему миру.
Рис. 1. Информационные объекты в разработке программного обеспечения
Основная классификация возникающих информационных объектов в процессе разработки и сопровождения таможенных информационных систем может быть представлена в виде модели, показанной на рис. 1 [2].
Информационные объекты, аналогичные атрибутам, и методы работы с ними сгруппированы в три разных цветовые зоны. Например, пересекающаяся область, документация для программных продуктов, охватывает как созданные артефакты, так и базу знаний. На пересечении «зоны знаний» и «проблемной зоны» находится история решения проблем. Выбор информационных систем в соответствии с этим подходом требует, с одной стороны, полного охвата этих проблемных областей, а с другой стороны, сводит к минимуму количество конкурирующих информационных систем в каждой из этих областей. Предположим, мы вводим систему регистрации проблем в верхней красной зоне, другую для регистрации инцидентов, третью для запросов на регистрацию, несколько других систем регистрации и другую систему регистрации ошибок [2, С.108] .
В этом случае общая сложность поддержки и управления системой возрастет, обучение будет сложным, а пользовательская информация увеличена. В частности, пользователи просто потеряют себя в том, что система будет записывать что – либо между ошибкой и желанием пересмотра или запроса и приложения и т. д. В других областях ситуация аналогичная.
Системы должны обеспечивать максимальную производительность в коллективной работе, хотя за счет некоторых индивидуальных удобств – обязательно должно быть «лекарство от страха» в форме поддержки контроля версий и истории изменений. Например, это означает выбор систем контроля версий с возможностью параллельной работы без исключительных блоков и автоматической модификации изменений, а также максимально возможную замену текстовых процессоров для документов в двоичном формате на системы группового управления документами в простых текстовых тегах, таких как SGML Docbook, XHTML. XML, LaTeX и т. д [1].
Кроме того, требуется максимальная прозрачность и простота мониторинга процессов, что означает возможность быстрого поиска и отслеживания информационных объектов и их взаимосвязей через веб – интерфейс, получения ответов на такие вопросы, как «что с этим было сделано». ? »,« Какой код был изменен для исправления? Таких и таких ошибок? »,« Где история обсуждения этой проблемы и как долго она решалась? », Не говоря уже о простом поиске текст для ответов на вопросы «где ключи от офиса?» и «что делать, если возникает ошибка?» 0x8040459 в. Модули PM – BLACK – BOX? ».
Рис. 2. Покрытие проблемных зон системами – решениями
Для себя мы выбрали тот, который показан на рис. 2 – диаграмма покрытия проблемных областей, показанных на рис. 1. Бронируйте сейчас: наш выбор может быть не оптимальным сегодня – для каждой выбранной нами системы есть коммерческие и бесплатные аналоги, которые могут быть превосходного качества, но эта система работает для нас, может быть взята за основу и заменена отдельными компонентами более уместно. Пунктирный квадрат указывает область систем с веб – интерфейсом, в котором однонаправленные стрелки указывают на возможность гипертекстовых переходов между соответствующими объектами в этих системах. Двунаправленные стрелки показывают более сложную интеграцию перегрузки данных. Следует также отметить, что OmniFind не является системой с открытым исходным кодом, но она полностью бесплатна и допускает адаптацию, которая достаточна для наших целей, и до момента ее выбора не было других бесплатных аналоговых поисковых систем, включающих морфологию России.
Заключение
В настоящее время мы используем две системы контроля версий: CVS и SVN (Subversion). Многие проекты были собраны для CVS, но многие из них в настоящее время недостаточно развиты, и нет смысла преобразовывать их в SVN, а все новые проекты, находящиеся в стадии активной разработки, были преобразованы в SVN. Для тех, кто выбирает систему контроля версий с нуля, мы рекомендуем немедленно использовать SVN. Дружественный графический интерфейс TortoiseSVN (также бесплатный и с открытым исходным кодом) позволяет работать с Subversion даже с обслуживающим персоналом. А отсутствие «унаследованных» заболеваний CVS (например, невозможность изменить структуру файла без потери истории) позволяет исправлять любые ошибки, допущенные неопытными сотрудниками в хранилище. Рассмотренный подход позволяет автоматизировать командную работу в компании – разработчике с сотнями сотрудников, практически бесплатно.
Он предлагает гибкость и независимость от методологий. В частности, один и тот же инструментарий может включать в себя проектные работы, например, с использованием методологии SCRUM, и оперативные действия, такие как техническая поддержка в соответствии с рекомендациями ITIL. В дополнение к пересмотру, есть много других интересных инструментов для поддержки разработки и тестирования с открытым исходным кодом, таких как CruiseControl для поддержки непрерывной интеграции, мощные инструменты документирования и многое другое.
Список литературы / References
- Грей Клиффорд Ф, Ларсон Эрик У. Управление проектами. Практическое руководство: Пер. с англ. — М.: Изд. «Дело и сервис», 2003.
- Дюваль, П. М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / П. М. Дюваль. – М. : Вильямс, 2008. – 345 с.
- Федоров, В. К. Контроль и испытания в проектировании и производстве радиоэлектронных средств / В. К. Федоров, Н. П. Сергеев, А. А. Кондрашин. – М. : Техносфера, 2005. – 504 с.
Список литературы на английском языке / References in English
- A successful Git branching model [Электронный ресурс]. — URL: http://nvie.com/posts/a – successful – git – branching – model (датаобращения: 15.11.2015)
- Scott Chacon. Pro Git / Scott Chacon, Ben Straub. — New York: Apress, 2009. 598 p.
- Susan Potter. Архитектура приложений с открытым исходным кодом / Susan Potter — New York: O’Reilly, 2013.
- CI Feature Matrix [Электронный ресурс]. – URL: http://confluence.public. thoughtworks.org/display/CC/Cl+Feature+.
