Дети, рожденные в год подписания 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). Это список из 17 утверждений, которые позволяют выявить риски применения DSDM. Утверждения касаются понимания философии и практик DSDM, соблюдения ролей в команде. Имеет смысл ознакомиться, если уже разбираетесь в подходе.

Alistair Cockburn’s Criticality and Team Size Factors

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

Boehm and Turner – Radar Chart

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

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

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

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

Stacey Complexity Model

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

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

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



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

Agile Suitability Model

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

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

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

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

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

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



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