Принципы и методы коллективной разработки программных продуктов. Часто обменивайтесь информацией – но не слишком часто. Система синхронизации удаленных пространств

Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок, приведенной на рис. 3.21.

Люблю одиночество, даже когда я один.
Ж. Ренар

Этот принцип был достаточно широко распространен в 70-80-е годы XX века. Сейчас он применяется редко.

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

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

Объем программного продукта, выполненного методом авторской разработки, в 5-20 раз меньше по сравнению с индустриальными аналогами.

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

2. Коллективная разработка

Собрать стадо из баранов легко, трудно собрать стадо из кошек.
С. П. Капица

Одним из основных вопросов коллективной разработки является разделение труда - от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста).

2.1. Технические командные роли

Равноправные соисполнители

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

• инженеры-разработчики (специалисты по инженерии программирования и программисты);
• технические писатели;
• инженеры тестирования;
• инженеры качества;
• специалисты по сопровождению продукта;
• специалисты по продажам продукта.

Тип работы определяет содержание и природу выполняемой работы. Приведем список типов работ и областей специализации на основе классификации Конгер .

• Разработка приложений.
• Программист.
• Специалист по инженерии программирования.
• Специалист по инженерии знаний.
• Работа с приложениями.
• Специалист по приложениям.
• Администратор данных.
• Администратор базы данных.
• Техническая поддержка.
• Системный администратор.
• Сетевой администратор.
• Администратор коммуникаций,
• Обеспечение качества продукта.
• Технический писатель.
• Инженер тестирования.
• Инженер качества.
• Маркетинг.
• Специалист по сопровождению продукта.
• Специалист по продажам продукта.
• Системное интегрирование.
• Системный интегратор.

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

Бригада главного программиста

- Почему бригада скорой помощи состоит из двух врачей?
- Один знает - куда ставить клизму, а другой - зачем!
Анекдот о специализации в команде

Харлан Миллз [Брукс 1999] предложил организовывать команды (бригады) главного программиста (chief programmer teams), подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку. Бригада главного программиста включает десять человек, выполняющих специализированные роли в команде (рис. 3.22).

Основные члены бригады выполняют функции, перечисленные ниже.

• Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.
• Дублер. Может выполнять любую работу главного программиста, но менее опытен. Подстраховывает главного программиста, может заниматься написанием кода, но не несет ответственности за проект.
• Администратор, он же - менеджер. Под его контролем - деньги, люди, помещения, машинные ресурсы, контакты с другими группами и руководством.
• Редактор. Фактически, это технический писатель. Его задача - критически переработать черновики документации (созданные главным программистом), снабдить их ссылками и библиографией и обеспечить публикацию или помещение в Интернете.
• Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.
• Инструментальщик. Разработчик специализированных инструментов - утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование операционной системы.
• Отладчик. Разработчик тестов и организатор тестирования программного продукта.
• Делопроизводитель. Отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Благодаря делопроизводителю, активные программисты освобождались от рутинных работ. Заметим, что в настоящее время функции делопроизводителя автоматизированы и переданы репозиторию проекта.

2.2. Психологические командные роли

Роб Томсет (Rob Thomsett) предложил восемь ключевых ролей в проекте (рис. 3.23).

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

В реальных командах программистов могут быть выделены не все из этих ролей. Роль исполнителя часто берут на себя сразу несколько членов команды.

2.3. Типы совместной деятельности

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

• Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а присутствие на них обязательно. Статистика показывает, что программисты проводят около 4% своего рабочего времени на собраниях.
• Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабочего времени.
• Естественная совместная деятельность имеет место, когда как минимум двое программистов работают над одной и той же задачей одновременно и обмениваются информацией о выполняемой работе. Эта деятельность занимает около 41% рабочего времени.
• Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.

3. Общинная модель разработки

Совершенство в проекте достигается не тогда, когда нечего добавить,
а тогда, когда нечего убрать.
Антуан де Сент-Экзюпери

Идеология общинной ("базарной") модели разработки сформулирована в программной статье Эрика Раймонда (Eric Raymond) "Собор и Базар". Общинная модель характеризуется тремя основными факторами.

• Децентролизованность разработки. Не существует ограничения сверху на количество людей, принимающих участие в проекте. Как правило, разработки такого типа ведутся на базе сети Интернет и могут включать любого заинтересованного разработчика Сети.
• Разработка ведется на базе открытых исходных текстов. По ним можно разобраться с сутью задачи и в любой момент подключиться к разработке.
• Большое количество внешних тестеров (бета-тестеров), позволяющих быстро обнаруживать ошибки и проблемы в программе.

Эрик Рэймонд сформулировал несколько уроков, которые позволяют лучше понять особенности общинной разработки.

• Каждая хорошая программа начинается с энтузиазма разработчика.
• Хорошие программисты знают, что можно написать, а великие - что можно переписать.
• При правильном отношении интересная проблема найдет вас сама.
• Когда вы теряете интерес к программе, ваша последняя обязанность - передать ее компетентному преемнику.
• Следует выпускать ранние и частые версии программ.
• Обнаружить проблему и исправить ее могут разные люди.
• Иногда использовать идеи пользователей лучше, чем свои идеи.

