Технологии коллективной разработки программного обеспечения. а).Последняя группа Асcура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует две основные модели организации коллектива при разработке ПО:

– Иерархическая модель. определяет начальников и подчиненных, т.е – это структура с вертикальной формой управления (контроля) элементами, входящими в неё. Фактически это пирамида, каждым уровнем которой управляет более высокий уровень. Можно выделить следующие недостатки иерархической модели:

§ нехватка информации на различных уровнях;

§ невозможность учесть все особенности проекта;

§ отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении – вверх по иерархии, к главному менеджеру;

§ трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;

§ сложность расстановки приоритетов.

– Модель проектной группы. В проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы - каждый за свой участок.

Можно выделить следующие недостатки модели группы:

§ разрозненная связь с внешними источниками информации;

§ несогласованное представление о разных сторонах проекта;

§ несогласованность личных планов членов группы;

§ отсутствие опыта, снижающее эффективность коллективной работы.

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

Рисунок 1 – Роли в модели проектной группы

Каждая ролевая группа выполняет свои задачи:

«Архитектура»

§ формулирует спецификацию решения и разрабатывает его архитектуру;

§ определяет структуру развертывания (внедрения) решения.

«Разработка»

§ определяет детали физического дизайна;

§ оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;

§ разрабатывает или контролирует разработку элементов;

§ подготавливает продукт к внедрению;

§ консультирует команду по технологическим вопросам.

«Тестирование»

§ обеспечивает обнаружение всех дефектов;

§ разрабатывает стратегию и планы тестирования;

§ осуществляет тестирование.

«Управление выпуском»

§ представляет интересы отделов поставки и обслуживания продукта;

§ организует снабжение проектной группы;

§ организует внедрение продукта;

§ вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;

§ организует сопровождение и инфраструктуру поставки.

«Удовлетворение потребителя»

§ представляет интересы потребителя в команде;

§ организует работу с требованиями пользователя;

§ определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;

§ определяет требования к системе помощи и её содержание;

§ разрабатывает учебные материалы и осуществляет обучение пользователей.

«Управление продуктом»

§ выступает в роли представителя заказчика;

§ организует работу с требованиями заказчика;

§ формирует ожидания заказчика;

§ формирует общее видение и рамки проекта;

§ определяет компромиссы между параметрами "возможности продукта / время / ресурсы";

§ организует маркетинг;

§ разрабатывает, поддерживает и исполняет план коммуникаций.

Влияние на успех группы такого важного фактора, как состав команды, выявили М. Белбин и его коллеги. Было проведено исследование нескольких сотен небольших групп в процессе их деятельности. Учёные определили, что поведение членов групп соответствует одной из девяти выделенных ими в ходе исследования ролей (Таблица 1).

Таблица 1 – Типология командных ролей М. Белбина

Виды командных ролей	Необходимые личностные качества и вклад в деятельность команды	Допустимые недостатки
Мыслитель (генератор идей)	Творческая направленность, богатое воображение, неординарность мышления. Стремление к новаторству. Источник оригинальных идей для команды.	Недостаточность опыта межличностного общения. Психологическая неустойчивость. Может долго задерживаться на рассмотрении "интересных идей".
Исполнитель	Претворяет идеи в практические действия. Превращает решения в легко выполнимые задания. Вносит упорядоченность в деятельность команды.	Недостаточная гибкость. Неприязнь к фантастическим идеям. Неприязнь к частым изменениям планов.
Доводчик	Усердие и добросовестность. Следит за тем, чтобы задания выполнялись полностью. Отслеживает своевременность выполнения заданий.	Чрезмерная обеспокоенность состоянием дел. Склонность к внутренним переживаниям. Нежелание перепоручать свои обязанности. Неприятие несерьезного отношения к его обязанностям со стороны других.
Оценщик (эксперт)	Исповедует беспристрастный критический анализ ситуации. Стратегический подход и проницательность в оценках. Точность суждений, стремление рассматривать все возможные варианты решения.	Недооценка факторов стимулирования и воодушевления. Недостаточность вдохновения и творческого воображения. Способность сбивать других, подавляя их инициативу.
Исследователь ресурсов	Владение искусством проведения переговоров, разнообразие контактов. Талант импровизатора, изучает благоприятные возможности. Энтузиазм, коммуникабельность.	Теряет интерес по мере угасания энтузиазма. Перескакивает от одной задачи к другой. Нуждается в повышенном внешнем давлении.
Формирователь	Постоянная ориентированность на решение поставленной задачи; стимулирует работу всей команды. Способствует реализации принятых решений; побуждает сотрудников работать интенсивнее. Энергичность, стремление к превосходству и работе с полной отдачей сил.	Легко переходит к состоянию раздражительности. Импульсивность и нетерпеливость. Нетерпимость к нечетким формулировкам и нерешительности в поведении. Результат - любой ценой.
Коллективист	Способствует гармонизации отношений в команде и устранению разногласий. Внимательно выслушивает собеседника; опирается на мнения других. Чуткость, отсутствие чрезмерной самоуверенности.	Нерешительность в кризисных ситуациях. Стремление избегать обострения ситуаций. Может воспрепятствовать совершению действий в решающий момент.
Председатель (координатор)	Четко формулирует цели; хорошо выполняет функции ведущего во время дискуссий. Способствует эффективному принятию решений. Имеет хорошие коммуникативные навыки; социальный лидер.	Может производить впечатление человека, склонного к манипуляциям. Склонность к переложению своих обязанностей на других. Может приписывать себе заслуги всей команды.
Специалист	Обладает редко встречающимися навыками и знаниями. Целеустремленность и способность концентрировать усилия. Инициативность и способность всецело отдаваться работе.	Полезен только в узкой профессиональной сфере. Зачастую слабые коммуникативные навыки. Иногда, образно выражаясь, "не видит леса за деревьями".

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

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

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

