Вам когда-нибудь задавали вопрос «Что такое Agile?», и у вас не было правильного ответа? Или кто-то сказал вам, что Agile — это что-то из мира разработки программного обеспечения? В таком случае сначала нужно понять, что Agile — это рабочая методология, которая применима не только к отделам разработки программного обеспечения. Чтобы объяснить, для каких типов задач лучше всего подходит метод Agile, предназначена модель сложности Стейси, которая помогает избавиться от неопределенности в проекте.

Краткое описание модели сложности Стейси

В модели сложности Стейси есть два измерения:

  1. Неопределенность требований: показывает степень определенности (или неопределенности) ваших требований и вероятность их изменения в будущем. По сути, это измерение определяет уровень неопределенности того, ЧТО вы должны сделать или построить.
  2. Неопределенность технологии: показывает степень неопределенности вашего подхода или технологии для завершения задачи (или создания приложения). Следовательно, это измерение определяет уровень неопределенности того, КАК вы строите проект.
Рис. 1. Модель сложности Стейси

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

Простые задачи

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

Примеры задач из этой категории: «чистка зубов» или «поездка на транспорте». Вы делаете это ежедневно, не задумываясь. Подход, который вы выбираете для решения таких задач: «Просто сделай это!».

Сложные задачи

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

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

Хаос

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

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

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

Тяжелые задачи

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

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

Простота модели

Скорее всего, если вы объясните эти четыре категории кому-нибудь, кто не имеет никакого отношения к разработке программного обеспечения или Agile, а затем спросите: «Как бы вы решали задачи из категории тяжелых?», то оппонент сможет придумать ответ самостоятельно. И именно по этой причине модель сложности Стейси очень привлекательна.

Ответ заключается в Agile

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

Согласитесь, что вышеизложенное позволяет моментально объяснить любой заинтересованной стороне, абсолютно не разбирающейся в Agile, что методология Agile — это способ реагировать на изменения!