Комментарии 24
В рамках стендапа нужно обсудить 3 вещи:
Что я делал вчера?
Что я буду делать сегодня?
Зачем?
Ну как… чтобы знать, что сотрудник писал код вчера и пишет код сегодня) Всё же очевидно)
А если серьёзно, то в жизни существуют команды, которые работают над задачей/продуктом, качество которого на втором плане. Зачастую, сотрудники в таких командах с низким уровнем отвественности и профессионализма, большой текучкой и прочее. Такие даже хотят, чтобы их периодами подпинывали. В таких случаях формат ежедневных отчётов может сработать, что бы продукт хоть как-то двигался.
Хороший вопрос. Бузесловно им стоит задаваться, прежде чем притащить какую-то практику в команду.
В моей практике в нескольких компаниях это помогало решать конкретные проблемы. Где-то менеджеру требовалось более детальное понимание того, как движется проект с долгосрочными задачами, чем статические положение карточек в жире, меняющееся раз в 3 дня. Где-то это помогало тимлиду вовремя детектить джунов, которым надо помочь с задачами. Где-то помогало участникам команды с взаимозависимыми задачами понять, как планировать свой день, и ждать ли от коллеги сегодня передачи работы.
Я понимаю, что в последний месяц в твиттере горит спор за и против стендапов.
Лично я из того лагеря, который за. Но с оговоркой того это внедряется не просто "потому что", а решает конкретные проблемы.
Уверен, что есть люди, которые аргументированно против. И если у них в команде без стендапов всё хорошо - так и замечательно. А если они поделятся тем как у них это работает, то и всем польза будет.
Погодите, я не против стендапов. Не случайно я процитировал только два вопроса из трёх :) Я против бессмысленных стендапов, и поочередный рассказ, кто что делал и кто что собирается делать — это яркий пример бессмыслицы. Мне ближе формат канбан-дейли, когда разговор идёт вокруг задач с оперативным обсуждением текущих проблем.
В моей практике были случаи, когда скрам-дейли заменялся на канбан-дейли без каких-либо потерь в информативности, но с кратным выигрышем по времени. Например, в одной крупной команде (10 разработчиков) ежедневный стендап занимал до часа. После перехода на канбан-дейли время стендапов сократилось до 15 минут (а после разделения на подкоманды — до пяти, но это уже другая история)
Не знал как работают канбан-дейли. Прочитал, звучит интересно, спасибо за идею. В моем варианте да, скрам-дейли.
Вы привели интересные примеры, которые я наблюдал в очных стендапах, и прекрасно понимаю отчего у людей так горит. Когда команда 10+ человек по очереди "отчитывается" и возможно мусолит то, где явно не нужны все 10+ человек. И всё это на час мучения каждый день.
Мы у себя побороли это именно письменным форматом, где каждый за 2 минуты напишет а за 3 прочитает. И если вдруг что-то с кем-то надо согласовать - в нужном месте с нужными людьми и согласует.
Сейчас мне сложно сходу ответить про то, мог бы я это использовать в своей команде, и был бы от этого профит. Но определённо я это обдумаю.
Ещё раз благодарю за идею, и рад за ваш обдуманный подход к внедрению и совершенствованию процессов
всё в совокупности — чтобы понимать соответствие скорости прогресса ожиданиям, а также того, стоит ждать, пока исполнитель сам решит нежданную проблему, или стоит позвать кого-то в усиление.
Ну, это если все стороны адекватны, разумеется.
Ну я не случайно именно эту часть не стал цитировать :)
Потому что в разные ситуациях лучше работают разные подходы — в каких-то нет нужны в ежедневных митах, в каких-то наоборот, они — обязательно нужны, в каких-то — лучше работает другой формат.
Более того, оно даже на разных этапах одного проекта может меняться, но тут уже сложнее людей к изменениям форматов митов приучать, особенно если это временная команда…
Если говорить о скраме (о более-менее правильном), то там не каждый отдельно работает над своими задачами, а вся команда стремиться закрыть спринт, разделение на "свои" задачи и "чужие" отсутствует. В такой ситуации стендапы нужны для координации внутри команды, лишние люди могут присутствовать, но только ушами.
Если говорить про удалёнку, то я, например, использую это ещё и для того, чтобы показать, что я не дурака валял весь день, и вспомнить, чем я вообще занимался вчера/перед выходными.
Я уже понял, что мой комментарий был очень неконкретный. У меня нет вопросов к дейликам, у меня есть вопрос к конкретно этим двум пунктам для обсуждения на дейли :)
Собственно, это стандартный план для стендапа. О чём ещё можно говорить на дейли, чтобы команда понимала, в каком состоянии находится спринт/история?
Например, о состоянии спринта и задач? А не о том, кто чем занимался, и чем планирует заниматься? :)
А задачи это не то чем команда занимается и планирует?
Странный вопрос. Разумеется, команда занимается задачами, чем же еще ей заниматься? :) Вопрос в том, почему бы сразу не обсуждать текущие проблемы с задачами вместо поочередного рассказа "как я провел день" от каждого члена команды?
Чтобы не повторяться, приложу ссылку на другой свой комментарий: https://habr.com/ru/post/561184/?reply_to=23121766#comment_23118536
Вопрос в том, почему бы сразу не обсуждать текущие проблемы с задачами вместо поочередного рассказа "как я провел день" от каждого члена команды?
Тут два варианта: если команда занимается только задачами спринта, то это эквивалентно.
Если команда занимается чем-то еще (консультациями других команд, например) то это "что-то" еще может быть тоже интересно с точки зрения загрузки членов команды и влияния на спринт.
А ведь была страна советов...
Короче, задача для многих команд просто непосильная по факту.
есть такие люди, которым не хочется полчаса слушать подкаст, а хочется за 5-10 минут прочитать структурированный текстТочно, есть )
Работа в распределенной команде: типичные проблемы и их решения