GROTEM / Express
Запрос на Демо доступ
Нажимая на кнопку, вы принимаете условия оферты
и соглашаетесь с политикой конфиденциальности
Оставьте свой телефон и мы свяжемся с вами!
Нажимая на кнопку, вы принимаете условия оферты
и соглашаетесь с политикой конфиденциальности
Осторожно: онлайн-касса может остановить бизнес с 1 января
Проверьте, готов ли ваш интернет-магазин к работе по новым правилам. Напишите свою почту, и мы пришлем чек-лист для проверки из 8 пунктов. Коротко и ясно.
Ваш email
Нажимая на кнопку, вы принимаете условия оферты
и соглашаетесь с политикой конфиденциальности
Кейс GROTEM

«Образцовый» Scrum-проект: клиент доволен, разработчик — нет

Как обнулить достоинства Scrum для клиента — объясняет директор по развитию Grotem на примере разработки сервиса регистрации онлайн-касс.
Этот кейс — для компаний, которые заказывают ИТ-разработку, и для разработчиков, которые только присматриваются к Scrum (есть такие?). Я расшифрую обязательные термины Scrum и объясню:

1. Что происходит у разработчика после старта проекта.
2. Что требуется от заказчика.
3. Почему не всё окей, когда вроде всё окей.

Если вы почти каждый день произносите «нам пора на дейли» — вам будет скучно читать. Хотя кто знает.
Что такое Scrum и почему он
Обычно начинают так: «Scrum — это фреймворк…». Мы предпочитаем говорить, что это способ создать продукт на основе доверия. Именно благодаря доверию случается высокая скорость разработки, увлеченность команды и актуальность продукта на выходе.

В отличие от Scrum, более классический подход к разработке Waterfall (каскадная модель), основан на недоверии. Недоверие рождает бюрократию. Десятки согласований, обоснований, килограммы бумаги и строгие письма в почте: «Просим придерживаться первоначального ТЗ, мы его полгода писали», «Бухгалтерия не одобрила ваше предложение по изменениям, требуется детально прописать, на что именно будет потрачен каждый час». Долго, нервно, некомфортно.

Часто заказчик не готов работать по Scrum. Тогда исполнитель идёт на хитрость: снаружи менеджеры строят декорации, похожие на Waterfall, а внутри команда работает по принципам Scrum. Зачем? Ну потому что сейчас бессмысленно делать большинство проектов по классике: слишком быстро всё меняется, слишком много неопределенности.

Получается странный и лицемерный гибрид. Работается по-прежнему некомфортно, на выходе легко получить не то, что нужно заказчику. Поэтому каждый Scrum-разработчик мечтает об образцовом проекте — когда клиент тоже готов соблюдать принципы, сочиненные Джеффом Сазерлендом. И у нас есть такой завершенный проект.
Запомнить: доверие в Scrum невозможно без открытости и предсказуемости. Заказчик и исполнитель вовремя говорят о проблемах и изменениях на проекте.
Кто клиент и какой проект
Клиент — производитель онлайн-касс «АТОЛ». Проект — бесплатный сервис быстрой регистрации касс. Мы были знакомы с клиентом: за год до этого интегрировали своё «кассовое» приложение с кассами «АТОЛ».
«АТОЛ» был первой кассой, с которой мы интегрировали наше приложение для курьеров и торговых представителей
Главная ценность сервиса — одно окно. Предприниматель покупает кассу у партнера «АТОЛа», партнер тут же её регистрирует. Предпринимателю нужно знать только ИНН и захватить флешку с электронной подписью. Не надо связываться с ФНС, забивать массу букв и цифр, рискуя ошибиться и потерять фискальный накопитель стоимостью 7 тысяч рублей.

В декабре 2017 года владелец продукта со стороны «АТОЛа» (product owner) представил список функций, которые должны быть в сервисе. На языке Scrum это называется бэклогом продукта. Потом мы вместе обсудили бизнес-цели и пришли к схеме решения. В схему вовлечена налоговая, операторы фискальных данных (ОФД) и сервис Dadata.ru, предоставляющий безошибочные данные предпринимателя для регистрации кассы.
Сервис быстрой регистрации (СБР) для партнеров «АТОЛа». ОФД — обязательное звено, по закону (54-ФЗ) все данные об операциях на кассе передаются через ОФД
Заказчик решил презентовать сервис с базовыми функциями 15 марта, на конференции партнеров «АТОЛа». К этому сроку нужно было сделать интеграцию с одним ОФД — Яндекс.ОФД. Первый спринт стартовал 10 января.
Запомнить: заказчик не обязан разбираться в тонкостях Scrum. Исполнитель помогает составить бэклог, уточняет критерии готовности продукта. Главное, что требуется от владельца продукта в начале — расставить задачи в порядке приоритета.
Спринты и хотелки
Спринт — это срок, за который команда разработчиков закрывает несколько «хотелок» на основе бэклога продукта. Например, две недели.

