Методы управления. Agile, Lean, Scrum, Kanban. Выравниваем процессы, убираем посредников, максимизируем ценность

Нередко в разговорах при мне упоминали названия различных гибких методологий разработки, а я не понимала, про что речь и какая между ними разница. Шило в правильном месте не давало мне покоя, пока я во всем не разберусь. Ну а коль скоро я все равно перелопатила гору контента, решила, чего добру пропадать, надо поделиться с общественностью. В общем, если вы тоже хотели разобраться, что же это за эджайл и откуда там взялись скрамы с канбанами, то вот.

Изначально программисты по природе своей — народ весьма творческий. Как правило, каждая задача может быть решена несколькими способами, и поиск оптимального — задача не банальная. В общем, на заре времен работали они не структурировано, как придется. Мол, вот вам задание, сидите и делайте. Как сделаете, так и молодцы — сравнить-то особо было не с кем.

Затем пришли военные — именно они были первыми заказчиками крупных проектов по разработке. У военных должно быть все четко: разработали регламент → написали ТЗ → отдали разработчикам → получили готовый проект через запланированное время. Эта методология получила название водопада (каскада). Звучит круто, но чтобы двигаться по водопаду, нужно иметь четкий образ результата и понимание шагов, идущих друг за другом, плюс достаточно денег и времени. Чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Можно сравнить с многоквартирным домом — большой, квартир много всякой формы и размера, но вот если непредусмотренный камин захочется где-то поставить, то может и не получиться. Другими словами, допиливать проект, «если что», может быть очень тяжело.

В реальном мире коммерческой разработки выясняется, что отдать ТЗ в разработку и через 2 года получить готовую систему никто не хочет — слишком многое может измениться за эти 2 года. Практически невозможно что-то сразу «отлить в граните” так, чтобы потом оно нас идеально устраивало на долгое время. Что-нибудь по-любому будет не устраивать или работать не так, как на самом деле надо (как потом выяснится). Поэтому бизнес нам говорит: “Сделайте мне круто, но чтоб мы по ходу ещё могли докручивать и чтобы оно зарабатывало уже со стадии альфа-теста».

Так задача чисто по разработке превращается в задачу по исследованию (всего, что связано с проектом) и лишь потом — разработке. Мы строим дачный домик, денег у нас не очень много, время тоже ограничено. Но мы хотим, чтобы домик при этом был максимально уютным.

С каждого этапа мы готовы (и должны) возвращаться на предыдущий, изменять ТЗ, дорабатывать правила, переписывать код, менять структуру проекта и данных, что-то выбрасывать, что-то добавлять и т.д. Процесс разработки превращается в хаос, которым нужно как-то управлять. Именно для этого и возникло огромное количество методик разработки, которые объединены общим названием Agile (гибкий). Все методологии — Скрам, Канбан, Экстрим Программинг — являются Agile-методиками. В чистом виде никакого Agile не бывает. Это, скорее, философия, общий подход. Сформулирован так называемый Agile-манифест

Не отрицая важности того, что справа, мы все-таки больше ценим то, что слева. Это — основополагающее. А еще сформулированы 12 принципов Agile.

Конкретных условий, «как работать», нет. По сути, Agile — это фундамент, на основе которого каждый может создать свою собственную гибкую методологию разработки. Разработчики так и поступили. Итак, какие же бывают методологии.

Lean.

Это методология выхода на рынок. Изначально разработана для производственных предприятий, но стала популярна и в стартапах. Основная цель — минимизировать потери, снизить издержки. Термин MVP — minimum viable product, минимально жизнеспособный продукт — как раз вышел из Лина. Методология говорит о том, что вы не должны создавать сразу готовый продукт целиком — потому что вы его будете писать 3 года, принесете на рынок, а рынок скажет: «Не, нам этого не надо”. “О боже мой» — скажете вы, — «я туда 10 миллионов влил». А рынок скажет — «Не волнует, выкидывай!». Как-то дорого, да? Лин говорит, что гораздо правильнее и выгоднее сначала сделать минимальный продукт. Только то, что человек захочет купить, за что проголосует рублем, то на самом деле и работает. Лин говорит о там, что вы должны показать рынку продукт , который хоть чего-то стоит. Но он никак не говорит про управление персоналом. Он говорит про выход на рынок.

