Мои контакты


вторник, 22 декабря 2015 г.

Три правила эффективного Standup Meeting

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

1. К стендапам нужно готовиться


Многие разработчики упускают этот момент. Когда наступает время стендапа и очередь доходит до них, они начинают на ходу вспоминать о том, что было сделано вчера, какие при этом возникли проблемы и что они планируют сделать сегодня. Проблема в том, что зачастую это происходит следующим образом: «Так-так... что же там вчера было-то?.. А, точно! Вот это вот сделал и что-то еще там поправил...»

В этот момент остальным членам команды приходится ждать пока кто-то что-то вспомнит, при этом что-то забудет и т.д. Проблемы, которые отсюда вытекают:
  • некоторые важные детали могут быть не упомянуты на стендапе;
  • время стендапа затягивается;
  • стендап превращается в нудное перечисление междометий и почесывание затылков.

Такие стендапы никому не нужны. Готовьтесь к стендапам. За пять минут до начала:
  • откройте Agile-доску — посмотрите на выполненные и оставшиеся задачи;
  • откройте репозиторий — посмотрите на коммиты, там сразу могут «всплыть» проблемы, которыми пришлось столкнуться и о которых стоит упомянуть. 

Подготовившись к стендапу и четко изложив все, о чем вам нужно сказать, другие ваши коллеги-разработчики захотят быть такими же эффективными. Проверено. Стендапы преобразятся.

2. Для заказчика — про бизнес


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

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

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

3. Для коллег — подробно, если им это интересно


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

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

Заключение


Конечно, эти правила — не панацея. Более того, они могут меняться, но на мой взгляд в них есть самое главное — здравый смысл. Подстраивайтесь под ваши условия, но не превращайте стендап-митинги в нудные «бубнилки».