Хотелки формулирует владелец продукта: «Как пользователь этого сервиса, я хочу, чтобы адрес моего интернет-магазина при регистрации подтягивался автоматически». В Scrum эти хотелки называются user stories.

Команда оценивает их и формирует бэклог спринта — список задач, которые надо выполнить, чтобы удовлетворить хотелки. В спринт берём только задачи, которые точно знаем, как решить. Если не знаем, то в этом спринте ищем варианты решения, а в следующем — решаем.

Состав спринта
Владелец продукта подтверждает состав спринта и обязательно определяет его цель. Это упрощает понимание, всё ли сделали на спринте. Бывает, что не все задачи решены, но цель достигнута. И наоборот: все задачи решили, а цели не достигли. Критерии приемки спринта обсуждаются всей командой с владельцем продукта.
Владелец продукта утверждает состав спринта и формулирует его цель в Telegram
Все спринты одинаковы по времени. У нас спринты всегда длятся две недели, точнее — десять рабочих дней. Из-за государственных праздников спринт может начинаться в понедельник, а может в пятницу.

Первые два спринта пристрелочные. Надо понять, какой объем задач реально делать за две недели и планировать так, чтобы команда не сидела без работы и не ночевала в офисе.

Во время спринта владелец продукта не вносит новые хотелки и не меняет приоритеты. Если появились идеи, лучше подождать обсуждения следующего спринта.
Диаграмма сгорания задач (burndown chart). Серая линия — запланированные задачи, красная — выполненные. В идеале линии сходятся на оси X
Сколько спринтов будет на проекте, сразу сказать нельзя. Могут появиться новые задачи, которые сделают продукт лучше. Или придется от чего-то отказаться, потому что выяснится, что это неактуально. Наш проект длился 12 спринтов, 120 рабочих дней. После презентации 15 марта мы продолжили улучшать продукт — например, интегрировали сервис с другими ОФД.

Если цель спринта достигнута, он считается успешным. Бывает, заказчик говорит: «Давайте этот спринт признаем успешным, там совсем немного осталось доделать, тем более причина не в вас, а в чужом API». Такие предложения принимать нельзя, а владельцу продукта их лучше не озвучивать.

Результативность спринтов. Второй спринт у нас редко успешный — берём слишком много задач. Всего на проекте было три неуспешных спринта из двенадцати
Идея не в том, чтобы получать хорошие оценки, как в школе, а в том, чтобы каждые две недели выдавать работоспособную версию сервиса с новыми функциями. Не все запланированные функции работают? Окей, спринт неуспешный, и команда не получит пиццу. Не страшно, если 50% спринтов неуспешны. Страшно, когда мухлюют.
Запомнить: заказчику важно научиться формулировать user stories, поставив себя на место пользователя, и определять цель спринта.
Как оцениваются спринты
Оценка спринтов — самое сложное. В Scrum задачи рассчитываются не в часах, а в относительных единицах. Обычно их называют story points (для простоты — стори-поинты). Стори-поинты включают в себя риски, сложность и внешние факторы: потерю связи с сервером ФНС, проблемы с ОФД и так далее.

Некоторые команды вместо стори-поинтов используют разные размеры футболок (S, M, XL) или породы собак. Одна задача «весит» как такса, другая, посложнее, — доберман, третья — сенбернар. Это весело, когда делаешь внутренний продукт и сам себе заказчик. Когда заказчик внешний, его бухгалтерия вряд ли такое оценит.

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

Покер планирования. Участники команды «вскрылись» и не пришли к консенсусу — будут переигрывать
В каждом спринте у нас 35–40 стори-поинтов. Если задача «весом» 5 стори-поинтов не доделана, заказчик экономит сразу на 5 стори-поинтах — засчитывается только 100-процентная готовность.