Scrum.

Если немного погуглить, то мы узнаем, что скрам — это методика игры в регби. И, как ни странно, это не то, что нам нужно. Скрам — самая популярная из гибких методологий. Она позволяет решать задачи в сжатые сроки с минимальными затратами. Результат — каждые 2 недели!

Скрам-подход делит рабочий процесс на равные «спринты» — временные промежутки от недели до месяца. Каждая команда сама решает, сколько у нее длится спринт. Перед началом спринта команда решает, какие задачи сделает в этот период. Это обязательство, которое команда берет на себя. В конце каждого спринта, в идеале, должен быть какой-то результат (фича). Можно что-то не сделать, но только по очень веским причинам. Когда спринт закончен, команда обсуждает результаты, и начинается новый спринт.

Скрам скрамом делают его церемонии:

• Планирование спринта — совещание команды перед началом спринта.
• Daily Scrum или стэндап. Быстрая встреча, на которой собирается вся команда. Каждый рассказывает, что он делал вчера, что будет делать сегодня, с какими трудностями столкнулся на пути. Это нужно для того, чтобы каждый из команды понимал, как проходит процесс, знал про все, что делают другие. Позволяет выявить проблему до того, как она станет критической.
• Ретроспектива. Что пошло не так? Почему? Что сделать, чтобы стало лучше? Главное, чтобы все были заинтересованы в улучшении процесса и конечного продукта.
• Итоги спринта. Проводит Product Owner. Рассказ о том, что нового появилось в продукте за это плодотворное время.

Чем меньше церемоний соблюдается, тем хуже работает этот метод разработки.

Важно, чтобы новые задачи не добавлялись в спринт, который уже идет. Их вносят на следующий спринт. Кажется, идеальная схема, но на практике подходит не всем.

Канбан.

Здесь нет спринтов, а команда решает наиболее приоритетные задачи. Приоритеты расставляет заказчик вместе с руководителем проекта. Иногда их расставляют вместе с командой.

Для визуализации процессов в канбане используют доску, на которой располагают все задачи. Выглядит она примерно так:

Задачи в виде стикеров расположены на доске. Это позволяет очень наглядно отобразить, сколько всего у команды задач и на каком они этапе. Все видят, кто чем занят и когда задача будет наконец-то выполнена.

Бывает так, что в одном из столбцов слишком много задач. Команда в данном месте не справляется, и ей нужна помощь. В таком случае все задачи приостанавливаются, чтобы не усложнять и так сложную ситуацию. А свободные люди помогают решать задачи.

Гибкие методологии снижают бюрократию, позволяя команде самой решать поставленные задачи. Устранение посредников — та необходимая ценность, которая дает отличные результаты. В скраме нет приоритета отдельных задач, в нем главное — закончить спринт. То есть выкатить новую фичу. Это полезно, если вы делаете MVP. Канбан нужен, чтобы видеть, как загружена команда, и выполнять очень срочные задачи, которые невозможно отложить на потом.

В конце необходимо сделать важную ремарку: в этой статье я дала описание «чистых” версий скрама и канбана. В жизни же все сложнее. Почти ни одна IT-компания в мире не использует чистый скрам, а работает на сборном “Франкенштейне» из разных методик. Например, можно из канбана в скрам взять доску с задачами, но выглядеть она будет в виде спринта. И это нормально. Каждая команда сама определяет для себя методы, которые эффективно решают ее задачи. Ведь мы помним, что люди и взаимодействие важнее процессов и инструментов.