Agile
Иерархическая Структура Работ в agile
Создание WBS требует значительного времени, крайне высокой экспертизы руководителя проекта и глубокого вовлечения членов команды, экспертов, заказчиков и прочих заинтересованных сторон. Что делать, если вы не можете всё это обеспечить?
Работая в agile-среде или agile-организации при производстве программного обеспечения классическая WBS или Иерархическая Структура Работ (ИСР) может быть не самым удобным инструментом.
Причин неудобства несколько:
Причин неудобства несколько:
1
WBS отражает масштаб работ всего проекта. Даже если используется итеративный или инкрементный жизненный цикл и вглубь прорабатывается иерархия только ближайшей итерации/инкремента, требуется понимание требований, ограничений и допущений всего проекта для корректного выявления взаимозависимостей комплексов работ и снижения рисков.
В гибком производстве заблаговременное осознание требований ко всему продукту и всех его функций не обязательно и даже порой не поощряется. Часто, обозначив начальные условия, команда работает над продуктом реагируя на изменяющиеся данные — собираемые метрики непрерывно меняющегося настроения рынка потребителей.
2
WBS декомпозирует активности проекта до минимально необходимого уровня комплекса работ, требуемого для осуществления оценки работ необходимой точности.
В гибком производстве чаще вместо дальней строгой даты выхода в промышленную эксплуатацию всей задуманной заказчиками функциональности размечают дорожную карту, набор релизов и планируемый состав функций в том или ином релизе. При этом все заинтересованные стороны понимают, что состав любого релиза может радикально поменяться, а дорожную карту требуется корректировать при изменении ожиданий потребителей и/или заинтересованных сторон, тем самым делая предварительную оценку работ высокой точности нецелесообразной.
Создание WBS требует значительного времени, крайне высокой экспертизы руководителя проекта и глубокого вовлечения членов команды, экспертов, заказчиков и других заинтересованных сторон.
Несложно догадаться, что при ожидаемых изменениях плана инвестировать существенное время и ресурсы в его моделирование — занятие бессмысленное.
В гибком производстве часто используют альтернативный Иерархической Структуре Работ (WBS) способ декомпозиции, или попросту разбивке задач, иногда называемый Agile Breakdown Structure (ABS).
В гибком производстве часто используют альтернативный Иерархической Структуре Работ (WBS) способ декомпозиции, или попросту разбивке задач, иногда называемый Agile Breakdown Structure (ABS).
Общий случай Иерархической Структуры Работ в гибком производстве:
Сотрудники организации создают Инициативы, в рамках которых требуется изменить существующий продукт/услугу или добавить новый продукт/услугу.
Эти инициативы удовлетворяют целям и задачам организации, которые, в свою очередь, есть декомпозиция стратегии организации.
Эти инициативы удовлетворяют целям и задачам организации, которые, в свою очередь, есть декомпозиция стратегии организации.
Команды разбивают инициативы, согласованные к реализации, на логические рабочие блоки, называемые Эпиками (Epic). Они имеют чётко определённые цели и считаются завершёнными ("закрываются") после достижения целей.
Обычно над ними работают несколько команд в течение нескольких итераций, если итерации применяются в организации. Спринт — яркий пример итерации в производстве.
Обычно над ними работают несколько команд в течение нескольких итераций, если итерации применяются в организации. Спринт — яркий пример итерации в производстве.
Функции (Feature) или в простонародье "фичи" определяют новую функциональность или изменение существующей, необходимое для реализации цели Эпика. Функции или фичи представляют собой то, что непосредственно поставляется клиенту.
Для реализации одной функции может потребоваться много итераций и даже много команд.
Для реализации одной функции может потребоваться много итераций и даже много команд.
Функции разбиты на Пользовательские Истории (User story), которые являются рабочей единицей команды. В гибком подходе команда намечает истории, необходимые для завершения фичи. Подход похож на декомпозицию WBS, однако вместо задачи или комплекса работ, история представляет собой атомарный сценарий или небольшой набор атомарных сценариев, которые заранее умышленно подробно не прорабатываются.
Над пользовательской историей работает одна команда в течение одной итерации.
Над пользовательской историей работает одна команда в течение одной итерации.
Истории могут и должны быть разбиты на Задачи (Task) — атомарные единицы работы в гибком производстве. В Scrum или фреймворках, которые на нём базируются, декомпозиция пользовательской истории на задачи происходит во время планирования итерации. Степень декомпозиции должна обеспечивать возможность коллективной точной оценки пользовательской истории.
Задачи выполняются командой в итерации, на которую спланированы их пользовательские истории. В задаче подробно описывается, как команда будет выполнять эту единицу работы, часто применяется стандартный подход описания технической спецификации.
Задачи выполняются командой в итерации, на которую спланированы их пользовательские истории. В задаче подробно описывается, как команда будет выполнять эту единицу работы, часто применяется стандартный подход описания технической спецификации.
Прослеживаемость требований
В Гибкой Иерархической Структуре Работ цепочка взаимосвязей и преобразования различных типов элементов практически идентичны традиционному жизненному циклу требований из Инжиниринга Систем, а значит как прямая, так и обратная прослеживаемость неразрывно впечатана в этот подход.
Границы применимости гибкого подхода декомпозиции инициатив организации
1 Риски внешних (для команды и продукта) зависимостей минимальны или отсутствуют
Это не означает, что зависимостей совсем нет и не будет, скорее что они могут быть проработаны и учтены в работе команды "как раз вовремя" (Just in Time), то есть по ходу их выявления.
2 Высокая культура команды
Команда должна быть достаточно фамильярна с гибким производством и тем, что из него вытекает.
3 Высокая культура организации
Руководство компании должно понимать, почему они не видят WBS и почему не должны её требовать.
4 Высокая степень декомпозируемости разрабатываемого продукта на релизы
Автомобиль либо готов, либо не готов. Разнести его на релизы не получится.
5 Гибкие ограничения бизнеса
Жёстко ограниченный бюджет или несдвигаемая дата релиза готового продукта или неизменяемый состав продукта или недоступность представителей бизнеса, кроме как в определённые даты — всё это требует менее гибкого и более основательного предиктивного жизненного цикла проекта / производства с тщательным предварительным анализом требований и рисков.
