Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил
Статья написана в соавторстве c Алексеем Мелентьевым.
Привет, давайте знакомиться. Мы — Алексей Мелентьев, Senior QA и Senior Team Lead с
О Scrum написано так много, что никаких открытых вопросов об этом методе управления проектами, кажется, оставаться не должно. Но все ли понимают, что этот Scrum представляет собой на практике, как его внедрять и без чего он не получится? Считаем, задуматься об этом полезно всем, кто интересуется современными методиками разработки, а уж тем более тем, кто работает в проектах, претендующих на использование Scrum. Особенно проджект-менеджерам и тимлидам, которые руководят командами в таких проектах.
Чтобы разобраться, мы собрали десяток наиболее характерных вопросов о Scrum и провели опрос среди коллег, работающих в разных проектах и командах, с разными заказчиками и технологиями. Мы не пытались собрать репрезентативную выборку, и главной темой в статье будет не статистика ответов. Мы постарались выявить проблемные точки, проще говоря, самые распространенные ошибки в представлениях о Scrum-методах.
Сразу оговоримся, что мы ни в коем случае не беремся оценивать целесообразность самого Scrum-подхода или эффективность его применения в отдельных командах. Речь пойдет исключительно о распространенных случаях несоответствия теории и практики, а также представлений самих IT-специалистов об этом методе. Думаем, всем, кто сам работает по Scrum, наш материал поможет проверить базовые настройки.
Иллюстрация Алины Самолюк
Команды без Scrum-мастера
Около 70 % опрошенных ответили, что в их команде нет Scrum-мастера. Это бесспорный антирекорд нашего опроса. Впрочем, для аутсорсинговых проектов результат, пожалуй, выглядит предсказуемым: не так уж просто продать заказчику специалиста, задача которого только следить за процессом. По крайней мере именно так чаще всего выглядит Scrum-мастер в глазах заказчика.
Конечно, в командах, исповедующих Scrum, есть проджект-менеджеры и тимлиды. Так ли важно, если никого из них официально Scrum-мастером не называют? Пожалуй, нет, если PM или TL не забывает об основной задаче — обслуживании интересов команды. Служить тем, кто занимается разработкой и тестированием продукта, важнее и сложнее, чем управлять или руководить ими. К сожалению, немало менеджеров и лидов несут свои звания с излишней гордостью. Те, кто не до конца понимает свою роль, обычно считают, что они пусть и немного, но все-таки важнее остальных членов команды.
Эта на первый взгляд безобидная и скорее психологическая проблема ведет к другой, более практического характера. Мы с удивлением обнаружили, что в подавляющем большинстве проектов последнее слово остается за менеджером проекта, тимлидом, продакт-оунером, но только не за командой. Здесь мы видим прямое противоречие с принципами Scrum, согласно которым именно команда должна решать, кто и что будет делать, а затем совместно нести полную ответственность за ход и результаты работы. Scrum-мастер или тот, кто выполняет его роль, всего лишь организует процесс, помогая принять правильное решение, а затем качественно и в срок справиться с задачами, которые коллеги (при его равном участии) поставили сами себе.
Почти каждому из нас хотя бы раз приходилось работать в такой команде, где PM продавливает свою точку зрения, а когда приходится отвечать за провалы или отложенные сроки, ищет крайних. Вместо того чтобы понять, что нет правых и виноватых, а есть команда. И либо она смогла с твоей помощью выстроить процесс и быть эффективной, либо нет.
Работа без планирования
Всего лишь 12 % опрошенных ответили, что пользуются техниками планирования, такими как Planning Poker. Еще 45 % заявили, что проводят командное планирование без применения каких-либо техник, а целых 43 % признались, что командного планирования не проводят вовсе, доверяя этот этап работы проджект-менеджеру или тимлиду.
Нам эти данные кажутся удручающими. Как команда может нести ответственность за то, о чем ее не спрашивали? Как PM или TL может знать все подводные камни дизайна, разработки и тестирования?
Да, планирование — это, возможно, не самое интересное занятие. Процесс бывает сложным, может продолжаться долго, причем порой кажется, что время, потраченное на него, просто потеряно. Но эта часть не менее важна, чем написание кода или, скажем, подготовка вайрфреймов. Но этому нужно учиться. Планирование — ключ к комфорту вашего заказчика и команды. Именно грамотная подготовка предотвращает «пожары»: работу в ночь перед релизом или по выходным, потому что «мы опять не успеваем».
Стоит признать, мы ни разу не видели проект, в котором абсолютно все прошло по изначально утвержденному плану. Но это не значит, что к этому невозможно приблизиться и не стоит стремиться. Если вы научитесь трезво оценивать объем работы, который ваша команда способна выполнить за спринт, процесс улучшится и жить станет легче. Вы сами удивитесь насколько.
Еще до DataArt Настя работала в проекте, где планирование и оценки делали только Dev Lead и Project Мanager, не советуясь с теми, кто непосредственно будет выполнять задания. Как результат — либо сроки срывались и приходилось объясняться с заказчиком, либо разработчики тайно овертаймили, чувствуя свою вину за то, что не успевают. Хотя дедлайнов они сами не устанавливали. После этого все поняли, что подход был в корне неправильный и участвовать в планировании должны все.
Жизнь без стори-поинтов
От проблем планирования плавно переходим к следующей ошибке. Всего лишь 35 % опрошенных пользуются стори-поинтами, остальные предпочитают оценивать задачи в часах.
Пожалуй, каждый, кто работал по Scrum-методу, когда-то возмущался: «Кому нужны эти стори-поинты?» Этот период в карьере длится ровно до тех пор, пока не попадешь в проект, где они тебе действительно помогут. Story points позволяют правильно оценивать объем работы, которую команда успевает сделать за спринт.
В чем разница с оценкой в часах? В том, что стори-поинты помогают отвязаться от привычных «Я выполню эту задачу за 10 часов. А я протестирую ее за 5» и оценивать сложность задачи в целом, основываясь на опыте. Потому что оказывается, что 10 часов на разработку плюс 5 часов на тестирование не гарантируют выполнения задачи за 15 часов. Часть времени тратится на коммуникацию, на уточнения всевозможных деталей, на погуглить, попить кофе и тому подобное. Возможно, задача еще и не пройдет тестирование с первого или второго раза и потребует доработки. Возможно, найдутся неточности в требованиях.
И таких «возможно» в каждом проекте великое множество. Именно благодаря стори-поинтам можно абстрагироваться от мелочей и оценить сложность задачи в целом. Они помогают трезво взглянуть на объем задач, который ваша команда успевает выполнить за спринт. А ведь в итоге важен как раз объем работы, а не время, потраченное на нее.
Рост команды без границ
Около 35 % опрошенных ответили, что их команда насчитывает более 10 человек. Нам и самим приходилось работать в команде 40+ специалистов. Результат предельно предсказуем: дейлики по часу, ретроспективы на 10 с лишним часов... Как мы до такого докатились, спросите вы? Очень просто!
Сначала нас было не больше десяти, потом мы начали расти, но и представить не могли, что нас когда-нибудь станет больше 15. А зря! Стоило вовремя задуматься о том, чтобы разбить команду на подпроекты, чего и вам желаем. Если видите, что команда разрастается, а ежедневные созвоны хоть немного затягиваются, не откладывайте — прикиньте, не пора ли вам разделиться.
В нашем случае на одном из дейликов мы просто осознали, что так дальше длиться не может, и начали перебирать варианты, как быть дальше. В итоге мы разбились на подкоманды. У каждой команды были свои лиды, которые ходили на созвон своей подкоманды и на лидовский созвон. Результат: дейлики стали укладываться в 30 минут, а их эффективность выросла в разы.
Работа без созвонов? Созвоны без коллег?
Мы все знаем распространенные «церемонии» в Scrum: ежедневные созвоны, планирование, ретро, демо и так далее. Но, к сожалению, многие команды пренебрегают всеми или некоторыми собраниями.
Ежедневные стендапы проводят многие, хотя даже их иногда считают лишней тратой времени. Когда-то давно Настя работала в нераспределенной команде, где решили сэкономить
Однако, когда команда большая, соответствовать регламенту в 15 минут сложно. Часто люди начинают обсуждать детали конкретной задачи и созвон превращается в балаган. Принцип золотой середины требует говорить по существу и быстро — так, чтобы уложиться в отведенное время.
Чаще команды пренебрегают общим планированием (см. выше), оставляя все оценки тимлиду. Потом команде остается удивляться, пытаясь соответствовать плану, который им навязали.
Еще чаще игнорируют ретро. Менее 50 % опрошенных не проводят ретроспективу и ревью спринта, потому что считают это лишней тратой времени.
Но сам факт проведения ретро не решает все проблемы. Некоторые команды проводят его, но не делают никаких заметок и action items. А если и делают, то у многих они остаются без внимания. Хорошо — назначать ответственных или исполнителей для всех action items, а каждое очередное ретро начинать с анализа того, что было записано на предыдущем.
Мы уверены, что ретро — это классная штука, благодаря которой можно посмотреть назад и проанализировать свои ошибки, только нужно приложить немного усилий, чтобы оно было действительно эффективным.
Спринт без ясной цели
Многие знают, что бэклог спринта менять нельзя. И да и нет. Но почему так сложно?
Представьте, что в ходе спринта вы должны построить одноэтажный дом. В середине спринта говорят, что нужно изменить цвет занавесок в гостиной этого дома с синего на зеленый. Но ведь бэклог нельзя изменить!
Самое главное — не бэклог спринта, а его цель. Если было решено, что нужно построить дом — это та цель, к которой вы стремитесь. Изменение цвета занавесок никак не повлияет на успех вашего спринта, если дом будет построен. Оказалось, что нужны зеленые? Если это возможно, почему бы и нет. Конечно, я не говорю о ситуации, когда вместо одного этажа вдруг потребовалось два, да еще и гараж в подвале, о котором изначально речи не было. Такое обновления требований, возможно, даже потребует остановки спринта и переоценки всех изменений. Однако в любом случае главное — понимать, каковы будут последствия внесения новых требований.
В одном из первых серьезных проектов Леши заказчик очень любил менять цели, увидев какие-то новые фичи на конференциях. Он немедленно требовал таких же, и его не волновало, что сотрудники работают совсем над другим. Как говорится, желание заказчика — закон. Нужно срочно? Срочно переключаемся. Потом выяснялось, что новая задача влечет изменения не только фронта, но логики на бэкенде. «Но раз мы начали делать изменения на бэкенде, не добавить ли нам еще вот такую фичу?» — спрашивает заказчик. Результат — релиз увидел только третью версию сайта на год позже запланированного.
Недостижимый идеал
В идеальном Scrum-проекте все участники должны быть многофункциональными. К сожалению, пока настолько универсальных команд мы не встречали. Догадываемся почему: человек не может уметь делать все. В нашем мире нет супергероев, даже человек типа «и швец и жнец» (пусть даже без музыкальных способностей) — большая редкость. Невозможно одинаково успешно развиваться во всех направлениях, потому-то и возникает специализация и «зоны профессиональной ответственности».
Четкое разделение обязанностей позволяет наладить параллельные процессы. Возможно, вы смотрели фильм «Основатель» про создателей сети McDonald’s. Братья Макдональды придумали, как выстроить производственную цепочку с большим количеством людей, где каждый делает свою работу: жарит котлеты, нарезает овощи, наливает напитки или пробивает заказ на кассе. Это стало залогом скорости производства без потери качества: на каждом этапе за него отвечает сотрудник, досконально знающий свой участок работы.
Это не защитит вас от сбоев на 100 %, но это ближе к реальности, чем мечта о коллегах, которые могут в любой момент выступать в роли разработчика, тестировщика или аналитика. Хотя если вы работаете или работали в такой многофункциональной команде, то, пожалуйста, поделитесь опытом в комментариях! Нам очень интересно.
Выводы, или Мораль без морализаторства
- Теория — это хорошо, но каждый проект уникален и иногда требует особого подхода. В то же время с теорией время от времени необходимо сверяться. Если вы претендуете на применение Scrum-методологии, но последовательно отказываетесь от ее элементов, заявленных как необходимые, рано или поздно придется признать, что у вас не Scrum-проект.
- Успешный и идеальный — это не синонимы. Идеальных Scrum-команд в аутсорсинге, по нашим наблюдениям, просто нет. Вряд ли кому-то удастся убедить заказчика оплатить все процессы, без которых идеалом называться не получится. Но само по себе это не разрушит вашего проекта: вы можете делать успешные релизы, приближаясь к методологии вашей мечты в рамках утвержденного бюджета. Главное — не только плыть по течению, но и сверяться с проложенным курсом.
- Не бойтесь импровизировать, ведь менеджмент проекта — сложный процесс, и в каждом случае к задачам придется подстраиваться. Действовать строго по инструкции не выйдет, а уж гибкие методы точно не предполагают догматизма. Важно лишь не идти на поводу у собственного мозга, выдающего за адаптацию методологии отказ от регулярного планирования или обязательного созвона. Действуя в угоду сиюминутному комфорту, мы порой создаем себе серьезные проблемы в будущем.
Подстраиваясь под обстоятельства, не забывайте о специальной литературе, лучших практиках и собственном опыте — подводных камнях, на которые нас иногда повторно несет.
Литературы по Scrum, конечно, много, но ниже мы решили оставить немного классики, которая поможет понять, как правильно построить процесс:
- www.scrumguides.org;
- Kniberg, H. «Scrum and XP from the Trenches / Scrum и XP: заметки с передовой»;
- Sutherland, J.J. «Scrum: The Art of Doing Twice the Work in Half the Time / Scrum. Революционный метод управления проектами»;
- Stellman, A., Green, J. «Learning Agile: Understanding Scrum, XP, Lean, and Kanban / Постигая Agile. Ценности, принципы, методологии».
