Привет! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю 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 кажется очень простым, но все-таки имеет много подводных камней. Мы работаем по этому фреймворку почти год, но только сейчас мы начали более-менее четко оценивать свои способности, начали наращивать скорость развития.
Автор: maksitron
