Неправильный Scrum

«То, что в первом приближении может очень походить на agile на самом деле может быть просто хаосом и способом траты денег, не имеющих четких целей и демотивирующих проектную команду.».

Алексей Кривицкий, тренер SCRUMguides

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

Данная история — пример хаоса, возникающего при неправильном обращении с agile-методологиями.
В прошлом году я участвовал в нескольких проектах, которые формально делались по методологии Scrum. Проекты были аутсорсинговыми, наш клиент продавал их своему клиенту как Scrum, соответственно, контракта с фиксированной оплатой не было, оплата шла повременная. Схема разработки была итерационной, каждая итерация включала в себя демо-версию продуктов и сессию планирования следующей итерации. Приоритеты требований менялись в зависимости от результатов демо. Так что же было не так?

1. Начнем с того, что проекты были крупными и распределенными. Над одним проектом могло работать 35-45 человек, находящихся в разных офисах в разных городах в разных часовых поясах. Согласитесь, серьезное осложнение для процесса, где по канонам все должны работать в одном офисе (в идеале — в одной комнате), ведь живое общение — одна из основ agile-процесса: именно живое общение снижает уровень бумажной бюрократии.
2. В первую очередь, наши клиенты восприняли Scrum с его ежедневными «стоячими совещаниями» как отличный способ получения отчетности (одна из величайших проблем крупного бизнеса в том, что отчитаться о проделанной работе часто важнее, чем эту самую работу качественно выполнить). Выглядело это так: каждый день для общения по телефону собирались руководители разработки из разных офисов и докладывали американскому руководству о состоянии текущих задач и дальнейших планах, после чего координировали работу со своими командами. Но у этих руководителей было по несколько групп разработчиков, а это в сумме — 20-25 человек на каждого… Реалистично отчитаться о задачах каждого из них — задача нетривиальная, потому к совещаниям вскоре подключили и руководителей команд. Даже для тимлидов не всегда было по силам досконально описать ситуацию в текущих задачах и способы ее решения, потому к совещаниям время от времени стали подключать и ключевых разработчиков. В итоге, большинство ключевых сотрудников стало отвлекаться на час-полтора каждый день, чтобы посовещаться. Это называлось «daily scrum» (который по правилам длиться должен не более 15 минут) и не могло не вредить общей продуктивности.
3. Вскоре клиенты признали — такой подход не годится. Ведь больше всего о конкретных задачах проекта знают сами разработчики — значит они и должны отчитываться о своей работе, как это написано в книгах по Scrum’у. Но в команде проекта 30-40 разработчиков, притом, работающих в разных офисах, выслушать их всех и не потерять нить обсуждения крайне трудно. Выход был найден: вместо телефонных разговоров стали использовать групповой чат, логи которого всегда можно было перечитать. Но теперь уже не только ключевые сотрудники, но и вся проектная команда тратила ежедневно 1-2 часа на отчетность.
4. Отчетность эволюционировала: когда стало понятно, что 1-2 из 8 рабочих часов ежедневно — это неприличная роскошь, схему пришлось изменить. Теперь разработчикам просто задавали подряд 3 классических для Scrum вопроса: «Что сделали за прошедший день?», «Что делаете теперь?», «Есть ли у вас препятствия на пути?», а разработчики должны были синхронно ответить на эти вопросы в чате. Больше никаких индивидуальных обсуждений… Позже американское руководство анализировало логи этих чатов… Зато все успевали «выговориться» за 15 минут. Было понятно, что подобные «daily scrum’ы» — чистый формализм, к счастью, разработчики воспринимали этот идиотизм с юмором.
5. Впрочем, отчеты разработчиков вовсе не освобождали локальных руководителей разработки от собственных отчетов (еще более формальных) и за каждую итерацию, и за каждый день в отдельности. Я до сих пор не могу понять, где наши американские коллеги находили время для чтения всех отчетов.
6. Все без исключений agile-методологии итеративны. В конце итерации (в Scrum они называются спринтами) мы получаем билд продукта, готовый к демонстрации. Создатели методологии XP предпочитают короткие итерации в 1-2 недели, Scrum — длинные в 1-2 месяца. Наш клиент решил сделать итерации максимально короткими — 1 неделя, то есть 5 рабочих дней. А иногда у нас бывали и микро-итерации — 2-3 дня… Клиент надеялся таким образом иметь больший контроль над процессом: ведь 1 неделя работы в неправильном направлении не так губительна, как две или даже четыре недели. Кроме того, если итерации недельные — значит и отчеты о результатах итерации можно получать каждую неделю. На практике же недельные итерации приводили к спешке: разработчики торопились, чтобы успеть закончить хоть что-то значимое в столь короткие сроки (впрочем, это скорее ошибка менеджмента), из-за чего уделяли минимум времени тестированию собственного кода. Осложняло ситуацию еще и то, что из 5 дней спринта реально на разработку оставалось всего 4, так как день уходил на «разворачивание» продукта, подготовку демо-версии и.т.п.. Каждый новый билд кишел глюками и мелкими недоработками.
7. Роль тестировщиков в agile-процессе до сих пор слабо освещена. Клиента это нисколько не смущало, потому тестировщики у нас не были интегрированы в процесс разработки, а разработчики — в процесс тестирования. Если демо у нас в проектах проводилось каждый понедельник, то тестировщики (находящиеся не в тех же офисах, где работали разработчики) приступали к работе над тестированием нового билда лишь во вторник. Сессии планирования (стоит ли рассказывать, что, вопреки принципам Scrum’а, рядовые сотрудники в них не участвовали?) у нас проходили по четвергам, тестирование последнего билда в это время все еще длилось. Таким образом, просто не получалось составить план следующей итерации так, чтобы сначала исправлялись глюки, а лишь затем разрабатывался новый функционал. Можно было лишь предполагать что-то вроде «40% времени мы потратим на исправление ошибок». Такой подход вел к неконтролируемому распространению глюков.
8. Сами заказчики продуктов были удалены от проектных команд. Такой инструмент гибких методологий как «пользовательские истории» тоже не использовался. Таким образом, заказчики и конечные исполнители не находились «на одной волне» и нередко воспринимали одни и те же требования по-разному. А ведь это одна из проблем, которую должны решать гибкие методологии.
9. Не было и «ретроспектив». В конце каждого спринта команды не собирались вместе, чтобы обсудить слабые стороны итерации и решить, как можно улучшить процесс: распределенная природа разработки этого не позволяла. Иногда такие вопросы обсуждались руководителями на сессиях планирования, но решались лишь локальные вопросы — глобальные (а их было большинство) требовали многократного утверждения высшим руководством в США и «повисали» на неопределенный срок.

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

В последующих проектах совместно с клиентом нам удалось изменить стратегию, мы масштабировали agile-процесс для работы распределенных команд, отказались от понятия «Scrum» и побороли большинство проблем, описанных в этой статье, что увеличило продуктивность работы в несколько раз. Хотите узнать, как мы этого добились, как внедряли изменения? — это тема следующей статьи.