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

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

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

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

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

Лекция 2. Групповая разработка Программного обеспеченья (ПО).

Структурная формула всего механизма

Строение групп Асcура

Степень подвижности механизма

Кинематические пары

Обозначение на структурной схеме Соединяемые звенья Вид Тип пары Индекс пары
Характер соприкосновения Степень подвижности

Число одноподвижных кинематических пар p 1 =7 , число двух подвижных кинематических пар р 2 =0.

а).Последняя группа Асcура

б).Предпоследняя группа Асcура

в).Начальный механизм

7.Класс всего механизма II , так как наивысший класс группы Ассура, входящей в данный механизм II.

  • изучение инструментария коллективной разработки
  • изучение принципов организации процесса разработки и управления коллективом разработчиков

Определения:

Source control (revision control, source code management (SCM)) - по-русски это все обычно называют системами контроля версий. Контролировать ими можно много чего, но меня они, конечно, интересуют в плане работы с кодом. Основная идея систем контроля версий - запоминать все внесенные изменения с комментариями . Понятно кто когда что менял, зачем. Главное - можно все эти изменения откатить. Ну а кроме этого систему контроля версий можно обвешать дополнительными фишками и рюшечками.

Репозиторий, хранилище - место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Существуют репозитории для хранения программ, написанных на одном языке (например, CPAN для Perl) или предназначенных для одной платформы. Многие современные операционные системы, такие как OpenSolaris, FreeBSD и большинство дистрибутивов Linux, имеют официальные репозитории, но также позволяют устанавливать пакеты из других мест. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку. Репозитории используются в системах управления версиями, в них хранятся все документы вместе с историей их изменения и другой служебной информацией. Русское сообщество Subversion рекомендует использовать вместо термина репозиторий термин хранилище, поскольку он полностью соответствует как прямому переводу слова «repository», так и его понятию. Существуют различные автоматизированные системы создания репозиториев. Один из типов репозиториев: хранилища на CD/DVD - установочные диски для пакетов того или иного ПО.



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

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

Пример, Redmine BUGS - the Bug Genie Bugzilla eTraxis GNATS

Базовые принципы разработки ПО в VCS

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

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

Самые известные, которые чаще всего упоминаются - CVS, Subversion (SVN), Perforce. Все системы, что я перечислила, объединяет то, что это системы с одним, выделенным сервером, на котором и находится репозиторий с кодом. Скорее всего вы работали с какой-то из них. Если ни с какой не работали, то очень рекомендую поставить Subversion. Его легко и непринужденно можно погонять на одной локальной машине и получить полное представление о работе систем контроля версий.

Небольшой словарик для понимания дальнейшего. Переводами народ себя обычно не утруждает:-).
Транк (trunk) - основная ветка кода
Бранч (branch) - ответвления (для экспериментов, например)
Чекин (Check in (submit, commit)) - отправка кода в репозиторий
Чекаут (Check out) - получение изменения из репозитория.
Конфликты - возникают, когда несколько человек правят один и тот же код, конфликты можно разрешать
Патч - кусок с записанными изменениями, которые можно применить к репозиторию с кодом

Список литературы

Авторская разработка Авторская разработка – это создание программных продуктов, при котором весь жизненный цикл разработки поддерживается одним человеком. Был распространён в г.г. и сейчас применяется редко из-за сложности, объема, требуемого качества, сопровождения. С появлением ПК программное обеспечение стало продуктом массового применения, поэтому стали доминировать крупные компьютерные компании с развитой структурой менеджмента и рекламной компанией. Авторские разработки применяются в области наукоемких приложений. Для таких приложений характерна необходимость многолетнего изучения предметной области, практически полное отсутствие начального финансирования проекта, малая рентабельность, которая определяется узким кругом области.


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


Коллективная разработка Коллективная разработка – это создание программного продукта коллективом разработчиков. Один из основных вопросов коллективной разработки является разделение труда. Один человек не способен создать приложение масштаба предприятия. Ни один разработчик просто не удержит в голове все требования к системе и варианты проекта. Поэтому сегодня разработкой промышленных систем занимаются проектные группы, и все обязанности распределяются среди членов группы. Существует две основные модели организации коллектива при разработке ПО: 1) иерархическая модель (начальник -> подчинённые) 2) модель группы (не определяет структуру коллектива с точки зрения отдела кадров) Основной моделью разделения труда в наше время является иерархическая структура. подчинённые) 2) модель группы (не определяет структуру коллектива с точки зрения отдела кадров) Основной моделью разделения труда в наше время является иерархическая структура.">


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


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


