-Я хочу устроить панику, понятно?
-Ты там бойню устроишь, а не панику.
«Большой куш»

В течение уже достаточно долгого времени мне попадаются на глаза посты, статьи и даже целые книги, задача которых — донести до читателя советы о том, как правильно делать Скрам. Все они, в общем-то, однотипны и построены на предположении, что большинство людей некорректно понимают предлагаемые практики, их назначение и важность. В этих источниках активно доказывается, что Скрам все-таки работает, говорится о принятии ценностей, о перестроении мышления на уровне компании, о тонкостях организации митингов и прочих нюансах, которых по итогам каждый раз набирается вагон и маленькая тележка. Судя по всему, проблема действительно существует, ведь даже Кен Швабер и Джеф Сазерленд описывают Скрам как “легковесный, простой в понимании и сложный в овладении” [1]. Но только ли дело в практиках? Может быть, люди не понимают саму суть Скрама? Когда что-то начинает приносить серьезные деньги, то не секрет, что именно прибыль становится путеводной звездой этого корабля. Может быть все эти тренинги, сертификации и спешно переучивающиеся в скрам-мастеров менеджеры проектов затмили собой изначальный посыл? Вполне вероятно. Но так ли это? Данный опус — это попытка взглянуть на проблему под немного другим углом, с точки зрения больше технической, чем какой-либо еще.

Стив Макконнелл в своей книге “Совершенный код” пишет: “Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки” [2]. Идея сама по себе не нова —  стремление к простоте пронизывает всю историю программного обеспечения и культивируется до сих пор. “Простота — ключ к надежности”, говаривал Дейкстра. “Управление сложностью — квинтэссенция программирования”, вторит ему Керниган. И тут внезапно применительно к Скраму мы встречаем определение “сложный в овладении”. Это еще что такое? Налицо очевидное противоречие. Мы тут вообще-то изо всех сил со сложностью боремся, так зачем нам явно сложная методология разработки? Нонсенс? Но возможно, ответ как раз и заключается в том, что Скрам — это не методология. И не разработки.

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



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

“Скрам – это фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и в то же время продуктивно и креативно разрабатывать продукты наивысшего качества.”

Первое, что мы замечаем, — это слово “фреймворк”, и стоит отметить, что именно на таком определении настаивает Кен Швабер. Но что такое фреймворк с нашей, технической, точки зрения? Это внешний каркас, определяющий структуру системы. Одной из характерных черт такого рода каркасов является реализация принципа инверсии управления. Inversion of Control — понятие, довольно широко сегодня используемое в первую очередь применительно к механизму внедрения зависимостей. Однако, как показывает практика, люди не только путают понятия IoC и DI, но иногда даже их отождествляют. Давайте же разберемся с этим раз и навсегда. Рассмотрим простую программу:

static class Program {
  static void Main() {
     A();
     B();
     C();
  }
}

Наш главный метод Main вызывает сначала функцию A, затем B и, наконец, C. Это могут быть библиотечные функции или какие-то внутренние методы приложения. Таким образом, именно программа определяет набор и последовательность совершаемых действий, она сама собой управляет. Такой поток управления называют прямым. Если направление этого потока обратить в противоположную сторону, мы получим то, что еще называют голливудским принципом — не звоните нам, мы сами вам позвоним (или более техническим языком: не вызывайте нас, мы сами вас вызовем). Фреймворки реализуют именно такой подход, предоставляя точки расширения. Мы как разработчики подключаем к этим точкам свой код, который вызывается ровно тогда, когда внешний каркас посчитает нужным это сделать, при этом код самого каркаса остается неизменным. Именно этим фреймворки отличаются от обычных библиотек, а подобный поток управления называют инвертированным.

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

Управляет ли Скрам потоком выполнения? Да, конечно. Он предоставляет нам итеративно-инкрементную концепцию спринтов, определяет список действий в рамках каждого спринта и даже задает распорядок дня. Тут вопросов никаких.

Является ли Скрам неизменным? И снова да. Об этом авторы говорят нам буквально прямым текстом: “Каждый элемент фреймворка служит определенной цели и является ключевым для успеха и использования Скрама.” Еще одно прямое попадание.

