Лекция №1. Управление программными проектами

Прежде, чем приступить к разбору Яндекс Трекера, необходимо освежить знания по управлению проектами. Существуют различные определения проекта:

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

Из вышеперечисленных определений, можно выделить следующие аспекты проекта:

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

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

Управление проектами — деятельность по решению задач и достижению поставленных целей проекта.

Управление проектами – применение знаний, навыков, инструментов и техник при выполнении проектной деятельности для достижения требований проекта и запланированных результатов.

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

Основные отличия разработки ПО от других видов управления проектами:

  • Конечный результат проекта по разработке программного обеспечения нематериален
  • Недостаточность накопленного в данной области опыта
  • Быстрое изменение используемых в проекте технологий
  • Опыт управления проектами по разработке программного обеспечения часто не может быть применён к другим проектам

Рассмотрим методы разработки программного обучения.

«Waterfall Model» (каскадная модель или «водопад»)

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

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

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

«Incremental Model» (инкрементная модель)

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

Каждая часть представляет собой готовый элемент. Иногда его можно даже использовать отдельно. Как правило, он разрабатывается так, чтобы уже не переделывать его. Именно поэтому и используется каскадная модель внутри инкрементной модели.

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

«Iterative Model» (итеративная или итерационная модель)

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

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

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

«Agile Model» (гибкая методология разработки) Гибкие методики разработки (англ. agile software development, agile-разработка) — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.

К гибким методикам, в частности, относят экстремальное программирование, DSDM, Scrum, FDD, BDD и другие.

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

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

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

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

Agile Manifesto разработан и принят 11—13 февраля 2001 и содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

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

Основополагающие принципы Agile Manifesto:

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

«Spiral Model» (спиральная модель)

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

Работа идет по спирали, на каждом витке которой осуществляется 4 основных действия: создание плана, анализ рисков, разработка и конструирование, оценка результата и сбор фидбека. Если все 4 этапа успешно пройдены, то разработка переходит на новый виток.

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

«V-Model» (V-образная модель)

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

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

«RAD Model» (rapid application development model или быстрая разработка приложений)

Методология разработки RAD подходит тем компаниям, которые хотят максимально быстро запустить продукт. Суть заключается в том, что все этапы создания программы делятся не несколько отдельных блоков, с каждым из которых работает отдельная команда разработчиков.

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

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

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

Следующая лекция