Примерный состав бригады: 1. разработчики специалисты по инженерии и программированию (приёмы и методы программирования, знания инструментальных систем) программисты 2. технические писатели 3. специалисты по качеству 4. специалисты по сопровождению 5. специалисты по продаже


Разделение по типам работы: 1. разработка приложений требует: программистов специалистов по инженерии и программировании специалистов по инженерии и знаниям 2. работа с приложениями - эксплуатация требует: специалистов по приложениям администраторов данных администраторов баз данных 3. техническая поддержка системный администратор сетевой администратор администратор коммуникации 4. обеспечение качества программы технический писатель специалист по тестированию специалист по качеству 5. маркетинг специалист по сопровождению специалист по продаже продукта 6. системное интегрирование системный интегратор (основные задачи: предложить заказчику варианты решения проблемы, выбрать приемлемый вариант по цене, технике и реализовать)


Модель бригады главного программиста 1. Главный программист: анализ проектирование создаёт, реализует, пишет документацию. большой опыт работы и существенными знаниями с большим талантов 2. Дублёр Может выполнять любую работу главного программиста, но с небольшим опытом работы. Не несёт ответственность. 3. Администратор (менеджер) контроль денег, людей, помещений, машинных ресурсов, контактов с другими группами и руководством. 4. Редактор технический Критически перерабатывает документацию. Перерабатывает языки документации, которые разрабатывает программист. 5. Языковед Эксперт в тонкостях языка программирования. Может найти эффективные способы программирования. Обычно работает с несколькими бригадами программистов. 6. Инструментальщик Разработчик специализированных инструментальных утилит, скриптов, поддерживает основной инструментарий и оказывает по нему консультации. Может осуществлять администратор. Работает с несколькими бригадами. 7. Отладчик Разработчик тестов и организатор тестирования ПП (тестировщик, тестер) 8. Делопроизводитель Отвечает за регистрацию всех данных в бригаде, благодаря активным программистам освобождается от рутинных работ. В настоящее время функции делопроизводителя автоматизированы и выключены из проекта.


Модели коллективной разработки компании Microsoft (MSF) MSF не готовое решение, а каркас, который можно адаптировать для нужд любой организации. Один из элементов этого каркаса - модель проектной группы. Она описывает структуру группы и принципы, которым надо следовать для успешного выполнения проекта Хотя модель группы разработчиков весьма конкретна, при знакомстве с MSF ее нужно рассматривать в качестве отправной точки. Разные коллективы реализуют этот каркас по-разному, в зависимости от масштаба проекта, размеров группы и уровня подготовки ее членов.


Чтобы проект считался удачным, следует решить определенные задачи: удовлетворить требования заказчика проект должен выполнить требования заказчиков и пользователей, иначе ни о каком успехе не может быть и речи, возможна ситуация, когда бюджет и график соблюдены, но проект провалился, так как не выполнены требования заказчика; соблюсти ограничения разработчики проекта должны уложиться в финансовые и временные рамки; выполнить спецификации, основанные на требованиях пользователей спецификации это подробное описание продукта, создаваемое группой для заказчика; они представляют собой соглашение между проектной группой и клиентом и регулируют вопросы, касающиеся приложения, в основе этого требования лежит принцип «сделать все, что обещано»; выпустить продукт только после выявления и устранения всех проблем не существует программ без дефектов, однако группа должна найти и устранить их до выпуска продукта в свет, причем устранением ошибки считается не только ее исправление, но и, например, занесение в документацию способа ее обхода; даже такой способ устранения проблем предпочтительнее, чем выпуск приложения, содержащего невыявленные ошибки, которые в любой момент могут преподнести неприятный сюрприз пользователям и разработчикам;


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


