Постигая Agile

• следить, чтобы в команде не появился «мальчик для битья», на которого валятся все шишки[45];

• прислушиваться к мнению коллег, а не навязывать свое представление о том, как надо работать;

• действительно брать на себя ответственность. Все ли в команде готовы к этому.

Чтобы понять, готовы ли вы к уважению, спросите команду (себя в том числе) и руководителя, согласны ли они:

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

• давать команде достаточно времени на выполнение задач и не требовать от нее сверхурочных работ;

• доверять команде выбирать задачи, которые ей подходят и нужны для проекта, а не полагаться на строгое распределение ролей, матрицы RACI и т. д.;

• никогда не говорить, будто вы понятия не имеете, почему команда приняла то или иное решение.

Чтобы понять, готовы ли вы к сосредоточенности, спросите команду (себя в том числе) и руководителя, согласны ли они:

• не просить никого в команде сделать работу, которая не входит в текущий спринт;

• не просить никого из членов команды выполнить работу, которая не была включена в ее планы, только потому, что «мне нужно, чтобы это срочно было сделано»;

• ставить наиболее важные интересы компании выше всех прочих проектов и работ;

• не требовать, чтобы члены команды работали над конкретными задачами в наперед заданном порядке.

Чтобы понять, готовы ли вы к открытости, спросите команду (себя в том числе) и руководителя, согласны ли они:

• действительно прислушиваться к мнению других и размышлять над ним;

• думать о планировании проекта и пользователях, если раньше этого не делали;

• задумываться о технических деталях;

• интересоваться, над чем работает сидящий рядом программист и служит ли это общей цели;

• что программист, сидящий рядом с вами, должен действовать аналогичным образом.

Чтобы понять, готовы ли вы к мужеству, спросите команду (себя в том числе) и руководителя, согласны ли они:

• никогда не обвинять менеджера проекта в отсутствии планирования;

• никогда не сетовать на «эти дурацкие требования», не попавшие в оценку, сделанную владельцем продукта или старшими менеджерами;

• тратить время на то, чтобы действительно понять пользователей;

• не добиваться совершенства там, где клиенту нужен просто добротный продукт.

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

Часто задаваемые вопросы

Не являются ли бэклог и доски задач простой разновидностью графика проекта? Не делают ли scrum-команды то же самое, что и моя команда?

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

Одно из основных различий между эффективной scrum-командой и традиционными проектными командами заключается в том, что план scrum-команды не отправляется на полку сразу после составления, чтобы быть извлеченным оттуда только в случае срыва сроков. Они проверяют его выполнение на ежедневном scrum-митинге, чтобы сразу выявить возникающие проблемы. Более того, многие эффективные scrum-команды резервируют не менее часа в неделю для работы с владельцем продукта над обновлением бэклога (некоторые называют это «причесывание»). Владельцы продукта все время открывают для себя новые возможности. Во время еженедельных встреч по бэклогу команда вместе с владельцем продукта обсуждает создание новых карточек пользовательских историй с критериями удовлетворенности. Они присваивают очки новым пользовательским историям, а затем вместе с владельцем продукта расставляют приоритеты новых историй в бэклоге продукта, отталкиваясь от того, насколько они важны и как долго их делать.

Это дает команде два очень мощных инструмента. Один из них – это получение обширного опыта по оценке трудоемкости, так что, когда приходится вносить изменения, она точно знает, как спрогнозировать их влияние.