Разработка программного обеспечения, кроме достаточно сложного технического аспекта, имеет сложный организационный или даже психологический аспект.
Так известно, например, что потребности заказчика всегда достаточно сложно определить полностью в какие-то начальные моменты разработки и даже после обследования. Это влечет за собой большое количество незапланированных работ, что отрицательно сказывается на качестве продукта.
Вопрос в том, как построить модель отношений заказчика и разработчика с учетом интересов обеих сторон и без потери качества?
Каждая сторона состоит из независящих функционально ролей. Каждая роль может включать в себя несколько человек. Роли совместимы только внутри сторон.
Итак, сторона заказчика имеет следующие ключевые роли: менеджер продукта и бизнес-аналитик.
Менеджер продукта — это представитель разработчика у заказчика, он обязан представлять интересы заказчика у разработчика. Это главный источник информации как для заказчика, так и для разработчика, его цель — полное удовлетворение потребностей заказчика в рамках выделенных ресурсов.
Бизнес-аналитик — это представитель заказчика, ответственный за создание системы. Он досконально знает бизнес-процесс своего предприятия и обязан предоставлять полную и достоверную информацию.
Сторона разработчика : менеджер программы, аналитик, программист, тестировщик.
Менеджер программы — это главный технический специалист проекта, он является хранителем спецификации и заинтересован в ее минимальных изменениях во время разработки.
Аналитик формализует информацию, получаемую со стороны заказчика в виде моделей, он обязан уметь выявлять закономерности и делать правильные обобщения, анализировать и проектировать комплекс взаимосвязанных программ для реализации функций предметной области.
Программист — непосредственно кодировщик.
Тестировщик — специалист по тестированию, он отвечает за соответствие системы ее спецификации.
Сторона качества : бизнес-аналитик и технолог.
Бизнес-аналитик — специалист по предметной области вообще, независимо от конкретного предприятия.
Технолог — специалист по технологии, контролирующий правильность ее использования.
В реальности каждая сторона работает в противовес двум остальным и необходима для сохранения общего баланса.
Каждая роль может включать в себя несколько человек. Нужно учитывать, что при работе над большим проектом возникает проблема взаимодействия исполнителей между собой. Взаимодействие исполнителей друг с другом требует времени, что в определенной степени снижает производительность труда . Причем взаимное непонимание приводит к дополнительным затратам на последующих стадиях разработки, например, непонимание среди программистов приводит к дополнительным затратам на тестирование.
Проблема взаимодействия возникает уже при работе группы из четырех и более человек. Для управления их работой необходим руководитель.
Решением этой проблемы может стать организация бригад
, например бригады главного программиста
,если рассматривать на примере программистов.
Бригададолжна включать от 3 до 7 человек. Число 10 является верхней границей численности бригады. Это обусловлено требованием максимальной управляемости коллектива.
В бригаде в зависимости от квалификации выделяют следующих специалистов.
Руководитель бригады (например, главный программист) — это превосходно подготовленный, творчески мыслящий, наделенный организационными способностями специалист. Он выполняет работу верхнего уровня, в том числе распределение работы внутри бригады.
Заместитель руководителя бригады (например, старший программист) поддерживает тесную связь с руководителем бригады и дорабатывает более мелкие вопросы. При обсуждении проекта заместитель должен выступать в роли оппонента руководителю бригады.
Непосредственно исполнители (например, младшие программисты) — два или три "менее опытных" (но не "менее способных") специалиста. Они выполняют работу нижнего уровня, определенную руководителем бригады.
В большом проекте в состав каждой или нескольких бригад могут входить следующие специалисты.
Администратор отвечает за распределение времени, подбор кадров, размещение исполнителей, финансирование, поддержку связи с высшим руководством.
Библиотекарь ведет системную библиотеку, например, библиотеку модулей, используемых в оперативном режиме. Все изменения в программные модули вносит только библиотекарь. Он также ведет системную документацию — системный журнал.
Технический исполнитель (документатор) занимается написанием документации по проекту, что освобождает более квалифицированных специалистов от этой рутинной работы.
Секретарь выполняет обычную работу секретаря.
Опыт разработки крупных ПО показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы . Реализация подсистем должна выполняться отдельными группами специалистов. В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода).
Поэтому после первоначального определения функций, которые должно выполнять разрабатываемое ПО, проект распределяется между различными командами разработчиков (рис. 12.1).
Рис. 12.1. Группы специалистов, занятых в разработке ПО
(n — количество функций ПО)
При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.
Результатом стадии должны быть:
Общая информационная модель системы;
Глобальные функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
Точно определенные интерфейсы между автономно разрабатываемыми подсистемами (те данные, которые передаются между ними);
Построенные прототипы экранных форм, отчетов, диалогов (должен быть определен стандарт интерфейса пользователя).
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом.
Коллективные разработки часто сталкиваются с проблемами разделения ресурсов - файлов и каталогов и необходимости синхронизации времени и места.
Системы разделения файлов
Для поддержки коллективной работы с файлами применяются три основных класса систем.
Системы управления версиями файлов.
Системы управления пространствами пользователей.
Системы синхронизации удаленных пространств.
Если три класса систем выпускаются одним производителем, то часто каждая последующая система в этом списке использует предыдущую систему, выступая в качестве надстройки.
О системах управления версиями файлов следует использовать не только при коллективной, но и при индивидуальной (авторской) разработке для решения задачи отслеживания изменений между различными версиями. Мы помещаем информацию об этих системах в данном разделе лишь с целью подчеркнуть их полную незаменимость при коллективных разработках.
Поскольку данные системы действительно очень важны, их реализации существуют в большом количестве практически для всех операционных систем. Приведем два стека таких систем (табл. 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/ ));
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. 3 Июль 2015, 11:03
30 июня в МГТУ СТАНКИН состоялось заседание общественного совета по реализации проектов в области коллективной разработки программного обеспечения. В нем приняли участие сотрудники ФПИ, ООО «Рексофт», ЗАО «Топ Системы», АО «Системы управления», АО «Объединенная приборостроительная корпорация», ОАО «Объединенная авиастроительная корпорация», ГК "Росатом", АО «Вертолеты России», ОАО «Объединенная ракетно-космической корпорация», ИТ кластера Сколково и других научных и производственных организаций ОПК, научные сотрудники институтов РАН, МГУ им.М.В.Ломоносова, ведущих технических ВУЗов, представители Минкомсвязи и Минпромторга России.
Участники совещания отметили, что задачами общественного совета являются научно-техническая и технико-экономическая экспертиза планируемых и выполняемых проектов коллективной разработки ПО, участие в приёмке и подготовка предложений по внедрению результатов, полученных при выполнении проектов коллективной разработки ПО, подготовка предложений в органы исполнительной власти Российской Федерации, общественные и другие организации по вопросам повышения эффективности выполнения работ в области коллективной разработки ПО, подготовка предложений в организации по стандартизации, связанных с подготовкой новых и корректировкой существующих нормативных документов в области коллективной разработки ПО. Целью деятельности общественного совета является повышение эффективности выполнения проектов, направленных на решение проблем импортозависимости и обеспечения технологического лидерства страны на основе коллективной разработки отечественного программного обеспечения.
На заседании были утверждены: положение об общественном совете по реализации проектов в области коллективной разработки ПО, план заседаний общественного совета, сформирована рабочая группа по стандартизации, а также группы потребителей и образовательных учреждений. Участники совещания одобрили технологические принципы, заложенные в основу интегрированной инженерной программной платформы. Председателем общественного совета был избран заместитель генерального директора – руководитель направления информационных исследований Фонда перспективных исследований Сергей Гарбук. Заместителем председателя был избран заместитель генерального директора АО «Объединённая приборостроительная корпорация» Андрей Чендаров.
Кроме того, участники совещания решили, что требуется регулярное доведение информации по проекту «Гербарий» до заинтересованных сторон. В ходе проработки вопросов управления НСИ следует рассмотреть возможность использования современных международных стандартов и сформировать профиль требований, предъявляемых к ИПО, а также предложить инструментарий для управления требованиями. В части квалификационного тестирования поступило предложение проанализировать возможность использования сторонних продуктов, а также включить в сценарии нагрузочное тестирование. Замечено, что при лицензировании продуктов необходимо обеспечить вариант лицензирования по АРМ, а не только по пользователям. Также отмечено, что изложенные в ходе выступлений принципы являются актуальными и могут эффективно использоваться при разработке других типов программного обеспечения. Гарантией работоспособности решений на технологической платформе «Гербарий» являются обязательные для всех без исключения разработчиков механизмы валидации и квалификационного тестирования модулей. Предложенные к реализации механизмы коммерциализации и лицензирования призваны увеличить заинтересованность разработчиков и потребителей в переходе на данную технологическую платформу. Для реализации планов по импортозамещению в области инженерного ПО разработку программных средств управления полным жизненным циклом высокотехнологической продукции целесообразно осуществлять на базе предложенных технологических решений и принципов коллективной разработки.
Разработка программного обеспечения – это групповой процесс. Большинство программных продуктов рождается в результате коллективных усилий. Люди являются одной из главных составляющих, необходимых для производства программного продукта. При организации работы программистов важно учитывать не только их технические навыки, но и взаимодействие между ними.
Существует две основные модели организации коллектива при разработке ПО:
– Иерархическая модель. определяет начальников и подчиненных, т.е – это структура с вертикальной формой управления (контроля) элементами, входящими в неё. Фактически это пирамида, каждым уровнем которой управляет более высокий уровень. Можно выделить следующие недостатки иерархической модели:
§ нехватка информации на различных уровнях;
§ невозможность учесть все особенности проекта;
§ отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении – вверх по иерархии, к главному менеджеру;
§ трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;
§ сложность расстановки приоритетов.
– Модель проектной группы. В проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы - каждый за свой участок.
Можно выделить следующие недостатки модели группы:
§ разрозненная связь с внешними источниками информации;
§ несогласованное представление о разных сторонах проекта;
§ несогласованность личных планов членов группы;
§ отсутствие опыта, снижающее эффективность коллективной работы.
При разработке программного обеспечения выполняемые задачи распределяются по семи ролевым группам и шести ролям. Участники команды, выполняющие конкретную роль, должны рассматривать проект с точки зрения своей специализации и обладать необходимой квалификацией.
Рисунок 1 – Роли в модели проектной группы
Каждая ролевая группа выполняет свои задачи:
«Архитектура»
§ формулирует спецификацию решения и разрабатывает его архитектуру;
§ определяет структуру развертывания (внедрения) решения.
«Разработка»
§ определяет детали физического дизайна;
§ оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна;
§ разрабатывает или контролирует разработку элементов;
§ подготавливает продукт к внедрению;
§ консультирует команду по технологическим вопросам.
«Тестирование»
§ обеспечивает обнаружение всех дефектов;
§ разрабатывает стратегию и планы тестирования;
§ осуществляет тестирование.
«Управление выпуском»
§ представляет интересы отделов поставки и обслуживания продукта;
§ организует снабжение проектной группы;
§ организует внедрение продукта;
§ вырабатывает компромиссы в управляемости и удобстве сопровождения продукта;
§ организует сопровождение и инфраструктуру поставки.
«Удовлетворение потребителя»
§ представляет интересы потребителя в команде;
§ организует работу с требованиями пользователя;
§ определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта;
§ определяет требования к системе помощи и её содержание;
§ разрабатывает учебные материалы и осуществляет обучение пользователей.
«Управление продуктом»
§ выступает в роли представителя заказчика;
§ организует работу с требованиями заказчика;
§ формирует ожидания заказчика;
§ формирует общее видение и рамки проекта;
§ определяет компромиссы между параметрами "возможности продукта / время / ресурсы";
§ организует маркетинг;
§ разрабатывает, поддерживает и исполняет план коммуникаций.
Влияние на успех группы такого важного фактора, как состав команды, выявили М. Белбин и его коллеги. Было проведено исследование нескольких сотен небольших групп в процессе их деятельности. Учёные определили, что поведение членов групп соответствует одной из девяти выделенных ими в ходе исследования ролей (Таблица 1).
Таблица 1 – Типология командных ролей М. Белбина
| Виды командных ролей | Необходимые личностные качества и вклад в деятельность команды | Допустимые недостатки |
| Мыслитель (генератор идей) | Творческая направленность, богатое воображение, неординарность мышления. Стремление к новаторству. Источник оригинальных идей для команды. | Недостаточность опыта межличностного общения. Психологическая неустойчивость. Может долго задерживаться на рассмотрении "интересных идей". |
| Исполнитель | Претворяет идеи в практические действия. Превращает решения в легко выполнимые задания. Вносит упорядоченность в деятельность команды. | Недостаточная гибкость. Неприязнь к фантастическим идеям. Неприязнь к частым изменениям планов. |
| Доводчик | Усердие и добросовестность. Следит за тем, чтобы задания выполнялись полностью. Отслеживает своевременность выполнения заданий. | Чрезмерная обеспокоенность состоянием дел. Склонность к внутренним переживаниям. Нежелание перепоручать свои обязанности. Неприятие несерьезного отношения к его обязанностям со стороны других. |
| Оценщик (эксперт) | Исповедует беспристрастный критический анализ ситуации. Стратегический подход и проницательность в оценках. Точность суждений, стремление рассматривать все возможные варианты решения. | Недооценка факторов стимулирования и воодушевления. Недостаточность вдохновения и творческого воображения. Способность сбивать других, подавляя их инициативу. |
| Исследователь ресурсов | Владение искусством проведения переговоров, разнообразие контактов. Талант импровизатора, изучает благоприятные возможности. Энтузиазм, коммуникабельность. | Теряет интерес по мере угасания энтузиазма. Перескакивает от одной задачи к другой. Нуждается в повышенном внешнем давлении. |
| Формирователь | Постоянная ориентированность на решение поставленной задачи; стимулирует работу всей команды. Способствует реализации принятых решений; побуждает сотрудников работать интенсивнее. Энергичность, стремление к превосходству и работе с полной отдачей сил. | Легко переходит к состоянию раздражительности. Импульсивность и нетерпеливость. Нетерпимость к нечетким формулировкам и нерешительности в поведении. Результат - любой ценой. |
| Коллективист | Способствует гармонизации отношений в команде и устранению разногласий. Внимательно выслушивает собеседника; опирается на мнения других. Чуткость, отсутствие чрезмерной самоуверенности. | Нерешительность в кризисных ситуациях. Стремление избегать обострения ситуаций. Может воспрепятствовать совершению действий в решающий момент. |
| Председатель (координатор) | Четко формулирует цели; хорошо выполняет функции ведущего во время дискуссий. Способствует эффективному принятию решений. Имеет хорошие коммуникативные навыки; социальный лидер. | Может производить впечатление человека, склонного к манипуляциям. Склонность к переложению своих обязанностей на других. Может приписывать себе заслуги всей команды. |
| Специалист | Обладает редко встречающимися навыками и знаниями. Целеустремленность и способность концентрировать усилия. Инициативность и способность всецело отдаваться работе. | Полезен только в узкой профессиональной сфере. Зачастую слабые коммуникативные навыки. Иногда, образно выражаясь, "не видит леса за деревьями". |
В равной степени важными для эффективной командной работы их можно считать лишь при условии, что они применяются в надлежащее время и наилучшим образом. Например, в тот период, когда команда только приступает к рассмотрению проблемы или к разработке проекта, обычно требуются инновационные идеи (т.е. нужен «мыслитель»). Затем возникает необходимость оценки того, как эти идеи могут быть претворены в практически выполнимые задачи (т.е. нужен «исполнитель»). Успех достигается при условии, что в команде есть хороший координатор («председатель»), задача которого - обеспечить наибольшую отдачу от членов команды в нужное время. Движущую силу и стимул команда обретает в лице энергичного «формирователя». Когда возникает необходимость в проведении сложных переговоров с другими группами, большое значение приобретают качества, которыми обладает «исследователь ресурсов». Чтобы сдерживать чрезмерные проявления энтузиазма, отвлекающие от главной цели, в составе команды должен быть «оценщик» (т.е. «эксперт»). Всевозможные трения и недоразумения между членами команды устраняются усилиями «коллективиста». Благодаря наличию «специалиста» команда имеет редко встречающиеся навыки и знания, в которых периодически возникает необходимость. Роль «доводчика» состоит в том, чтобы не упустить из виду даже мельчайшие детали реализации всех намеченных планов.
Однако для успешной разработки программного обеспечения недостаточно просто распределить среди участников проектной команды роли и обязанности. Необходимо, чтобы все участники команды понимали и соблюдали следующие базовые принципы коллективной работы:
– Единое понимание целей проекта. Данное условие является важнейшим фактором успеха как при разработке ПО, так и при любой совместной деятельности. На начальных этапах работы каждый участник команды имеет собственное мнение и представление о продукте. Необходимо обсудить частные мнения и по итогам обсуждения выработать концепцию проекта – единый документ, который содержит:
§ описание возможностей продукта (что продукт позволяет сделать);
§ конкретизацию продукта (описание функциональных возможностей данной версии);
§ описание путей реализации проекта.
– Равенство, свободный обмен информацией, общая ответственность и четкие ролевые функции. В группе разработчиков важна каждая роль. Только такой подход позволяет наладить свободный обмен информацией между проектными группами и отдельными разработчиками и сформировать общую ответственность за качество продукта проекта.
– Ориентация на продукт и понимание целей заказчика, нацеленность на результат.
– Постоянное коллективное обучение. Обучение людей является одной из важнейших составляющих успеха проекта и всей компании. Постоянное коллективное обучение позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. На разных этапах реализации проекта применяются следующие виды обучения:
§ обучение на опыте других проектов;
§ изучение методологии;
§ изучение технологий.
– Эффективное взаимодействие с внешними группами. Проектная группа должна эффективно взаимодействовать с внешними группами – с заказчиком, пользователями, другими разработчиками. За эффективность внешних взаимодействий отвечают менеджер проекта, менеджер продукта, специалист по внедрению и логистик. В их обязанности входят как внутренние, так и внешние контакты.
Можно выделить следующие этапы развития команды:
1. Первый этап – формирование (или шумиха) – характеризуется избытком энтузиазма. Люди должны преодолеть внутренние противоречия, переболеть конфликтами прежде, чем сформируется действительно спаянный коллектив. На этом этапе многое зависит от лидера: он должен четко поставить цели членам команды, верно определить их роли в проекте.
2. Второй этап – бурление (или неразбериха) – самый сложный и опасный период. Мотивация новизны уже исчезла, а сильные и глубокие стимулы у команды еще не появились. Неизбежные сложности или неудачи порождают конфликты, «поиск виновных». На этом этапе важно обеспечить открытую коммуникацию в команде – конфликты не следует прятать или разрубать. Споры необходимо разруливать – спокойно, терпеливо и тщательно.
3. Третий этап – становление. В команде растет доверие, люди начинают замечать в коллегах не только проблемные, но и сильные стороны. На смену битве амбиций приходит продуктивное сотрудничество. Четче становится разделение труда, исчезает дублирование функций. Лидер перестает находиться в состоянии постоянного аврала, работа по построению команды на этом этапе – уже не тушение пожара, а скрупулезный труд по отработке общих норм и правил.
4. Четвертый этап – отдача. Наконец-то можно получить дивиденды за потраченные усилия. Команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов. Люди хотят и могут совершенствоваться, они более всего заинтересованы в профессиональном росте. Растет значение нематериальной мотивации сотрудников, а оценивать и поощрять материально лучше команду в целом. Если четвертый этап достигнут, значит, команда создавалась не зря.
Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:
– групповая работа над кодом, документами;
– учет проблем, ошибок, требований;
– документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
– организация правильного тестирования.
Работа средств коллективной разработки основана на выполнении двух базовых функций:
– Ведение общей для всех разработчиков базы данных проекта, содержащей историю изменений в каждом файле проекта.
– Автоматизация следующих операций:
§ доступа к общей базе данных;
§ обработки конфликтующих версий файла;
§ именования различных версий файла;
§ ввода и сохранения комментариев к изменениям.
Формирование рабочих коллективов и выбор программного проекта вещи взаимосвязанные. В данном курсе даётся возможность студентам сначала «собрать команду», а потом выбрать проект. Группы, работающие над проектом должны состоять из 3-5 человек. Группы менее 3 человек, не позволят студентам получить навыки коллективной работы над проектом. Группы более 5 человек требуют более сложной координации и допустимы для уже сложившихся творческих коллективов.
При формировании групп следует учитывать психологическую совместимость, входящих в них студентов. Задача преподавателя помочь студентам получить навыки конструктивной работы в коллективе. При формировании и утверждении групп следует избегать как существующих, так и потенциальных конфликтов внутри одной группы.
В сильные сформированные группы преподаватель может по собственному усмотрению добавить студента, не нашедшего группу самостоятельно. Студенты, не сумевшие сформировать группы, разделяются на группы преподавателем, либо вводятся в уже существующие группы.
Сформированные группы утверждаются преподавателем. Если преподаватель считает, что с точки зрения освоения практических навыков, предусмотренных программой ТРПО, данная группа малоэффективна, то он вправе расформировать или переформировать такую группу. Использовать данное право следует только в исключительных случаях, предварительно проконсультировавшись с лектором.
Студенты на основе своих личных предпочтений и желаний организуют рабочие команды. Следует выбирать тех людей, с которыми приятно и интересно работать. После выбора темы проекта рекомендуется распределить роли между участниками, договориться о способах взаимодействия, а так же определить количество часов в неделю, выделяемых на работу над проектом каждым участником. Данный момент является очень важным, поскольку одной из распространенных причин провала проекта является невыполнение рабочих обязательств одним или несколькими членами группы.
Следует определить схему и частоту проведения собраний. Встреча коллектива, совместно работающего над проектом должна проходить не реже одного раза в неделю. Собрание является точкой интеграции полученных результатов проекта и определения дальнейших действий проекта. На собрании обсуждаются и вырабатываются различные решения, касающиеся проекта. Например, распределение задач, определение приоритетов, назначение ответственных, изменение плана и т.п.
1. Руководитель проекта назначает секретаря и оглашает заранее подготовленную повестку собрания и краткий отчет о текущем состоянии проекта. (~5 минут).
2. Участники собрания вносят замечания. В результате формируется окончательная повестка собрания. (~5 минут).
3. Собрание идет согласно выработанной повестке. Заслушиваются отчеты разработчиков о проделанной работе, включая отчеты об исправлении замечаний, и выполняется анализ текущей документации и других артефактов. Обсуждаются и определяются дальнейшие направления и задачи. (~35–70 минут).
4. Подведение итогов. Распределение задач, назначение ответственных и т.п. (~10 минут).
В случае недостаточности еженедельных собраний для командной работы разработчиков, команда может использовать дополнительное время. Например, это полезно на начальных этапах проекта в случае активной работы с заказчиком
Разработчики сочетают командную работу с индивидуальной. В процессе разработки каждому из разработчиков должны поручаться конкретные задачи для решения. Зоны ответственности, роли разработчиков и другие правила, регулирующие индивидуальную работу и ее сочетание с командной, фиксируются в плане проекта. Текущее распределение задач отражается в протоколах собраний и индивидуальных журналах разработчиков.
Преобладающим методом коллективной разработки является организация бригад. Метод предметных связей используется реже, тогда когда ведется разработка не тиражируемого продукта силами организации, которая будет и вести его эксплуатацию.
С административной точки зрения, бригада - структурная производственная единица, которая может быть образована в рамках существующего структурного подразделения для выполнения определенной работы, имеющей конкретный результат.
При определении результата работы бригады может быть сформулировано частичное техническое задание.
Существуют два варианта бригад:
предметная область определяется в терминах программирования, то есть задание представляется собой результат работы относящийся к программированию;
предметная область определяется в терминах того языка, который используется в предметной области (функционально и математическо ориентированные программные продукты);
В первом случае предметная область имеет вид хорошо знакомый и понятный программисту и работа предполагает техническое проектирование может выполнить программист. Бригада может быть сформирована из специалистов одного профиля (в основном программисты).
Во втором случае работы по техническому проектированию могут быть выполнены специалистом в предметной области. Принятое им проектное решение, вплоть до технического проекта в дальнейшем доводится до машинной реализации специалистом-программистом, параллельно эксплуатируется документация, по возможности, должна разрабатываться специалистом из предметной области. В процессе внедрения, проверка работоспособности программного продукта тоже проводится специалистом из предметной области.
Формирование специализированных бригад (из специалистов одного профиля). Результат работы отдельной бригады не всегда представляет собой конечный результат разработки.
Сложнее вести управление разработкой, требуется строгая формализация работ каждой бригады. На поздних этапах разработки результаты могут отклоняться от ТЗ.
Если из-за сложности и масштабности разработки требуется большое число исполнителей и организация нескольких бригад, то рекомендуется:
Рассмотреть вопрос о специализации бригад по функциональному признаку;
Желательно выделить ведущую, главную бригаду. Эта бригада выполняет наиболее существенное задание и как можно больше участвует в жизненном цикле. Бригаде даются другие бригады соисполнители (которые могут быть со своим ТЗ).
Выявляются функции управления, подлежащие автоматизации, или те по которым пересматриваются ранее действующие решения. Решаются задачи методами иерархической декомпозиции: разбиения некоторой сложной проблемы функции управления на ряд ее частных составляющих (под проблем), до тех пор, пока по каждой составляющей полученной на очередном шаге не будет детально определены информационные входы и выходы.
После того как определились с взаимосвязью отдельных задач, проводится обследование информационной схемы решаемых задач. Сначала выходная информация (пожелания заказчика), входная информация (оперативная, нормативно-справочная) и процесс-метод реализации перехода от входа к выходу.