Есть системные пометки.

30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. 3 Июль 2015, 11:03

30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. В нем приняли участие сотрудники ФПИ, ООО «Рексофт», ЗАО «Топ Системы», АО «Системы управления», АО «Объединенная приборостроительная корпорация», ОАО «Объединенная авиастроительная корпорация», ГК "Росатом", АО «Вертолеты России», ОАО «Объединенная ракетно-космической корпорация», ИТ кластера Сколково и других научных и производственных организаций ОПК, научные сотрудники институтов РАН, МГУ им.М.В.Ломоносова, ведущих технических ВУЗов, представители Минкомсвязи и Минпромторга России.

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

На заседании были утверждены: положение об общественном совете по реализации проектов в области коллективной разработки ПО, план заседаний общественного совета, сформирована рабочая группа по стандартизации, а также группы потребителей и образовательных учреждений. Участники совещания одобрили технологические принципы, заложенные в основу интегрированной инженерной программной платформы. Председателем общественного совета был избран заместитель генерального директора – руководитель направления информационных исследований Фонда перспективных исследований Сергей Гарбук. Заместителем председателя был избран заместитель генерального директора АО «Объединённая приборостроительная корпорация» Андрей Чендаров.

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

3. menu – меню. Реализовано в виде списка, причем каждый пункт может содержать подменю, которое тоже представляет собой список. Каждый элемент списка обязательно содержит текст (часто с горячей клавишей) и может содержать иконку 32*32, сочетание «горячих клавиш» для вызова элемента без вхождения в меню или символ 4. Сочетание icon+menu = Tool panel (Панель инструментов)

4. pointers – механизм индивидуальной настройки пользователя. Обозначается маленькой стрелкой в левом нижнем углу иконки. Пользователь может конфигурировать под себя любое количество указателей в любой папке и области.

Разработчик и архитектор в больших программах – разные люди.

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

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

19. Требования к программистам. Формирование команды программистов.

Требование к программистам и их оценка

1. Уровень образования

По учреждению выясняются возможности

Тестирование знаний

Резюме – представление опыта программистов, характеризующее его возможное применение.

На производительность влияют:

1. Наличие амбиций человека (собственная оценка своих качеств и себя в коллективе)
2. Уровень притязания. Самооценка может быть источником конфликтов в коллективе.
3. Коммуникабельность! при сдаче проекта.

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

20. Организация процесса работы команды программистов (персональная организация и коллективная работа).

Осуществляет руководитель проекта.

Опытный руководитель распараллеливает работы. Идет пересечение этапов.

По каждому этапу четко сформулирован результат. Если результата нет, то этап не завершен.

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

Документация создается с начала реализации проекта. Оформляется в соответствии с ГОСТом (ISO) или с корпоративными стандартами документациями.

Удобно использовать маршрутный лист.

Достоинства подхода:

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

2. документация отражает текущее состояние работы над проектом

3. при окончании проекта требуется минимум усилий для оформления документации для передачи заказчику.

Организация персональной работы программиста

Менеджер планирует работу программисту, формулирует суть работы, сроки. Ежедневный самоотчет о проделанной работе позволяет менеджеру лучше планировать рабочее время программиста. Написание самоотчета занимает от 15 до 30 минут в день, но дисциплинирует программиста и дает возможность менеджеру перепланировать работу так, чтобы успеть.

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

Организация коллективной работы

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

«Рабочая тетрадь». Все проектные решения документируются в рабочую тетрадь. Иногда размер всех рабочих тетрадей по проекту достигал толщины в 1 м.

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

Версия 0 является версией, готовой в бета-тестированию.

Согласование работ:

1. Распараллеливание работ

2. Сетевое планирование

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

1. MS Outlook
2. Time manager
3. MS Project – управление ресурсами, планирование с дискретностью от часа до месяца. Позволяет работать удаленным пользователям надо удаленным проектом.

21. Планирование работы команды программистов. Эффект второй системы.

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

1. Шифр, номер работы
2. Описание выполнения
3. Время окончания
4. Результат, если работа окончена.

Отслеживает эту информацию менеджер группы.

По оценкам 28-33% времени программист пишет программу. Остальное – совещания, согласования, поиск литературы, обучение, координация с программистами, пишущими совместные с его модулями – 60%.

Задача менеджера – минимизировать 60% так, чтобы увеличить время работы программиста над программой. Если менеджер хороший, то он сможет снизить 60% до 50%.

Критическая ситуация – проект не успевает по срокам:

В этом случае возможны следующие шаги:

1. увеличить число программистов на проект (зачастую только усугубляет положение);
2. на существующем количестве перераспределить работу, ввести дополнительное время;

Эффект второй системы

Часть фирм планируют разработку системы на «выброс», чтобы получить представление о трудностях, ошибках, проверить основные идеи, а после разрабатывать вторую систему.

22. Работа с заказчиком.

