УПРАВЛЕНИЕ ЗАДАЧАМИ В AGILE И WATERFALL

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

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

Поэтому когда речь идет о Waterfall, то к моменту начала разработки подразумевают наличие технического задания (ТЗ). С точки зрения работы команды с конкретными задачами в процессе создания/разработки проекта всё предельно просто – каждый отдельный пункт ТЗ представляет собой практически автономный функционал, который нужно поручить конкретному человеку или команде (в случае нескольких команд). Как правило, между пунктами ТЗ присутствуют зависимости, которые разрешаются правильной приоритезацией. Фактически, всё что требуется от команды – это последовательная реализация пунктов ТЗ согласно приоритетам и составленной спецификации (в случае необходимости, некоторые функциональные требования декомпозируют на подзадачи).

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

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

В Agile общепринятыми являются следующие практики (список гораздо более длинный, акцент сделан на те практики, которые касаются проектных работ):

1. Приоритезация задач
2. Итеративность разработки
3. Коммуникация с клиентом и внутри команды
4. Пользовательские истории
5. Планирование релиза
6. Митинги [2]

Помимо разбиения крупных задач на более мелкие (что, в прицнипе, характерно для любой сложной работы), для Agile характерно упорядочивание списка работ (бэклога проекта). Таким образом становится возможным более важное отправить в работу раньше, что в полной мере соответствует направленности на клиента. Управление бэклогом – крайне важная часть Agile-методологий [3].

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

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

В отличие от формирования единого ТЗ, вся функциональность проекта описывается определенным образом (например, в рамках Definition of * группы документов) в виде пользовательских историй, которые являются единицой работы, которую возможно завершить в рамках одной итерации. Пользовательские истории зачастую включают в себя описание ожидаемой функциональности в виде критериев приемки, оценку времени и т.д. В случае, когда пользовательская история слишком объемная или сложная, её разделяют на более мелкие.

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

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

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

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

Список литературы:

1. Каскадная модель (Waterfall model) [Электронный ресурс] – Режим доступа. – URL: https://qalight.com.ua/baza-znaniy/kaskadnaya-model-waterfall-model
2. Стеллман Э., Грин Дж. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2017. – 448с
3. Перерва А., Еранов С., Иванова В., Сергеев С. Путь IT-менеджера. Управление проектной средой и IT-проектами. – СПб.: Питер, 2016. – 320с