Дети, родившиеся в год подписания Agile-манифеста, в этом году празднуют свое совершеннолетие.
А взрослые продолжают спорить, где применим Agile. Обычно они фокусируются на направлениях: можно ли использовать Agile вне ИТ? Иногда они добавляют драматизма: вы пробовали построить атомную электростанцию, используя Agile? Для художественного эффекта это, конечно, лучше.
Но если вы хотите сделать продукт, а не выиграть выступающий конкурс, то лучше смотреть на него применительно к конкретной ситуации.
В этой статье мы поговорим о нескольких моделях оценки применимости Agile и подробно рассмотрим одну из них — Модель пригодности Agile, представленную в Agile Practice Guide от PMI и Agile Alliance.
Фильтр пригодности DSDM
В 1994 году Консорциум DSDM разработал опросники «Фильтр пригодности проекта» (PSF) и «Фильтр пригодности организации» (OSF), которые оценивали пригодность проекта и организации для гибкого подхода и фиксировали потенциальные источники проблем.DSDM теперь доступен на веб-сайте Консорциума гибкого бизнеса.
Анкета по проектному подходу (PAQ) .
Это список из 17 утверждений, которые помогают определить риски использования DSDM. Заявления касаются понимания философии и практики DSDM, а также поддержания командных ролей.
Имеет смысл прочитать ее, если вы уже понимаете подход. 
Факторы критичности Алистера Кокберна и размера команды
Алистер Кокберн использовали показатели «критичность системы» и «размер команды», чтобы показать, какой из методов семейства Crystal следует использовать в зависимости от совокупности факторов.Критичность относится к уровню ущерба, который может быть причинен, если что-то пойдет не так.
Алистер объясняет значение модели в своей речь на TEDx. 
Бём и Тернер – Радарная диаграмма
В этой модели для оценки используются 5 критериев, а результаты отображаются на радиолокационной диаграмме.Авторы предлагают оценить:
- Уровень подготовки персонала
- Доля потребностей, которые меняются ежемесячно
- Культура
- Размер команды
- Критичность (такая же, как и у предыдущей модели)
Модель сложности Стейси
Модель используется для оценки проекта с точки зрения неопределенности.Вертикальная ось показывает, понятно ли, что мы хотим сделать.
Горизонтальная ось показывает, понимаем ли мы, как этого добиться.
Оси образуют четыре области, на которые может попасть проект: простое, сложное, сложное и хаос.
После определения домена вы можете выбрать подход. 
О других моделях можно почитать, например, на сайте Майк Гриффитс , один из разработчиков DSDM и Agile Practice Guide. И мы переходим к модели гибкой пригодности, которая представляет собой синтез описанных выше моделей.
Гибкая модель пригодности
Как это работает
Несколько человек, в идеале включая спонсора, представителей команды и заказчика, отвечают на вопросы, сгруппированные в 3 области:- Культура – насколько окружающая среда способствует этому подходу?
- Команда – может ли сама команда воспользоваться преимуществами этого подхода?
- Проект – а что насчет самого проекта? Насколько гибким необходимо и возможно быть?
(ты можешь скачать ).
Давайте пройдемся по вопросам.
Домен «Культура»
Поддерживать: Поддерживает ли спонсор проекта (супервайзер) использование гибких методов в этом проекте?
Н.
Б.
Если спонсор говорит «делай, что хочешь», это не поддержка.
Уверенность: Рассмотрим спонсора проекта и представителей заказчика, работающих с командой.
Верят ли эти заинтересованные стороны, что команда сможет преобразовать их видение и потребности в продукт или услугу — при их поддержке и постоянной обратной связи? 
Если на входе вас встречает техническое задание толщиной с войну и мир, а на выходе вас ждет комиссия с хмурыми лицами и защищающая отчет – это очень плохой знак.
Думаю об этом.
Решения: Будет ли у команды автономия в принятии местных решений о том, как завершить работу над проектом?
Кто-то посоветовал одному из моих друзей «внедрить 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+ будет немного сложнее с самоорганизацией ;) Опыт: Учитывайте опыт и навыки ключевых ролей в команде.
Есть ли в команде по одному опытному члену команды на каждую роль?
Стажер, которым ты закроешь все дыры, не в счет. Доступ: Будет ли команда иметь ежедневный доступ хотя бы к одному представителю клиента/бизнеса для получения отзывов и ответов на вопросы?
Не фантазируйте.
Вспомни, как это было в прошлый раз.
Домен «Проект»
Изменения: Какой процент требований, скорее всего, будет меняться каждый месяц?
Здесь полезно вспомнить Модель сложности Стейси.
Если для вас ничего не меняется, то зачем вам гибкость? Критичность: Рассмотрите потери, которые могут возникнуть из-за дефектов, определите, к чему может привести отказ.
Не всегда возможно просто пойти дальше и исправить ошибки.
Особенно плохо обстоят дела с физическими объектами.
Поставлять: Можно ли разрабатывать и оценивать продукт по частям? Смогут ли представители клиентов/бизнеса предоставить своевременную обратную связь по поводу приращений? 
Инкремент должен быть готов к использованию, а не просто показываться на демо-версии.
Результаты
В конце концов, точки и значения соединяются.
Центрированные результаты показывают готовность к гибким подходам.
Результаты в гибридной зоне показывают возможность сочетания гибкого и прогнозного подхода.
Чем дальше от центра расположены результаты, тем выше вероятность того, что оптимальный подход является прогнозирующим.
Вполне вероятно, что ваша диаграмма будет иметь экстремумы в обоих направлениях.
Главное, не воспринимать полученные результаты как медицинский диагноз.
Это отправная точка для анализа текущей ситуации и дальнейшей работы над изменениями, если они потребуются.
Соавтор лера_иленкова
Теги: #Управление разработкой #Управление проектами #Управление продуктом #agile #agile-методологии #agile-разработка #водопад
-
Спамеры Объявили Третью Мировую Войну
19 Oct, 24 -
Аркадный Волейбол. 40 Кб Удовольствия
19 Oct, 24 -
Iphone 5: Проблемы С Экраном. Видео
19 Oct, 24 -
Улучшенное Предложение Google
19 Oct, 24 -
Не Ждите От Crm Чудес – Просто Работайте
19 Oct, 24 -
Интернет-Саммит Был Отключен От Интернета
19 Oct, 24 -
Opera 9.5 – Официальный Релиз
19 Oct, 24
