Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

---

2.2. Обоснование выбора методологии «скрам» для моделирования процесса управления IT-проектом

В настоящее время существует множество гибких методологий, но наиболее популярными являются «экстремальное программирование» (XP), «скрам», «бережливая разработка» (lean), «разработка, управляемая функциональностью» (fdd) и «канбан». В таблице 2 приведен сравнительный анализ данных методологий (Abrahamsson, 2002):

Таблица 2 Сравнительный анализ "гибких" методологий

Название	Ключевые моменты	Уникальные особенности	Недостатки
«экстремальное программирование» (XP)	Маленькие команды, ежедневные совещания, неформальный тип коммуникации внутри команды, минимум документации	Постоянное корректирование проекта для повышения его эффективности и для адаптации к изменениям	Больше подходит для индивидуальных практик, чем для глобального управления, так как в последнем случае есть риск формирования недисциплинированных команд
«скрам»	Независимая, небольшая, самоорганизующаяся команда разработчиков, длина итерации – 2-4 недели, команда сама решает сколько времени ей нужно для выполнения задачи, неформальный тип коммуникации внутри команды, ежедневные совещания, присутствует только базовая документация	Высокий уровень коммуникации и взаимодействия внутри команды, четко прописанная формальная организация этой методологии, наличие «надсмоторщика» за командой, полная ориентация на требования заказчика	Есть риск увеличения времени проекта за счет издержек «скрам»-мероприятий
«бережливая разработка» (lean)	Использование визуализирующих инструментов, разработка через тестирование, короткие итерации	Главными являются те функции ПО, которые ценны для заказчика, присутствует постоянное мотивирование команды	Решения принимаются долго, недостаток дисциплины, походит только для маленьких проектов
«разработка, управляемая функциональностью» (fdd)	Пяти шаговый процесс, объектно-ориентированная разработка, очень короткие итерации (могут достигать по длительности несколько часов)	Простота метода, объектное моделирование	Данная методология фокусируется только на проектировании и внедрении, очень мало внимания уделено именно разработке
«канбан»	Самоорганизующаяся команда, утерянный смысл понятия «итерация» - весь упор на задачи	Нет ограничений по времени выполнения, зато есть ограничение на число «работы в данный момент», эффективно, когда неизвестно, что может в дальнейшем потребоваться заказчику от ПО	Недостаток дисциплины, затяжной характер

---

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

«Скрам» - наиболее популярная «гибкая» методология, широко используемая зарубежными компаниями, такими как Yahoo!, PayPal, Nike, Google, SAP, GE для управления проектами (Deemer, 2007). Согласно шестому и седьмому ежегодным государственным исследованиям «гибкой» разработки Интернет-ресурса Version One, методология «скрам» используется как метод «гибкого» управления IT-проектом в несколько раз чаще, чем остальные методологии (рисунок 8 и рисунок 9):⁶⁷



Рис. 8 Популярность методологии "скрам" в 2011 году



Рис. 9 Популярность методологии "скрам" в 2012 году

---

2.3. Описание методологии «скрам»

Методология «скрам» была впервые представлена в 1990-х годах Кеном Швабером и Джефом Сазерлендом в виде четко задокументированного и формализованного «руководства по «скраму».

«Скрам» - это гибкий и легкий процесс управления и контроля программным обеспечением и процесса разработки продукта в быстро меняющихся условиях» [28, с. 19]. Данная методология устанавливает определенные правила управления IT-проектом (разработкой или внедрением информационной технологии), которые основываются на возможности постоянной корректировки требований и на внесении тактических изменений.

Перед началом проекта участники обсуждают глобальные цели и базовую стратегию, направленную на достижение этих целей. Лицо со стороны Заказчика проекта представляет интересы своей компании путем описания бизнес-функций внедряемого или настраиваемого программного обеспечения. Со стороны исполнителя определяется состав команды разработчиков и другие ресурсы, после чего сторонами обсуждаются примерные рамки проекта, а так же дата начала первой итерации. Итерация в «скраме» получила название спринт, и она длится две-четыре недели. Все спринты имеют относительно фиксированную длительность: это означает, что если запланирована дата окончания спринта, то при наступлении этой даты (с минимальной погрешностью) все работы данного спринта должны закончиться, вне зависимости от того, успела ли команда проекта выполнить задание или нет. Минимальная погрешность означает, что на практике какие-то задержки все же возможны, но, тем не менее, они не должны превышать двух-трех дней для спринта, длительность которого равняется двум неделям.

Модель методологии «скрам» состоит из трех главных компонентов: ролей, артефактов и мероприятий. В данной методологии присутствуют три роли: Владелец продукта, Скрам-мастер и Скрам-команда.

• 
  Владелец продукта чаще всего является заказчиком, который поддерживает в актуальном состоянии список требований к проекту. Чем лучше и четче владелец продукта опишет требования, тем меньше будет вопросов у разработчиков, тем реже будет изменяться функционал программного обеспечения с течением времени. Именно Владелец продукта определяет приоритет требований, то есть сам заказчик решает, какие функции программного обеспечения являются наиболее срочными и важными для компании на какой-то конкретный момент;
  
• 
  Скрам-мастер ответственен за понимание сущности всего «скрам»-процесса другими участниками. Скрам-мастер чем-то похож на традиционного менеджера проекта, но у него есть одно отличие: он не отдает явных приказов и не устанавливает сроки разработчикам, он, напротив, помогает им при возникновении каких-либо трудностей и следит, чтобы их работа была слаженной. Именно от Скрам-мастера зависит атмосфера в команде разработчиков, а, как следствие, и их инициативность, удовлетворенность и общий результат. Скрам-мастер решает любые проблемы, которые могут как-то помешать команде, будь то сломанное оборудование или внешнее давление со стороны заказчика. Скрам-мастер также следит, чтобы все события «скрама» (о которых будет написано ниже) происходили регулярно и с максимальной эффективностью;
  
• 
  Скрам-команда «…состоит из профессионалов, выполняющих работу по разработке потенциально «готового» к выпуску новой версии продукта в конце каждого «спринта» [36, с. 5]. Обычно количество разработчиков и программистов не превышает восьми, и все они являются заинтересованными в успешной реализации IT-проекта. Перед началом каждой итерации Скрам-команда ставит достижимую и значимую для заказчика цель, а во время итерации направляет все свои усилия на достижение этой цели в срок с заявленным качеством. Достижение цели характеризуется наличием запланированного кода, который впоследствии был отлажен, а возможные дефекты итерации устранены. Скрам-команда сама устанавливает себе сроки (обсудив их со Скрам-мастером и Владельцем продукта), сама оценивает свои возможности и распределяет время.
  

---

Среди артефактов методологии «скрам» выделяют журнал продукта, журнал спринта и диаграммы сгорания (рисунок 10):



Рис. 10 Артефакты методологии "скрам"

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

Схематически это можно представить следующим образом (рисунок 11):



Рис. 11 Формирование журнала спринта

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

---