Waterfall, Agile, Scrum, Kanban: основы управления проектами

В третьем выпуске подкаста «Пока деньги капают» интегратора Битрикс24 компании СофтСервис разобрали основные аспекты методов и инструментов управления проектами.

В гостях Максим Баталин – тренер AgileLAB, Agile Coach, Release Train Engineer, SPC. Максим консультирует не только IT-бизнес, но и, к примеру, производственные компании, нефтегазодобывающей отрасли, машиностроения, компании в сфере бухгалтерского учета, юридической помощи и другие.

Выпуск уже доступен на YouTube и Яндекс.Музыке. А для тех, кто «любит глазами», есть инфографика. Здесь же будет его короткая текстовая версия.

Максим: Мир меняется, мир ускоряется во всех смыслах, и сейчас у нас есть гораздо больше переменных, которые мы способны учесть на среднесрочную перспективу и на длительное планирование. Если эти факторы не учитывать, может серьезно пострадать качество продуктов. Соответственно, когда страдает качество, компании стремятся что-то изменить в своей работе, чтобы сделать проект лучше, чтобы он был более успешным на рынке, и, в конечном итоге, чтобы за счет этого заработать больше денег. Главный стимул здесь – быть конкурентоспособными, заработать больше, или как минимум сделать классный интересный продукт. Можно сказать, что стремление внедрять новые подходы к управлению проектами – это реакция на изменчивость среды.

Анна: Я правильно понимаю, что ты специализируешься на внедрении гибких методик?

Максим: В целом, да. Но нужно понимать, что все зависит от среды, окружения, того, что происходит в компании. На определенном этапе, при определенном продуктовом портфеле компании приходится искать компромиссы – выстраивать гибридные модели. Agile про то, как быстро заработать много денег, сделав классный продукт. Но при этом нужно понимать, что Agile – это недешево. Приведу такую аналогию: есть видео-ролик: на Формуле-1 в 60-х годах прошлого столетия на пит-стоп заезжает автомобиль и дальше полторы минуты меняют шины. И все радуются. Сейчас машина залетает, и в считаные секунды делают все, что нужно. Понятно, что сейчас в этом задействованы десятки человек, что само по себе недешево. В целом, можно как раньше по полторы минуты менять резину и на этом сэкономить, но в таком случае вас обойдут конкуренты и вы не выиграете главный приз. То есть, в целом, Agile – это недешево, но позволяет заработать значительно больше.

Максим: Если крупными мазками, то Waterfall был разработан Уинстоном Ройсом, чтобы структурировать управление проектами. Однако многие забывают, что сам Ройс говорил, что Waterfall не подходит для сложных продуктов и крупных проектов. В это случае стоит использовать итерационный подход: сначала сделайте самое важное, покажите клиенту, а потом на основании обратной связи опять запускайте новые циклы по доработке. Поэтому мне в целом сложно противопоставлять Waterfall и Agile: они оба классные, просто используются для разных целей и в разной среде.

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

Что касается Agile, здесь мы можем делать все и сразу. В каждом цикле мы делаем то, что важно нам здесь и сейчас, и реализуем это в короткие сроки. Важно, что здесь мы за маленький промежуток времени делаем какой-то функционал, показываем его клиенту, получаем обратную связь и приступаем к доработкам на следующем цикле. Дальше опять показываем, опять собираем обратную связь и реализуем новые доработки. Так мы сможем дать клиенту максимально соответствующий его требованиям продукт и адаптироваться к изменениям его потребностей и рынка в целом. Все циклы мы делаем от начала до конца, при этом мы параллельно можем запускать сразу несколько процессов.

Максим: Давай зафиксируем, что Waterfall хорошо себя показывает на проектах с низким уровнем изменчивости, где все требования понятны и прозрачны, т.е. где нужно просто взять и сделать. Сюда можно отнести и шаблонные для нас проекты. В этом случае мы можем описать некую этапность работ. Сам Ройс предлагал некое количество определенных этапов, но, с моей точки зрения, придерживаться именно них не обязательно, можно описать процесс по своим этапам. Главное – принцип, что каждый новый этап следует за предыдущим. Важно еще понимать, что Waterfall работает для проектов с небольшой длительностью, на мой взгляд, до 2 месяцев, поскольку какой-то результат, работая по этой методике, мы получим только в самом конце. Так, если мы проработали над проектом до 2 месяцев, и поняли, что совершили где-то ошибку, можем просто заложить еще неделю на исправление дефектов. А если мы будем делать по Waterfall крупный проект, и потом в конце поймем, что сделали что-то не так, цена ошибки будет очень большой. Как реакция на это и появился Agile.

Максим: Начнем с того, что когда появился Waterfall, он хорошо себя показал, т.к. проекты в нем стали более быстрыми, более управляемыми. Соответственно, больше из них доживало до финальной стадии. Но ускорялись не только процессы, но и среда: появлялись средства электронной коммуникации, конкуренты тоже становились быстрее и так далее. Многие начали самостоятельно искать подходы, как ускориться, делились ими в сообществе, на конференциях. И в какой-то момент они собрались и создали Agile-манифест, где, по сути, аккумулировали свои знания и опыт. По сути, он призван помочь в трудной ситуации довести проект до успешного завершения. Он содержит 4 ценности и 12 принципов.

