В последние годы я работаю в проектном офисе, где мы, в том числе, подбираем методологии для реализации на проекте и опираемся на самые распространенные подходы: проектный – PMI, продуктовый – Scrum, процессный – Канбан. И поскольку мы ответственный проектный офис, мы не просто играем в методологии, мы пытаемся ответить на вопрос, оптимально ли мы подобрали методологию для конкретного проекта. Мы их подбираем, пытаемся скоординировать, где необходимо. Заодно проверяем себя, пытаемся придумать критерии эффективности, чтобы оценить, удачно ли была выбрана методология, можно ли было выбрать другую – более оптимальную, не ошиблись ли мы.
Во время работы мы ориентируемся на ядро каждого подхода. Например, у PMI есть библия PMBoK, у Scrum – Scrum Guide, с Канбан – несколько сложнее.
И хотя мы читаем все книжки, которые написаны на эти темы, в том числе, авторами этих методологий, мы используем только ядро. То ключевое, что имелось в виду, что вкладывал автор, который придумывал подход.
Кроме того, вызов, с которыми мы сталкиваемся, – мы должны отвечать на запросы проектной команды, особенно это характерно для молодых IT-команд, которые хотят работать по современному Scrum вместо устаревших диаграмм Ганта. И нам надо уметь отвечать на вопрос, можем ли в данном случае работать по Scrum, почему, какие проблемы до этого необходимо решить. И мы ищем ответы на эти вопросы. Мы применяем подходы, комбинируем их.
Почему именно Scrum?
Я выбрал тему про один их самых популярных Agile подходов – это фреймворк Scrum.
И сразу хочу обратить внимание, что эта статья - это не критика Scrum. Это перечень проблем, которые, с моей точки зрения, вы должны уметь решать. Либо вы знаете, как их решить, либо у вас могут возникать сложности, которые поставят под угрозу проект или вашу карьеру.
Итак, сложности, проблемы, с которыми нужно уметь работать, если вы хотите использовать Scrum
Проблема 1. Scrum Guide противоречит Agile манифесту
Неожиданности в применении Scrum начинаются с Agile манифеста. Это прекрасное творение менеджерской мысли, прекрасная гуманистическая вещь утверждает, что люди важнее процессов, а готовность к изменениям важнее следования первоначальному плану. И прекрасно то, что с этим абсолютно все согласны. Я не встречал менеджера, который был бы не согласен с этим. Никто не говорил мне, что надо плевать на людей, надо отпускать полкоманды, надо позволить расстроиться заказчику, лишь бы процесс был нерушим. Я успел поработать в госсекторе и с военной приемкой, но даже в этих зарегулированных отраслях не было таких людей, кто бы сказал, что процессы важнее людей.
В теории можно представить себе такую историю, где-то в глубине “банкинга”, когда действительно процесс очень важен, потому что если вы его меняете, риски очень высоки. И тут действительно лучше пусть полкоманды уволится, чем нарушатся процессы. Ибо риски очень велики. Но в целом в абсолютном большинстве проектов все менеджеры, как бы они не работали – по Канбан или Scrum – все согласны, что люди важнее процессов. И это очень хорошо. Ведь упираться в первоначальный план, вопреки здравому смыслу, нелепо.
Тем интереснее, что на эту тему пишет Scrum. Для этого нужно дочитать так называемое исчерпывающее руководство по Scrum до конца, до последних страниц. Там есть такое заключение:
«Роли, артефакты, правила и события Scrum не подлежат изменению. …Если вы что-нибудь меняете, то полученный результат Scrum уже не является…. Scrum существует только в виде цельного фреймворка…»
Scrum явно говорит, что нельзя ничего выкидывать. Вы можете что-то добавить свое, если оно не противоречит букве или духу Scrum. Но если вы что-то выкинули, это уже не Scrum. Не используйте это слово, потому что вы применяете уже другой подход, который не может так называться.
Интересно сопоставить эти вещи: с одной стороны, есть Agile манифест, в котором люди и взаимодействие важнее процессов, а готовность изменений важнее планов, а с другой – Scrum говорит, что он существует только в виде цельного фреймворка. И как же они сосуществуют? Что же важнее?
Это кажется умозрительной проблемой. Но она оказывается важной, потому что из нее вытекают другие проблемы, связанные с применением Scrum.
И сложность, которую надо понимать, – Scrum Guide не совсем соответствует Agile манифесту, в том числе, благодаря вышеназванным заключениям. Он очень жестко ставит рамки.
Вообще Scrum Guide – самый жесткий из всех фреймворков, которые я знаю в управлении в принципе. Подходы в традиционном проектном управлении гораздо мягче.
Проблема 2. Нет возможности удовлетворить потребности заказчика
Основа Scrum – абсолютная вера в то, что крайне важно раннее вовлечение заказчика. «Держать руку на пульсе» – это важно для заказчика, это большая ценность. Мы его вовлекаем, мы даем ему частый прирост полезной эмоциональности.
Знаете эту картинку? Ее очень любят сторонники Agile.
Понимаете, в чем здесь проблема? В том что это невозможно.
Это картинка буквально говорит нам: «не заставляйте заказчика долго ждать автомобиль, дайте ему что-то полезное, дайте ему сначала самокат, потом велосипед, потом мотоцикл, потом машину». Но нет ни одного способа из мотоцикла сделать автомобиль! Это технически нельзя, это разные продукты. Надо выкинуть мотоцикл и сделать с нуля автомобиль. Ничего нельзя взять из самоката, чтобы превратить его в велосипед. Там нет ни одной полезной детали, это абсолютно другой продукт.
Пример из моей жизни. Мы делаем медицинский сервер, который должен хранить медицинские изображения. Он умеет принимать данные томографа, складывать их и отдавать по запросу. И для заказчика важны следующие вещи: стабильность работы, масштабируемость и низкое энергопотребление. Нет никакой возможности дать заказчику кусочек сервера. Сперва сервер, который имеет только принимать данные, потом сервер, который умеет принимать и отдавать данные, потом сервер, который может их сортировать, а потом сервер, который работает энергоэффективно и надежно. Заказчик будет ждать сервер до тех пор, пока мы не дадим ему нормальный сервер. Никакие «наполовину прожаренные булочки» его не устроят.
Это кажется маргинальным примером, но таких очень много в IT-проектах. Scrum хорошо работает в тех случаях, когда у вас много пользовательской функциональности, когда вы делаете, например, интернет-магазин или мобильную игру и можете постоянно добавлять какие-то кнопочки, каких-то персонажей, и каждый прирост полезен, и заказчик может пользоваться промежуточными вариантами. Но если в вашем проекте большой бэкэнд (backend) или требуется очень тщательное проектирование, и это занимает огромную часть проекта, выкинуть которую никак нельзя, то Scrum, скорее всего, будет не за что зацепиться.
Вывод, который мы сделали: проверяйте себя. Если продукт, который вы собираетесь делать, содержит много пользовательской функциональности, тогда Scrum может быть применим. Если же у вас что-то похожее на наш сервер, и вы сперва долго работаете, а потом выдаете значимый элемент, и промежуточные части не важны, тогда Scrum подойдет гораздо хуже - ему просто не за что будет “зацепиться”.
Знаете фразу: «Нельзя построить мост по Scrum»? Так вот нельзя построить мост по Scrum! Заказчику нужен мост целиком. Никакие половинки и четвертинки или просто сваи ему не нужны, он не может их использовать. Поэтому нужно проверять себя, сколько у вас полезной функциональности, годится ли здесь продуктовый подход такого рода или нет.
Проблема 3. Невозможно оценить сроки
Еще одна проблема, с которой мы столкнулись, и вы должны уметь ее решать, если хотите, чтобы Scrum работал. Это оценка сроков.
Коллеги, сейчас я расскажу очевидную для многих вещь. Но мне важно это сделать, чтобы подвести вас к проблеме. Как Scrum работает со сроками? Он отвергает экспертные оценки, он считает, что попытка прогнозировать сроки в IT – это всегда самообман, это химера, какая-то выдумка. И Scrum говорит, не надо пытаться придумать, сколько работа длится, надо померять это по факту: мы поработаем, увидим и вместо гипотез будем пользоваться фактами. И такой способ оценки сроков будет точнее.
Как это выглядит на практике? Scrum собирает у заказчика все его пожелания («хотелка» 1, 2, 3) и складывает их в некое условные «ведро» под названием backlog. Я очень упрощаю, но смысл такой. Затем мы находим самую простую задачу, наименее трудоемкую, и, вместо оценки сроков, спрашиваем себя, какова ее трудоемкость. Этот показатель у нас будет условной единицей трудоемкости. Это так называемый один условный стори поинт (story point). Потом мы оцениваем, какая трудоемкость у соседней задачи. Например, она вдвое более трудоемкая, чем самая простая. Тогда ее оценивают в 2 стори поинта. А еще есть задачи, у которых 3 стори поинта, 4 стори поинта. Найдется еще задача, которая будет такой же простой, как самая легкая, и ей тоже присвоят оценку в 1 стори поинт. И так мы продвигаемся по всем «хотелкам», все их оцениваем, а каждая получает оценку в стори поинтах.
Дальше мы идём работать. В Scrum важна ритмичность, поэтому мы решаем идти двухнедельными спринтами. Сколько задач мы можем «переварить» за 1 спринт? Мы не знаем. Как это определять? На глаз – методом, так называемого, комсомольского прищура. Вы прикидываете, что, наверное, 5 стори поинтов будет нормально, берете задачи на 5 стори поинтов и всей командой работаете 2 недели.
Допустим, с большим напряжением вы справились. Так выяснилось, что задачи на 5 стори поинтов вы можете закрыть за спринт, но это очень тяжело. В следующий спринт вы берете меньше задач, например, в 3 стори поинта суммарно. И очень легко с ними справляетесь. Но это тоже плохо, потому что осталось свободное время после спринта.
В очередной спринт вы берете, скажем, задач на 4 стори поинта и справляетесь довольно спокойно. И когда вы поработали 2-3 спринта, вы можете подсчитать так называемую мощность команды (velocity). Это не скорость, а именно мощность – сколько вы можете «переваривать» задач за спринт.
На это нужно именно 2-3 спринта. Никакой один калибровочный спринт вам не ответит нормально на вопрос о сроках исполнения проекта. Вам нужно несколько раз попробовать, только тогда вы поймете на самом деле, какая мощность.
Что дальше делает Scrum со сроками? Он спрашивает себя, сколько осталось не отработанных задач. Допустим, на 30 стори поинтов. Если наша velocity находится где-то между четырьмя и пятью, возьмем пять, чтобы команда работала в высоком тонусе, значит, с задачами мы справимся за 6 спринтов. Зная, сколько длится спринт, мы можем сказать, когда закончим проект.
Это называется диаграмма сгорания. Ее можно нарисовать и понять, какие у нас сроки. Это то, что предлагает Scrum.
Еще важно понимать: velocity – это командный показатель. Это тоже философия Scrum, где очень важно чувство локтя, чувство плеча, взаимовыручка. Scrum постоянно говорит нам, что команды являются самоорганизующимися. То есть если мы подходим к завершению спринта и видим, что кто-то не справляется со своей задачей, то мы бросаемся ему помогать и дожимаем этот спринт, и обязательно укладываемся в сроки. Так команда становится сплоченной и самоорганизующейся, развивается и так далее.
Так работает Scrum, поэтому velocity меряет обязательно команду, а не человека. Если вы начинаете втихаря мерить velocity каждого человека, это убьёт ту самую командность.
Представьте, я инженер. И вдруг я понимаю, что какой-то менеджер меряет мои задачки, мою производительность. У меня как минимум появляется вопрос, а нужно ли помогать коллеге. Если я пойду ему помогать, он свои задачки закроет, я справлюсь хуже, мои метрики упадут.
Поэтому Scrum категорически не поощряет индивидуальные метрики. И velocity – эта командная метрика.
И вот проблема: вы потратили 2 - 3 спринта, а обычно спринты не меньше двух недель (мало кто использует недельный спринт), померяли velocity, прикинули, какие могут быть сроки завершения проекта. И в этот момент, скорее всего, произойдет что-нибудь такого плана: кто-то из сотрудников уволился, кто-то ушёл в отпуск, кто-то приболел. Или у вас новичок в команде появился. То есть изменилась ваша команда. Временно или навсегда. Вопрос: какая у вас velocity на следующий спринт? Неизвестно! Вы этого не знаете. Это же метрика командная, а команда только что изменилась. Что нужно, чтоб понять velocity? Конечно, поработать еще два-три спринта, т.е. месяц-полтора. Тогда вы снова ее нащупаете.
И представьте, что примерно каждые два месяца команда будет меняться, и velocity будет все время непредсказуемо меняться. И вам придется опять работать с обновленной командой, чтобы нащупать, какая она теперь.
Может быть, у вас исключение, и ваша команда не меняется, она стабильная. И velocity у вас не прыгает. Но практика показывает, что чаще всего velocity прыгает у всех, а значит, все время будет колебаться ваша диаграмма сгорания.
Проблема Scrum в том, что он почти никогда не позволит вам нормально предсказывать сроки. Вы все время будете додумывать, придумывать, не сможете положиться на ту метрику, которую вам предлагают по умолчанию. Потому что команда изменчива, а вы меряете только командную velocity, а она меняется.
Что с этим делать? На самом деле достаточно просто понимать, что Scrum никогда нормально не может спрогнозировать сроки окончания разработки. К счастью, на многих проектах это неважно. На многих проектах сроки ставятся умозрительно – из серии, заказчик сказал, что «хотелось бы к декабрю закончить». Этот срок он взял из головы, и с ним можно договориться. Но если у вас есть жесткий срок, он определён каким-то неизменным контрактом или привязан к чему-то объективному (у заказчика что-то случится по истечении этого срока), и не может быть сдвинут, тогда Scrum использовать тяжело. Он никогда не может нормально предсказывать сроки окончания. Там это никак не сделать.
Проблема 4. Ваша команда не кроссфункциональна
Еще одна сложность Scrum в том, что ваша команда наверняка не кроссфункциональна, как бы вам не казалось обратное.
Что вообще такое кроссфункциональность? В Скрам-гайд сказано:
«СкрамR08;команды являются самоорганизующимися и кроссфункциональными» (стр. 5).
И: «Кроссфункциональность – наличие в рамках команды всех необходимых навыков для командного создания Инкремента Продукта» (стр. 7).
Это можно понимать двумя способами. Первый – каждый специалист умеет и программировать, и тестировать, и выступать бизнес-аналитиком, и проектировать интерфейс. Вот он кросс функциональный. Но это звучит очень страшно, потому что команду из таких людей собрать крайне затруднительно.
Второй способ, как обычно все понимают кросс функциональность, – это когда в команде есть все нужные роли: есть и аналитики, есть и те, у кого лучше программирование получается, и тестирование, т.е. команда в целом обладает всем нужным набором, чтобы делать продукт. Сориентируемся именно на втором варианте.
В Scrum есть такое пояснение: разработчик – это единственная роль в команде разработки, и другие роли в команде разработки не признаются. А если дальше посмотреть Scrum Guide, то там написано, что подкоманды делать в нем нельзя.
Как вы помните, выкидывать из Scrum ничего нельзя, иначе это не Scrum. Пока помним про этот абзац, но не будем в него вдаваться.
Давайте сконцентрируемся на варианте, когда кроссфункциональность – это наличие в целом такой команды, которая может сделать все, что надо. Представим, что в ней есть только три простые роли: (обычно в командах больше ролей) аналитик, разработчик и тестировщик. Это совсем простой пример.
Как они делят между собой полномочия внутри спринта? Начинается спринт. Мы взяли какую-то «хотелку» заказчика в реализацию. Первое, что нужно сделать, – включиться аналитику, он задачи прорабатывает и передает дальше. Он начинает работать (у него красные глаза), а остальные пока ждут.
Аналитик поработал, по мере его работы появляются какие-то постановки, спецификации. Тут подключается разработчик.
Разработчик начинает работать (теперь уже у него красные глаза), спринт идет дальше. Аналитик, тем временем, немного отходит от дел, потому что свою часть работы сделал.
Со временем просыпается еще и тестировщик.
Он принимает от разработчика задачи, и под конец спринта уже в основном работает тестировщик (до красноты глаз). Периодически он возвращает разработчику какие-то дефекты, их правят, иногда вместе ходят к аналитику, если оба не поняли задачу.
То, о чем я рассказал, – бред. Потому что треть спринта «спит» каждая из ролей: в конце не особо нужен аналитик, а в начале не особо нужен тестировщик и разработчик, им делать нечего. Но это абсурд.
Что делают многие команды? Очень часто они запускают как бы аналитика с опережением. Как это может выглядеть? Аналитику предлагают работать заранее, чтобы он шел на 1 спринт вперед, прорабатывать задачки. И тогда разработчику будет, что делать. Попробуем представить себе это. Аналитик включается на 1 спринт раньше, берет задачки, делает по ним постановки, работает по ним с какой-то своей мощностью. На спринт позже просыпается разработчик. И у него уже всегда есть работа. Принимая задачки от аналитика, он работает с какой-то своей velocity.
Важно, что мощность разработчиков - это уже другой показатель, это как бы другая команда (1 или несколько разработчиков), и у них своя velocity, они могут работать быстрее аналитика или медленней. Нам нужно тоже ее померять, чтобы понимать, насколько нужно с опережением идти аналитику. Видимо, еще на 1 спринт позже подключается тестировщик, который принимает от разработчика задачки и тестирует их со своей velocity.
Это только три роли, а представьте, если их больше. Понятно, что это опять бред.
Каждый, кто так делал, понимает, что рано или поздно произойдет: споткнется аналитик и повалится вся схема. Например, он не успеет дать задачки разработчику, и у них у всех не будет работы. Более того, мы только что сильно усложнили подход. У нас есть теперь три команды, и у каждой своя velocity. И вообще все это подозрительно похоже на диаграмму Ганта, которую мы так не любим.
Сейчас полезно вспомнить тот абзац, про который мы говорили раньше: разработчик – единственная роль в команде разработки, других Scrum не признаёт.
Отсюда вывод, который мы сделали для себя: кроссфункциональность – это в прямом смысле слова, именно в первом смысле слова, когда все умеют всё. Scrum без костылей и без лишних вопросов работает тогда, когда у вас действительно все члены команды могут всё: разработчик может и протестировать, и выступить аналитиком, и дизайн немного запилить, если нужно. Вот тогда понятно.
Что делать? Одно из двух: либо спросить себя, является ли наша команда на самом деле кросс функциональной (так бывает, но редко), либо придумать свой способ решения проблемы переключения ролей.
Как ее еще пытаются решать? Аналитика, например, выносят вообще из Scrum команды, чтобы он работал с задачами на уровне backlog’а. Тестировщика пытаются заменить автотестами. Но это тоже не очень просто, на практике еще миллион вопросов возникает.
Проблема 5. Слишком много времени на планирование
Одна из ценностей Scrum, особенно если верить книжкам, которые написал один из авторов Scrum Guide, – Scrum экономит время на планировании. Команда не тратит время на то, чтобы делать планы в начале, а сразу идет работать. Но давайте посчитаем, сколько на самом деле уходит времени на планирование в Scrum.
Представим себе недельный спринт. Что такой недельный спринт? Это 5 рабочих дней, 5 прямоугольников.
На что тратится время при планировании Scrum? Во-первых, в Scrum есть планирование спринта. Если бы спринт был месячный, то планирование должно было бы занимать не более 8 часов, а он у нас недельный. Согласно обтекаемой формулировке Scrum Guide, если спринт короче, то на его планирование нужно меньше времени. Насколько меньше, непонятно. Но на практике очень мало команд может планировать спринт быстрее чем за три-четыре часа, это в среднем.
Есть еще так называемый ежедневный Scrum. Так называемый стендап - очень полезная практика, когда в начале каждого дня все члены команды собираются и отвечают на три вопроса (условно):
- что я делал вчера?
- что я буду делать сегодня?
- чем мне можно помочь?
На это уходит не больше 15 минут в день. В 15 минут не так-то просто уложиться, но это достижимо. Если возникают вопросы в ходе ежедневного Scrum, то они переносятся на отдельное совещание: специалисты, которых касаются проблемы, остаются и между собой все обсуждают. Они тратят на это столько времени, сколько нужно – 40 минут, 50 минут, сколько потребуется.
На что уходит время еще? Есть такая вещь, как обзор спринта и ретроспектива. Обзор спринта в месячном спринте занимает не больше 4 часов, а ретроспектива – не больше 3 часов. Если бы спринт был месячным, то на ретроспективу и обзор ушел бы целый рабочий день – 7 часов. В нашем примере он не месячный, но опять же по нашему опыту, быстрее, чем за три-четыре часа и обзор, и ретроспективу провести сложно.
Но и это еще не все. Еще есть такая вещь, как уточнение backlog’а, которая может занимать до 10% времени от всего свободного времени команды.
А теперь давайте посчитаем, что получилось на нашем недельном спринте:
- планировать спринт – полдня в неделю;
- ежедневный Scrum, если все дни сложить, это 0,15 дня за всю неделю в сумме;
- вопросами, которые требуют обсуждения, мы пренебрежем, посчитаем, что их не было, и мы потратили 0, хотя на практике будут такие вопросы, и мы на них время потратим;
- на обзор и ретроспективу ещё полдня в неделю;
- еще примерно полдня в неделю на уточнение backlog’а.
В сумме получается 1,65 дня, то есть 30% рабочего времени. Столько уходит на планирование недельного спринта.
Понятно, что если спринт длиннее, то времени на планирование удельно будет тратиться меньше. Вот почему никто не использует недельные спринты: слишком много времени уходит на планы.
Но если у вас принят месячный спринт, там другие проблемы. Вы же обещали заказчику вовлечение, частые поставки, где же они? Раз в месяц? Scrum отбирает у заказчика возможность прогнозировать сроки, но зато дает ему вовлечение, «руку на пульсе» и частые поставки – регулярно. Но раз в месяц – это не частные поставки. Любой проектный подход запросто обеспечит ежемесячные релизы. Тут Scrum уже ни при чем. Поэтому месячные спринты – тоже не очень популярный подход. В основном используются двух-трехнедельные спринты, и там у каждого свои особенности. И там тоже довольно много времени уходит на планирование.
Что с этим делать? Просто понимать, что Scrum – это один из очень прожорливых до времени на планирование фреймворков. Если проектные подходы тратят много времени в начале и не очень много – в процессе, то Scrum очень много времени тратит на планирование постоянно.
Другие проблемы Scrum
Коллеги, есть ещё множество проблем. Например, если ваша команда уже сейчас не является высоко эффективной и дружной, то, по нашему опыту, применение Scrum и всякие коучи не сделают ее более эффективной и дружной. Дело в том, что у вас сначала должна быть дружная команда, и тогда отлично зайдет Scrum. Первична именно команда, а не фреймворк.
Также вам всегда будет хотеться, чтобы владельцы продукта были немножко получше, немного покруче. Это проблема не человека, это проблема того, что роль слишком перекручена. На нее возложена функция троих человек, как минимум. Такие универсальные люди в природе почти не встречаются. Поэтому всем всегда не нравится их владелец продукта, кажется, что нужен человек посильнее, и будет меньше проблем.
В рамках этого доклада я не успеваю рассказать, почему Scrum не нравится финансистам, и почему он незаметно проталкивает вам консалтинг. Все это вынесено в отдельную статью, которую можно почитать по ссылке.
И еще раз подчеркну: это не критика подхода. Это предупреждение. Есть проблемы, о которых вы должны знать, и должны понимать, в чем они заключаются. И вы должны знать способ, как вы преодолеете их: для каждой нужно сформулировать свое решение. Тогда Scrum можно применять смело.
В завершение скажу: мы применяем Scrum. Просто это не так легко и не так безопасно, как кажется иногда.
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.
