Планирование управления конфигурациями
Конфигурационное управление один из важных процессов производства программного обеспечения. Об этой области знаний написана не одна книга. Мы будем говорить только о том, что эта работа должна быть спланирована.
План проекта должен включать в себя работы по обеспечению единого хранилища всей проектной документации и разрабатываемого программного кода, обеспечению сохранности и восстановление проектной информации после сбоя. Работы по настройке рабочих станций и серверов, используемых участниками проектной команды, тоже должны войти в план. Кроме этого в плане должны содержаться работы, необходимые для организации сборки промежуточных выпусков системы, а также ее конечного варианта.
Эти работы, как правило, выполняет один человек — инженер по конфигурациям. Если проект небольшой, то эта роль может быть дополнительной для одного из программистов. Я как-то видел, что эту роль выполнял менеджер проекта. «Размазывать» эту работу на всех участников проекта, во-первых, неэффективно. Установка и конфигурирование среды разработки, например, баз данных и серверов приложений, требует определенных компетенций и знаний особенностей конкретных версий продуктов. Если эти навыки придется осваивать всем разработчикам, то на это уйдет слишком много рабочего времени. Во-вторых, «размазывание» работ по управлению конфигурациями может привести к коллективной безответственности, когда никто не знает, от чего не собирается проект и как откатиться к консистентной версии.
Управление конфигурациями может многократно усложниться, если проектной команде параллельно с разработкой новой функциональности продукта приходится поддерживать несколько релизов этого продукта, которые были установлены ранее у разных клиентов. Все эти работы должны быть учтены в плане проекта.
Планирование управления рисками
Управление рисками это определенная деятельность, которая выполняется в проекте от его начала до завершения. Как и любая другая работа в проекте управление рисками требует времени и затрат ресурсов. Поэтому эта работа обязательно должна планироваться. Планирование управления рисками — это процесс определения подходов и планирования операций по управлению рисками проекта. Тщательное и подробное планирование управления рисками позволяет:
выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками, определить общие основания для оценки рисков, повысить вероятность успешного достижения результатов проекта.
Планирование управления рисками должен быть завершено на ранней стадии планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов.
В соответствии с исходными данными для планирования управления рисками служат:
Отношение к риску и толерантность к риску организаций и лиц, участвующих в проекте, оказывает влияние на план управления проектом. Оно должно быть зафиксировано в изложении основных принципов и подходов к управлению рисками. Стандарты организации. Организации могут иметь заранее разработанные подходы к управлению рисками, например категории рисков, общие определение понятий и терминов, стандартные шаблоны, схемы распределения ролей и ответственности, а также определенные уровни полномочий для принятия решений. Описание содержания проекта подробно описывает результаты поставки проекта и работы, необходимые для создания этих результатов поставки. План управления проектом, формальный документ, в котором указано, как будет исполняться проект и как будет происходить мониторинг и управление проектом.
План управления рисками обычно включает в себя следующие элементы:
Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте. Распределение ролей и ответственности. Список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности. Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками.
Эти данные включаются в базовый план по стоимости проекта. Определение сроков и частоты выполнения процесса управления рисками на протяжении всего жизненного цикла проекта, а также определение операций по управлению рисками, которые необходимо включить в расписание проекта. Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Такую структуру можно разработать с помощью составления иерархической структуры рисков (Рисунок 25). Общие подходы для определения уровней вероятности, шкалы воздействия и близости рисков на проект.
Рисунок 25. Пример иерархической структуры рисков проекта
Шкала оценки воздействия отражает значимость риска (Таблица 2) в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.
| 3 | Катастрофические | Потери более $100K |
| 2 | Критичные | Потери от $10K до $100K |
| 1 | Умеренные | Потери менее $10K |
Хотя риск может воздействовать и на сроки проекта, и на качество получаемого продукта, но все эти отклонения могут быть оценены в денежном эквиваленте. Например, последствия задержка по срокам для заказной разработки может быть выражена в сумме денежных санкций, определенных в контракте.
Похожая шкала может быть применена для оценки вероятности наступления риска (Таблица 3).
| 3 | Очень вероятно | Шансы наступления весьма велики |
| 2 | Возможно | Шансы равны |
| 1 | Мало вероятно | Наступление события весьма сомнительно |
Еще одной важной характеристикой риска является близость его наступления. Естественно, что при прочих равных условиях рискам, которые могут осуществиться уже завтра, следует сегодня уделять больше внимания, чем тем, которые могут произойти не ранее, чем через полгода.Для шкалы оценки близости риска может быть применена, например, следующая градация: очень скоро, не очень скоро, очень нескоро.
Планирование управления содержанием
Одна из распространенных «болезней» программных проектов называется «ползучий фичеризм». Это, когда к изначально спроектированной будке для любимой собаки сначала пристраивают сарайчик для хранения садового инвентаря, а потом и домик в несколько этажей для ее хозяина. И все это пытаются построить на одном и том же фундаменте и из тех же самых материалов. Эта болезнь стала причиной летального исхода многих проектов разработки ПО.
Поэтому, сразу, как только удалось стабилизировать и согласовать ИСР, необходимо разработать план управления содержанием проекта. Для этого следует:
Определить источники запросов на изменение. Установить порядок анализа, оценки и утверждения/отклонения изменения содержания. Определить порядок документирования изменений содержания. Определить порядок информирования об изменении содержания.
Первая задача, которую необходимо решить при анализе запроса на изменения — выявить объекты изменений: требования, архитектура, структуры данных, исходные коды, сценарии тестирования, пользовательская документация, проч. Затем требуется спроектировать и детально описать изменения во всех выявленных объектах. И наконец, следует оценить затраты на внесение изменений, тестирование изменений и регрессионное тестирование продукта и их влияние на сроки проекта.
Эта работа, которая потребует затрат рабочего времени и порой значительных разных специалистов: аналитиков, проектировщиков, разработчиков, тестировщиков, наконец, менеджера проекта. Поэтому эта работа должна обязательно быть учтена в плане.
Подсчет функциональных точек, связанных с транзакциями
Подсчет функциональных точек, связанных с транзакциями — это четвертый шаг анализа по методу функциональных точек.
Транзакция — это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.
В методе различаются следующие типы транзакций (Таблица 9):
EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне. EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF. EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.
Таблица 9. Основные отличия между типами транзакций. Легенда: О — основная; Д — дополнительная; NA — не применима.
| Изменяет поведение системы | О | Д | NA |
| Поддержка одного или более ILF | О | Д | NA |
| Представление информации пользователю | Д | О | О |
Оценка сложности транзакции основывается на следующих ее характеристиках:
FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции. DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.
Для оценки сложности транзакций служат матрицы, которые представлены в Таблица 10 и Таблица 11.
Таблица 10. Матрица сложности внешних входных транзакций (EI)
| Low | Low | Average |
| Low | Average | High |
| Average | High | High |
Таблица 11.
Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ)
| Low | Low | Average |
| Low | Average | High |
| Average | High | High |
Таблица 12. Сложность транзакций в не выровненных функциональных точках (UFP)
| Low | 3 | 4 |
| Average | 4 | 5 |
| High | 6 | 7 |
Рисунок 40. Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook
Каждый "Check box" оценивается, как 1 DET. Выпадающий список — 1 DET. Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то, для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно матрице (Таблица 10), мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с матрицей (Таблица 12), данная транзакция должна быть оценена в 3 не выровненных функциональных точек (UFP).
Подсчет функциональных точек, связанных с данными
Третий шаг — подсчет функциональных точек, связанных с данными. Сначала определяется сложность данных по следующим показателям:
DET (data element type) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.
Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности (Таблица 7).
Таблица 7. Матрица сложности данных
| 1-19 DET
20-50 DET 50+ DET | ||
| Low | Low | Average |
| Low | Average | High |
| Average | High | High |
Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) (Таблица 8) в зависимости от их сложности.
Таблица 8. Оценка данных в не выровненных функциональных точках (UFP) для внутренних логических файлов (ILFs) и внешних интерфейсных файлов (EIFs)
| Low | 7 | 5 |
| Average | 10 | 7 |
| High | 15 | 10 |
Для иллюстрации рассмотрим пример оценки в не выровненных функциональных точках объекта данных «Клиент» (Рисунок 39).
Рисунок 39. Пример оценки в не выровненных функциональных точках объекта данных «Клиент».
Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 неповторяемых уникальное полей данных. Согласно матрице (Таблица 7), нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно Таблица 8 его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.
Прагматичный подход. Метод PERT
Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат.
Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис». Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета. Диапазон неопределенности достаточно охарактеризовать тремя оценками:
Mi — наиболее вероятная оценка трудозатрат.
Oi — минимально возможные трудозатраты на реализацию пакета работ. Ни один риск не реализовался. Быстрее точно не сделаем. Вероятность такого, что мы уложимся в эти затраты, равна 0.
Pi — пессимистическая оценка трудозатрат. Все риски реализовались.
Оценку средней трудоемкости по каждому элементарному пакету можно определить по формуле:
Ei = (Pi + 4Mi + Oi)/6.
Для расчета среднеквадратичного отклонения используется формула:
CKOi = (Pi - Oi)/6.
Если наши оценки трудоемкости элементарных пакетов работ статистически независимы, а не испорчены, например, необоснованным оптимизмом то, согласно центральной предельной теореме теории вероятностей суммарная трудоемкость проекта может быть рассчитана по формуле:
Е = ∑ Ei
А среднеквадратичное отклонение для оценки суммарной трудоемкости будет составлять:
Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу:
E95% = E + 2 * СКО.
Это значит, что вероятность того, что проект превысит данную оценку трудоемкости составляет всего 5%. А это уже вполне приемлемая оценка, под которой может расписаться профессиональный менеджер.
Список элементарных пакетов работ, который используется при оценке трудоемкости, как правило, берется из нижнего уровня ИСР проекта.
Но может быть использован и накопленный опыт аналогичных разработок. Проиллюстрирую данный подход на примере реального проекта. В Ассоциации CBOSS задачей проекта, который нам с коллегами посчастливилось реализовывать, была разработка на основе стандартов J2EE общесистемного ПО для перевода рабочих мест CBOSS на новую трехзвенную архитектуру. Был разработан набор стандартных компонентов и сервисов, из которых как из конструктора можно эффективно и качественно собирать прикладные подсистемы. Высокоуровневая архитектура реализовывала стандартный паттерн MVC (Рисунок 36), каждый из компонентов которого имел «точки расширения» для прикладной разработки, которые на рисунке выделены красным светом.
Рисунок 36. Высокоуровневая архитектура J2EE фреймворка для разработки приложений.
Такими точками расширения являлись:
Пользовательский экран (UI Form), который собирался из готовых визуальных компонентов. Обработчики (Action), которые обрабатывали на сервере приложений события от активных визуальных компонентов, входящих в состав экрана. Объекты (Business Obj), которые моделировали прикладную область, и к которым обращались обработчики событий.
Так вот, хотя все разрабатываемые рабочие места различались по функциональности и сложности, накопленная статистика фактических трудозатрат на разработку прикладных систем позволяла нам оценивать проекты разработки нового приложения достаточно быстро и с высокой достоверностью.
Согласно этой статистике, разработка и отладка требовала у программиста:
для одного экрана — от 2 до 20 часов (наиболее вероятно — 4 часа); для одного обработчика событий — от 4 до 32 часов (наиболее вероятно — 8 часов); для нового бизнес-объекта — от 2 до 8 часов (наиболее вероятно — 3 часа); для добавления нового бизнес-метода — от 2 до 26 часов (наиболее вероятно — 6 часов).
Весь проект прикладной разработки измерялся в «попугаях»:
КUI — количество пользовательских экранов. KAct — количество обработчиков событий. КBO — количество новых бизнес-объектов. KBM — количество новых или модифицируемых бизнес-методов.
Если новое разрабатываемое приложение содержит 20 пользовательских экранов, 60 обработчиков событий, 16 новых бизнес-объекта и 40 новых бизнес-методов, которые необходимо добавить, как в новые, так и в уже существующие бизнес-объекты, тогда, согласно нашей статистике,
| ЕUI = (2 + 4*4 + 20) / 6 = 6.7 чел.*час., ЕAct = (4 + 4*8 + 32) / 6 = 11.3 чел.*час., ЕBO = (2 +4*3 + 8) / 6 = 3.7 чел.*час., EBM = (2 + 4*6 + 26) / 6 = 8.7 чел.*час., |
СКОUI = (20 - 2) / 6 = 3 чел.*час СКОAct = (32 - 4) / 6 = 4.7 чел.*час CKOBO = (8 - 2) / 6 = 1 чел.*час СКОBM = (26 - 2) / 6 = 4 чел.*час |
Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, получим
Е95% = 1220 + 2 *46 ≈ 1300 чел.*час.
Хотя относительная погрешность в оценке трудоемкости каждой такой элементарной работы составляла десятки процентов, для нашего проекта, в котором было таких «попугаев» было 136, относительная погрешность оценки суммарной трудоемкости, сделанной по методу PERT, составила, приблизительно, лишь 4%.
Даже если у нас очень размытые оценки трудоемкости каждой из элементарных работ, но они независимы, то ошибки мы делаем как в меньшую, так и большую стороны. Поэтому при фактической реализации проекта эти ошибки будут компенсироваться, что позволяет нам оценить общие трудозатраты по проекту существенно точнее, чем трудозатраты на каждую элементарную работу. Но это утверждение будет справедливо только в том случае, если наша ИСР содержит все необходимые работы, которые должны быть выполнены для получения всех продуктов проекта.
Полученную оценку трудоемкости кодирования необходимо умножить на четыре, поскольку помним (см. ), что кодирование составляет только 25% общих трудозатрат проекта. Поэтому суммарная трудоемкость нашего проекта составит, приблизительно, 5200 чел.*час.
Как мы уже говорили ранее, если сотрудник на 100% назначен на проект, это, как правило, не означает, что он все 40 часов в неделю будет тратить на проектные работы.
Тратить он будет 60–80% своего рабочего времени. Поэтому, в месяц сотрудник будет работать по проекту, примерно, 165 * 0.8 = 132 чел.*час/мес. Следовательно, трудоемкость проекта в человеко-месяцах составит, приблизительно 5200 / 132 ≈ 40.
Тогда согласно формуле Б.Боэма (Рисунок 15) оптимальная продолжительность проекта составит:
T = 2.5 * (40)1/3 = 8.5 месяцев,
а средняя численность команды — 5 человек.
Помним, что потребление ресурсов в проекте неравномерно (Рисунок 13), поэтому начинать проект должны 1–3 человека, а на стадии реализации начальная численность команды может быть увеличена в несколько раз.
Если же собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то нам не остается ничего другого, как использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:
FPA IFPUG — метод функциональных точек, метод COCOMO II, Constructive Cost Model.
Правильные люди
Рональд Рейган говорил: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им».
За годы работы у меня сформировалось собственное видение правильного командного поведения. Эффективный командный игрок:
Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело. Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег. Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги. Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению. Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет взаимовыгодное решение в конфликтах. Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Вместе с тем, встречаются патологии поведения, которые, на мой взгляд, неприемлемы в команде:
Непорядочность. Лживость, отсутствие совести и чувства справедливости, способность на низкие поступки. Синдром острого дефицита эмпатии. Эгоцентризм. Неуважение и невнимание к партнерам. Склонность к отрицательным оценкам других. Грубость. «Каждый сам за себя! — никто тебе не поможет!» «Человек человеку волк!» «Звезданутость». Завышенная самооценка. Подчеркивание собственного превосходства. Умничанье. Человек сильно переоценивает свой личный вклад в общее дело и поэтому считает, что он должен работать меньше, чем его «менее способные» коллеги. Вульгарный анархизм. Вольница — это полная безответственность, свобода от каких либо обязательств перед другими, ничем не сдерживаемые проявления чувств, действия или поступки. «Произвольничать, поступать самовольно, в обиду другим, нагло, дерзко» (с) В.Даль.
Не путать со «свободой»! «Социальный паразитизм». Стремление прожить вольготно за чужой счет там, где ответственность размыта, а личный вклад трудно четко выделить.
Моя рекомендация: лечить патологию «хирургически» — избавляться от проблемных людей. Воспитывают в детском саду, ну еще немного в начальной школе. Дальше люди воспитываются только самостоятельно, а окружающие могут лишь помогать или не мешать в этом процессе. Убежден, что каждый взрослый человек имеет то, к чему он осознанно или неосознанно стремится. Нянчиться и воспитывать человека — это значит ограждать его от проблем, закрывать ему путь к переосмыслению своего опыта и развитию, «загонять болезнь внутрь» при помощи «социального аспирина».
Я знаю ровно четыре необходимых и достаточных условия для того, чтобы сотрудник эффективно решил поставленную мной задачу. Это
Понимание целей работы. Умение ее делать. Возможность ее сделать. Желание ее сделать.
Для того чтобы обеспечить выполнение этих условий, руководитель должен уметь эффективно выполнять четыре функции:
Направлять. Если сотрудник не понимает что делать, задача руководителя — обеспечить общее видение целей и стратегии их достижения. Обучать. Если сотрудник не умеет, задача руководителя — «обучать», быть наставником и образцом для подражания. Помогать. Если у сотрудника не может выполнить работу, задача руководителя — «помогать», обеспечить исполнителя всем необходимым, убрать препятствия с его пути. Вдохновлять. Если у сотрудника не достаточно желание выполнить работу, задача руководителя — «вдохновить», обеспечить адекватную мотивацию участника на протяжении всего проекта.
Принципы количественного управления
«Тем, что нельзя измерить, нельзя управлять». Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Для каждого измеримого показателя должны быть определены его плановые значения. Для каждого планового значения должны быть определены три области критичности отклонений:
Допустимые отклонения. Предполагается, что никаких управляющих воздействий не требуется. Критичные отклонения. Требуется тщательный анализ причин отклонения и при необходимости применение корректирующих действий. Недопустимые отклонения. Требуется срочный анализ причин отклонения и обязательное применение корректирующих действий.
Измерения необходимо производить регулярно. Цель — выявить причины наступивших или возможных критичных и недопустимых отклонений. Результатом анализа должны стать планирование корректирующих действий по компенсации недопустимых отклонений, их реализация и мониторинг результативности применения этих корректирующих действий.
Все измерения необходимо сохранять в репозитарии проекта. Измерения, накопленные в ходе проекте, являются наиболее достоверной основой при детальной оценке и планировании работ на следующих итерациях проекта.
Поскольку главная задача менеджера удержать проект в пределах «железного» треугольника, то, в первую очередь, необходимо анализировать отклонения проекта по срокам и затратам. Делается это при помощи метода освоенного объема . Приходилось сталкиваться с мнением, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки. Но если ИСР проекта, ориентирована на инкрементальную разработку, то это означает, что на верхних уровнях декомпозиции находятся компоненты проектного продукта и их функционал, а не производственные процессы. Следовательно, если в проекте реализованы, протестированы и документированы 50 % функциональных требований, то есть все основания полагать, что осталась приблизительно половина проектных работ.
Суть метода оценки проекта по освоенному объему заключается в следующем. Сначала оценивается отклонение от графика SV (Shedule Variance) в денежных единицах:
SV = EV - PV,
где
EV (Earned Value) — освоенный объем. Плановая стоимость выполненных работ. Объем выполненных работ, выраженный в терминах одобренного бюджета, выделенного на эти работы для плановой операции и элемента иерархической структуры работ; PV (Planned Value) — плановый объем. Плановая стоимость запланированных работ. Утвержденный бюджет, выделенный на плановые работы, выполняемые в рамках плановой операции или элемента иерархической структуры работ.
Например. Пусть мы на текущий момент реализовали (протестировали и документировали) 20 функциональных требований, на каждое из которых было запланировано затратить по 40 чел.*час. по 1000 руб, то освоенный объем будет
EV = 20 * 40 * 1000 = 800 000 руб.
Если же на текущий момент планировалось реализовать только 15 требований, то плановый объем будет
PV = 15 * 40 * 1000 = 600 000 руб.
Следовательно, мы опережаем график (отклонение от графика положительное) на величину
SV = EV - PV = 800 000- 600 000 = 200 000 руб.
Как пересчитываете отклонение от графика, выраженное в денежных единицах, в сокращение сроков проекта иллюстрируется на Рисунке 43.
Если мы опережаем график, то это не обязательно означает что проект идет успешно. Хорошо это или плохо зависит от значения другого показателя метода освоенного объема: CV (Cost Variance) — отклонения по затратам, которое оценивается по формуле:
CV = EV - AC
где
AC (Actual Cost) — фактические затраты. Фактическая стоимость выполненных работ. Фактические затраты на выполнение работ за определенный период в рамках плановой операции или элемента иерархической структуры работ.
Например, если мы для того что сократить время работ по проекту работали 25% времени сверхурочно и в выходные дни с двойной оплатой, то фактические трудозатраты составили:
AC = 20 * (30 * 1000 + 10 * 2000) = 1 000 000 руб.
Поэтому отклонения по затратам в нашем случае будет
CV = EV - AC PV = 800 000 - 1 000 000 = - 200 000 руб.
Отрицательное значение отклонения по затратам означает, что мы превысили бюджет, что, в общем случае, не очень хорошо. Но если срок завершения проекта для нас имеет высший приоритет, и наши прогнозируемые затраты по завершению проекта не превышают плановых с учетом управленческого резерва (Рисунок 43), то в этом случае можно считать, что проект выполняется успешно.
Рисунок 43. Оценка и прогноз показателей по методу освоенного объема
Отклонение от бюджета и по срокам в абсолютных денежных единицах недостаточно для характеристики проектов разных масштабов. Более наглядны относительные показатели: индекс выполнения сроков SPI (Schedule Performance Index)
SPI = EV / PV
и индекс выполнения стоимости CPI (Cost Performance Index)
CPI = EV/ AC,
которые характеризуют проект независимо от его размера. Если значения обоих индексов больше 1, то это свидетельствуют о благополучном состоянии в проекте.
Какие еще измеримые показатели целесообразно применять в управлении программным проектом?
В первую очередь это показатель прогресса проекта, доля реализованных и проверенных высокоуровневых требований к проекту, например отношение числа завершенных сценариев использования продукта к их общему числу.
Другой показатель — стабильность проекта, общее количество принятых (утвержденных спонсором или заказчиком) изменений в плане управления проектом. Чем выше нестабильность в проекте, тем больше сложность в управлении работами и ниже производительность участников.
Если кто-то думает что код это решение проблемы, то это не так. Код это новый источник проблем. Поэтому всегда следует измерять текущий размер проекта — количество строк исходного кода, добавленных, измененных и удаленных в ходе выполнения проекта разработки ПО. Чем больше объем исходного кода, тем больше времени потребуется на внесение изменений и исправление ошибок.
При увеличении объема проектного продукта трудозатраты на каждую новую строку исходного кода увеличиваются.
Если за номинал взять производительность проектной команды при производстве продукта в 10 KSLOC, то та же команда на проекте в 100 KSLOC покажет производительность в 1.3–1.7 раз меньшую, а на проекте в 1000 KSLOC следует ожидать, что производительность снизится в 1.6–3.0 раза .
Большой объем кода так же потребует большего количества людей на его сопровождение. Поскольку, даже если будет выявляться только несколько критических ошибок в год, то для того чтобы их исправить в приемлемые сроки, например, за 24 часа, в продукте общим объемом в 1000 KSLOC то один программист с этим не справится. Это связано с тем, что для того чтобы исправить ошибку в ограниченные сроки необходимо оперативно выявить и устранить ее причину, а для этого надо хорошо знать архитектуру и код программного продукта. Чтобы эффективно сопровождать продукт подобного объема необходимо иметь в «горячем» резерве примерно 20 разработчиков, потому что 50 KSLOC, на мой взгляд, это предельный объем кода, который может удерживать в голове и эффективно сопровождать один человек. И еще проблема: чем этих людей занимать в свободное от исправлений ошибок время, если нет новых проектов развития продукта.
Следующий важный показатель состояния проекта — это средняя производительность, отношение текущего размера проекта к фактическим затратам по проекту. С. Макконнелл приводит следующие показатели (минимальное, максимальное и среднее значение) производительности в KSLOC на один чел.*мес. фактических затрат для стандартных типов проектов объемом в 100 KSLOC:
300-7000 (800) — интранет система. 200-7000 (600) — бизнес система. 100-2000 (300) — Интернет система. 50-600 (100) — системное ПО, телекоммуникации. 20-300 (50) — системы реального времени.
Высокая производительность в проекте — это далеко не всегда хороший признак. Приходилось встречаться с проектами, в которых вследствие активного применения метода «copy+past», средняя производительность в разработке бизнес системы достигала 2000 SLOC/чел.*мес.
Однако для реализации требуемого функционала было написано в 3–4 раза больше кода, чем это могло бы потребоваться при адекватной проработке архитектуры.
Еще одна группа количественных показателей, которые следует наблюдать в ходе реализации проекта, характеризует качество программного продукта:
Дефектность продукта — количество выявленных дефектов на единицу объема продукта (например, KSLOC). Доля не устраненных дефектов — отношение количества незакрытых максимально критичных и критичных дефектов к количеству выявленных несоответствий. Средние затраты на сопровождение — средние трудозатраты на исправление одного дефекта. Высокое значение этого показателя может свидетельствовать о некачественной архитектуре программного продукта. Документированность кода — определяет процент строк исходного кода с комментарии по отношению к общему количеству строк.
Следует подчеркнуть, что наблюдать надо за средними по проекту значениями показателей, и ни в коем случае не пытаться измерять индивидуальные характеристики производительности и качества. Главные причины, почему это не следует делать, заключаются в том, что, во-первых, в этом случае вместо слаженной командной работы мы получим личную конкуренцию, а, во-вторых, наиболее «продвинутые» разработчики станут работать на формальные показатели, а не на достижение целей проекта.
Если команда действительно состоялась, то для нее характерна коллективная ответственность за достижение общих целей. И, как пишет, Т.Демарко , «менеджер проекта должен занимать очередь, чтобы покритиковать сотрудника, не выполняющего свои обещания», поскольку в правильной команде для этого всегда найдется масса желающих.
Проект и организационная структура компании
Организационная структура компании отражает ее внутреннее устройство, потоки управляющих воздействий, распределение труда и специфические особенности производства. Функциональная и проектная организации — противоположные полюса, а матричная организация — промежуточные состояния. Нет одной лучшей организационной структуры. Нет смысла противопоставлять функциональные структуры и проектные организации.
Синоним функциональной структуры — иерархическая структура (Рисунок 7).
Рисунок 7. Функциональная структура
Функциональная структура имеет следующие особенности:
Сохраняется принцип единоначалия Понятные и стабильные условия работы Хорошо приспособлены для операционной деятельности. Специализация подразделений позволяет накапливать экспертизу. Затруднено принятие решений и коммуникации между исполнителями. Осуществляются только через руководство. Управление сконцентрировано и держится на компетенции высшего руководства Как правило, неэффективен контроль за ходом проекта (нет целостной картины)
Функциональная структура предполагает многоуровневую иерархию. Руководители функциональных подразделений это начальники управлений, начальники подчиненных им служб, отделов, лабораторий, секторов, групп. А еще у каждого начальника есть заместитель и, порой, не один. Примеры: министерства, ведомства, научные институты и предприятия советского периода.
На другом краю спектра организационных структур находится проектная структура (Рисунок 8).
Рисунок 8. Проектная структура
В чисто проектных организациях:
Проект организуется как самостоятельное производственное подразделение. Персонал на проект набирается по временным контрактам. После завершения проекта персонал увольняется. Медленный старт. Опыт не аккумулируется. Команды не сохраняются.
Проектные организации не самые эффективные, но порой единственно возможные для выполнения проектов, которые физически удалённы от исполняющей организации, например, строительство нового нефтепровода.
В разработке ПО наиболее распространена матричная организация.
ОУП разрабатывает корпоративные политики и стандарты в области проектного управления, планирует и осуществляет профессиональное развитие менеджеров.
Одной из особенностей матричных структур является то, что они становятся «плоскими», исчезает многоступенчатая иерархия. Предприятие, как правило, делится на функциональные отделы, в которых работают специалисты разных категорий, напрямую подчиняющиеся начальнику отдела. Начальники лабораторий, секторов, групп упраздняются за ненадобностью. В матричных структурах роль начальника функционального подразделения в производственном процессе заметно снижается, по сравнению с функциональными структурами. В его компетенции остаются вопросы стратегического развития функционального направления, планирование и развитие карьеры сотрудников, вопросы материально-технического обеспечения работ. Следует учитывать, что такое перераспределение полномочий и ответственности от функциональных руководителей к менеджерам проектов часто служит источником конфликтов в компаниях при их переходе от функциональной структуры к матричной.
Проект — основа инноваций
Классическое управление проектами выделяет два вида организации человеческой деятельности: операционная и проектная.
Операционная деятельность применяется, когда внешние условия хорошо известны и стабильны, когда производственные операции хорошо изучены и неоднократно испытаны, а функции исполнителей определены и постоянны. В этом случае основой эффективности служат узкая специализация и повышение компетенции. «Если водитель трамвая начнет искать новые пути, жди беды».
Там, где разрабатывается новый продукт, внешние условия и требования к которому постоянно меняются, где применяемые производственные технологии используются впервые, где постоянно требуются поиск новых возможностей, интеллектуальные усилия и творчество, там требуются проекты.
Проект — временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.
У операционной и проектной деятельности есть ряд общих характеристик: выполняются людьми, ограничены доступностью ресурсов, планируются, исполняются и управляются. Операционная деятельность и проекты различаются, главным образом, тем, что операционная деятельность — это продолжающийся во времени и повторяющийся процесс, в то время как проекты являются временными и уникальными.
Ограничение по срокам означает, что у любого проекта есть четкое начало и четкое завершение. Завершение наступает, когда достигнуты цели проекта; или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается.
Уникальность также важное отличие проектной деятельности от операционной. Если бы результаты проекта не носили уникальный характер, работу по их достижению можно было бы четко регламентировать, установить производственные нормативы и реализовывать в рамках операционной деятельности (конвейер). Задача проекта — достижение конкретной бизнес-цели. Задача операционной деятельности — обеспечение нормального течения бизнеса.
Проект — это средство стратегического развития (Рисунок 5).
Цель — описание того, что мы хотим достичь. Стратегия — констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а цели в реальность.
Рисунок 5. Проект — средство стратегического развития
Таким образом, каждая работа, которую выполняет конкретный сотрудник, привязывается к достижению стратегических целей организации.
Проекты объединяются в программы. Программа — ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности.
Проекты и программы объединяются в портфели. Портфель — набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей.
Проекты и управление ими существовали всегда. В качестве самостоятельной области знаний управление проектами начало формироваться в начале ХХ века. В этой дисциплине пока нет единых международных стандартов. Наиболее известные центры компетенции:
¦ PMI, Project Management Institute, PMBOK — американский национальный стандарт ANSI/PMI 99-001-2004.
¦ IPMA, International Project Management Association. В России — СОВНЕТ.
Примерно 50 лет назад человечество начало жить в новой общественно-экономической формации, которая называется информационное или постиндустриальное общество. Мы живем в эпоху перемен, глобализации и интеллектуального капитала.
Эпоха перемен. Все в мире стало непрерывно и стремительно изменяться. Изобилие стало причиной острейшей конкуренции. Инновации — неотъемлемый атрибут нашего времени. «Если у вас медленный доступ в Интернет, вы можете навсегда отстать от развития информационных технологий». Практика должна постоянно перестраиваться применительно к новым и новым условиям. Пример.
Hewlett-Packard получает большую долю прибыли на товарах, которые год назад даже не существовали .
Глобализация. Всеобщая взаимозависимость и взаимосвязанность.
Транснациональные компании. Бизнес идет туда, где дешевле рабочая сила. Интернет. Конкуренция без границ. Пример. Google. За ночь любой из нас в принципе может создать многомиллионную компанию у себя в гараже. С помощью Интернета вы можете выйти на рынок, на котором более 100 млн. потребителей.
Все решают таланты. Простая мобилизация средств и усилий уже не может обеспечить прогресс. Вспомним Ф. Брукса , «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше». Идею богатства теперь связывают не с деньгами, а с людьми, не с финансовым капиталом, а с «человеческим». Рынок труда превращается в рынок независимых специалистов и его участникам все больше известно о возможных вариантах выбора. Работники интеллектуального труда начинают самостоятельно определять себе цену.
Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) — деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата.
Репродуктивная деятельность уходит в прошлое. В постиндустриальном обществе интеллект — основная производственная сила. Сегодня от 70 до 80% всего, что сегодня делается людьми, производится при помощи их интеллекта . В любом товаре, сделанном в США, доля зарплаты составляет 70 процентов. Но это в среднем по всем товарам. Что касается разработки ПО, то почти все, что в этой отрасли производится, создается при помощи интеллекта.
Все меньший объем человеческой деятельности может быть организован в виде повторяющихся операций. Традиционный пример операционной деятельности — это работа бухгалтерии.Но жизнь так стремительно изменяется, что сегодня, по утверждению сведущих людей, подготовка и сдача годового финансового отчета каждый раз реализуется как самостоятельный проект.
Проект это основа инноваций. Сделать то, до чего другие компании еще не додумались, сделать это как можно быстрее, иначе это сделают другие. Предложить потребителю более качественный продукт или такой продукт, потребность в котором потребитель даже не может пока осознать.
PSP/TSP
Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [,]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:
учитывать время, затраченное на работу над проектом; учитывать найденные дефекты; классифицировать типы дефектов; оценивать размер задачи; осуществлять систематический подход к описанию результатов тестирования; планировать программные задачи; распределять их по времени и составлять график работы. выполнять индивидуальную проверку проекта и архитектуры; осуществлять индивидуальную проверку кода; выполнять регрессионное тестирование.
Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:
установить собственные цели; составить свой процесс и планы; отслеживать работу; поддерживать мотивацию и максимальную производительность.
Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.
Рабочее планирование
Управление — это расчленение, анализ, определение последовательности действий, конкретная реализация. Управление фокусируется на нижнем уровне: как мне сделать это наилучшим образом? Эта компетенция руководителя определяет эффективность движения по выбранному пути. Как правило, менеджеры, вышедшие из программистов, без особого труда овладевают необходимыми управленческими навыками.
Базовое расписание, составленное на этапе планирования проекта, служит ориентиром для мониторинга состояния дел на макроуровне. Для оперативного управления проектом используется рабочий план. Рабочее планирование рекомендуется выполнять методом «набегающей волны»: работа, которую надо будет выполнить в ближайшей перспективе, подробно планируется на низшем уровне ИСР, а далеко отстоящая работа планируется на сравнительно высоком уровне ИСР.
Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист. Трудоемкость элементарной работы каждого из исполнителей должна быть от 4 до 20 чел.*час. Если трудоемкость задачи не укладывается в эти пределы, следует провести декомпозицию работы.
Для рабочего планирования целесообразно использовать систему управления задачами или багтрекинга, поскольку она позволяет задавать последовательность переходов задачи от исполнителя к исполнителю, управлять приоритетами работ и адекватно отслеживать их статус: анализ, проектирование, кодирование, тестирование, документирование. Работа должна считаться законченной только тогда, когда реализация требования протестирована и документирована.
В зависимости от уровня профессионализма и зрелости команды проекта распределение работ может осуществляться либо директивно с жесткой постановкой срока и контролем исполнения каждой задачи, либо эти полномочия делегируются исполнителям. В этом случае они сами выбирают задачи последовательно в соответствие с приоритетами, а их выполнение анализируется периодически на статус митинге.
Можно рекомендовать еженедельные собрания по статусу проекта всей команды или, если проект достаточно большой, то ключевых его частников: руководителей подпроектов и лидеров команд. Хорошее время для этого утро понедельника, поскольку участники проекта, особенно студенты, которые совмещают учебу и работу, часто работают в выходные, но, разумеется, не потому, что аврал, а потому что им так удобнее. Обсуждаются, как правило, всего три вопроса:
Угрозы и проблемы. Анализ результатов за неделю. Уточнение приоритетов задач на новую неделю.
Как правило, нет смысла оценивать процент реализации работы в промежуточном состоянии, поскольку, если задача передана в тестирование, то это вовсе не означает, что 70% работы сделаны. На этапе тестирования может быть выявлена ошибка проектирования и вся работа начнется заново. Рекомендация — использовать правило «50/100». Если работа по задаче начата, то следует учитывать ее, как выполненную на 50%. А 100% поучает только протестированная и документированная работа.
Расчет количества вьровненных функциональных точек (AFP)
Дальнейшая оценка в выровненных функциональных точках зависит от типа оценки. Начальное оценка количества выровненных функциональных точек для программного приложения определяется по следующей формуле:
AFP = UFP * VAF.
Она учитывает только новую функциональностсть, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:
DFP = (UFP + CFP) * VAF,
где CFP (conversion functional point) — функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.
Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:
EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB),
где
ADD — функциональные точки для добавленной функциональности; CHGA — функциональные точки для измененных функций, рассчитанные после модификации; VAFA — величина фактора выравнивания рассчитанного после завершения проекта; DEL — объем удаленной функциональности; VAFB — величина фактора выравнивания рассчитанного до начала проекта.
Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP.
Метод анализа функциональных точек ничего не говорит о трудоемкости разработки оцененного продукта. Вопрос решается просто, если компания разработчик имеет собственную статистику трудозатрат на реализацию функциональных точек. Если такой статистики нет, то для оценки трудоемкости и сроков проекта можно использовать метод COCOMO II.
Ресурсы
Для того чтобы понять, сколько будет стоить реализация программного проекта, требуется определить и оценить ресурсы необходимые для его выполнения:
Людские ресурсы и требования к квалификации персонала. Оборудование, услуги, расходные материалы, лицензии на ПО, критические компьютерные ресурсы. Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта.
Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. О том, как следует подходить к оценкам трудозатрат на реализацию проекта разработки ПО, мы будем подробно говорить в следующих лекциях. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100% .
Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом:
Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО
Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы.
Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час.
Исходя из эмпирической кривой Б. Боэма (Рисунок 15), численность команды, близкая к оптимальной, составила 10 человек, из них
Ресурсы проекта
8.1. Требования к персоналу
8.1.1. 1 — руководитель проекта,
8.1.2. 1 — технический лидер (архитектура, проектирование),
8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование),
8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению),
8.1.5. 3 — тестировщика.
8.2. Материальные и другие ресурсы
8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий
8.2.2. 2 серверных комплекса (для разработки и тестирования):
8.2.3. Сервер приложений с установленным BEA Weblogic AS
8.2.4. Сервер оперативной БД с установленной Oracle RDBMS
8.2.5. Сервер каталога с установленной OODB "Poet"
8.3. Лицензии на средства разработки и тестирования:
8.3.1. Oracle Designer — 1 лицензия
8.3.2. Symantec Visual Cafe for Java — 5 лицензий.
8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент).
8.4. Расходная часть бюджета проекта4
8.4.1. Разработка и сопровождение прикладного ПО:
8.4.1.1. 9000 чел.*час. * $40 = $360 000
8.4.2. Поставка оборудования и операционно-системного ПО:
8.4.2.1. 3 сервера * $10 000 = $30 000
8.4.3. Поставка базового ПО:
8.4.3.1. BEA Weblogic AS $20 000
8.4.3.2. Oracle RDBMS $20 000
Итого: $430 000
1 Проект стартовал в 2000 году, тема UML тогда была на слуху и даже оставались те, кто верил, что из модели на UML можно будет генерировать исходный код.
2 Таково было требование Заказчика, поскольку этот инструмент использовали его программисты, которым предполагалось передавать систему на сопровождение.
3 Еще один пример горячей темы и не оправдавшихся надежд — это объектно-ориентированные базы данных. У заказчика проекта уже были закуплены лицензии на эту базу данных и он очень хотел получить возврат от этих инвестиций.Поэтому ее использование в проекте стало одним из требований. К счастью, нам удалось быть достаточно убедительными и обосновать необходимость дополнительно использовать RDBMS Oracle для решения транзакционных задач. О том, к чему это привело, я подробно рассказал в своей книге: С. Архипенков, "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Москва, 2008.
4 Мы в данном разделе оцениваем себестоимость проекта. Определение продажной цены проекта не входит в рамки данного курса.
Риски
Риск — неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта .
Как правило, в случае возникновения негативного риска, почти всегда стоимость проекта увеличивается и происходит задержка в выполнении мероприятий, предусмотренных расписанием проекта. Управлению рисками проекта будет посвящена отдельная лекция.
На этапе инициации, когда нет необходимых данных для проведения детального анализа, часто приходится ограничиваться качественной оценкой общего уровня рисков: низкий, средний, высокий.
В случае нашего проекта-примера раздел «риски» будет выглядеть следующим образом.
Риски проекта
10.1. Задачи системы поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. Суммарный уровень рисков следует оценить выше среднего.
RUP
Унифицированный процесс (Rational Unified Process, RUP) был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику — поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.
Сроки
Ф. Брукс писал: «Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер».
Там же Брукс приводит исключительно полезную, но почему-то редко применяемую, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барии Боэмом (Barry Boehm) на основе анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м. (человеко-месяцев), пожно утверждать что:
Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)1/3. То есть оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в человеко-месяцах. Следствием является кривая, дающая оптимальную численность проектной команды (Рисунок 15). Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время. Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне зависимости от количества занятых в нем! (Рисунок 16)
Этот примечательный результат дает менеджеру программного проекта солидное подкрепление, когда высшее руководство требует принятия невозможного графика.
Рисунок 15. Закон Б.Боэма
Для сколь-нибудь серьезного программного проекта недостаточно определить только срок его завершения. Необходимо еще определить его этапы — контрольные точки, в которых будет происходить переоценка проекта на основе реально достигнутых показателей.
Контрольная точка — важный момент или событие в расписании проекта, отмечающее достижение заданного результата и/или начало / завершение определенного объема работы. Каждая контрольная точка характеризуется датой и объективными критериями ее достижения.
Как мы говорили ранее, современный проект разработки ПО должен реализовываться с применением инкрементального процесса. В этом случае контрольные точки должны соответствовать выпуску каждой промежуточной версии ПО, в которой будет реализована и протестирована определенная часть конечной функциональности программного продукта. В зависимости от сложности и масштаба проекта продолжительность одной итерации может составлять от 2 до 8 недель.
Рисунок 16. Следствия закона Б.Боэма
Соответствующий раздел концепции нашего проекта-примера будет иметь следующий вид.
Сроки проекта
9.1.03.03 старт
9.2. 28.11 завершение
9.3. Контрольные точки:
9.3.1. 15.04 ТЗ утверждено
9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).
9.3.3. 15.05 Монтаж оборудования у заказчика завершен .
9.3.4. 30.05 Базовое ПО установлено у заказчика.
9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика
9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную эксплуатацию утвержден
9.3.7. 28.11 Система передана в промышленную эксплуатацию.
SW-CMM
В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.
Данная модель определяет пять уровней зрелости процесса разработки ПО.
Начальный — процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей. Повторяемый — установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах. Определенный — процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект. Управляемый — собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных. Оптимизируемый — постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.
Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.
Управление приоритетами проектов
Эффективные процессы инициации программного проекта минимум наполовину определяют его будущую успешность. Недостаточное внимание именно этой фазе проекта неизбежно приводит к существенным проблемам при планировании, реализации и завершении проекта.
Инициация состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Процессы инициации часто выполняются вне рамок проекта и связаны с организационными, программными или портфельными процессами. В ходе процесса инициации уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. На этом этапе также выбирается менеджер проекта, если он еще не назначен, и документируются исходные допущения и ограничения. Эта информация заносится в Устав проекта и, если он одобряется, проект официально авторизуется.
Устав проекта — документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта.
В российской практике данный документ чаще называется Концепция проекта. Концепция (от лат. conceptio — понимание, система), определённый способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.
В компании, которая принимает решение о старте того или иного проекта разработки ПО, должна существовать единая система критериев для оценки его значимости. Система критериев должна позволять из множества возможных для реализации проектов выбрать наиболее приоритетные для компании.
Приоритет любого проекта должен определяться на основе оценки трех его характеристик:
Финансовая ценность. Стратегическая ценность. Уровень рисков.
Шкала оценки финансовой ценности проекта может выглядеть следующим образом:
Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны. Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет.
Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания. Средняя. Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес. Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.
Например. Финансовая ценность проектов разработки ПО, проектов внедрения или сопровождения, которые выполняются в соответствие с заключенными коммерческими договорами, может быть оценена как высокая. Проект планового развития функциональности продуктов в соответствии с требованиями рынка, инициируемое менеджером продукта на основе анализа предложений отделов маркетинга, консалтинга, продаж и технической поддержки, может получить оценку финансовой ценности выше среднего, а проекты изменения технологических процессов или проекты внутренней автоматизации могут иметь среднюю финансовую ценность.
Одной финансовой ценности для определения приоритета проекта недостаточно. Например, ни одна компания разработчик ПО не возьмется за автоматизацию нелегального оборота наркотиков, если это не соответствует стратегии ее бизнеса. Поэтому, важным показателем приоритета проекта является его соответствие стратегическим целям компании.
Шкала оценки стратегической ценности проекта может иметь следующий вид:
Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет. Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года. Средняя. Поддерживается доверие рынка к компании.
Повышает мнение клиентов о качестве предоставляемых услуг или способствует выполнению обязательств перед несколькими клиентами. Конкуренты уже имеют или способны повторить новые возможности в пределах года. Низкая. Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.
Третьим обязательным показателем приоритета проекта должна быть оценка уровня его риска. Ни один проект, который имеет даже самую высокую оценку финансовой выгодности, не будет запущен в производство, если достижение этой сверхвыгоды имеет минимальные шансы.
Примерная шкала оценки уровня рисков проекта может иметь следующий вид:
Низкий. Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы. Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе. Выше среднего. Цели проекта недостаточно четки. Задачи системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе, в отношении которой крайне мало ясности. Технологии имеют неподтвержденную стабильность.
Если компания уделяет мало внимания управлению приоритетами своих проектов, то это приводит к переизбытку реализуемых проектов, перегруженности исполнителей, постоянным авралам и сверхурочным работам и, как следствие, к низкой эффективности производственной деятельности.При старте нового проекта с высоким приоритетом, компания должна остановить или закрыть менее значимые проекты, чтобы обеспечить новый проект необходимыми ресурсами, а не пытаться сделать все и сразу за счет интенсификации работ, как правило, это не получается.
Управление проектом, направленное на снижение рисков
На стадии инициации проекта оценка его трудоемкости имеет погрешность от -50% до +100% . Это, если оценка хорошая! А если плохая, то неопределенность, а, следовательно, и риски сорвать сроки и превысить плановую трудоемкость, могут быть в разы больше. Если не прилагать специальных усилий этот «дамоклов меч» неопределенности будет висеть над проектом на всем его протяжении (Рисунок 31).
Проектом следует управлять так, чтобы риски несвоевременной сдачи и перерасхода ресурсов постоянно снижались.
Ранее мы уже говорили о том, что 80% ценности разработки обусловлена лишь 20% требований к продукту, без реализации которых продукт для заказчика становится просто ненужным. Остальные требования, как правило, так называемые «украшательства», от части которых заказчик, как правило, может отказаться, чтобы получить проект в срок. Поэтому следует в первую очередь реализовывать ключевые функциональные требования.
Но есть и еще архитектурные риски. Известно, что закон Парето применим и к потреблению вычислительных ресурсов: 80% потребления ресурсов (время и память) приходится на 20% компонентов. Поэтому, необходимо реализовывать архитектурно-значимые требования так же в первую очередь, создавая «представительный» прототип будущей системы, который «простреливает» весь стек, применяемых технологий. Прототип позволит измерить и оценить общесистемные свойства будущего продукта: доступность, быстродействие, надежность, масштабируемость и проч. (Рисунок 32)
Ошибка — реализовывать сначала легкие требования, чтобы продемонстрировать быстрый прогресс проекта.
Рисунок 31. Неопределенность не уменьшается, если управление не направлено на раннее разрешение рисков
Рисунок 32. Определение приоритетов требований на первые итерации проекта
Управление, нацеленное на снижение рисков, позволяет существенно снизить неопределенность на ранних стадиях проекта (Рисунок 33).
Рисунок 33. Управление, нацеленное на снижение рисков, позволяет уменьшать неопределенность
Проработка ключевых функциональных требований и детальное планирование их реализации позволяет уменьшить разброс начальных оценок, примерно, в 2 раза: от -30% до +50%. Детальное проектирование и разработка прототипа будущей системы позволит получить еще более точные оценки общей трудоемкости: от -10% до +15%.
Может оказаться так, что по результатам прототипирования, уточненные оценки суммарной трудоемкости окажутся неприемлемыми. В этом случае проект придется закрыть досрочно, но потери при этом, будут значительно меньше, чем в случае, если то же самое произойдет, когда проект уже в 2 раза превысит первоначальную оценку трудоемкости.
Если с заказчиком не удается найти взаимоприемлемое решение при первоначальной оценке проекта, то разумно попытаться договориться о выполнении проекта в 2 этапа с самостоятельным финансированием:
Исследование. Бизнес-анализ, уточнение требований, проектирование и прототипироание решения, уточнение суммарных оценок трудозатрат. Эта работа, как правило, требует 10 % общих трудозатрат и 20% времени всего проекта. Непосредственно реализация. Если уточненные оценки трудозатрат окажутся приемлемыми для заказчика.
С вменяемыми заказчиками это часто удается.
Уточнение содержания и состава работ
«Если не получается проглотить слона целиком, то его надо порезать на отбивные». Человечество пока не придумало ничего более эффективного для решения сложной задачи, чем анализ и ее декомпозиция на боле простые подзадачи, которые, в свою очередь, могут быть разделены на еще боле простые подзадачи и так далее. Получается некоторая иерархическая структура, дерево, в корне которого находится проект, а на листьях элементарные задачи или работы, которые надо выполнить, чтобы завершить проект в условиях заданных ограничений. Согласно :
Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) — ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.
Основой для разработки ИСР служит концепция проекта, которая определяет продукты проекта и их основные характеристики. ИСР обеспечивает выявление всех работ, необходимых для достижения целей проекта. Многие проекты проваливаются не от того, что у них нет плана, а от того что в этом плане забыты важные работы, например тестирование и исправление ошибок, и продукты проекта, например пользовательская документация. Поэтому, если ИСР составлена корректно, то любая работа, которая в нее не вошла не может считаться работой по проекту.
ИСР делит проект на подпроекты, пакеты работ, подпакеты. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку сроков и объемов работ. ИСР должна включать все промежуточные и конечные продукты.
Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы:
Техническое задание Эскизный проект Технический проект Рабочий проект Внедрение
Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты.
Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход не эффективен. Как мы уже говорили, современный процесс разработки коммерческого ПО должен быть инкрементальным. Это означает, что на верхнем уровне декомпозиции нашего проекта должны находиться продукты проекта, а на следующем уровне — компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на «фичи» — функции, которые они должны реализовывать.
Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например, подсистема логирования, безопасности, библиотека визуальных компонентов GUI.
При составлении базового плана работ не стоит стремиться максимально детализировать все работы. ИСР не должна содержать слишком много уровней, достаточно 3-5. Например, ИСР нашего проекта-примера разработки «Автоматизированной системы продажи документации» может выглядеть следующим образом (Рисунок 17).
1. Проект разработки «Автоматизированной системы продажи документации»
1.1.Подготовка технического задания на автоматизацию
1.1.1.1. Проведение аналитического обследования
1.1.1.2. Разработка функциональных требований
1.1.1.3. Разработка требований базовому ПО
1.1.1.4. Разработка требований к оборудованию и к операционно-системному ПО
1.1.1.5. Согласование и утверждение ТЗ
1.1.1.6. ТЗ утверждено
1.2. Поставка и монтаж оборудования
1.2.1.Разработка спецификации на оборудование 1.2.2.Закупка и поставка оборудования
1.2.3. Монтаж оборудования
1.2.4. Установка и настройка опреационно-системного ПО
1.2.5. Монтаж оборудования завершен
1.3. Поставка и установка базового ПО
1.3.1 . Разработка спецификаций на базовое ПО 1.3.2.Закупка базового ПО
1.3.3. Развертывание и настройка базового ПО
1.3.4. Базовое ПО установлено у заказчика
1.4. Разработка и тестирование прикладного ПО
1.4.1. Разработка спецификаций на прикладное ПО
1.4.2. Установка и конфигурирование рабочей среды
1.4.3. Проектирование и разработка ПО
1.4.3.1. Авторизация и аутентификация пользователей.
1.4.3.2. Разработка подсистемы заказа документации
1.4.3.2.1. Просмотр каталога продуктов.
1.4.3.2.2. Поиск продуктов по каталогу.
1.4.3.2.3. Заказ выбранных продуктов.
1.4.3.2.4. Просмотр информации о статусе заказа.
1.4.3.2.5. Информирование клиента об изменении статуса заказа.
1.4.3.2.6. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).
1.4.3.3. Разработка подсистемы обработки заказов
1.4.3.3.1. Просмотр и обработка заказов исполнителями из службы продаж.
1.4.3.3.2. Просмотр статистики поступления и обработки заказов за период.
1.4.3.3.3. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика
1.4.3.4. Разработка подсистемы сопровождения каталога 1.4.3.4.1. Подготовка и сопровождение каталога продукции.
1.4.3.5. Исправление ошибок
1.4.4. Тестирование ПО
1.4.4.1. Раунд 1
1.4.4.2. Раунд 2
1.4.4.3. Раунд 3
1.4.4.4. Выходное тестирование
1.4.5. Документирование прикладного ПО
1.5. Обучение пользователей
1.5.1 .Подготовка учебных курсов 1.5.2.Обучение сотрудников Отдела 123 1.5.3.Обучение руководства ОАО XYZ 1.5.4.Обучение администраторов системы
1.6. Ввод в опытную эксплуатацию
1.6.1. Развертывание и настройка прикладного ПО
1.6.2. Проведение приемо-сдаточных испытаний
1.6.3. Акт передачи системы в опытную эксплуатацию утвержден
1.7. Сопровождение системы в период опытной эксплуатации
1.8. Система передана в промышленную эксплуатацию
Рисунок 17. Иерархическая структура работ проекта разработки «Автоматизированной системы продажи документации» (курсивом выделены контрольные точки проекта)
Должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). Для каждого пакета работ должен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компании-исполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами.
ИСР является одним из основных инструментов (средств) в механизме управления проектом, с помощью которого измеряется степень достижения результатов проекта. Важнейшая ее функция это обеспечить консистентное представление всех у частников проекта относительно того, как будет делаться проект. В последующем базовый план будет служить ориентиром для сравнения с текущим исполнением проекта и выявления отклонений для целей управления.
Выбор модели процесса
Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).
Таблица 1. Плюсы и минусы тяжелых и легких моделей процессов разработки ПО
| Тяжелые | Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды.
Отсутствуют ограничения по объему и сложности выполняемых проектов. | Требуют существенной управленческой надстройки.
Более длительные стадии анализа и проектирования. Более формализованные оммуникации. |
|
| Легкие | Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями.
Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации. |
Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды.
Объем и сложность выполняемых проектов ограничены. |
Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа «Карго» — религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения («муштру») и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи «USA». Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.
Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО» проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет [, ].
Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что :
У каждого проекта должна быть своя модель процесса разработки. У каждой модели — свое время.
Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х П» (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.
Рисунок 4. «Закон 4-х П». Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала
Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.
и идеи, выраженные на языке
То, что производят программисты нематериально — это коллективные мысли и идеи, выраженные на языке программирования. В силу уникальности отрасли опыт, накопленный в отраслях материального производства, мало способствует успеху в управлении программным проектом. Прямые аналогии с этими отраслями не работают. Управлять разработкой ПО надо иначе.
Не существует единственного правильного процесса разработки ПО. Эффективный производственный процесс должен основываться на итеративности, инкрементальности, самоуправляемости команды и адаптивности. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.
Чтобы программный проект стал успешным, необходимо:
Четко ставить цели. Определять способ достижения целей. Контролировать и управлять реализацией. Анализировать угрозы и противодействовать им. Создавать команду.
Проект — этот средство стратегического развития. Цель — описание того, что мы хотим достичь. Стратегия — констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а цели в реальность.
Участников типового проекта разработки ПО можно условно разделить на пять групп ролей:
Анализ. Извлечение, документирование и сопровождение требований к продукту. Управление. Определение и управление производственными процессами. Производство. Проектирование и разработка ПО. Тестирование. Тестирование ПО. Обеспечение. Производство дополнительных продуктов и услуг.
У программного проекта имеется четыре фактора, которые определяют его успешность:
Выполнен в соответствие со спецификациями. Выполнен в срок. Выполнен в пределах бюджета. Каждый участник команды уходил с работы в 18:00 с чувством успеха.
Эффективные процессы инициации программного проекта во многом определяют его будущую успешность. Недостаточное внимание этой фазе проекта неизбежно приводит к существенным проблемам при планировании, реализации и завершении.
Концепция проекта это ключевой документ, который используется для принятия решений в ходе всего проекта, а также на фазе приемки — для подтверждения результата.
Приоритет проекта определяется на основе оценки трех показателей:
Финансовая ценность. Стратегическая ценность. Уровень рисков.
На верхнем уровне ИСР должны находиться не процессы, а продукты проекта, на следующем уровне — компоненты из которых эти продукты состоят. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО.
Помимо работ, непосредственно направленных на создание программного обеспечения, в плане проекта должны быть предусмотрены необходимые ресурсы для обеспечения работ по следующим процессам:
управление содержанием; управление конфигурациями, управление качеством, управление рисками, управление проектом.
В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей.
Отказываться от управления проектными рисками это все равно, что в кинотеатре не иметь огнетушителей и плана эвакуации на случай пожара.
Все, что мы делаем, управляя проектом разработки ПО, должно быть направлено на борьбу с рисками не уложиться в срок, перерасходовать ресурсы, разработать не тот продукт, который требуется.
Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.
Главные причины провала программных проектов:
Требования заказчика отсутствуют / не полны / подвержены частым изменениям. Отсутствие необходимых ресурсов и опыта. Отсутствие рабочего взаимодействия с заказчиком. Неполнота планирования. «Забытые работы». Ошибки в оценках трудоемкостей и сроков работ.
Оценка трудоемкости должна быть вероятностным утверждением. Это означает, что для нее существует некоторое распределение вероятности, которое может быть очень широким, если неопределенность высокая, или достаточно узким, если неопределенность низкая.
Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат.
Если собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:
FPA IFPUG — метод функциональных точек, метод COCOMO II, Constructive Cost Model.
Не реалистичность оценок один из серьезнейших демотивирующих факторов для участников проектной команды. Недооценка приводит к ошибкам планирования и неэффективному взаимодействию. Агрессивные сроки, постоянное давление, сверхурочные, авралы служат причиной того, что затраты на проект растут экспоненциально и неограниченно.
Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Для того чтобы стать лидером, необходимо:
Признание командой профессиональной компетентности и превосходства лидера. Полное доверие команды к действиям и решениям лидера, признание его человеческих качеств, убежденность в его честности, порядочности, вера в его искренность и добросовестность.
Мотивация должна начинаться с подбора сотрудников в команду. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.
Рабочая группа прежде, чем она станет эффективной командой, должна пройти четыре обязательных последовательных стадии: 1) Forming, 2) Storming, 3) Norming, 4) Performing.
Если руководитель не будет прилагать дополнительные усилия команда, рано или поздно, начнет «сползать» с плато наивысшей эффективности в состояние застоя и стагнации. Задача менеджера на этом этапе — «точить пилу»: поддерживать требуемый уровень мотивации, быть штурманом, искать новые пути и открывать новые возможности. Четыре стадии развития команды должны циклически повторяться, чтобы обеспечить непрерывный рост производительности.
Для оперативного управления проектом используется рабочий план. Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист.
Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1–2 недели. Для каждого измеримого показателя должны быть определены его плановые значения и допустимые отклонения.
В состав измеряемых показателей должны входить следующие характеристики проекта:
Освоенный и плановый объемы работ и фактические затраты по проекту. Показатели прогресса и стабильности проекта. Размер продукта. Производительность. Показатели качества программного продукта.
По результатам проекта обязательно должна быть реализована обратная связь. Цель — сохранить результаты, знания и опыт, полученные в проекте, для более эффективного и качественного выполнения аналогичных проектов в будущем.
Растите профессионалов
Работа менеджера проекта подобна труду садовника.
Подобно тому, как садовник любовно отбирает наиболее подходящие растения для своего будущего сада, менеджер набирает людей, наиболее соответствующих целям проекта.
Подобно тому, как садовник ищет лучшую почву для каждого растения с учетом его особенностей, менеджер для каждого участника проектной команды ищет наиболее подходящую для него задачу.
Подобно тому, как садовник тщательно лелеет своих питомцев, оберегает их от вредных воздействий, следит за тем, чтобы ни одно растение не затеняло другое, а только дополняло его и способствовало его росту, менеджер проекта терпеливо работает с каждым участником проектной команды, способствуя его правильному развитию, охраняя от внешних и внутренних потрясений, для того, чтобы максимально раскрыть его индивидуальные способности и увеличить отдачу от них, с удовлетворением отмечает каждое новое достижение.
«Что посеешь, то и пожнешь» — этот закон одинаково применим как к труду садовода, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.
Завершение проекта
Главная цель этой фазы — проверить и передать заказчику результат проекта. Для этого необходимо выполнить приемо-сдаточные работы в соответствии с процедурой приемки, которая должна быть определена заранее на самой ранней стадии проекта.
Результаты проекта должны быть переданы во внедрение или сопровождение, или должным образом законсервированы для дальнейшего использования. Не должно оставаться «зависших» работ по проекту. Все линейные руководители всех участников должны быть извещены о завершении работ по проекту, и освобождении сотрудников.
Важная задача, которая должна быть решена на данной фазе, это реализация обратной связи по проекту. Цель — сохранить результаты, знания и опыт, полученные в проекте, для более эффективного и качественного выполнения аналогичных проектов в будущем. Необходимо архивировать все результаты, документировать опыт, уроки по проекту и предложения по улучшению технологии выполнения работ и управления проектами.
Все проекты и в особенности провальные проекты должны завершаться итоговым отчетом, если компания не хочет «наступать на одни и те же грабли». Помним о том, что «вчерашние проблемы, это сегодняшние риски».
Итоговый отчет должен содержать следующую информацию:
Итоги проекта: Достижение целей проекта Дополнительные полезные результаты Фактические сроки Фактические расходы Обоснование отклонения от целей Отклонения результатов от требований Уроки проекта Проблемы проекта и способы их решения Материалы программные компоненты для последующего использования Предложения по изменению технологий или стандартов компании
На фазе завершения желательно реализовать и план мотивации участников проектной команды, поскольку отложенное вознаграждение мотивирует существенно слабее.
Жизненный цикл проекта. Фазы и продукты
Ранее уже отмечалось, что каждый программный продукт имеет свой жизненный цикл, в который проект разработки очередного релиза входит как одна из фаз. Аналогично, каждый проект разработки ПО имеет свой собственный жизненный цикл, который состоит из четырех фаз (Рисунок 12).
Рисунок 12. Жизненный цикл и основные продукты программного проекта
На фазе инициации проекта необходимо понять, что и зачем мы будем делать — разработать концепцию проекта. Фаза планирования определяет, как мы будем это делать. На фазе реализации происходит материализация наших идей в виде документированного и протестированного программного продукта. И, наконец, на фазе завершения мы должны подтвердить, что мы разработали именно тот продукт, который задумали в концепции проекта, а также провести приемо-сдаточные испытания (ПСИ) продукта на предмет соответствия его свойств, определенным ранее требованиям.
Как правило, редкий проект выполняется в соответствие с первоначальными планами, поэтому важным элементом фазы завершения является «обратная связь»: анализ причин расхождения и усвоение уроков на будущее. Помним, что управляющая система без обратной связи не может быть устойчивой.
Более подробно о каждой фазе проекта и их продуктах будет рассказано в последующих лекциях.
Завершая обзор управления проектами «с высоты птичьего полета», необходимо упомянуть еще об одной особенности проекта по сравнению с операционной деятельностью. Если в операционной деятельности ресурсы расходуются более-менее равномерно по времени, то в проектном управлении расходование ресурсов в единицу времени имеет явно выраженное колоколообразное распределение (Рисунок 13)
Рисунок 13. Распределение ресурсов по фазам проекта
Проект часто начинается с идеи, которая появляется у одного человека. Постепенно, по мере формулирования, анализа и оценки этой идеи, привлекаются дополнительные специалисты. Еще больше участников требуется на фазе планирования проекта. Пик потребления ресурсов приходится на фазу реализации.
В современных моделях разработки ПО реализация осуществляется на основе сочетания итеративного и инкрементального подходов.
Итеративность предполагает, что требования к системе и ее архитектура прорабатываются не один раз, а постепенно уточняются от итерации к итерации. Это означает, что на каждой итерации происходит полный цикл процессов разработки: уточнение требований, проектирование, кодирование, тестирование и документирование.
Инкрементальность состоит в том, что результатом каждой итерации является версия ПО, которая реализует часть функциональности будущего программного продукта и может быть введена в тестовую или опытную эксплуатацию, а также оценена заказчиком и будущими пользователями. Это означает, что после каждой итерации происходит прирост требуемого функционала, а нереализованных функций будущего продукта остается все меньше.
Сочетание итеративности и инкрементальности обеспечивает эффективность разработки и существенное снижение рисков по ходу проекта. Об этом мы еще будем говорить.
На последней фазе происходит постепенное высвобождение участников проектной команды. Следует помнить, что проект должен иметь четкое окончание во времени, после которого все работы по проекту закрываются, и на проект перестают тратиться ресурсы. Не должно оставаться «зависших» работ.
