В стендап-митингах приходится участвовать каждый день. Зачастую их проводят утром, например, через час после начала рабочего дня. Стендапы — это важная составляющая процесса разработки, в частности, позволяющая распространяться знаниям о проекте в команде. Поэтому очень важно сохранять этот процесс эффективным и не допускать превращения его в нудные «бубнилки». Мы определили три простых правила, которые нам помогают в этом.
Многие разработчики упускают этот момент. Когда наступает время стендапа и очередь доходит до них, они начинают на ходу вспоминать о том, что было сделано вчера, какие при этом возникли проблемы и что они планируют сделать сегодня. Проблема в том, что зачастую это происходит следующим образом: «Так-так... что же там вчера было-то?.. А, точно! Вот это вот сделал и что-то еще там поправил...»
В этот момент остальным членам команды приходится ждать пока кто-то что-то вспомнит, при этом что-то забудет и т.д. Проблемы, которые отсюда вытекают:
Такие стендапы никому не нужны. Готовьтесь к стендапам. За пять минут до начала:
Подготовившись к стендапу и четко изложив все, о чем вам нужно сказать, другие ваши коллеги-разработчики захотят быть такими же эффективными. Проверено. Стендапы преобразятся.
Заказчик на стендапе хочет слышать в основном только то, что непосредственно связано с его продуктом в контексте бизнеса, т.е. что появилось нового, что исправлено и т.п. Это вещи, которые несут реальную ценность для него или пользователей. Поэтому здесь не должно быть места для подробного технического описания.
К примеру, вместо того, чтобы сказать «Я написал новую миграцию для схемы базы данных и переписал код таким образом, чтобы поддерживать связь один-ко-многим вместо один-к-одному. Таким образом, пользователи теперь могут добавлять несколько приложений к договору, а не одно», следует просто сообщить, что у пользователей теперь есть возможность добавлять несколько приложений к договорам.
Такой подход сокращает общее время стендапа, а также не дает скучать тем, кому технические подробности в данном случае не очень интересны. Однако, если кто-то выразил интерес в том, чтобы узнать технические детали решения, стоит о них рассказать. Кроме того, технические детали стоит раскрывать еще и тогда, когда решение было совсем не тривиальным.
Для коллег-разработчиков подробно рассказывать о технических деталях решения определенной задачи имеет смысл опять же тогда, когда это им интересно, либо когда решение или сама задача были нетривиальными.
Если взять пример с договорами, упомянутый выше, то, скорее всего, все разработчики и без уточнений поняли, как эта задача была решена. На всякий случай, можно просто напрямую спросить, интересно ли им услышать о решении.
Конечно, эти правила — не панацея. Более того, они могут меняться, но на мой взгляд в них есть самое главное — здравый смысл. Подстраивайтесь под ваши условия, но не превращайте стендап-митинги в нудные «бубнилки».
1. К стендапам нужно готовиться
Многие разработчики упускают этот момент. Когда наступает время стендапа и очередь доходит до них, они начинают на ходу вспоминать о том, что было сделано вчера, какие при этом возникли проблемы и что они планируют сделать сегодня. Проблема в том, что зачастую это происходит следующим образом: «Так-так... что же там вчера было-то?.. А, точно! Вот это вот сделал и что-то еще там поправил...»
В этот момент остальным членам команды приходится ждать пока кто-то что-то вспомнит, при этом что-то забудет и т.д. Проблемы, которые отсюда вытекают:
- некоторые важные детали могут быть не упомянуты на стендапе;
- время стендапа затягивается;
- стендап превращается в нудное перечисление междометий и почесывание затылков.
Такие стендапы никому не нужны. Готовьтесь к стендапам. За пять минут до начала:
- откройте Agile-доску — посмотрите на выполненные и оставшиеся задачи;
- откройте репозиторий — посмотрите на коммиты, там сразу могут «всплыть» проблемы, которыми пришлось столкнуться и о которых стоит упомянуть.
Подготовившись к стендапу и четко изложив все, о чем вам нужно сказать, другие ваши коллеги-разработчики захотят быть такими же эффективными. Проверено. Стендапы преобразятся.
2. Для заказчика — про бизнес
Заказчик на стендапе хочет слышать в основном только то, что непосредственно связано с его продуктом в контексте бизнеса, т.е. что появилось нового, что исправлено и т.п. Это вещи, которые несут реальную ценность для него или пользователей. Поэтому здесь не должно быть места для подробного технического описания.
К примеру, вместо того, чтобы сказать «Я написал новую миграцию для схемы базы данных и переписал код таким образом, чтобы поддерживать связь один-ко-многим вместо один-к-одному. Таким образом, пользователи теперь могут добавлять несколько приложений к договору, а не одно», следует просто сообщить, что у пользователей теперь есть возможность добавлять несколько приложений к договорам.
Такой подход сокращает общее время стендапа, а также не дает скучать тем, кому технические подробности в данном случае не очень интересны. Однако, если кто-то выразил интерес в том, чтобы узнать технические детали решения, стоит о них рассказать. Кроме того, технические детали стоит раскрывать еще и тогда, когда решение было совсем не тривиальным.
3. Для коллег — подробно, если им это интересно
Для коллег-разработчиков подробно рассказывать о технических деталях решения определенной задачи имеет смысл опять же тогда, когда это им интересно, либо когда решение или сама задача были нетривиальными.
Если взять пример с договорами, упомянутый выше, то, скорее всего, все разработчики и без уточнений поняли, как эта задача была решена. На всякий случай, можно просто напрямую спросить, интересно ли им услышать о решении.
Заключение
Конечно, эти правила — не панацея. Более того, они могут меняться, но на мой взгляд в них есть самое главное — здравый смысл. Подстраивайтесь под ваши условия, но не превращайте стендап-митинги в нудные «бубнилки».
Комментариев нет:
Отправить комментарий