25
Основной расчёт в проекте по Agile делается на командную работу.
Каждый участник проекта по Agile осознает свою личную ответственность
за общий результат и ориентирован на работу в сплоченной команде.
Чтобы быстро исправлять несоответствия, которые были допущены,
и быстро улучшать и развивать продукт в нужном направлении, команда
проекта получает обратную связь от заказчика и пользователей по
завершении каждой итерации.
Быстрое изменение направления в условиях неопределенности и
готовность к этим изменениям путем итерационного подхода позволяет
гибким методологиям эффективно действовать и положительно влиять на
процесс реализации и результат проекта.
Существует множество гибких методологий управления проектами,
также часто встречаются и их гибриды – комбинации нескольких гибких
методов для получения большей эффективности и результативности в
сочетании двух-трех различных методологий в определенных сферах
деятельности. Например, достаточно часто встречается сочетание методов
Kanban и Scrum. Также существуют сочетания гибких и классических
методологий управления, например, PMBoK и Agile. Такие системы
управления называются гибридными.
Положительным качеством гибридного подхода заключается в
высокоуровневых задачах и их взаимосвязях, а также тестировании и
поставке конечного продукта, которые определяются с помощью ИСР
(Иерархической структуры работ). Agile, в данном случае, используется для
ускорения разработки каждого из компонентов - инкрементов продукта.
Следуя классическим методам построения ИСР и c помощью
декомпозиции крупных задач, цель проекта разбивается на подцели, сроками
выполнения пакета работ в течении 2–4 недели (спринта).
26
Такой подход, сочетающий в себе гибкий и каскадный методы,
является наиболее эффективным вариантом разработки большинства
комплексных интеграционных проектов.
17
1.2. Ключевые отличия гибких подходов к управлению
проектами от классических
Ключевые ценности и принципы Agile:
Люди и их взаимодействие важнее, чем процессы и инструменты
Общение между персоналом важнее закрепленных регламентов. Не
всегда установленные на предприятии процессы являются наиболее
эффективными и поэтому приветствуется любое взаимодействие
сотрудников, которое может привести к большей эффективности и более
быстрой доставки ценности клиенту. Приоритет общения над
инструментами не означает полный отказ от последних, скорее наоборот, в
ходе гибких методов управления происходит создание новых инструментов.
Таким образом, цель новых инструментов состоит не в защите устоявшихся
процессов компании, а в помощи сотрудникам в доставке клиентской
ценности. Роль руководства в данной связи заключается в поиске и отборе
наиболее мотивированных сотрудников, способных работать
самостоятельно, и предоставлении им для этого наиболее благоприятных
рабочих условий.
Работающий продукт важнее документации и инструкций
Основная цель заключаемого между сторонами контракта –
защититься на случай невыполнения контрагентом взятых на себя
обязательств и разграничить ответственность между сторонами контракта. В
случае если все заинтересованные стороны доверяют друг другу и каждая из
них действительно заинтересована в как можно скорейшей разработке
продукта, подобная документация представляется излишней. При этом
полного отказа от документации в процессе применения гибких методов
17
Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО // Издательский Дом ПИТЕР –
2017. -288с
27
управления проектами не происходит, однако теперь ее цель – передача
экспертизы, информации касательно нового продукта. Достаточно быстрое
появление работающего продукта, помимо всего прочего, улучшает
психологическое состояние сотрудников и повышает их мотивацию.
Работа с клиентом важнее согласования условий контракта
На практике нередко возникают ситуации, когда клиент в начале
проекта не до конца осознает, какой именно результат он хочет получить.
Поэтому довольно часто клиент желает внести изменения в уже
утвержденный проект. Однако, чем ближе проект подходит к своему
завершению, тем сильнее возрастает стоимость внесения изменений. В
результате, либо компании приходится вносить дорогостоящие изменения в
проект и заново проходить через многие этапы, либо клиент остается
неудовлетворенным. Постоянное взаимодействие с заказчиком позволяет
избежать подобных проблем.
Эффективно реагировать на изменения важнее, чем следовать
первоначальному плану
В современном мире случаются ситуации, когда продукт устаревает,
даже не успев выйти в продажу. Такие ситуации вызваны тем, что в
утвержденный в начале проекта план невозможно вносить какие-либо
значительные изменения. Помимо этого, первоначальный план не учитывает
изменения, которые могут произойти в ходе реализации проекта, и
потенциальные новые риски. При гибких методах управления проектами
решения по рискам не откладываются на неопределенный срок, а
обсуждаются и прорабатываются в ходе каждой итерации. Также тщательно
учитывается и любая новая информация, появившаяся в ходе проекта,
поскольку она способна приблизить разрабатываемый продукт к тому,
который клиенты хотят получить. Данный пункт не предусматривает,
разумеется, полного отказа от планирования, однако планировать следует
28
только ту работу, которая останется неизменной на протяжении всего
проекта.
18
Основное различие между гибкими и классическими методами
управления (модель «водопада») связано с отношением к неопределенности,
возникающей в ходе реализации проекта. В то время как в классическом
управлении проектами любые изменения нежелательны, риски пытаются
спрогнозировать с помощью специальных инструментов, для проектов,
осуществляемых с применением гибких методов управления, изменения –
возможность модернизировать конечный продукт так, чтобы он
максимально отвечал потребностям клиентов и текущей рыночной ситуации.
При этом, нельзя не отметить тот факт, что на выбор между
классическим и традиционными методами управления оказывают серьезное
влияние особенности отрасли и внутренние возможности компании, такие
как доступный технологический процесс, квалификация специалистов,
наличие экспертизы в компании и возможности получения прибыли.
Второе отличие, которое можно выделить, это организация работы
команды проекта. Если в классических подходах это вертикаль управления –
Управляющий комитет => Куратор/Заказчик => Руководитель => Команда
проекта, то в гибких методах обычно присутствует самоорганизация внутри
команды, то есть нет внутренней иерархии.
В данном случае Руководитель проекта, который выступает Scrum-
мастером команды, не может указывать команде, каким образом создавать
продукт, а Команда самостоятельно регулирует собственную работу,
устанавливает временные границы и условия работы в рамках «спринта».
В структуре команды нет разделения на подразделения,
выполняющие отдельные функции, при этом в команду разработки входят
функциональные специалисты, которые обладают необходимыми навыками
для работы, таким образом, даже если отдельные члены команды владеют
18
Agile Manifesto // 2001. -1с.
29
узкоспециализированными знаниями в различных областях, ответственность
за продукт лежит на всей команде в целом.
Руководителю команды определены следующие функции:
Руководитель проекта берет на себя роль «Scrum-мастера», который
настраивает работу самоорганизованных команд, но не мешает их
деятельности. Он отвечает за то, чтобы донести особенности работы до всех
лиц, взаимодействующих с проектом, включая тех, кто не входит в состав
команды. Также, он проводит обучение команды для улучшения
самоорганизации и функциональных навыков каждого члена команды.
19
Контролирует связь команды с заказчиками и рынком, собирает обратную
связь для повышения ценности предприятия и его деятельности.
Устраняет помехи, препятствующие работе команды.
20
Также существует отличие касательно соблюдения методологий
управления. В классическом подходе используется конкретный, хорошо
структурированный план – PMBoK или PRINCE2, а также используются
определенные отраслевые стандарты и практики. В гибких методологиях в
свою очередь используются верхнеуровневые фреймворки, такие как Scrum,
а также существует множество практик для сбора опыта (извлечения
уроков), такие как ежедневный Scrum, ретроспектива спринта, спринт.
Еще одно важное отличие – рамки и работы проекта. Если в
классическом подходе «Системы сложные» - продукт и требования к нему
известны, зафиксированы и описан процесс работ, то в гибких методологиях
иначе. «Запутанные системы» - неизвестен продукт или процесс его
создания, состав работ не определен и границы проекта размыты, нет точных
дедлайнов.
21
19
Блог Unusual Concepts - https://blog.unusual-concepts.ru/agilebasics/
20
Майк Кон. Scrum. Гибкая разработка ПО // Диалектика-Вильямс - 2011. -575с.
21
Ильина О.Н. Методология управления проектами: становление, современное состояние и развитие. – М.:
Вузовский учебник: ИНФРА-М, 2016 – 208 с.
30
Традиционно авторы выделяют 5 этапов классического проектного
управления. Однако, к ним можно добавлять и дополнительные этапы, что
непосредственно определяется особенностями каждого конкретного проекта.
Этап 1. Инициация. Определение требований к проекту
руководителем проекта и командой. Этот этап предполагает проведение
совещаний и «мозговых штурмов» с целью определения параметров и
качеств продукта.
Этап 2. Планирование. На данном этапе команда решает, какими
способами и с помощью каких средств она будет достигать поставленной на
предыдущем этапе. Уточняются и детализуются цели и результаты проекта,
а также перечень работ по проекту. Конкретизация обозначенных выше
аспектов проекта позволяет на этой основе построить планы по срокам и
бюджет, оценить риски и выявить интересы сторон.
Этап 3. Разработка. Этот этап не является обязательным, не
выделяется как самостоятельная в некоторых проектах. Часто данный этап
является частью этапа планирования. Выделение разработки в отдельный
этап характерно для технологических проектов. На этом этапе определяется
конфигурация будущего проекта и/или продукта, а также технические
способы его достижения цели проекта. К примеру, в технологических
проектах, на данном этапе может быть выбран язык программирования.
Этап 4. Реализация и тестирование. Этот этап предполагает
непосредственное проведение работ по реализации проекта. На четвертном
этапе проводятся работы по проекту, а также контроль по заранее
установленным параметрам за успешностью реализации. В зависимости от
особенностей проекта происходит тестирование продукта, продукт может
проверяться на соответствие заранее установленных требований заказчика
либо других заинтересованных сторон. По итогам тестирования продукта
выявляются несоответствия реального и ожидаемому результатов,
производится исправление недостатков продукта.
31
Этап 5. Мониторинг и завершение проекта. В зависимости от
особенностей конкретного проекта, данный этап может реализовываться в
разных вариантах. Одним из вариантов завершения может быть передача
заказчику продукта, созданного в рамках проекта. Другим вариантом может
стать взаимодействие с клиентом с целью дальнейшего улучшения проекта,
повышения удовлетворенности, поддержки результатов проекта. Эти
варианты часто встречаются в проектах в области обслуживания клиентов
либо в IT-проектах.
22
Основные недостатки гибких методов управления связаны с
формированием кросс-функциональной команды. Во-первых, необходимо
затратить значительное количество дополнительных ресурсов, как
денежных, так и временных, прежде чем команда сможет функционировать с
максимальной эффективностью. Во-вторых, поскольку данный подход
предусматривает гораздо большее количество межличностного
взаимодействия, человеческий фактор несовместимости выходит на первый
план. Наконец, не все сотрудники могут перестроиться на новый рабочий
процесс и принципы управления или имеют желание осваивать новые
функциональные роли.
Хорошим примером будет модель развития группы по Такмену:
22
ГОСТ 54869-2012 Проектный менеджмент. Требования к управлению проектами. – М.: Стандартинформ,
2012
32
Рисунок 4. Модель формирования команд Брюса Такмена
Forming (Формирующая стадия)
На этой стадии формирование личных взаимоотношений
характеризуется зависимостью. Члены команды полагаются на лидера
группы как на руководящего и направляющего дальнейшего процесса.
Также, у членов группы есть потребность в принятии остальными, они
начинают составлять впечатления о коллегах, о сходствах и различиях и
формируют предпочтения для будущей группы общения. Правила поведения
исходят из того, чтобы придерживаться простых вещей и избегать
противоречий, также избегаются серьёзные и сложные темы и проявления
глубоких чувств. Дискуссии в основном ведутся вокруг определения
содержания задачи, подхода и других похожих проблем. Чтобы перейти с
данной стадии на следующую, каждый из команды должен отказаться от
обхождения тем, не представляющих угрозу и пойти на риск возможности
конфликта.
33
Storming (Конфликтная стадия)
Эта стадия характеризуется конкуренцией и конфликтом во
взаимоотношениях на тему направленности деятельности группы и
определения локальных задач. По мере того, как члены группы пытаются
организовать работу, конфликт неизбежно оказывает влияние на их личные
взаимоотношения и им приходится подстраиваться под идеи, принципы и
убеждения в соответствии с организацией группы. В процессе данной стадии
могут возникать вопросы о том, кто будет отвечать за тот или иной аспект
работы, какие общие правила, какова система вознаграждения и критерии
оценивания. Также, в поведении участников могут возникать широкие
колебания, основанные на возникающих проблемах конкуренции между
враждующими сторонами, и из-за дискомфорта, возникающего на этом
этапе, некоторые могут сохранять молчание и не вступать в конфликтное
взаимодействие, в то время как другие пытаются доминировать. Чтобы
перейти на следующую стадию, члены команды должны пересмотреть
стратегию доказывания и выяснения, и начать непосредственно решение
существующей проблемы. Самая важная черта, способствующая
достижению следующей стадии - способность слушать.
Norming (Нормирующая стадия)
Межличностные отношения на данной стадии характеризуются
сплочённостью, потому как, каждый член команды активно поддерживает
вклад остальных и участвует в решении общих вопросов. Таким образом,
участники готовы изменить своё предвзятое мнение, основываясь на фактах,
предоставленных остальными, и они активно вовлекаются в обсуждение
насущных вопросов, лидерство распределяется, и стираются границы между
подгруппами. Когда участники начинают лучше узнавать друг друга,
возрастает их уровень доверия друг к другу, что способствует сплочённости
и именно на этой стадии люди начинают испытывать чувство групповой
принадлежности, чувство облегчения в результате разрешения
межличностных конфликтов. На этой стадии люди разделяют чувства и идеи
34
друг друга, дают и получают обратную связь, творчески подходят к
решению задач, они чувствуют себя хорошо, будучи частью эффективной
группы. Основным недостатком нормирующей стадии является то, что
участники могут начать опасаться неизбежного распада группы и начать
сопротивляться любым изменениям.
Performing (Стадия функционирования)
Не все команды достигают данной стадии, но, если члены команды
все-таки переходят на этот этап, их отношения друг с другом развиваются до
истинной взаимосвязанности. На этом этапе люди могут работать
независимо, в подгруппах или как единое целое с равными возможностями,
так как, их роли и полномочия динамично в соответствии с меняющимися
потребностями группы и отдельных лиц. Отдельные члены команды
становятся более уверенными в себе и не нуждаются в одобрении
большинства. Существует сплоченность: групповая идентичность
завершена, моральный дух и уровень групповой лояльности высок.
Появляется взаимная поддержка: в решении проблем принимаются и
рассматриваются разные варианты, делается акцент на достижениях.
Также существуют две завершающие стадии.
Adjourning (Расставание)
Заключительная стадия по Такмену, которая включает в себя
прекращение функционирования команды и её расформирование, когда все
поставленные задачи решены. Завершение сплочённой командной работы
может быть своего рода кризисом для членов коллектива из-за возникающих
неопределённостей перед новыми задачами.
Transforming (Перегруппировка)
Подразумевает перераспределение ролей в кросс-функциональной
команде для дальнейшей деятельности команды. После этой стадии процесс
формирования команды начинает новый цикл.
23
23
Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО // Издательский Дом ПИТЕР –
2017. -288с