§ описание возможностей продукта (что продукт позволяет сделать);

§ конкретизацию продукта (описание функциональных возможностей данной версии);

§ описание путей реализации проекта.

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

– Ориентация на продукт и понимание целей заказчика, нацеленность на результат.

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

§ обучение на опыте других проектов;

§ изучение методологии;

§ изучение технологий.

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

Можно выделить следующие этапы развития команды:

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

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

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

4. Четвертый этап – отдача. Наконец-то можно получить дивиденды за потраченные усилия. Команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов. Люди хотят и могут совершенствоваться, они более всего заинтересованы в профессиональном росте. Растет значение нематериальной мотивации сотрудников, а оценивать и поощрять материально лучше команду в целом. Если четвертый этап достигнут, значит, команда создавалась не зря.

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

– групповая работа над кодом, документами;

– учет проблем, ошибок, требований;

– документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;

– организация правильного тестирования.

Работа средств коллективной разработки основана на выполнении двух базовых функций:

– Ведение общей для всех разработчиков базы данных проекта, содержащей историю изменений в каждом файле проекта.

– Автоматизация следующих операций:

§ доступа к общей базе данных;

§ обработки конфликтующих версий файла;

§ именования различных версий файла;

§ ввода и сохранения комментариев к изменениям.

Формирование рабочих коллективов и выбор программного проекта вещи взаимосвязанные. В данном курсе даётся возможность студентам сначала «собрать команду», а потом выбрать проект. Группы, работающие над проектом должны состоять из 3-5 человек. Группы менее 3 человек, не позволят студентам получить навыки коллективной работы над проектом. Группы более 5 человек требуют более сложной координации и допустимы для уже сложившихся творческих коллективов.

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

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

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

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

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

1. Руководитель проекта назначает секретаря и оглашает заранее подготовленную повестку собрания и краткий отчет о текущем состоянии проекта. (~5 минут).

2. Участники собрания вносят замечания. В результате формируется окончательная повестка собрания. (~5 минут).

3. Собрание идет согласно выработанной повестке. Заслушиваются отчеты разработчиков о проделанной работе, включая отчеты об исправлении замечаний, и выполняется анализ текущей документации и других артефактов. Обсуждаются и определяются дальнейшие направления и задачи. (~35–70 минут).

4. Подведение итогов. Распределение задач, назначение ответственных и т.п. (~10 минут).

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

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

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

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

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

Существуют два варианта бригад:

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

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

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

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

Формирование специализированных бригад (из специалистов одного профиля). Результат работы отдельной бригады не всегда представляет собой конечный результат разработки.

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

Если из-за сложности и масштабности разработки требуется большое число исполнителей и организация нескольких бригад, то рекомендуется:

Рассмотреть вопрос о специализации бригад по функциональному признаку;

Желательно выделить ведущую, главную бригаду. Эта бригада выполняет наиболее существенное задание и как можно больше участвует в жизненном цикле. Бригаде даются другие бригады соисполнители (которые могут быть со своим ТЗ).

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

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

Все множество разработок в зависимости от количества участников и типов взаимоотношений между ними может быть сведено к триаде разработок, приведенной на рис. 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) "Собор и Базар". Общинная модель характеризуется тремя основными факторами.

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

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

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

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