В этом посте мы разберёмся, какие распространённые ошибки в применении Scrum, приводят к провалу. И в этот раз мы посмотрим на проблему с точки зрения команды разработчиков.
Большинство симптомов исходят из неправильной трактовки ролей и их обязанностей. В Scrum выделяется только три роли:
- scrum-мастер,
- владелец продукта,
- команда разработки.
Что понимается под dev-командой в Scrum
Профессиональная команда разработки в Scrum — это группа профессионалов, которая предана своему делу и может создавать инкремент продукта для достижения цели спринта. Каждую итерацию команда превращает элементы бэклога в работающий и ценный продукт. Команда каждый раз отвечает на несколько вопросов:
- Каково техническое здоровье инкремента? Действительно ли он работает? Интегрируется ли с предыдущим инкрементом?
- Действительно ли выполненная работа имеет ценность для конечного пользователя? Как инкремент удовлетворяет потребность клиента?
Команда разрабатывает определение «Готово», благодаря которому каждому участнику понятно, что нужно получить в итоге. Dev-команда несёт ответственность за инкремент, и, как следствие, ответственность за качество продукта.
Команда разработки не предполагает подгрупп. Это кросс-функциональная команда — она обладает всеми навыками, необходимыми для доставки задач каждый спринт. Также в теории Scrum указано, что команда самоорганизующаяся. Никто не говорит команде разработчиков, как делать работу, чтобы получить инкремент. Это подразумевает и то, что команда решает собственные проблемы, как технические, так и межличностные.
Предполагается, что команда разработчиков тесно сотрудничает с конечными пользователями, чтобы лучше понять их потребности и ожидания. Вместе с владельцем продукта разработчики постоянно уточняют бэклог и помогают расставить приоритеты. Команда ожидает, что в спринт попадут только те задачи, которые соответствуют DoR. Они достаточно декомпозированы и чётко сформулированы, так что их можно превратить в готовый функционал за спринт.
Что может пойти не так?
Организация может иметь иные ожидания от команды разработки. Например:
- воспринимать команду только как рабочие руки без творческих сил, поэтому команда получает готовый список задач и технических заданий, которые нужно сделать,
- оценивать команду по скорости выполнения задач и настаивать, что для ускорения процесса разработчикам нужно больше работать (=перерабатывать),
- владелец продукта настаивает на снижении качества для увеличения скорости поставки,
- команда должна брать в спринт все экстренные запросы, которые появляются в течение итерации, и не имеет права отказать,
- в команде не хватает компетенций, ей приходится обращаться в другие отделы и зависеть от их загруженности,
- руководство считает, что нельзя давать право на самоорганизацию, так как это приведет к анархии. Scrum-мастер и владелец продукта выполняют роль контроллёров,
- разработчики не должны общаться с заинтересованными сторонами, так как у них не хватит времени на разработку,
- если к работе команды привлекать клиентов, они не поймут нас и обесценят компанию.
Если какие-либо из этих пунктов являются неустранимым препятствием, то организации может не подходить стиль, который предлагает Scrum. Это нормально, и можно найти другие методы разработки. Или же, может, попробовать изменить свой настрой, чтобы действительно попробовать Scrum?
У команды также может сложиться неверное представление о том, что ожидают от её участников. Каждый отдельный разработчик может по-разному понимать свою роль. Например:
- разработчик должен сосредоточиться только на своих задачах,
- для него самое главное — личная продуктивность,
- он считает, что совместная работа снизит продуктивность, так как два и более человек работают над одной задачей, вместо двух,
- если он не может завершить свою работу из-за внешних зависимостей, его это не касается,
- если у него проблемы с другими людьми, за него об этом позаботится scrum-мастер,
- решение всех проблем падает только на scrum-мастера,
- в случае непредвиденных обстоятельств нужно ждать владельца продукта для принятия решения, а команда не знает продукт,
- достижение цели спринта — ничего не значит, если мы не доделали что-то, закончим в следующем спринте,
- если в бэклог спринта попадает больше работы, команда готова жертвовать качеством,
- он готов рассказать о своей задаче только к концу спринта и т. д.
С таким видением команде трудно стать самоорганизующейся и нести ценность самостоятельно. Scrum-мастер должен отработать с командой ожидания от роли разработчика и составить конкретные договорённости. Если вся команда принципиально не готова работать таким образом, то запустить Scrum без “НО” не получится.
Что можно сделать?
Для начала проведите срез по тому, как команда понимает свою роль и как менеджеры определяют границы самоорганизации. Спросите каждого, готов ли он идти к целевой модели и отказаться от конвейерной разработки. Исходя из этого можно выстроить план развития команды и строить эффективные процессы.
