Примечание: ниже представлены мои ЛИЧНЫЕ убеждения насчёт Agile и командной организации. У вас всё может быть иначе.
Недавно я стал техническим менеджером продукта в своей компании, и это мой первый опыт руководства командой инженеров. Вплоть до января я был разработчиком, недовольным обилием совещаний.
Так что последние полгода я проводил эксперимент, состоящий из нескольких новых правил:
- Нет летучкам (стендапам)
- Нет регулярному планированию
- Нет ретроспективам
- Все совещания добровольны
Может показаться, что это чересчур. Но в этом безумии есть некоторая логика.
Я хотел, чтобы команда знала, что я ей доверяю. Знала, что справляться с техническим долгом, изучать новое и работать в собственном ритме — нормально. Я сформулировал задачи на квартал и положился на то, что работа будет сделана. А потом свалил в туман.
И вы таки не поверите — работа была сделана. Много работы.
Мы были чрезвычайно производительной командой, которая отвечала на изменения и великолепно справлялась с каждой поставленной задачей.
Но прежде чем подробно рассмотреть, почему эксперимент сработал, давайте взглянем на то, как действует обычная Agile-команда.
Обычная Agile-команда
Создадим вымышленную команду под названием «Суперзвёзды Agile».
«Суперзвёзды Agile» работают недельными спринтами.
Так, каждый понедельник они проводят час, планируя работу на неделю. Каждый день в 10 утра они встречаются на летучке, где каждый участник команды рассказывает, что сделал вчера, что будет делать сегодня, есть ли у него заблокированные задачи, и выступает с объявлениями. В конце недели они отводят час на ретроспективу, где обсуждают, что прошло хорошо, что прошло плохо, и создают задачи, чтобы решить найденные проблемы.
Звучит довольно логично, так?
Как этот рай производительности может разрушиться? Сейчас увидите.
- Trello (или что вы там используете) должна быть синхронизирована с тем, что обсуждается на совещаниях. Часто это не удаётся. С ростом команды становится ещё сложнее.
- Летучки ПООЩРЯЮТ ежедневную смену планов. Непоследовательность — отличный способ сломать разработчику состояние потока.
- Летучки заставляют каждого участника команды быть производительным в установленном месте и в установленное время.
- Экстраверты прекрасно чувствуют себя на летучках, планёрках и ретроспективах. Неудивительно, что технический долг — такая распространённая проблема. Разработчики не должны быть вынуждены РВАТЬСЯ погасить технический долг. Команды должны работать в устойчивом темпе.
- Зачем поощрять обсуждение проблем раз в неделю? Нужно решать их незамедлительно, а не только на ретроспективах.
- Спринты поощряют итеративную разработку. Это очень привлекательно для таких людей, как я, — приверженцев маленьких, сжатых запросов на включение кода, а не долгоживущих ветвей функциональности. Но это не одно и то же. Спринты поощряют приоритет функционала над техническим долгом. Часто ли вам приходилось уговаривать команду отвести целый спринт на погашение технического долга?
Что будет, если не планировать каждую неделю, не делать ретроспектив и не проводить летучек?
Прекратите проводить летучки
Летучки раздражали меня всегда. Эффект от них обычно такой: разработчики отвлекаются, чувствуют, будто их заставляют заниматься функционалом в ущерб техническому долгу, и к тому же они легко могут длиться дольше получаса.
Побочные эффекты отказа от летучек таковы:
- Разработчики больше общаются
- Команда лучше приспособлена к удалённой работе
- Погашается технический долг
- Разработчики чувствуют себя более уверенно и меньше напрягаются
- Разработчики знают, что вы доверяете им и поддерживаете их
Моя должность в Spotify — технический менеджер продукта. Моя роль — «стоять у руля» (например, решать, над чем мы работаем). Если я каждый день меняю курс, у меня проблемы. Если вся организация каждый день меняет курс, исправить это — моя работа.
Реальность такова: я сказал своему руководству, что мы можем выполнить до конца квартала, и я предпочитаю верить, что моя команда знает, что для этого требуется, и подойдёт к задаче творчески.
Я хочу дать им как можно больше свободы.
Хочется на денёк отложить работу и посвятить его open source? Жги.
Хочется пару дней позаниматься чем-то совершенно другим? Развлекайся.
Думаешь, наш технический долг вышел из-под контроля, и хочешь это исправить? Давай дружить.
Я знаю, что ты приведёшь нас к цели, и кто я такой, чтобы повторять тебе каждый день: «ну, у нас в журнале пожеланий к продукту самые приоритетные — X, Y, Z»?
Нафиг этот шум.
Прекратите планировать каждый спринт
Регулярное планирование меня тоже всегда раздражало. Довольно редко, по моему опыту, обстановка меняется настолько радикально, чтобы всей команде понадобилось вместе разбираться, что делать. Но если уж случилась чрезвычайная ситуация, конечно же, созывайте совещание и обсуждайте на здоровье. При этом я не против планирования, я против планирования по расписанию.
Вот как всё выглядит, когда мы не планируем каждую неделю или две:
- Разработчикам доверяют, что они будут заниматься тем, чем надо
- Разработчиков гораздо реже прерывают, поэтому они заканчивают начатое
- Журнал пожеланий к продукту используется как очередь задач в порядке приоритета
- Задачи добавляются в журнал по мере необходимости, непрерывно
- Проблемы обсуждаются сразу же
- Планирование происходит, когда меняются планы. Усталость от совещаний снижается, и команда понимает, что это крайняя мера и обсуждаются важные вещи
Прекратите проводить ретроспективы
Представьте, что у вас роман и всё идёт великолепно. Вам непременно надо начать ходить на еженедельную семейную терапию, так?
Нет, конечно. Так нахрена нам ретроспективы каждую неделю или месяц?
Кроме того, зачем нам ждать ретроспективы, чтобы обсудить проблему или похвалить кого-то?
Вот как всё выглядит, если отказаться от ретроспектив:
- Разработчиков не прерывают, так что они фигачат
- Проблемы решаются быстрее
- Стикеры и маркеры не пропадают, и вместо них мы покупаем себе обед
Вот некоторые вопросы, которые, я знаю, вам хочется задать
«Как я пойму, над чем работать?»
Хорошо: выберите пункт из журнала пожеланий к продукту.
Лучше: журнал отсортирован по приоритету, и вы выбираете из него самую приоритетную задачу.
Отлично: вы работаете над техническим долгом или над open source, чтобы дать себе отдохнуть.
«Что делать, если задача заблокирована?»
Хорошо: выберите другую задачу из журнала.
Лучше: создайте в Trello колонку «Заблокировано», переместите туда задачу, потом выберите другой пункт из журнала.
Отлично: переместите задачу в колонку «Заблокировано», выберите другой пункт из журнала и скиньте команде сообщение в Slack, чтобы они знали о блоке.
«Как отслеживать прогресс?»
Хорошо: просто спросите у вашей команды, только не спрашивайте каждый день.
Лучше: обновляйте и актуализируйте журнал пожеланий к продукту. В Trello, блин, загляните.
Отлично: больше общайтесь с командой, если поставлена высокоприоритетная задача. В остальном доверяйте команде, пока она не обманет вашего доверия и не завалит задачу. Иногда непринуждённо справляйтесь, как дела, за обедом или кружкой пива.
«Погодите. У нас всё хорошо с техническим долгом, а летучки мы проводим!»
Шикарно!
Видимо, у вас разговорчивые разработчики, рвущиеся гасить технический долг, и руководство, которому глубоко небезразлично качество разработки.
Но реальность такова, что большинство компаний устроены не так, и даже ваша компания, скорее всего, не очень-то хорошо подходит интровертам.
Вывод
Эффективные команды всё ставят под вопрос. Ещё они доверяют друг другу. И ещё они много и результативно фигачат.
Эта статья — попытка поставить под вопрос обычное поведение Agile-команд. Ежедневные летучки, планирование раз в неделю или две и ретроспективы раз в неделю или две. И это мы ещё не обсудили оценку задач.
Мой совет всем командам: не усложняйте всё с самого начала.
Летучки, планирование и ретроспективы — инструмент, а к выбору инструментов надо подходить с умом.
Перевод статьи palmerj3: “You don’t need standup”
