Lecture16 (Лекции по Технологии программирования. Компонентный подход)

Технологии программирования. Компонентный подходВ. В. КуляминЛекция 16. Управление разработкой ПОАннотацияРассматриваются основные деятельности, входящие в компетенцию руководителей проектов. Вобщем рассказе о некоторых аспектах управления ресурсами, персоналом, рисками икоммуникациями проекта выделены особенности управления проектами по созданию ПО.Ключевые словаОрганизационная культура, структура организации, заинтересованные лица, спонсор, менеджер,заказчик, пользователь, команда проекта, цели проекта, содержание проекта, ресурсы,иерархическая структура работ, метрики сложности ПО, COCOMO II, сетевая диаграмма, PERTдиаграмма, диаграмма Ганта, критический путь, мотивация персонала, сплоченная команда,управление рисками, разрешение конфликтов, ведение переговоров.Текст лекцииЗадачи управления проектамиЭта лекция посвящена управлению проектами по разработке, поддержке или модификациипрограммного обеспечения.

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

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

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

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

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

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

Однако полностью в деньги можно перевеститолько используемое оборудование и материалы, да и то с некоторыми потерями вовремени на их приобретение и подготовку к работе.Вместе со временем бюджет задает основные ограничения на содержание и возможныерезультаты проекта.• Персонал.Персонал иногда рассматривается как возобновляемый ресурс, имеющий денежныйэквивалент («наймем проектировщика за 1500 у.е. в месяц»). Однако чаще всего людиведут себя не совсем так, как оборудование или мебель, — они не позволяют себя«передвигать», «убирать» и «добавлять» с такой же легкостью.

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

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

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

Работа с элементами программ в этомаспекте не слишком отличается от работы с кирпичами и строительными блоками. Аесли эти блоки еще и стоят кое-как, то при попытке передвинуть их программиставообще может «завалить» — отладка полученной программы потребует колоссальныхусилий.o Движение к нужному результату при разработке ПО очень тяжело проконтролировать.При возведении здания или постройке корабля можно непосредственно наблюдать затем, как продвигается работа. При создании сложной программной системы силамимногих разработчиков нужно аккуратно подбирать индикаторы того, как идут дела,иначе легко впасть в заблуждение относительно истинного положения вещей.• Программные системы практически всегда уникальны.Каждая из них обладает своим набором характеристик (включая все реализуемые функции,производительность при их выполнении, все элементы пользовательского интерфейса ит.п), так или иначе отличающихся от характеристик других программ, даже делающих «тоже самое».

Если обладающая нужными свойствами (в том числе и подходящей ценой)программа уже имеется, незачем создавать ее заново — достаточно приобрести ее иливзять ее код и скомпилировать. Поэтому практически каждая разрабатываемая программауникальна — она должна иметь такие характеристики, которыми не обладает ни одна ужесозданная.o Тем самым, почти каждый проект по разработке ПО включает элементы творчества,создания того, чего еще никто не делал.

Крупные же проекты требуют решения сразунескольких ранее не решенных задач. Управление проектами с элементами творческой•деятельности очень сильно отличается от управления проектами, в которых заранееясно, что именно надо делать и как.o Другое следствие этой уникальности ПО — отсутствие стандартных процессовразработки. Нет целостных подходов к созданию ПО, которые годились бы для всехслучаев, а не только для определенного вида проектов. Кроме того, для хорошоопределенных процессов, таких, как RUP, XP, Microsoft Solution Framework или DSDM(Dynamic Systems Development Method, Метод разработки динамичных систем),недостаточно четко очерчены области их применимости. Каждый раз менеджерупроекта приходится только на основании своего опыта и советов экспертов приниматьрешение о том, какой процесс разработки использовать и как его модифицировать длядостижения большей эффективности в конкретном проекте.Есть много аргументов в пользу того, что программный код является проектом, а неконечным продуктом.При разработке ПО переход от проекта к продукту почти полностью автоматизирован —требуется лишь скомпилировать код и развернуть систему в том окружении, где она будетработать.