Руководство профессионального скрам-мастера: Практические советы по внедрению аджайл-подходов
Скрам-модель подразумевает выявление препятствий на пути к результатам. Законы скрама защищают команду от хаоса – так, чтобы к концу спринта она смогла выполнить свои обязательства перед клиентом.
Цикл жизни проекта, как правило, краток, а препятствия, которые необходимо выявлять, возникают постоянно, поэтому список проблем, требующих вмешательства скрам-мастера, может быть бесконечным. В ходе работы команда ежедневно, ежечасно сталкивается с самыми разными препятствиями и отвлекающими моментами. Владелец продукта и стейкхолдеры, подводя итоги спринта, внимательно исследуют продукт. Это часто приводит к изменениям в бэклоге продукта и, таким образом, в самом продукте. Ретроспектива спринта дает команде возможность сосредоточиться на совершенствовании процесса, чтобы в дальнейшем он протекал более гладко. Следует отметить, что скрам-модель содержит три встроенных механизма для выявления проблем. Как говорят в Техасе, если вы ищете приключений на свой зад, то обязательно их найдете. А скрам может выявить немало проблем.
Так что же нам, скрам-мастерам, делать со всеми этими трудностями? Нужно спросить себя: «Трудность, с которой мы столкнулись, настоящая проблема нашей организации или просто досадный сбой?» Рассмотрим пример настоящей проблемы – документ, который необходимо представить для утверждения в Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA). Скажем, в ходе ретроспективы команда указала, что эта проблема приводит к непроизводительным потерям, – но ведь ни один продукт не попадет на американский рынок без разрешения от FDA. Так что это и есть настоящая проблема, с которой придется тщательно работать.
Или, например, давайте представим себе, что на ретроспективе спринта сотрудник жалуется, что его часто отрывали от командной работы, заставляя переключаться на другой проект с другим менеджером. Это серьезная проблема? Вполне возможно. Но, возможно, и просто сбой. Почему? Скрам гласит: члены команды должны быть преданы общему делу и сосредоточены на выполнении обязательств перед командой. Когда разработчик вынужден отвлечься на другой проект, у него голова идет кругом от перегрузок, поскольку объем работы увеличивается. Вполне вероятно, что он не выполнит свои обязательства ни перед командой, ни по другому проекту. Пока элементы функциональности не готовы, невозможно провести их инспекцию и адаптацию, что сводит на нет все плюсы эмпирического контроля. Словом, это неприемлемый вариант, членов команды нельзя отрывать от текущей работы. В таких случаях скрам-мастер должен предупредить владельца продукта, что выполнение разработчиком своих обязательств находится под угрозой. Возможно, о проблеме придется довести до сведения руководства, чтобы такие просьбы больше не повторялись, – да и сами члены команды должны научиться отказывать. Впрочем, маловероятно, что описанная ситуация возникнет в самом начале работы.
Готова ли ваша команда