Пару лет назад я работала фронтенд разработчицей и скрам-мастерицей в команде, где мы научились закрывать спринты в срок и уводить вниз беспощадные burndown графики. Я была так обескуражена этим фактом, ведь это был мой первый и, как впоследствии оказалось, последний раз, когда процессы работали. Эйфория была такой сильной, что я даже выступала с докладом про то, как круто у нас сработал SAFe (Scaled Agile Framework) и чем он отличается от скрама. Моей ошибкой было уверить тогда в методологию больше, чем в себя и свою команду. После этого доклада мне час задавали вопросы, ведь процессы работают только в книжках, а тут все работало с реальными людьми, что совершенно не сходилось с реальностью тех, кто находился в аудитории. Так почему же если процессы разработки не работают, то их продолжают внедрять? Спустя 2 года разочарований после успеха, думаю, у меня есть часть ответа. Давайте разбираться.

Хватит болтать, пойдем работать!

Начнем с мифа об интровертности программистов. Последние годы все коммерческое ПО на свете пишется командами. В IT кто уже только не работает, а образ программиста-одиночки жив и по сей день. Все мы обладаем разными характерами, но общаться по работе придется, и на самом деле это и не нравится большинству. Люди, жалующиеся на бесконечное количество митингов (встреч, если вы их в компании называете по-русски), чаще вовсе не интроверты, они просто устали присутствовать на обсуждениях, которые их не касаются. Скорее всего эти люди с удовольствием обсудят с вами новый фильм, погоду или выходные, но только не чертовы задачи (фу-фу, а работать то когда). Проблема же тут в том, что на самом деле ваши митинги не эффективны – большая часть на них скучает, никто к ним не готовится, результата от них не видно. Какое-то бесконечное бессмысленное насилие разговорами, когда можно было бы код пописать, ну. Так вот, скучающие люди правы, хороший менеджмент — это не мешать хорошему человеку работать. Тут «совы-эффективные-менеджеры» хватаются за сердце и в полной растерянности начинают задавать вопросы: «А как? А что делать-то?». Все просто — услышать ответ, принять его и простить, попробовать применить на практике.

Митингов должно быть настолько мало, насколько возможно, они должны быть настолько короткими, насколько возможно, а результат от них очевиден и прозрачен для всей команды. Иначе зачем это все? Добиться этого можно, если внедрять процессы там, где они нужны и быть достаточно гибкими, чтобы адаптировать правила под себя, ведь agile переводится как “гибкий”.

А нам вообще это нужно?

Как понять, что agile процессы вообще вам нужны? Если у вас команда из 3-4 человек, то вы и так прекрасно в курсе, кто чем занимается, можете спросить напрямую или в общем чате, там ведь так мало людей. При таком количестве людей разногласий мало, и процессы не для вас придумывали. Достаточно знать что пилить и к какому сроку, разбить зоны ответственности. Если вас больше 10, то тут тоже будут проблемы – митинги будут затягиваться, народ скучать, а ответственность висеть в воздухе, потому что никто за нее не захочет браться. Процессы работают в командах из 5-10 человек, оптимально 7-9, точка. Все остальные «натягивания совы на глобус» не работают. Часто методологии выбираются не командой, а руководством и не исходя из проблем конкретного проекта, а из «сферическо-конной» идеи в вакууме, что модный agile нужно внедрить на уровне компании, т.е. в каждой команде. Если у вас слишком большие команды, то их нужно декомпозировать, изолировать коммуникацию внутри небольших и периодически синхронизироваться между командами. Подробнее об этом в LeSS и SAFe.

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

Дейлики

