Руководство проектами по разработке по в компании - Большая энциклопедия инструкций и руководств

Управление проектами по разработке программного обеспечения. Проблемы и пути решения

Время на прочтение
15 мин

Количество просмотров 26K

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

Внимание, статья от 2001 года!

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

Вступление

Сегодня существует достаточно большое количество стандартных процессов и методологий, применяя которые фирма получает ту или иную модель производства ПО. Самыми известными из них являются CMM (Capability Maturity Model) и серия стандартов ISO 9000. Как правило, организации внедряют эти процессы исключительно для того, чтобы получит сертификат соответствия своего процесса одному из вышеупомянутых стандартов. Однако, как не парадоксально это звучит, зачастую попытки внедрить один из вышеупомянутых процессов пагубно сказывались на стабильности работы фирмы.

В последние 3 года на западе стали модными термины «легковесный процесс», «адаптивный процесс», «единый рациональный процесс» и «экстремальное программирование». Что это такое? И почему иногда эффект от внедрения ISO9000 оказывается негативным? Какой процесс предпочесть и какими критериями руководствоваться при выборе процесса? Остальная часть статьи является попыткой найти ответы на эти и другие вопросы.

Классификация проектов

Модель и параметры процесса производства ПО в значительной мере зависит от типа проекта. У каждой команды есть свои заказчики, с которыми сложились те или иные отношения.

«Свой» заказчик

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

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

Продукт под заказ

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

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

Тиражируемый продукт

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

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

Аутсорсинг

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

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

Проблемы

Организация процесса

Наиболее типовую в России модель процесса производства программного обеспечения можно охарактеризовать следующим образом: «Каждый разработчик выбирает тот или иной метод или технику для создания программ в соответствии с собственными привычками и пристрастиями. Практически полное отсутствие четкой ответственности за выполнение тех или иных функций. Качество программного обеспечения является случайной величиной и напрямую зависит от способностей отдельных сотрудников компании. Практически все зависит от инициативы и деловых качеств нескольких личностей». Эта формулировка практически полностью соответствует 1 уровню CMM под названием «начальный». По некоторым источником, 2 года назад доля фирм-производителей программного обеспечения, использующих эту модель, составляла свыше 70%.

Вот какие выводы делает Мартин Фаулер [4], сравнивая процесс производства программного обеспечения с классическими типами строительства и производства:

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

Требования и итеративность

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

Фаулер пишет: «В процессе производства программного обеспечения все зависит от требований. Если вы не можете добиться устойчивости требований, вы не сможете создать предсказуемый план». Как же быть? С одной стороны требования должны быть устойчивыми, а с другой они будут неизбежно меняться в ходе проекта.

Ключ ко всему – итеративный процесс производства.

Пути решения

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

Линейный и итеративный жизненные циклы создания ПО

Линейный жизненный цикл создания программного обеспечения (также известный как «Водопад») предусматривает последовательное прохождения 6 этапов: обследование, постановка задачи, проектирование, программирование, тестирование и внедрение. Такой жизненный цикл предполагает неизменность требований, предъявляемых к ПО, с момента постановки задачи до момента подписания акта о внедрении разработанного продукта, каким бы длительным не был этап разработки программного обеспечения.

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

Современный бизнес очень динамичен, и требования к электронному магазину изменятся не один десяток раз в течение процесса его разработки. И каждый раз придется переписывать значительную часть кода и приводить множество документов в соответствие с новыми обстоятельствами. А это, как правило, незапланированные потери времени, ресурсов и усилий, что, в итоге, выливается в срыв сроков и производство программного обеспечения, не удовлетворяющего (или не полностью удовлетворяющего) требованиям заказчика. Где же выход? Выход, в данном случае, один – использование итеративного цикла создания ПО. Такой цикл представляет собой набор итераций, в рамках каждой из которых проект проходит через все 6 вышеупомянутых этапов. Итеративный цикл позволит выявлять серьезные проблемы на самых ранних этапах разработки, управлять рисками, раньше начинать тестирование т.п. Такой процесс становится более динамичным и управляемым.

Существующие методологии

В мире существует довольно много типовых процессов производства программного обеспечения. ISO9001, ISO12207, ISO15504, CMM (Capability Maturity Model), MSF (Microsoft Solution Framework), RUP (Rational Unified Process), SCRUM, XP (eXtremal Programming), Crystal Clear, ASD (Adaptive Software Development), Lean Development – все это разновидности процессов производства программного обеспечения, семейства процессов и методологии. Под методологией понимается набор методов, практик, метрик и правил, используемых в процессе производства ПО. Согласно Алистеру Кобурну [1], методология нужна для того, чтобы:

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