Модель проектной группы Менеджер продукта Менеджер программ Разработчики Тестеры Инструктор Логистик Работа над проектом включает множество разных видов деятельности и изучение требований с разных точек зрения, поэтому распределение основных задач по нескольким ролям повышает шансы на успех проекта. Как видно из рисунка, в MSF определены шесть таких ролей, которые и составляют модель проектной группы. У каждой из ролей свои обязанности, выполнение которых и обуславливает удачу проекта.


Цели и роли Шесть ролей модели проектной группы связаны с шестью целями проектной группы, что проиллюстрировано в таблице. Все эти цели важны для успеха проекта в целом, и поэтому все роли равноправны. В этой модели нет руководителя всего проекта есть группа людей, знающих, что нужно делать и делающих это. ЦельРоль Удовлетворение требований заказчика Соблюдение ограничений проекта Соответствие спецификациям Выпуск только после выявления и устранения проблем Повышение эффективности труда пользователя Простота развертывания и постоянное сопровождение Менеджер продукта Менеджер программы Разработчик Тестер Инструктор Логистик


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


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


Менеджер программы Менеджер программ – его задача вести процесс разработки с учетом всех ограничений. Является руководителем разработки. Его цель повысить авторитет каждого члена группы, а не подавить их своим авторитетом. Главная обязанность выполнить все стадии разработки так, чтобы нужный продукт выпущен был в назначенное время. Он координирует деятельность других членов группы. Главный менеджер программы составляет график проекта на основе информации, полученной от остальных членов группы. Для выполнения своих обязанностей менеджер программы должен отлично разбираться в деловой стороне проекта и иметь ясное представление о технологиях, необходимых для его выполнения. От руководителя отдела программного менеджмента требуется коммуникабельность и талант организатора. Менеджер программы отвечает и за бюджет проекта, объединяя требования к ресурсам всех членов группы в единый план расходов.


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


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


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


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


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


Крупные проекты. Чтобы справиться с крупным проектом, приходится делить проектную группу на тематические и функциональные подгруппы. Тематические группы. Это небольшие подгруппы из одного или нескольких человек, роли которых различны. Каждой из таких групп выделяется некий набор функциональных возможностей приложения, за все стороны проектирования и разработки которого она и отвечает (включая составление проекта и графика реализации). Например, какой-либо группе нужно предоставить решать задачу вывода данных на печать. Функциональные грппы Функциональные группы формируются в рамках одной роли. Они нужны в очень крупных проектных группах или при работе над крупномасштабными проектами, когда отдельные роли нуждаются в дополнительном подразделении. Например, в Microsoft отдел менеджмента продукта обычно состоит из групп планирования и маркетинга. Обе они занимаются менеджментом продукта, но первая отвечает за определение действительно необходимых заказчику функций приложения, а вторая за информирование потенциальных клиентов о достоинствах продукта.


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


Деструктивные и созидательные сочетания ролей На рис. показаны комбинации ролей, оказывающие позитивное и негативное влияние на проект. Роли, отмеченные буквой «3» Запрещено нельзя совмещать из-за конфликтов интересов. Вероятность совмещения ролей, отмеченных буквой «Н» Нежелательно и из-за сильного различия в необходимой квалификации Например, знания и опыт менеджера продукта и логистика сильно отличаются. Сочетания ролей, помеченные буквой «Д» Допустимо возможны, так как их интересы совпадают. Например, как тестеры, так и инструкторы отвечают за выполнение требований пользователей. Менеджер продукта Менеджер программы РазработкаТестиро- вание ИнструкторЛогистика Менеджер продукта ззддн Менеджер программы ззннд Разработка ззззз Тестиро- вание днздд Инструктор днздн Логистика ндздн


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


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


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


Принципы и методы эффективной коллективной работы Общее представление о проекте Группа равных Ориентация на продукт Ориентация на отсутствие дефектов Понимание целей бизнеса Ответственность в равной мере Совместное проектирование Обучение на опыте других проектов Обучение группы Изучение методологии Изучение технологий


Координация работы с внешними группами Разработчик Тестер Логистик Менеджер продукта Инструктор Менеджер программы Пользователи Планирование бизнеса Технологическая архитектура Стратегическое планирование Технологические цели Группы эксплуатации и сопровождения Проектная группа Пользователи Бизнес-цели Заказчик

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/ ));