Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.
Рассмотрим острые методологические проблемы, на которые почему-то редко обращают внимание. Порассуждаем, как не споткнуться о такие камни преткновения или хотя бы удержать равновесие после этого.
Спойлер: многие затронутые вопросы спорные, и готовых решений у нас нет (как, наверное, у большинства PM). Так что заранее приглашаем всех желающих к диалогу и обмену опытом в комментариях.
Методология оторвана от реалий разработки, а проект «вывозят» только усилия отдельных специалистов
Представьте: работа идет полным ходом, устраиваются спринт-ревью, ретроспективы и стендапы… Или карточки с тасками уже не умещаются на Kanban-доске. Только вот «корабль» никак не плывет или постоянно сбивается с курса. Все, что делает менеджмент, кажется бессмысленными ритуалами и провоцирует круглосуточные кранчи. Возникает вопрос: зачем вообще нужны эти методологии?
Возможные решения
Повторюсь, идеального подхода к разработке пока не придумали — у каждого свои плюсы и минусы. Так верны ли лозунги «Kanban до победного конца!» или «Спринт в две недели — не больше не меньше!»? Даже если кажется, что у вас единственно верный подход, не всегда нужно «прибивать его гвоздями» на весь проект.
Некоторые эксперты считают, что в зависимости от ситуации и от стадии разработки допустимо менять подходы и даже целые методологии. Тогда команда будет по-настоящему гибкой и сможет выбирать те практики, которые упростят работу. Особенно это актуально для сложных и длительных проектов, где многое меняется с течением времени
В нашей практике однажды пришлось на лету переобуться из классического Kanban в гибридный Scrumban. Это придало новый импульс разработке и помогло все-таки уложиться в отведенные сроки. С одной стороны, разработчики перестали хвататься за все подряд в ущерб уже начатым задачам. Внедрение спринтов добавило проекту обстоятельности, появился небольшой временной задел, чтобы оценить целесообразность и приоритетность изменений. С другой стороны, в рамках каждой итерации сохранилась полная гибкость Kanban: возможность переопределять приоритеты и очередность задач внутри спринта. По примерным оценкам, смена методологии помогла повысить производительность команды на 10%.
Иногда полезно менять продолжительность спринтов прямо в ходе проекта. В России это оправдано, например, в длинные новогодние праздники, когда итерация легко растягивается с положенных двух недель до трех.
Другая подобная ситуация — когда в ходе разработки накапливается большой пул понятных и простых задач, которые реально выполнить быстро, но лишняя неделя до сдачи расхолаживает команду и сбивает темп. Тогда можно в качестве исключения, наоборот, сократить спринт. Получится временной буст к доставке фич.
Однажды таким образом нам удалось на 30% повысить деливери фич при разработке мобильного приложения с кучей мелких интеграций. Одновременно на 20% увеличилось количество выполняемых за неделю задач
Правда, если слишком долго вести разработку короткими спринтами, получится «бег в колесе», и команда быстро выгорит. Здесь важно балансировать нагрузку исходя из ситуации.
Порой стоит менять периодичность установочных встреч, а также других методологических мероприятий. Разрабатывая одну крупную платформу аналитики данных, мы двигались двухнедельными спринтами, как завещал Scrum. Но пока готовили MVP, а реальных пользователей не было, регулярно собираться на стендапах не имело смысла. Все ограничивалось спринт-ревью по итогам итераций, а возникающие рабочие вопросы эффективно решались в чатах или на точечных совещаниях.
После запуска ситуация изменилась, потребовалось тщательнее координировать усилия команды. Тогда мы решили устраивать 15-минутные стендапы и обсуждать, кто что выполнил вчера, делает сегодня и планирует на завтра. Классический Scrum требует проведения таких мероприятий ежедневно, но нам хватало двух раз в неделю.
Гибкие методологии не учитывают состав и численность команд
Командный вопрос — едва ли не самый увесистый камень в огород Scrum, Kanban и гибких методологий в целом. Они хорошо работают в случае с небольшими, статичными и однородными командами. Когда в разработку вовлечено много участников, а специалисты регулярно сменяются или несколько групп реализуют один проект, начинаются проблемы. Например, деление скоупа на небольшие спринты усложняет онбординг новых разработчиков.
При большом числе участников трудно воплотить в жизнь и один из ключевых управленческих принципов Agile — самоорганизацию. Те же scrum-команды сами решают, как именно выполнять поставленные задачи. Для этого сотрудники должны синхронизироваться друг с другом: знать навыки и стиль работы коллег, понимать, к кому обратиться за помощью или, напротив, когда подставить плечо. Нужно оставаться в контексте всех взаимодействий в команде.
Чем больше команда, тем сложнее выстроить открытую коммуникацию. Это все равно что сравнивать общение соседей в поселке, где «без спроса ходят в гости», и жизнь в мегаполисе. Отчасти поэтому классический Agile и предписывает работать группами по 5 — 9 человек
Теория теорией, но на практике такое возможно далеко не всегда. Нам нередко приходится оперировать командами и в 20 человек, включая аналитиков, фронт-разработчиков и бэкендеров, дизайнеров, тестировщиков, тимлидов, продуктовых менеджеров. В отдельных случаях группы исполнителей разрастаются до 35 — 40 специалистов.
Коммуникации запутываются еще сильнее, когда создаешь крупный продукт, интегрированный с различными внешними инструментами. Наглядный пример — маркетплейс, куда из всевозможных партнерских систем стекается информация по ценам и остаткам. В такой ситуации разработчики вынуждены постоянно контактировать со сторонними техническими специалистами. А ведь с точки зрения современных методологий разработки их всех будто не существует.
Возможные решения
Тут многое зависит от координирующих действий владельца продукта — product owner. Некоторые ответственные менеджеры понимают вышеупомянутый принцип самоорганизации чересчур буквально. Дескать, разработчики сами обо всем договорятся, а я посмотрю на результаты. Такой продакт может совсем не принимать участия в планировании спринтов. Тогда с большой вероятностью в итоге получится не то, что нужно.
Чтобы избежать рассинхрона, владельцу продукта стоит самостоятельно выстраивать коммуникационные потоки и организовать summary всех встреч. Упрощенно, такие протоколы сводятся к тому, что «по итогам мероприятия решено сделать так-то, от кнопки N отказаться, внести изменения в макеты X и Y». Причем это касается не только регламентных стендапов и спринт-ревью, но и любых внеплановых совещаний.
Стоит хотя бы пару раз забыть прописать договоренности, как начинаются «разброд и шатание». Люди выпадают из контекста, и выполнение задач буксует
Если говорить о чисто методологических решениях, то для крупных проектов со множеством участников придуман так называемый Large-Scale Scrum, позволяющий масштабировать разработку. Однако в России он не прижился. Почему так сложилось или, точнее говоря, не сложилось — отдельный вопрос. Буду признателен, если поделитесь мнением в комментариях или приведете примеры применения крупномасштабного Scrum.
Разрабы выгорают и непонятно, что с этим делать
При формальном подходе к организации процесса для разработчика зачастую все сводится к святому долгу выдавать определенный объем кода каждые 2 — 3 недели. Полкоманды выкосило сезонное ОРВИ или забрали на другой проект, возник технический форс-мажор, случилось землетрясение или цунами — никого не волнует. Нужна новая фича — вынь да положь! Как итог — переработки, отсутствие нормальных выходных, стресс. Так можно выгореть очень быстро, причем не только профессионально.
Возможные решения
Опять же, в Agile-манифесте нет готового решения этой проблемы. Просто еще на этапе планирования важно учесть одну шокирующую истину: все мы люди, а не роботы.
Чтобы больничные с отпусками не стали для менеджера или заказчика неожиданностью, лучше изначально закладывать на это дополнительные 15% к общему сроку реализации проекта. Тогда оставшимся в строю членам команды не придется героически спасать положение. Да и отдохнувшие разрабы просто лучше пишут код
Облегчает участь сотрудников и чередование задач по сложности. Не стоит несколько спринтов подряд заставлять их пилить самые сложные фичи. После каждого «тяжелоатлетического рывка» не помешает выделить итерацию на декомпрессию: простые доработки, исправление ошибок, ликвидацию пресловутого техдолга.
Постепенно многие типовые задачи, которые еще недавно отнимали целый день, начинают выполняться за несколько часов. Эффект получается, как от тренажерного зала, когда разбавляешь серьезные нагрузки тренировками вполсилы. Специалисты не увольняются, делается меньше ошибок, проект движется быстрее.
Нет четких общепринятых метрик качества проделанной работы
На первый взгляд, что может быть проще: отличить качественно и некачественно выполненную работу? Но если в Waterfall требования к создаваемому продукту и его характеристикам фиксируются в ТЗ, то в Agile не так. Гибкие методологии больше ориентированы на живое обсуждение фич, чем на подготовку проектной документации. Как правило, в них не описываются инструменты для оценки качества работы, проделанной отдельными разработчиками и командой в целом. Даже на четкий список требований к продукту не всегда можно ориентироваться. А нет формализованных требований к качеству — возникает свобода для вариаций и трактовок.
Возможные решения
Скатываться в «водопад» с его ТЗ и согласованиями, наверное, не стоит, но промежуточная документация не помешает. Речь о так называемых Definition of Done (другими словами, «критериях приемки»). В них прописывается, какими характеристиками должны обладать фичи или функции, чтобы считаться готовыми и выполненными качественно.
Если сильно упростить, «на платформе должна быть реализована возможность авторизации» — это еще не DoD. Нужно детализировать, что пользователь может авторизоваться в режиме 24/7, а его сессия длится столько-то времени и т. д. Подобные критерии приемки желательно прописать не только к функциональности ПО, но и к характеристикам кода. Это позволит существенно снизить бэклог рефакторинга.
Да, такой подход затягивает реализацию проекта, возникает необходимость в дополнительной системной аналитике. Таким образом, несколько увеличивается стоимость разработки. Команда проекта вынуждена прорабатывать дополнительные кейсы в части безопасности, отказоустойчивости и т. д. Зато получится избежать неприятных сюрпризов из серии «вы не угадали мои ожидания», а качество продукта будет выше. И главное — оно станет понятным и измеряемым, что исключит спорные ситуации.
Нет надежной методики прогнозирования сроков
Большинство гибких методологий нацелено на оперативную доставку фич. Из-за этого их фокус смещается на короткие итерации (например, спринты), в то время как общая картина остается туманной. Особенно это актуально для крупных и продолжительных проектов: agile-команды часто не представляют, как именно будут выглядеть конечные результаты их работы. Неясно и время, за которое реально достичь этого «не знаю что».
Конечно, гибкие методологии в классическим виде предлагают способы просчитать сроки разработки и производительность команды. Что касается Scrum, то в нем предусмотрены сторипоинты (Story Point). Скажем, на старте три спринта подряд разработчики дают приблизительные оценки того, сколько задач они выполняют и за какое время. По итогам итераций анализируется реальный объем проделанной работы, который соотносится с количеством взятых в исполнение сторипоинтов. Вот вам и производительность участников. Полученные показатели суммируются и масштабируются на всю команду, что дает возможность вычислить примерные сроки.
Обычно оценки в сторипоинтах «живут» в Jira или Youtrack, только на практике зачастую такие данные туда не заносятся, а статистика не ведется — не доходят руки. Более того, сколько не считай сторипойнты, они не помогут заранее оценить нечеткие задачи.
Даже элементарный запрос типа «сделайте нам простенькую авторизацию» можно выполнить десятком способов, которые предполагают разные сроки. Порой в команде начинается настоящая война за форматы реализации, где нет ни победивших, ни проигравших. Зато есть недовольный заказчик, недоумевающий, почему «пустяковая» работа выполняется так долго и нет даты релиза
Чем сложнее задачи и разрабатываемое ПО, тем выше вариативность реализации фич и меньше определенность по дедлайнам. Особенно, если в работе есть исследовательский компонент, как это часто бывает в машинном обучении. Поскольку здесь еще не накоплено достаточного опыта и статистики, нередко приходится вообще идти вслепую сплошными ресерчами.
Возможные решения
Идеальных и математически выверенных решений здесь, похоже, нет. Без системной аналитики не обойтись. Провести сравнительный анализ, посмотреть примеры и лучшие практики реализации похожих проектов — все это помогает более реалистично ставить дедлайны проекта.
Что до отдельных задач, то неплохо показывает себя комбинирование и сравнение прогнозов от разных аджайловских методов оценки, таких как Complexity buckets или Т-shirt sizing. Последний мы применяем особенно часто. Таски классифицируются по размерам, точно майки или джинсы в магазине одежды:
S — самая простая задача, которую разработчик может выполнить за несколько часов. Например: нужно поправить формат для вывода неких данных при передаче фронту.
M — задача, на которую требуется 2 — 3 рабочих дня. Допустим, это добавление в интерфейс ПО индикаторов или кнопок фронтэнд-разработчиком.
L — на подобные задачи, как правило, уходит неделя или чуть больше времени. Это может быть реализация каких-нибудь серьезных функций в базах данных.
XL — наиболее масштабные задачи, выполнение которых занимает целый спринт или даже несколько итераций. Помимо прочего, сюда относится реализация сложной обработки данных, поступающих сразу из нескольких разных систем.
«Детских размеров» в нашей сетке не предусмотрено. Поэтому все, что меньше S, не считается отдельной таской, а относится к фиксам и доработкам.
Теперь о том, как это действует. Составляя план, проектный менеджер или тимлид отправляет пул работ на оценку самим разработчикам. Те, исходя из своего опыта, присваивают каждой задаче соответствующий размер. По «биркам» S, M и даже L, как правило, никаких вопросов не возникает — здесь хватает насмотренности разрабов.
Первым делом руководитель обращает внимание на XL-ки, которые отдельно обсуждаются с командой. Иногда оказывается, что это скорее раздутый «оверсайз», чем по-настоящему масштабная задача. Следовательно, ее логичнее разбить на несколько более мелких частей с маркировками L, M или даже S. Или же все сформулировано правильно, и действительно требуется провести ресерч, более фундаментально подойти к оценке дедлайнов.
Такая размерная сетка помогает менеджерам быстрее сориентироваться: соединить оценки отдельных задач в общий план с понятными сроками, расставить приоритеты, просчитать риски. Разработчики же получают возможность прикинуть фронт работ и рационально распределить время.
Нет надежной методики оценки стоимости отдельных фич и формирования бюджета проекта
Непросто адекватно оценить и стоимость отдельной фичи, ведь по факту она меняется в зависимости от жизненной стадии проекта или продукта. Некоторые вещи кажутся просто неподъемными на старте, но легко выполняются, когда у разработчиков уже есть устоявшаяся кодовая база. Бывает и все наоборот: например, внедрение новых ролей в CRM-систему проще выполнить на ранних этапах разработки, а под конец та же задача обходится намного дороже.
По ходу дела меняются условия, внедряются технологии, обучаются разработчики — проект непрерывно эволюционирует и соответственно меняется стоимость разработки.
Многие пытаются прикинуть трудозатратность фичи, разбив ее на маленькие части. Только сегодня она распадется на 10 составляющих, завтра — на 8, а через месяц — на 2. Выходит, круг замыкается, и можно даже не пытаться оценивать стоимость фич и разработки? На самом деле, все не так пессимистично.
Возможное решение
Просчитать все до минуты и копейки «на берегу» действительно не получится. Придется постоянно сверяться с roadmap проекта и каждую неделю или две приоритизировать отмеченные на ней задачи, соотнося их с текущими требованиями заказчиков.
Случается так, что на roadmap отмечена крупная киллер-фича с наибольшим бизнес-велью и ряд мелких второстепенных задач. Но в реальности она оказывается более трудоемкой, чем планировалось. Не лучше ли тогда бросить все ресурсы на нее, отказавшись от менее важной функциональности? Может возникнуть и обратная ситуация, когда главные задачи спринта удается выполнить с опережением графика и есть возможность взять в работу что-то еще. И тот, и другой сценарий меняет сроки, трудоемкость и стоимость разработки.
Подобные моменты лучше регулярно проговаривать с заказчиком или инвестором. Параллельно следует обсуждать их актуальные ожидания от уже взятых в работу фич — не поменялось ли что-нибудь? Так получится правильно пересмотреть приоритеты в рамках roadmap и скорректировать бюджет в рабочем порядке. Словом: коммуникация, коммуникация и еще раз коммуникация
Что же касается вышеупомянутого изменения стоимости фич на разных стадиях жизненного цикла проекта, то здесь отчасти помогает все та же системная аналитика и изучение похожих проектов. Но ключевое слово «отчасти», везде свои особенности.
Методология — не панацея
Можно просто взять пару руководств по Agile и применить на практике, но не стоит рассчитывать, что все заработает как по волшебству. Какими детализированными ни были бы современные методологии разработки ПО, в них достаточно белых пятен и поводов подумать своей головой.
Опираясь на проектный опыт, мы выделили несколько наиболее актуальных проблем, которые возникают в связи с несовершенством методологий, и предложили возможные решения. Не идеальные, но проверенные на практике.
Возможно, вам, например, удалось разработать свою методику работы. Теперь вы всегда попадаете в яблочко в оценках стоимости фич и бюджета проекта. Поделитесь ей в комментариях, и не забудьте прихватить с собой примеры решения этой и любых других методологических проблем. Будем рады ознакомиться с новыми подходами, гибридными методологиями или отдельными проектными кейсами — удачными и не очень. Все это ценный опыт, который, как известно, «самый лучший наставник».