Запомнить: в Scrum команда быстро реагирует на проблемы. Не надо ждать подтверждения на оплату дополнительных часов, чтобы её решить. Всё уже заложено в стори-поинтах.
Команда Scrum
В образцовом Scrum команда самодостаточна и универсальна. Все готовы друг друга подстраховать. Отпуск у фронтенда? Бэкенд с тестировщиком подменят. Девопс на больничный ушел? Не проблема, аналитик тоже так умеет. Коллеги «со стороны» привлекаются только в критических случаях. У нас такого на проекте не было.

На время проекта команде выделяется отдельная комната. Здесь все равны и каждый отвечает за продукт, а не только за свою часть работы. Учитывайте это, не спрашивайте: «Кто у вас главный?»

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

Скрам-мастер — это вроде модератора, только круче. Он следит за выполнением правил Scrum, обеспечивает команду маркерами и пиццей, фиксирует, что команда наговорила на собраниях и разруливает сложные ситуации
Правда, что в Scrum много болтовни?
Да. Грубо говоря, один из десяти спринтов один уходит на общение, девять — на разработку.
«Сначала было ощущение, что слишком много времени тратится на всякие собрания. Можно же потратить его на разработку продукта».
Илья, участник проекта, первый раз работает по правилам Scrum
Новички в Scrum удивляются: как можно 4–5 часов тратить на разбор двухнедельного спринта. На самом деле такое собрание в конце каждого спринта (ретроспектива) очень важно. Ретроспектива помогает команде стать командой, здесь открыто говорят, что чья-то Metallica в наушниках мешала работать и что кому-то пора перестать опаздывать. Если спринт признан неуспешным, это главная тема собрания: команда разбирается в причинах и делает выводы, чтобы улучшать результат от спринта к спринту.

Желательно, чтобы на первых двух ретроспективах был владелец продукта (у нас обычно в Zoom). Это помогает построить доверительные отношения и лучше понять, как работает именно эта команда.

Скрам-мастер записал всё, что обсудили на ретроспективе. Чтобы ретроспективы были бодрее и продуктивнее, мы используем метод шести шляп. Пицца на столе означает, что спринт был успешный
Кроме ретроспективы есть ежедневные 15-минутные встречи (Scrum Daily, они же дейли, они же митинги). Каждый говорит, что сделал вчера, что сделает сегодня и какие есть сложности. «У меня не получается с передачей данных ФНС. Максим, помогай». — «Хорошо, в 16:00 займусь». Здесь участие владельца продукта не требуется.

На пятый день спринта — груминг. Вместе с владельцем продукта обсуждаем текущий спринт и определяем приоритетные задачи на следующий.

Кроме ретроспективы есть ежедневные 15-минутные встречи (Scrum Daily, они же дейли, они же митинги). Каждый говорит, что сделал вчера, что сделает сегодня и какие есть сложности. «У меня не получается с передачей данных ФНС. Максим, помогай». — «Хорошо, в 16:00 займусь». Здесь участие владельца продукта не требуется.

На пятый день спринта — груминг. Вместе с владельцем продукта обсуждаем текущий спринт и определяем приоритетные задачи на следующий.

Запомнить: владелец продукта всегда на связи с командой. Нужно иметь замену на случай отпуска или увольнения. Иногда владелец продукта — не штатный сотрудник компании-заказчика.
Почему мы недовольны результатом
Вот что написал клиент в ответ на просьбу оценить наш общий скрам-опыт:

«Scrum дал нам продукт ожидаемого качества в ожидаемые сроки. На текущий момент продукт готов к использованию»

Мы недовольны, потому что сервиса нет на рынке. Формально он готов, но доступа у клиентов «АТОЛа» к нему нет.

Пока мы ускоренно разрабатывали продукт, а потом улучшали —продвижение буксовало. Надо было уже в январе рассказывать о сервисе, получать обратную связь от рынка. К маю большинство партнеров должны были уметь пользоваться сервисом и предлагать его клиентам. Так бы не пропустили ажиотаж — предприниматели спешили зарегистрировать кассы к 1 июля, чтобы не иметь проблем с ФНС. Момент упущен, десятки тысяч предпринимателей не получили дополнительную ценность.

Главный вывод для заказчиков: работайте по Scrum, это быстрее «классики» с техзаданиями, честнее и часто дешевле. Выпускайте продукт на рынок через пару месяцев, не ждите идеальную версию.

Главный вывод для разработчиков: не забывайте напоминать клиенту о продвижении продукта и сборе отзывов уже через месяц-два. Иначе какой толк в Scrum, если продуктом даже через год никто не пользуется.