Дейлики не должны длиться по полчаса, их максимальное время должно быть 15 минут. Все вопросы и обсуждения не могут касаться всей команды, а потому должны быть вынесены в фоллоу-ап (короткий разговор сразу после дейлика только с заинтересованными людьми). Следить за этим должна в идеале вся команда, но как минимум скрам-мастер. Каждый пришел, сообщил над чем работает, что планирует делать дальше и с какими проблемами столкнулся. Если эти проблемы требуют обсуждения – просит остаться кого-то на фоллоу-ап. Если кто-то еще захочет остаться, то также останется, зато все, кто не может быть полезен в решении этой проблемы, пойдет работу работать, а не будет сидеть залипать в телефоне, получая фоновое раздражение. Кстати, про 3 вопроса: «Что делал/делаю? Что буду делать? Что мешает?». Совсем не обязательно формально на них отвечать: «Делал задачу 1234, буду делать 1234, проблем нет». Говорите: «Продолжаю работать над 1234». Задавайте вопросы такому человеку про проблемы, только если что-то он долго продолжает работать над задачей, и по оценкам она не должна быть такой сложной. В остальных случаях он ответит либо, что проблем нет, либо сам попросит о помощи и остаться на фоллоу-ап. Так ответственность остается на каждом члене команды – не надо скрам-мастеру за ручку водить взрослых людей, они знают, что делают. Также полезная практика, чтобы члены команды сами передавали слово следующему, а не ждали, пока скрам-мастер назовет их имя, ведь проект приятнее, когда это эстафета, а не когда учитель вызывает к доске.

Планирования здорового человека

Планирования не должны быть дольше часа. Чтобы добиться этого, все задачи должны быть подготовлены не после, не во время, а ДО планирования. После вышеупомянутого доклада, мне задали вопрос: «Как Вы заставляете свою команду думать заранее?». Тогда этот вопрос меня фрустрировал, потому что в моей картине мира заранее подумать о задаче было в интересах команды. Но, увидев ситуации в других командах, где людей и правда надо заставлять думать наперед, я подумала, что, возможно, вы не даете им над чем подумать – хороших вводных данных по задаче.

Тут очень важную роль играют PO (Product Owner) и BA (Business Analyst). К планированию все задачи должны быть хорошо описаны, а бэклог приоритезирован. Часто на планированиях нет ни того, ни другого, и команда сначала долго размышляет, что же хотел автор задачи, а потом оценивает «сферического коня в вакууме» и ожидаемо промахивается с оценкой. На моей практике, лучше всего работают описания задач с критериями приемки в виде Gherkin нотации, пришедшей из Behavior Driven Development (BDD). Особенно в виде таблиц, например:

При этом описания того, что понимается под корректным email, должны быть в этой же задаче, а лучше где-то в вики для будущих поколений, которые будут рефакторить эту форму и могут не до конца разобрать регулярку. Если выбран второй вариант, то в задаче нужно оставить ссылку. Также описания ошибок и пользовательских текстов к ним должны быть приложены к задаче. Если их не слишком много, то можно вписать их непосредственно в таблицу с критериями приемки. Для новой функциональности на фронтенде должен быть приложен макет, заранее подготовленный дизайнером. Все это важно потому, что подготовка такой задачи будет занимать только время PO, BA и дизайнера, а не всей команды во время планирования. Вопросы у команды появятся до того, как они приступят к задаче, а потому оценка будет более точная.

Описания багов должны содержать указание окружения, условия воспроизведения, шаги воспроизведения, результат и ожидаемый результат. Если можно записать видео, то добавить его. Для багов не обязательно писать в Gherkin нотации. Вообще используйте ее только для пользовательских историй, а технические описывайте так, чтобы было понятно. Это вообще хороший принцип - описывать чтобы было понятно, даже если у ваших коллег внезапная амнезия. Инструменты, которые вы будете использовать для этого, всегда остаются на ваше усмотрение.

Чтобы задача приходила на планирование совсем подготовленной нужно, чтобы на нее уже взглянули предполагаемые исполнители и QA. Это вообще без митинга можно сделать – PO подготовил задачу, скинул предполагаемому исполнителю, он задал вопросы, а вся остальная команда продолжает работу работать, а не ждать пока тот же самый диалог произойдет во время планирования или того хуже – после него. В зависимости от сложности задач и по необходимости можно проводить grooming/refiment митинги на 30-60 минут со всей командой перед планированием, на которых PO презентует задачи, а команда вносит коррективы, задает вопросы, которые мог не учесть предполагаемый исполнитель. Это нужно потому, что порой исполнитель не обладает знаниями о потенциальных проблемах с задачей или посмотрел на нее не со всех сторон. Не стоит обсуждать решения при всей команде, если заинтересованы в этом только 2-3 человека. Идентифицируйте проблемы, запишите их в задачу и обсудите в фоллоу-апе. Хорошо подготовленные задачи - это как хорошо продуманный склад. Затраченное время на его организацию окупается быстрым нахождением нужного. Именно поэтому митинги являются не менее важной работой, чем написание кода. В конечном итоге они должны приводить к большему удобству в разработке, а не препятствовать ей.

