Людям свойственно со временем забывать откуда все пошло, поэтому нужно вспоминать. Публикация навеяна статьей "Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка".

Конечно, это моя интерпретация, но она основана на огромном количестве времени обучения, самообучения и опыта в индустрии.

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

Идейная основа Agile-манифеста (ака честный и понятный Agile-манифест):

1. PMBoK и остальные классические методы управления проектами не дают достаточный результат. В топку их.

2. Пока что у человечества нет способа успешно завершать проекты. Поэтому мы рассчитываем на то, что и не будем (придется что-то двигать в пирамидке время, функционал, стоимость и качество).

3. Мы считаем, что в пирамидке имеет смысл двигать только функционал. Другими словами мы не гарантируем то, что успеем сделать, а все остальное гарантируем.

4. Делаем сначала самый критичный функционал, затем менее критичный. Функционал делаем так, чтобы все необязательные вещи отложить на потом, так чтобы быстрее прийти к ситуации минимально рабочего продукта (и уже от этого этапа заниматься улучшениями). Т.о., в любой момент будет выдана максимальная ценность на затраты.

5. Мы гарантируем, что будем максимально активно работать. Для этого мы обеспечиваем максимальную прозрачность для заказчика.

6. Мы гарантируем, что приложим усилия по постоянному анализу и улучшению того как мы работаем.

7. Ма гарантируем, что будем поставлять небольшими итерациями, чтобы иметь возможность быстро адаптироваться.

8. Мы всячески поддерживаем изменение ТЗ, чтобы сделать именно то, что нужно, а не то, что было понятно до начала проекта.

9. Мы ожидаем сильную вовлеченность заказчика в процесс разработки, т.к. это одна из общих черт успешных проектов.

Почему они сразу не написали что-то подобное? Видимо, не было цели сделать его простым и понятным. Или просто написали то, что и как успели. Все-таки согласовать что-то среди 17 человек (и у каждого огромный опыт) весьма сложно.

Другими словами: нет способов -> и не будет от нас -> что успеем функционал -> компенсации за такой подход.

Эти 9 пунктов соответствуют 4м пунктам манифеста. 12-ти основополагающим принципам не соответствует в одном пункте ("Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд."). Точнее этот пункт вынесен за скобки: его можно было бы сделать десятым, но у меня сильные сомнения в нем -- не знаю данных по нашей стране (а голословно не хотелось бы утверждать) и не видел на практике как эффективно строить подобные команды (не хотелось бы делать нереализуемые требования -- типа пишите код без ошибок и проблем не будет).

Обычно самые дискуссионные пункты 2 и 3. Давайте их рассмотрим подробнее.

Опытные заказчики прекрасно представляют, что проекты обычно проваливаются. Но это не значит, что все из них готовы на Agile-подход. Так же весьма распространен подход, когда сама разработка в итоге убыточна для подрядчика, а прибыль делается за счет завышенной цены поддержки. Бывает, что заказчик вполне сознательно разоряет подрядчика, просто потому что тот неопытный новичок. Тут нет какого-то особого рецепта, но в большинстве внутренних проектов в итоге приходят либо к Agile-подходу, либо просто смотрят сквозь пальцы на постоянные провалы проектов ("это жизнь", при этом без компенсационных пунктов из Agile). Для заказных проектов есть еще такой подход: глубокая специализация исполнителя, тогда в очередном проекте он не делает для себя ничего нового и может адекватно оценить проект.

Другой вопрос: почему только функционал, а не 3 других характеристики? Давайте рассмотрим:

1. Стоимость. Обычно есть некоторое бюджетирование и крайне неприятно его превышать. Например, чтобы в середине проекта увеличить команду в 2 раза -- не так уж это и будет эффективно.

2. Время. Обычно время довольно сильно связано со стоимостью. И часто есть какие-то связи с другими подразделениями, которые ожидают продукт к какому-то числу. Поэтому достаточно редко получается двигать время.

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

4. Функционал. Функционал крайне гибкая вещь в ПО. Его можно довольно сильно дробить, выделять быстрые и важные вещи, выделять медленные и не такие уж важные вещи, приоритизировать все это дело. Можно даже добиваться высокоуровневых целей проекта без каких-то удобных и важных, но некритичных вещей. Другими словами: в этом пункте огромный потенциал, который мы и хотим использовать.

Еще не все понимают, что "что успели функционал" фактически может означать увеличение времени и стоимости, если заказчик заапрувит дополнительный бюджет. При этом мы в любом случае поставляем что-то, что уже может быть использовано, просто может быть еще не так эффективно как хотелось бы.

Что же про Скрам? Это одна из реализаций Agile-манифеста. Получила высокую популярность за краткость и понятность артефактов/мероприятий.

При этом крайне часто Скрам внедряется без Скрама. Как так получилось? Внедряется весь основной процесс, но без скрам-мастера. Да, это тоже может быть и даже будет соответствовать Agile. Просто это нужно называть как-то не Скрамом.

Скрам-мастер -- это переговорщик без ИТ-знаний. Для внутренних команд он может быть среднего уровня (и получать заметно меньше менеджеров проектов, начальников отделов, тимлидов и тп -- в этом и один из смыслов). Основная задача: наладить взаимодействие всех на проекте (и внутри команды, и внешние связи). Нет права принимать никаких решений (и тут так же полезно отсутствие ИТ-знаний). Скрам-мероприятия используются как одна из стартовых точек регулярного общения.

Почему обычно не внедряется Скрам? Даже во внутренних командах многие руководители требуют персональную ответственность кого-то за результат команды и не хотят особо смотреть на прогресс команды в промежуточных стадиях. Нужны отчеты руководству выше, а скрам-мастер их писать не умеет (если это нормальный скрам-мастер ака выпускник факультета психологии). Поэтому вместо скрам-мастеров берут достаточно дорогих руководителей проекта, которые в итоге не дают результат, но дают много бумаги почему то, что получилось -- это успех.

Отдельная проблема Скрама -- это Скрам-альянс и многочисленные коучи. Хотя, может именно из-за них Скрам и приобрел такую узнаваемость (даже при том, что мало кто его по настоящему внедряет).