Максим: Agile нужно внедрять комплексно, потому что это в первую очередь образ мышления. Это философия, которая требует кардинальных изменений сразу во всей компании: культурные изменения, изменения во взаимодействии, в иерархии и так далее. То есть если, например, вы захотите внедрить Agile в одном каком-то подразделении, оставив без изменений остальные – у вас скорее всего не получится. Причина достаточно простая: в любом случае ваша Agile-команда будет взаимодействовать с другими подразделениями, что поломает все гибкие процессы внутри Agile-команды.

Максим: Scrum – достаточно простой с точки зрения «прочитать и понять», но весьма сложный для внедрения фреймворк. Все дело в том, что очень многие вещи не прописаны в скрам-гайде, к ним приходишь опытным путем или дополнительным образованием. Суть в следующем: есть три роли – разработчики (прим. – исполнители), скрам-мастер и владелец продукта. Эти роли выступают некой системой сдержек и противовесов, которые пытаются сохранить баланс в работе. Часто бывает так, что владелец продукта хочет всего и сразу, поэтому пытается по максимуму «запихать» задачи в разработку. В итоге команда перегружена, с одной стороны, все хорошо, все работают, с другой – результат у этого сомнительный. Мы легко можем столкнуться с ситуацией, когда в начале спринта в работу берется 150 задач, а в конце не завершена ни одна. То есть ценность у этого всего в итоге нулевая. И здесь начинается работа скрам-мастера, который понимает загрузку команды, понимает, можно ли добавить еще задач, или лучше доделать те, что есть уже в работе. Со временем команда обучается и может самостоятельно отказать владельцу продукта в добавлении новых задач в спринты. Так они уже начинают договариваться, что делать сейчас, что потом, и что приоритетней.

Также в Скраме есть система встреч, которые очень важны для организации циклов. Есть ежедневная встреча – daily scrum, где мы обсуждаем сложности и договариваемся, кто, что и когда будет делать, а также как мы эти проблемы будем решать. Есть встреча, или даже процесс – product backlog refinement, для того чтобы мы смотрели вперед и решали текущие вопросы, исходя из бизнес-требований. Еще одна встреча – обзор спринта (sprint review), где мы собираемся c ключевыми лицами, или стейкхолдерами, и показываем, что мы сделали за предыдущий спринт, а также собираем от них обратную связь. Эту обратную связь мы берем на ретроспективу, где мы должны понять, что у нас было хорошо, что было плохо, и как можно улучшить. И на следующий спринт мы планируем внедрить эти улучшения. Таким образом, у нас есть несколько циклов обратной связи: ежедневный скрам – тактический цикл обратной связи, где мы обсуждаем все с командой, обзор – когда мы собираем обратную связь от заказчика, и product backlog refinement – когда мы пополняем и оптимизируем наш бэклог.

Максим: Здесь нет конкретной величины, есть рамки – до 1 месяца. Для себя я выбрал размер спринта в 2 недели, потому что он позволяет не наделать много ошибок и быстро поправить те, что есть. Если говорить о том, что команда жалуется, что не успевает работать, и встречи по итогам спринта отнимают много времени, тут, на мой взгляд, дело не в размере спринта, а в эффективности встреч. Поэтому, если такая проблема стоит, я рекомендую просто изучить и внедрить фасилитацию на встречах. Второе, что могу порекомендовать – изучить «входы» и «выходы», т.е. определиться с ожиданиями от встречи, и подумать, что нужно команде, чтобы встреча прошла эффективно. Это поможет сделать планирование и бизнес в целом более предсказуемыми.

Максим: Еще один из методов, наверное, самый простой – это Kanban. Его можно внедрить без каких-то особых изменений в компании: ролей, процессов и так далее. В нем мы просто визуализируем нашу работу с задачами, описываем правила, которые у нас есть. Дальше мы итеративно придем к изменениям, которые можно внедрить. И в отличие от Scrum, Kanban охватывает все этапы: от возникновения идеи до завершающей покупки со стороны клиента. Чаще всего Kanban внедряют первоначально для того, чтобы руководить потоком, находить «бутылочные горлышки», повысить фокус, улучшить коммуникацию, плюс повысить прозрачность. Это если не углубляться. Если углубляться, вы откроете для себя нового, потому что там и роли есть и встречи (каденции), есть модель зрелости команд и так далее. Там есть много чего, что можно тоже развивать. Есть Scrumban, который совмещает Scrum и Kanban, и много еще сего интересного.

Максим: Нет. Это 2 разных подхода, у них разные задачи и разная среда. Мое субъективное мнение, но попытка скрестить Waterfall и итеративно-инкрементальный подход – это PMBOK. Подход классный, он стоит на границе между Waterfall и Agile. Там есть группы процессов, процессы, одна группа переходит в другую, у них есть возможность вернуться назад, плюс там есть этапы, или фазы, на которые мы можем добавить критерии приемки, и проводить переход из фазы к фазе через демонстрацию продукта и обратную связь. По ему мнению, это попытка скрестить 2 подхода, но, на мой взгляд, она проиграла битву с маркетингом, т.к. у PMBOK достаточно узкая аудитория. Сейчас все меньше остается гибридов, потому что Agile намного лучше продается.