Ретроспективы

И напоследок, ретроспективы – самый провальный митинг из всех. Первое, что я спрашиваю у команд: «Понимаете ли вы, зачем нужны ретроспективы?». К сожалению, большинство не понимает. Самая частая картина, которую я наблюдаю, люди приходят, ноют на разноцветных стикерах или креативно составленных виртуальных досках. В это время те, кто ныть не хочет, либо работу работают, либо в телефон залипают. Все ждут, когда уже все желающие наноются и разойдутся. В то время как ретроспективы должны быть инструментом улучшения процессов, анализом ошибок, объединения команды. А если вы и так молодцы и спринт вовремя закрыли, и проблем у вас нет, то похвалите друг друга и отменяйте ретро. Мы так делали, никто не умер, было хорошо.

Итак, как готовить ретроспективу. Во-первых, начните с хорошего, обратите внимание на то, с чем команда справилась и какие хорошие практики были внедрены – это закрепляет положительные тенденции и задает приятный тон для встречи. Дальше выявите проблемы, что можно было бы сделать лучше в следующий раз, чтобы их избежать. Проголосуйте командой и решайте самые важные, остальные со временем либо сами пройдут, либо станут важными. И самое главное – составьте список решений для проблем и назначьте ответственных. Без этого в ретроспективах нет никакого толка! В начале следующей ретроспективы – проверьте было ли выполнено предполагаемое решение проблемы ответственными и как это повлияло на последнюю итерацию. Вам это может показаться очевидным, но я видела это очень редко, а работала в большом количестве команд. Не забудьте про тайминг. Если ретроспектива занимает больше 2х часов, надо что-то с этим делать. Что именно – решите на ретроспективе. Формат ретроспективы может быть каким угодно, используйте хоть 50-тицветную палитру стикеров, главное, чтобы суть оставалось всегда одной и той же. Ретроспектива – это работа над ошибками.

Так, с основными митингами разобрались. Все остальные добавляйте по вкусу и необходимости. Или убирайте. Команде понравится. Но без фанатизма, чтоб все обо всем были в курсе, но не слишком устали – ищите баланс.

T-shaped != человек-оркестр

Из других палок в колесах ваших процессов - неправильное понимание T-shaped. Многие компании понимают это как команду людей-оркестров. Каждый в команде описывает задачи, разрабатывает дизайн, пишет бэк, пишет фронт, тестит (обязательно автоматизированно), знает дэвопс, играет на дуде и умеет летать. И если последние 2 качества вызывают улыбку, то почему-то предыдущий набор «эффективным менеджерам» кажется вполне реалистичным. Настоящий же T-shaped предполагает, что команда знает как что-то делается на проекте в разных сферах – это достигается через обмен знаниями, практики парного программирования и внутренние архитектурные митинги. И благодаря этим знаниям, команда может закрывать дыры при нехватке кого-то из членов команды. В штатном режиме команда должна быть кросс-функциональной, что значит в ней должно быть достаточно специалистов разных профилей для выполнения задач. Я это сравниваю с самолетом – его можно посадить без двигателей, но будет ли кто-то это делать каждый раз? Набирайте в команду отдельного дизайнера и девопса, разрешите им работать немного параллельно основному процессу. Дайте ломать приложение QA, разрабы свои продукты так не сломают. Наймите хорошего BA, от качественно описанных задач зависит весь процесс разработки.

Чтобы процессы работали, нужно, чтобы в них верили. Показывайте команде результаты, которых вы добиваетесь – burndown графики, сравнивайте что было и что стало. Отмечайте положительные сдвиги и увидите, что хорошо поставленные процессы действительно работают, а со временем даже не нуждаются в контроле.