Нужен ли тебе Agile: 5 моделей для проверки

Дети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.

DSDM Suitability Filter

В 1994 году DSDM консорциум разработал опросники Project Suitability Filter (PSF) и Organization Suitability Filter (OSF), которые позволяли оценить, насколько проект и организация подходят для применения гибкого подхода и зафиксировать потенциальные источники проблем.

Сейчас на сайте Agile Business Consortium доступен DSDM Project Approach Questionnaire (PAQ) ^[1]. Это список из 17 утверждений, которые позволяют выявить риски применения DSDM. Утверждения касаются понимания философии и практик DSDM, соблюдения ролей в команде. Имеет смысл ознакомиться, если уже разбираетесь в подходе.

Alistair Cockburn’s Criticality and Team Size Factors

Алистар Кокберн ^[2] использовал показатели “критичность системы” и “размер команды”, чтобы показать, какой из методов семейства Сrystal следует применять в зависимости от сочетания факторов. Под критичностью понимается уровень ущерба, который может быть нанесён, если что-то пойдёт не так. Смысл модели Алистар объясняет в своём выступлении ^[3] на TEDx.

Boehm and Turner – Radar Chart

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

Авторы предлагают оценивать:

1. Уровень подготовки персонала
2. Долю требований, которые ежемесячно меняются
3. Культуру
4. Численность команды
5. Критичность (как в предыдущей модели)

Модель можно построить онлайн ^[4] – двигаешь слайдеры и получаешь диаграмму.

Stacey Complexity Model

Модель применяется для оценки проекта с точки зрения неопределённости.

Вертикальная ось показывает, понятно ли, что мы хотим сделать. Горизонтальная ось показывает, понимаем ли мы, как этого достичь.

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

Почитать о других моделях можно, например, у Mike Griffiths ^[5], одного из разработчиков DSDM и Agile Practice Guide. А мы переходим к Agile Suitability Model, которая представляет собой синтез описанных выше моделей.

Agile Suitability Model

Как это работает

Несколько человек, в идеале включая спонсора, представителей команды и заказчика, отвечают на вопросы, сгруппированные в 3 домена:

• Культура – насколько окружение способствует подходу?
• Команда – сможет ли сама команда воспользоваться преимуществами подхода?
• Проект – а что с самим проектом? насколько нужно и можно быть гибкими?

Группа должна обсудить вопрос, прийти к общей оценке и занести её на лепестковую (радарную) диаграмму. (её можно скачать ^[6]). Пройдём по вопросам.

Домен “Культура”

Поддержка: Поддерживает ли спонсор проекта (куратор) применение гибких методов на данном проекте?

N.B. Если спонсор говорит “делайте, что хотите” – это ещё не поддержка.

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

Если на входе вас встречает ТЗ толщиной с войну и мир, а на выходе ожидает комиссия с хмурыми лицами и защитой отчета – это очень плохой знак. Задумайтесь.

Решения: Будет ли у команды автономия в принятии локальных решений по выполнению работы в проекте?

Одной моей знакомой кто-то посоветовал “внедрить agile”. Зная специфику компании, я спросил, повесила ли она уже на стену доску. Девочка в шоке сказала, что доски на стены у них вешать нельзя.

Если вы не можете самостоятельно решить, можно ли вешать на стены доски, не рассчитывайте на автономию. Это слово не про вас.

Домен “Команда”

Размер команды: Оцените размер основной команды проекта по следующей шкале:
1-9 = 1; 10-20 = 2; 21-30 = 3; 31-45 = 4; 46-60 = 5; 61-80 = 6; 81-110 = 7; 111-150 = 8; 151 – 200 = 9; 201+ = 10.

Возможно, в команде 100+ будет немного сложнее с самоорганизацией ;)

Опыт: Рассмотрите опыт и навыки ключевых ролей в команде. Есть ли в команде по одному опытному члену команды на каждую роль?

Стажёр, которым вы закрываете все дыры, не считается.

Доступ: Будет ли у команды ежедневный доступ хотя бы к одному представителю заказчика/бизнеса для получения обратной связи и ответов на вопросы?

Не фантазируйте. Вспомните, как это было в прошлый раз.

Домен “Проект”

Изменения: Какой процент требований возможно будет меняться каждый месяц?

Здесь полезно вспомнить Stacey Complexity Model. Если у вас ничего не меняется, то к чему вам гибкость?

Критичность: Рассмотрите потери, которые могут возникнуть из-за дефектов, определите, чем может закончиться провал.

Не всегда можно просто взять и пофиксить баги. С физическими объектами особенно плохо.

Поставка: Может ли продукт разрабатываться и оцениваться по частям? Смогут ли представители заказчика/бизнеса своевременно давать обратную связь по инкрементам?

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

Результаты

В конце точки со значениями соединяются.

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

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

Соавтор lera_ilenkova ^[7]

Автор: daIlenkov

Источник ^[8]