Но что мы встраиваем в этот фреймворк, в эти самые точки расширения, находящиеся между грумингами, стэндапами и ретроспективами? Очевидно, саму разработку со всеми ее компонентами: дизайном, тестированием, проектированием, конструированием, рефакторингом и т.д. Причем заметьте, Скрам никоим образом не пытается лезть в этот процесс, не делает попыток ни изменить его, ни диктовать свои правила и условия. Как любой порядочный фреймворк, он ничего не знает о бизнес-логике, с которой взаимодействует. А это означает, что вместо разработки ПО мы можем встраивать и другие вещи. И действительно, на сегодняшний день Скрам адаптирован для сферы финансов, здравоохранения, высшего образования. Отдельные энтузиасты используют его для строительства домов, ведения домашнего хозяйства и даже организации свадеб.  Но погодите. Если мы встраиваем разработку во фреймворк, буквально как черный ящик, то не получается ли так, что этот внешний каркас самой разработкой-то и не управляет? Именно!

Но что же он тогда делает? За ответом далеко ходить не надо, достаточно вернуться к первоисточнику: “решает сложные адаптивные проблемы”. В частности “показывает относительную эффективность вашего управления продуктом и практик разработки”, а результатом подобного наблюдения является “возможность их улучшить”.

Чтобы яснее понять, о чем идет речь, совершим небольшой экскурс в историю. Роберт Мартин, известный в широких кругах также как Дядюшка Боб, в своей речи “Будущее программирования” [3] выделяет две предпосылки появления гибких процессов. Одна из них заключается в том, о чем мы и так с вами в общем-то в курсе: в 90-х мир разработки ПО начал активно меняться, и водопад стал сбоить. Соответственно, нужны были новые подходы, ориентированные на динамичные бизнесы со всеми вытекающими характеристиками: необходимостью быстрой адаптации к рынку, склонностью к постоянным изменениям и т.д. Недаром Кент Бек называл одной из главных целей Agile  “стирание границы между разработкой и бизнесом”. Еще больше проникнуться этим утверждением можно, если принять во внимание, что на самом деле Бек использовал слово “heal” — исцеление. Однако смотреть на ситуацию с точки зрения одного только бизнеса было бы неправильно. Если вы откроете список авторов знаменитого Agile-манифеста, то обнаружите, что практически все эти люди — прожженные технари. Вполне логично предположить, что решали они не только проблему бизнеса, но и какую-то свою собственную, сугубо техническую. И это действительно так. По эмпирической оценке того же Боба Мартина количество программистов увеличивается вдвое каждые пять лет. Это означает, что в любой момент времени, вообще говоря,  половина всех разработчиков — это люди с опытом, не превышающим пятилетний срок. Является ли это проблемой? Пожалуй, что да. Опять же, суть вопроса не в конкретном временном отрезке, а в количестве опыта как таковом, ведь, будем откровенны, корреляция между временем и уровнем знаний существует и достаточно высокая. Таким образом, гибкие методологии не только стараются удовлетворить потребности бизнеса, предоставляя ему более понятную, удобную и выгодную модель разработки программных продуктов, но и занимаются вопросом недостаточного уровня профессионализма в командах программистов.

Скрам же, являясь фреймворком, предоставляет организационный инструмент, позволяющий, подобно лакмусовой бумаге, максимально быстро выявлять проблемы в этих двух областях и оперативно на них реагировать. Но не больше. Если вы не умеете наладить работу с требованиями, а ваши разработчики пишут некачественный, выползающий изо всех сроков и бюджетов код, то сам по себе Скрам не изменит ровным счетом ничего. Самое большое заблуждение как раз заключается в том, что люди ожидают, что одно только его применение способно оптимизировать внутренние процессы. “Ваши ожидания — это ваши проблемы”, как говаривал один небезызвестный футболист. Отсюда же следует, что задача скрам-мастера заключается не столько в пристальном и ревностном слежении за событиями, артефактами и правилами фреймворка, сколько именно в выявлении и устранении возникающих проблем. И да, это означает, что он должен не только уметь отличить хорошую пользовательскую историю от плохой, но и напрямую влиять на технические аспекты разработки, такие как внедрение тех или иных инженерных практик. Четыре ценности и двенадцать принципов — это лишь вершина айсберга Agile, а поддерживают их конвенция именования,  эволюционный дизайн, обзоры кода, разработка через тестирование, рефакторинг, непрерывная интеграция, шаблоны проектирования, парное программирование и прочие многочисленные технические методики. Помните: невозможно решить проблемы разработки с помощью одних лишь организационных выводов. От стэндапов и ретроспектив самих по себе лучший код не появится в ваших репозиториях. Но он имеет все шансы там оказаться, если с помощью инструментов Скрама вы научитесь выявлять проблемы команды в технических областях и будете обладать достаточным запасом компетенции, чтобы применять к ним именно технические решения.

И тогда никто и никогда не сможет скрамуниздить ваш “чистый код, который работает” [4].

[1] Scrum Guide
[2] Стив Макконнелл «Совершенный код»
[3] The Future of Programming
[4] Рон Джеффриз