По определению Джима Хайсмита [16] «Настоящее назначение методологий – это увеличение производительности, обеспечивающее решения для заказчиков »

Методологии можно условно разбить на 3 категории – тяжелые, легкие и средние. Упрощенно, каждая из которых предназначена для работы в условиях, соответственно, больших, малых и средних проектов. Однако, как мы увидим в последствии, это не совсем так.

Согласно Алистеру Кобурну [1]:

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

Все вышеприведенные определения носят концептуальный характер, поскольку не существует количественных метрик для данных величин.

Первая категория методологий появилась на свет раньше всех и является неотъемлемой частью моделей качества программного обеспечения. Тяжелые методологии отличаются тем, что охватывают все аспекты деятельности компании, производящей программное обеспечение – от управления требованиями и планирования процесса до регламентирования взаимоотношений с субподрядчиками и описания требований к вспомогательным процессам. Все методологии данной категории нетерпимы к изменениям и рассматривают людей как обычный ресурс. Примеры: CMM, ISO9000, SPICE.

Вторая категория методологий появилась на свет в качестве некоторой совокупности методов и практик, применявшихся небольшими командами разработчиков в успешных проектах. Здесь огромное значение уделяется взаимоотношениями между людьми внутри команды, учитываются вопросы терпимости и другие психологические аспекты. Все процессы данной категории предусматривают итерационный жизненный цикл разработки ПО. Если попытаться сформулировать основной смысл легких методологий, то получится следующее: «Обеспечение максимальной скорости и качества разработки ПО при минимуме ограничений и условностей». В частности, во всех легких методологиях предусмотрен лишь необходимый минимум документов, т.к. отдается должное принципу «Документация – это не есть понимание». Существенным отличием данных методологий от методологий первого типа является отношение к планированию. Лучше всего суть этого отличия выразил Джим Хайсмит: «В традиционном планировании отклонения от плана являются ошибками, которые должны быть устранены. Однако, в адаптивном процессе, отклонения ведут нас к правильному решению»[4]. Примеры: SCRUM, XP (eXtremal Programming), Crystal Clear.

В третью категорию методологий попадают так называемые «универсальные» процессы. Самым ярким и известным представителем данной категории является RUP. Основной характеристикой подобных процессов является масштабируемость – т.е. процесс может быть настроен как на работу в малой команде над небольшим проектом, так и в большой команде над большим и серьезным проектом.

Анализ применимости процессов

Алистер Кобурн, автор Crystal, является одним из наиболее известных современных специалистов, сделавших объектом своих исследований методологии. Результатом его исследований в данной области является книга «Agile Software Development»[1], в которой автор анализирует процесс производства ПО с различных точек зрения. Алистер Кобурн является автором концепции «Разработка программного обеспечения – это совместная игра изобретения и взаимодействия». Он выделяет 2 цели у этой игры:

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

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

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

Рисунки 1-3 иллюстрируют закономерности в использовании разных методологий командами разработчиков различной численности.

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

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

Рисунок 3 отражает потолок возможностей команды при использовании методологий разного веса.

Классификация

Кобурн разработал классификацию [1] типов проектов, основываясь на двух параметрах – размер проекта и его степень критичности. Различаются следующие степени критичности:

потеря комфорта (Loss of comfort). Потеря комфорта означает, что в случае ошибки в системе, жизнь людей немного осложнится, они должны буду делать больше ручной работы, или звонить друг другу, чтобы восполнить прерванный канал связи. Программы поддержки корпоративной инфраструктуры обычно лежат в этой области;
потеря существенного количества денег (Discretionary money). Означает потерю некоторого количества денег или какого-либо другого материального эквивалента, но только в рамках дискомфорта. Обычно, складские системы лежат в данной области;
невосполнимая потеря денег (Irreplaceable money, essential money). Означает потерю денег или их эквивалента в объемах, сравнимых с банкротством предприятия. Система управления национальным банком лежит в этой области;
потеря жизни (Loss of life). Означает, что в случае ошибки такой системы возникает опасность для жизни человека. Системы управления атомной станцией, космическим кораблем и самолетом лежат в данной области.

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

Выводы

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

Свой заказчик

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