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

Можно искать причины в свойствах нашего мозга, психологии и проблемах командной работы. И все-таки хочется поделиться несколькими простыми и проверенными на практике решениями.

В нулевых Во-первых, начните записывать то, о чем вы договорились. И обязательно сделайте так, чтобы все увидели и/или получили записи и помнили о договоренностях. Можно, конечно,  говорить «я забыл», если получив письмо с результатами ретроспективы, вы тут же отправили его в корзину. Хотя, если говорить о действительно командной работе, то наглядность и память о совместных обещаниях какой никакой, а все-таки мотиватор.

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

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

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

В-четвертых, назначьте того, кто будет следить за исполнением правила. Да-да, некоего “полисмена”, который будет следить за выполнением полиси – ваших правил и договоренностей. Это может быть кто-то из команды или Скрам Мастер (Scrum Master). Помните, что он будет делать это для того, чтобы вы стали лучше и поэтому с уважением относитесь к его замечаниям. И не считайте, что это только его забота – вы можете помочь и тоже спросить коллегу: «а ты не забыл обновить документацию?». Хорошая новость, что со временем это становится общей заботой, и надобность в полицейском отпадает :-).

В-пятых, следуйте правилу достаточно долго. Одна из проблем молодых (и горячих) команд, в том, что они кидаются менять правила уже через несколько дней после их введения. Необходимо выполнять практику не меньше месяца, прежде чем она станет вашей привычкой и все станет просто тем, как вы делаете свою работу. UPD: Вот отдельно на тему “силы привычки“.

В тоже время, имейте мужество прекратить делать то, что вам мешает. Обязательность ретроспективы в Scrum – это как раз тот момент, когда мы можем остановиться и подумать: «Что для нас не работает?», «Что мы можем попробовать делать?» и «Что мы должны продолжить делать?».

Все эти идеи просты и опробованы на множестве команд. Попробуйте и увидите результаты. А если вы уже так и делаете – напишите свои впечатления в комментариях 🙂