Хабрахабр

Семь проблем внедрения Scrum, о которых мы не знали

Привет, Хабр! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю product owner’ом. Почти год разработка нового интернет-банка «Мой бизнес» у нас идет по фреймворку Scrum, и в связи с этим я уже успел набить шишек. В этом посте я хотел бы рассказать о самых болезненных из них, а также о том, какие средства нам в итоге помогли. Чтобы вы смогли избежать подобных неприятностей.

Некоторые сотрудники принципиально против изменений

Фреймворк Scrum был принят в нашем банке, чтобы ускорить развитие и уменьшить TTM. Когда началось внедрение, выяснилось, что некоторые сотрудники оказались к этому не готовы. Они не понимали, зачем это надо и что это даст.

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

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

Разработчикам, о которых мы говорили выше, было немногим больше 30 лет. Негативная реакция на изменения не зависит от возраста. При этом у нас в команде отлично работает человек, которому уже за 50, — никаких проблем со Scrum у него не возникло.

Сложно взаимодействовать с теми, кто живет не по Scrum

В любой организации приходится сотрудничать с людьми, которые просто не работают по Scrum. В нашем случае это команды с других проектов и отделов. У них обычно гораздо более длинные этапы реализации проектов. Честно говоря, у нас по Scrum пока что работают только разработчики ДБО.

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

Мы приглашаем безопасников на наши встречи и демо, и теперь согласование полностью готового релиза занимает всего один день. Хоть мы и не поторапливаем другие подразделения, в сотрудничестве с нами они начинают работать быстрее. До этого уходило от недели до двух.

«Мы ничего не успеем за спринт!»

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

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

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

«Зачем нужны ежедневные стендапы?»

Поначалу коллеги скептически относились к тому, чтобы каждый день отвлекаться от привычной работы на стендап-встречи. Даже если они проводятся онлайн и требуют всего 10 минут.

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

Здесь достаточно посчитать, так ли это на самом деле. Многие думают, что скрам-встречи занимают очень много времени. Это не так много для того, чтобы организовать работу и оставаться в курсе всех дел. У нас получилось два часа в неделю из 40.

Как и если встреча затягивается больше чем на 15-20 минут. Если на стендап-встречи не хочет идти вся команда, да и сами встречи получаются не слишком активными, это сигнал к тому, что работа идет не так. Рассказ о своих занятиях и планах у человека не должен занимать больше одной-двух минут.

Если обсуждение задачи занимает больше 30 минут, мы его прекращаем. С тайм-менеджментом у нас связано еще одно правило. На это стоит обратить внимание. Это значит, что мы не успели разработать задачу, что она плохо декомпозирована и требует еще времени. Ограничение в 30 минут мы установили для себя — в каждой компании нужно устанавливать собственный барьер.

Непонятный бэклог

Успешность Scrum зависит, в первую очередь, от четкого планирования. Нужно определить, какое количество задач должно быть оценено и описано, а какое пока можно просто отложить. Не стоит пытаться охватить сразу все. Разработчику нужно понимать, что он будет делать в ближайшие два спринта. На более отдаленные сроки достаточно примерного представления — чем позднее, тем меньше деталей.

Неуместный микроменеджмент

Что разработчики делают сегодня? А что будут завтра? Бывает, руководители задают такие вопросы регулярно. Мы смогли объяснить своему руководству, что все интересующие моменты можно узнать на нашей скрам-доске или придя на ежедневный стендап. Никаких специальных отчетов с таблицами и мониторинга по задачам в Jira. Нам удалось сжать этот микроменеджмент до еженедельных встреч с руководством, где я отчитываюсь по конкретным выполненным задачам команды.

То, о чем почти не пишут

Напоследок — явная проблема, упоминания которой я почти нигде не нашел. Не нужно пытаться объединить скрам-мастера и product owner’а. Последний строит бизнес-подразделение, прорабатывает бэклог, выполняет KPI. Он заинтересован в успехе продукта и старается вникнуть во все — поэтому начинает назначать встречи, обсуждать какие-то детали. В общем, нагружает себя кучей функций, из-за которых на бэклог просто не остается времени.

Я организовывал встречи, стендапы, решал проблемы членов команд. Такое случалось и со мной. Сейчас мы нашли руководителя разработки, который имеет авторитет у команды и стал также выполнять функции скрам-мастера, поскольку имеет больший опыт работы по этому фреймворку. Из-за этого бэклог оставался не проработан, то есть на основную деятельность просто не было времени. Без хороших требований не будет хорошего продукта. Теперь я смог отойти от Scrum и полноценно сконцентрироваться на задачах product owner’а, который, в свою очередь, должен думать над требованиями. В результате бэклог стал улучшаться, к коллегам пришло понимание, как мы будем двигаться дальше.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть