Осторожно: агиль и токсичный скрам

Знали ли вы, что Agile придумали для программистов? Только для них. Неспроста в команде разработки Скрама есть всего одна роль - «разработчик». Остальным (даже заказчику) в нем нет комфортного места.

Приниматься за Скрам в проекте, где команда состоит из разных ролей и профессий – значит провалить проект. Почему? Есть спринт и есть команда. Важно не чтобы каждый сделал за что взялся, а чтобы до конца спринта успел «весь колхоз». Стоит одному споткнуться, как другие бросятся ему помогать, лишь бы уложиться в спринт. Тестировщик не успевает с работой до конца спринта? За пару дней до финиша разработчики (если они более-менее закончили свое) - бросаются на выручку. Да, они не тестировщики топ-класса, но помощь окажут. Команда в целом справится, спринт спасен.

А что, если разработчик «споткнулся» и помощь нужна ему? Тестировщик и дизайнер предложат ему свою помощь? Какую? Кодить что ли будут? А разработчик то обрадуется такой «помощи»? Очевидно - не сильно. Так вот. Все в команде должны быть разработчиками. Тогда то, что написано в Scrum Guide работает. Иначе - не имеет смысла.

Возьмем, например, ремонт квартиры. Он имеет мало смысла по частям, правда? Важно, когда и за сколько, в конечном счете, в квартиру можно будет въехать. Все эти цифры имеют значение. По ним можно понять, стоит ли вообще связываться с ремонтом прямо сейчас или лучше отложить. Снести стены, вскрыть полы и «там сориентироваться» - не очень рациональный подход.

Что же предлагает заказчику Скрам? Постоянное общение, вовлечение в каждый спринт. Но не оценку сроков. Другими словами, заказчик интересуется: «Ребята, когда закончите?». Ответ- «Подожди месяцок - другой, мы тебя сориентируем». Хотя, получить сроки спустя пару спринтов - только половина проблемы. Настоящая беда в том, что сроков вы все равно не получите. Люди на проекте меняются. Одни уходят в отпуск, другие болеют. Кто-то увольняется, в команду приходят новички. Каждая такая перестановка как-то влияет на «мощность» команды. Один человек выпал? Появились новые сотрудники? Velocity изменился! Какой он? Станет ясно после… да 2-3 спринтов (месяц-полтора).

И тут начинается самое интересное. Практика показывает, что люди на проекте перемещаются как раз каждые 2 месяца (пресловутые отпуска и болезни). А значит, мы НИКОГДА не знаем «мощности» команды. Метрика, единственная, позволяющая прогнозировать сроки в Скраме, не работает в реальной жизни никогда. Ты никогда на будешь знать срок окончания проекта, ибо «velocity в очередной раз недавно изменилась, мы ее только нащупываем».

У вас на проекте есть реальные ограничения по срокам и деньгам? Скрам вам точно не подходит.

Факт №3 - мост по Скраму не построишь.

Идея Скрама – каждый спринт выдавать заказчику новую пользу. Если вы разрабатываете сайт, где куча элементов и на каждый у заказчика есть своё мнение – да. А если пишете «сервак»? Какая заказчику польза от архитектуры, которую вы разрабатывали весь спринт? Или от админки, которую он и не просил?

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

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

Вернемся к ремонту квартиры. Там сперва все демонтировали (приходи, смотри). Затем побелили потолок и подвесили лампочку в патроне (приходи). Потом сантехник переварил трубу и временно поставил унитаз, а строитель разломал ненужную межкомнатную перегородку (снова смотри). А если я не хочу? Можно я приду 2 раза за полгода? Нет. Нельзя. Будь добр, выдели время.

Заказчика вовлекать надо. Но не каждый заказчик любит, чтобы его дергали часто. Особенно если он ждет десерт, а ему показывают наполовину прожаренную булочку.

Факт №5 – планирования в Скраме много.

«Скрам не тратит времени на планирование», - говорили они нам, «Ведь, пока вы тратите силы на детальный план (техническое задание и графики) - вы, во-первых, занимаетесь тем, что не нужно заказчику, а во-вторых, жизнь меняется и уходит вперед. Спустя пару недель ваши планы нужно переделывать, вы не успеваете произвести даже минимально-полезную «хотелку» пользователя».

«Как же не тратит?» - спросим мы. Примерно 0,5 дня уйдет на планирование каждого спринта. Еще примерно 0,5 дня на демонстрацию и ретроспективу каждого спринта. Плюс ежедневные стендапы продолжительностью от 15 до 30 минут. За недельный спринт набегает еще 1 час 15 минут, минимум (15% дня). Добавим сюда поддержку бэклога, которая должна занимать 10% от всего доступного времени Скрам-команды.

А дальше математика. Если наш спринт равен неделе (5*8 = 40 часов), а сумма всех наших потерь по времени такая, как описана выше (0,5+0,5+0,15+40*0,1), получаем 1,5 дня (12 часов). Значит, потери на планирование каждую неделю составляют 30%. Тридцать процентов! Вот вам Скрам без планирования.

Запуская Скрам - не думайте, что сможете не планировать. Вы лишь снимете с себя ответственность за сроки, а планировать будете не меньше. И привлекать к этому придется всех. Треть времени команда будет тратить на разговоры, не на код.

Факт №6 – хорошие владельцы продукта почти не существуют. 

 Из факта №1 мы помним, что Скрам отменяет все возможные роли, кроме разработчика (все, кто не в состоянии быть разработчиком - должны искать себе применение вне команды). Еще он доверяет постановку задач только одному человеку - владельцу продукта. Где такого взять, учитывая, что он должен знать ответы на все вопросы по продукту (а не искать их в ходе мучительных аналитических расследований)?

 Продукт-овнер в Скраме должен сочетать в себе аналитика, представителя бизнеса и маркетолога. Он должен знать рынок и конкурентов, понимать альтернативы, знать «как у них» и «что срабатывает, а что нет». Получается, что грамотный владелец продукта — это почти мифический персонаж, но без него Скрам правильно работать не будет. 

 А теперь, сделав правильные выводы, примите взвешенное решение. Скрам точно подходит для вашего проекта?