Плохо когда утренние stand-up встречи становятся встречами для менеджера, на которых он опрашивает каждого кто что сделал и будет делать. Мне кажется для этого есть более асинхронные форматы. Ведь предполагается, бОльшую часть времени разработчики будут между собой обсуждать текущие вопросы. Но, на мой взгляд, разработчикам гораздо удобнее в более мелких группах общаться, как правило, созвониться с кем-то конкретным и решить вопросы или получить консультацию.
@mudasobwa координация действий команды идёт на протяжении всего дня, соответственно, как и обсуждение/корректировка планов действий. Все эти вопросы о том кто застрял, у кого зашло изменение и т.д. решаются в любое время дня: в живую, сообщениями в чатах/каналах, созвонами (когда что-то особенное). Довольно часто замечаю что на стендапе дублируются сообщение какой-то информации, которую уже обсудили и те кому надо в контексте вопроса, а те кому это вообще неважно - слушают, но при этом, я уверен, без какой-либо пользы.
@noxdev ужас какой; я в курсе, что происходит в пяти командах, но если бы мне эту информацию приходилось получать порциями в течение дня хотя бы для одной из них — пришлось бы застрелиться из чатжепете.
На протяжении всего дня надо думать, а от этого неимоверно отвлекают всякие Маши и Пети со своими изменениями.
@mudasobwa "я в курсе, что происходит в пяти командах, но если бы мне эту информацию приходилось получать". Тут вопрос: "я" - это менеджер или разработчик? Если менеджер, то получается стендап как раз в первую очередь для него и это не очень коррелирует с тем что ранее было сказано, он вообще не нужен на стендапе. Но в целом это неплохой способ для него засинхронизироваться. Если разработчик - тут вопрос интереснее. Возможно у меня какой-то специфичный опыт, хотя я работал, ну навскидку в 6-7 разных командах и я не припомню такой ситуации что среднему разработчику нужно было быть в курсе того, что происходит в пяти командах. Многих особо не интересовало что происходит в одной-то.
Всё-таки я пока склоняюсь к тому, что стендапы это больше для менеджеров активность нежели для разрабов. Как правило, разработчик работает над 1-2 задачами и вся синхронизация у него идет on demand. Адекватный разработчик не будет ждать утро следующего дня, чтобы получить статус по задаче, которая блочит его. Как сказал один коллега: Пффф, нафиг мне все это нужно, я возьму да сам посмотрю другой Pull Request, а если что-то непонятно будет спрошу автора в асинхронном режиме. Зачем мне какая-то встреча.
Я разработчик. Principal engineer, но кода пишу уж точно не меньше коллег.
Статус по задаче, которая его блокирует, даже средний разработчик получить — может. А быть в курсе того, что не блочит — нет.
Дефрагментация знаний внутри команды — штука очень полезная: bus factor нивелирует, карму прихорашивает, ауру чистит, и все такое.
На галерах, наверное, где всем все пофиг — стендапы не нужны. Если команда — это команда, то десять минут в день на политинформацию — несомненное благо.
@mudasobwa Я понял твое мнение и оно точно имеет смысл и в целом-то я придерживаюсь такой же позиции, но хочу высказать пару нюансов, которые я заметил, работая в разных командах, с разработчиками разного уровня:
1) "А быть в курсе того, что не блочит — нет." - разработчикам не очень интересно погружаться, в данный момент (!), в какие-то другие области продукта, которые вне их задач. Даже при условии того, что через 3 недели ему нужно будет писать код, делать большие изменения в данной области. Очень многих тупо не хочется выгружать из контекста свою задачу и переключаться и понимать чью-то другую. Я такое постоянно вижу. И через пресловутые 3 недели разработчики задают ровно те вопросы, которые уже много много раз обсуждались на встречах, но им не хотелось особо вникать
2) "Дефрагментация знаний внутри команды" - я все-таки пришел к выводу, что опять же большинству разработчиков интересно погружаться, в новые для себя области, увеличивая тем самым bus factor, при работе с кодом, при внесении реальных изменений, при добавлении новых фичей, исправлении ошибок. Просто так, среднестатическому разработчику, слушать рассказы другого разработчика про то, что он там сделал - тупо тяжело и опять же неинтересно. Хочется самому потрогать код. Могу предположить, что скорее всего не так, в случае, когда у тебя команда состоит из людей, каждый из которых достаточно сильно потрогал почти каждый компонент продукта, чувствуется реальное владение кодом, и для него рассказ об изменениях в какого-то области продукта не выглядит чем-то непонятным. Он слушает и понимает о чем вообще говорит другой разработчик на встрече, ему не нужно напрягаться и пытаться вникнуть о чем вообще речь. К сожалению, так сложилось, что я пока не работал в таких командах - поэтому, как написать чуть выше, это предположение.
я всегда зову случайных людей из разных команд на брейнстормы, от джунов до синьёров, чтобы все были хотя бы в курсе всех проектов хотя бы поверхностно.
То же самое с кодревью. Всегда отдаю двоим, джуну/мидлу в теме, мидлу/синьёру — не в теме, вот и покрытие знаниями увеличилось.
Если на встрече нужно «напрягаться и пытаться вникнуть о чем вообще речь» — в команде фундаметальные проблемы.
@noxdev стендапы нужны для того, чтобы быстро скоординировать действия команды (сегодня Маша закончит задачу, Петя и Вера — приготовиться вмерджить, а Вася застрял, поэтому Кира сегодня погружается в его задачу и помогает). Иначе никто не в курсе, что вообще происходит в макромире.
Менеджер на стендапах не нужен.