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

image

Alistair Cockburn’s Criticality and Team Size Factors


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

image

Boehm and Turner – Radar Chart


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

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

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

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

image

Stacey Complexity Model


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

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

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

image

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

Agile Suitability Model


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


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

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

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

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


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

image

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

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

image

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

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

image

Одной моей знакомой кто-то посоветовал “внедрить 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.

image

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

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

image

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

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

image

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

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


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

image

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

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

image

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

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

image

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

Результаты


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

image

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

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

image

Соавтор lera_ilenkova

Комментарии (6)


  1. Aleks-NP
    28.08.2019 22:14

    Спасибо за статью. Единственный минус любой системы коммуникации и управления — человеческий фактор и субъективность оценки многих критериев. Тут поможет только одна система — «опыт и адекватность оценщика»


    1. daIlenkov Автор
      29.08.2019 01:57
      +1

      Тут тот же минус, к сожалению — опыт и адекватность оценщика тоже очень субъективны


  1. in_heb
    29.08.2019 08:47
    -1

    >Дмитрий Ильенков daIlenkov
    >Менеджер проектов
    >agile
    /0

    Spoiler
    В процессных фреймворках на базе принципов agile принципиально нет роли Менеджер проектов, их выгнали на мороз


    1. Kanut
      29.08.2019 09:03

      В процессных фреймворках на базе принципов agile принципиально нет роли Менеджер проектов, их выгнали на мороз

      Для них осталось мало места, но вот чтобы их прям во всём Agile и прямо «выгнали на мороз»…

      Особенно учитывая что 100% Agile я ещё нигде вживую не видел. :)


      1. in_heb
        29.08.2019 09:13
        -1

        Там где их не выгнали/не переквалифицировали в PO или другую роль, происходит адовая смесь олдскульных подходов в перемешку с новыми и как следствие становится ещё хуже чем было до попыток внедрения agile-based процессов.


        1. Kanut
          29.08.2019 09:18

          Это совсем другой вопрос. Хотя опять же есть и вполне адекватные концепты. Особенно в контексте каких-нибудь «Scrum of Scrums» или «Nexus».