Специфическая функция взаимодействия с потенциальным или реальным потребителем ПП.

1. 1 Заказчик, 1 Разработчик
2. Заказчик объявляет тендер на разработку. Выигрывает фирма, которая либо уменьшает стоимость разработки, либо за эту же сумму предоставляет больше возможностей. Играет роль имидж компании (участие и завершение аналогичных разработок, участие в семинарах, совещаниях по теме, открытость компании).

Преимущества:

Заказчик в курсе всей работы

Тестирование параллельно с написанием

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

Системы разделения файлов

Для поддержки коллективной работы с файлами применяются три основных класса систем.

Системы управления версиями файлов.

Системы управления пространствами пользователей.

Системы синхронизации удаленных пространств.

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

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

Поскольку данные системы действительно очень важны, их реализации существуют в большом количестве практически для всех операционных систем. Приведем два стека таких систем (табл. 5.2).

Таблица 5.2. Примеры средств поддержки коллективной разработки

Система управления версиями файлов

Система управления версиями файлов предназначена для отслеживания изменений между различными версиями файлов и разделения доступа к ним. Файлы обычно содержат программы на языках программирования и тексты.

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

Как и все широко распространенные программы утилита SCCS имеет надстройки в виде графического интерфейса, например утилиту vertool.

Система управления пространствами

Система управления рабочими пространствами пользователей предназначена для обмена результатами работы между отдельными разработчиками через объединение результатов в выделенном рабочем пространстве. Система работает на основе модели "копирование-изменение-слияние" и понятия "рабочее пространство".

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

Модель "копирование-изменение-слияние" отражает схему организации работы с пространствами. Основная последовательность действий такова:

Создается основное мастер-пространство, от которого разработчики порождают свои рабочие пространства.

После внесения изменений в своем рабочем пространстве разработчик передает их в мастер-пространство.

Все разработчики периодически обновляют свои рабочие пространства из мастер-пространства.

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

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

Система синхронизации удаленных пространств

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

Для осуществления пересылки можно воспользоваться стандартными средствами Интернета - электронной почтой или утилитой ftp. Для облегчения синхронизации следует завести два дополнительных пространства-порта и выполнять их синхронизацию (например, при помощи семафоров). Утилиты, выполняющие пересылку, должны тщательно сверять контрольные суммы, чтобы убедиться в корректности полученной информации. Естественно, в пересылаемый пакет информации входят только инкрементальные изменения (дельты), а не измененные файлы целиком.

Системы поддержки работы виртуальных групп

Общение в виртуальных группах очень часто осуществляется через Интернет, а в качестве средств общения выступают традиционные и хорошо известные средства, такие как:

видеоконференции;

аудиоконференции;

средства группового общения в реальном времени (чаты);

средства группового общения с разным временем подключения (доски объявлений, форумы);

электронная почта (включая списки рассылки, архивы и поиск по ним). Однако все перечисленные средства имеют определенные недостатки. Например, видео- и аудиоконференции не позволяют передавать файлы, а средства группового общения в Интернете не обеспечивают секретности от доступа любых других пользователей с одной стороны и позволяют разработчикам выступать анонимно с другой стороны.

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

Необходимость регистрации пользователя при его входе в систему.

Сохранение всей переписки и прочих данных в архиве.

Использование системы управления версиями текстов для программ и документации.

Классификация систем поддержки работы групп по предоставляемым ими возможностям общения была предложена Бобом Йохансеном (Bob Johansen).

В одно и то же время, в одном и том же месте (same time, same place).. Это классический случай, когда разработчики имеют возможность встречаться в одном помещении в определенное время. Здесь оказываются полезными следующие системы поддержки:

• система упорядочивания доступа к данным для показов видеозаписей, слайдов и других документов;

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

В одно и то же время, в разных местах (same time, different place). Системы должны обеспечивать общение в реальном времени. Для этого обычно применяются средства аудио- и видеоконференций.

В разное время, в одном и том же месте (different time, same place). Это довольно редкая ситуация, когда существует комната группы, но разработчики не имеют возможности собраться в ней в одно и то же время. Разработчику должна быть предоставлена возможность доступа к репозиторию проекта и всей информации, доступной на данном этапе проекта.

В разное время, в разных местах (different time, different place). Системы реализуют возможности ведения конференций, форумов и чатов с асинхронным подключением, возможность доступа к репозиторию проекта.

Неограниченные возможности доступа к данным (anytime, anyplace). Эта категория оставлена автором классификации на дальнейшее развитие коммуникационных технологий, когда возможности доступа к данным станут практически неограниченными.

Обратим внимание на то, что часто тип систем поддержки работы виртуальных групп зависит от рода их деятельности.

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

Группы проекта. Разработчикам требуется максимально возможное количество средств общения и доступа к репозиториям.

Группы сопровождения. Группам необходимы средства связи и быстрый доступ к данным из любого места.

Приведем несколько наиболее известных систем поддержки виртуальных групп:

Facilitate.com (компании Facilitate.com (http://www.facilitate.com/ ));