Авторы: Алексей Янчук, Константин Кондратюк

Казалось бы, на тему того, что лучше — waterfall или agile -– все те, кто хотели, уже сломали все копья. И казалось бы, большинством голосов согласились, что будущее все-таки скорее за agile. И тем не менее складывается ощущение, что процесс поиска аргументов за agile не отпускает «евангелистов».

Как-то на одной scrum-конференции один участник задал вопрос: как можно совместить Scrum и 9001 сертификацию? Встает один scrum-«евангелист», и начинает доказывать, что сертификат 9001 со Scrum-ом не совместим никоим образом, и вообще пережиток прошлого и никому он не нужен. Когда высказался, я (Алексей Янчук) решил взять слово. Говорю: 9001 и Scrum совмещаются очень просто. 9001 описывают всю компанию, Scrum — узкую область написания софта и взаимодействия с представителем пользователей. Опишите в 9001 как вы скраммите — и дело сделано.

После меня встает евангелист, и начинает убеждать публику, что я, как бы это так помягче сказать, нес ересь. 😉 Вызвало улыбку. Говорю: коллега, вы знаете, есть Scrum, а есть зарплата, которую вам платят. Вы знаете, откуда она берется? Так вот, говорю, как человек, который отвечает за выбор подрядчиков, открою вам страшную тайну. Никто никогда не читает десятки предложений. Выбирают два-три для детального прочтения, остальные, увы, идут в мусор. Эти 2-3 выбираются в первую очередь — сюрприз — по формальным признакам. Поэтому фирма, у которой есть Scrum и 9001 по определению придет на финиш раньше, чем Scrum от «евангелие».

В споре, что лучше — waterfall или agile — почти всегда забывают о том, что есть еще третья сторона — бизнес. Он же клиент. Он же заказчик. Он же тот, кто оплачивает работу. Я регулярно устраиваю sit down встречи с заинтересованными сторонами, где в неформальной обстановке обсуждается текущее положение дел. На одной из таких посиделок заказчик как-то пожаловался на опыт внедрения Scrum.

Что произошло? До Scrum-а была регулярная проблемы с тем, что разработчики обещали сроки, которые практически никогда не выполнялись. А теперь — он говорит — стало еще хуже. Если раньше мы знали, что обещанное к концу второго квартала будет работать к началу четвертого, то теперь мы даже понятия не имеем, когда над нашими задачами начнут работать.

Как же так? — спрашиваю я — ваш подрядчик весь из себя такой Scrum-сертифицированный? В чем проблема спланировать и закоммититься под несколько спринтов — есть в этом есть такая бизнес-необходимость? Да дело в том — отвечает заказчик, — что команда дает коммитмент только под следующий спринт. Исходя из того, что насыпалось в этот [цензура] бэклог. А сыпется туда достаточно!

О чем это мы? О том, что споры о том, что лучше — waterfall или agile — это по большому счету споры ни о чем. Невозможно написать идеальную спецификацию — которая бы не вызывала вопросов, и в результате которой получилось бы то, что на самом деле хотели. Поэтому любой ИТ проект будет похож на плавание галсом против ветра, в идеале не сильно отклоняясь от общего направления. Будь то waterfall или agile.

Успех или неуспех определяется в первую очередь лидерством: знать, куда идем, зачем, как работать с изменениями и ожиданиями заинтересованных сторон и почему мы делаем то, что делаем. Во вторую — командой, и только в третьих — инструментами. На английском есть такое хорошее выражение: «a fool with a tool is still a fool.» Что на русский можно перевести, как «заставь дурака Богу молиться, так он лоб себе расшибет».