Kanban/Agile/Scrum/Lean — гибкие методологии разработки — Карина Горбунова на

Введение

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

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

Что же такое продукт и продуктовый подход? Продукт – это не товар и не услуга в общем смысле. Продукт – это то, за что готовы платить ваши клиенты. Так, продукт компании BMW, это не средство передвижения, это драйв, удовольствие за рулем, статус и безопасность.

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

Разработка любого продукт имеет свой жизненный цикл, который можно свести к следующим этапам:

Отсюда определим Модель разработки продукта, как описание того, какие стадии жизненного цикла проходит продукт и что происходит на каждой из них. А Методология разработки — это набор методов по управлению разработкой. Т.е. те правила, техники и принципы, которые позволяют делать разработку максимально эффективной.

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

Но не все знают, что получили развитие эти методы с Пути Тойоты — Dao Toyota.

Dao toyota, lean и kanban

Помимо принципов ведения бизнеса, в Toyota сформировали основные виды потерь. К потерям относится все, что не создает ценности для продукта:

Для максимальной эффективности выстраивания рабочего процесса и устранения потерь в Toyota используется метод Kanban и Lean бережливое производство. Сначала подробнее рассмотрим Lean.

Производственная система Toyota TPS представляет собой уникальный подход к производству. Именно она породила движение за бережливое производство, которое (вместе с концепцией шести сигм) стало одной из доминирующих тенденций в разработке. Однако есть мнение, что несмотря на схожесть TPS и Lean, первое – это путь конкретной компании, а Lean production – набор методов и инструментов, которые базируются на философии Toyota, но могут быть реализованы на других производствах.

Сам термин «Бережливое производство» был введен Джоном Крафчиком в 1988 г. в рамках его работы в Международной автомобильной программе Массачусетского технологического институту. Исследования Крафчика в области бережливого производство были использованы Деймсом Вомеком и Дэниелем Джонсом в книге «Бережливое производство:

Таким образом, Lean — это не методология, так как в ней нет набора готовых инструментов. Это часть философии эффективной разработки, которая вышла из философии Toyota и впоследствии стала частью философии Agile. Lean бережливое производство призвано бороться со всеми видами потерь. В основе данной философии лежат принцип вытягивания и принцип «точно в срок» (Just in Time).

Принцип вытягивания производства предполагает производство продукта только на основании требований заказчика в строго необходимом количестве. Часто для инициации процесса производства служит карточка Kanban.

Принцип «точно в срок» (Just in time) предполагает, что система планирования и организации работы компании построена так, что все необходимые элементы поступают в производственный процесс в нужный момент и в необходимом количестве. Также этот принцип предполагает бездефектное производство, так как брак может сломать всю четкую систему планирования.

К Lean бережливому производству можно отнести следующие методы организации труда и разработки:

На производстве это может быть специальное соединение деталей с пазами, которые невозможно установить как-то иначе, чем требуется. В программном обеспечении можно установить «маску» на поле, чтобы невозможно было ввести данные в формате, который может вызвать ошибку программы.

Данный метод уникален для разных отраслей. Для примера можно привести конвейер по сборке правых зеркал заднего вида, который можно оперативно переналадить на сборку левых зеркал заднего вида.

Слово Kanban имеет японское происхождение и переводится как «рекламный щит, вывеска».

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

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

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

Простой пример реализации доски Kanban представлен ниже. В общем случае каждый столбик является отдельным этапом жизненного цикла разработки.

Основные принципы:

Из этих принципов можно сформулировать и ограничения метода:

Как устроена agile-команда

Работать по методологии Agile значит отказаться от стандартных принципов управления, потому что это не способ руководства, а способ взаимодействия. Это означает, что каждый участник команды имеет равнозначные позиции относительно других. Внутри проектов распределяются роли, которые берут на себя сотрудники из разных отделов. В сфере IT самые необходимые роли в Agile-проекте — это:

При этом даже человек на должности product owner формально не является руководителем, он просто берет на себя ответственность за формулировку требований к продукту: доносит до остальной команды видение того, как должен выглядеть продукт и каким функционалом он должен обладать.

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

По методологии Agile организована работа, например, в Netflix. Огромный коллектив стримингового сервиса разделен на множество команд, и у каждого сотрудника есть своя сфера ответственности, качество которой он обеспечивает. Каждая команда сосредоточена на решении проблем в своей предметной области, но, если нужны дополнительные инструменты, общие для нескольких команд разработчиков, начинается сотрудничество.

При переходе на новую модель компании могут допустить ошибки:

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

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

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

• Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
• Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
• Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
• Готовность к изменениям во взвешивании со следованием первоначальному плану.

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

Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой — поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи.

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

Примеры scrum-практик: оценки

Здесь не будет канонического/кошерного/ванильного Scrum’а, который описан Швабером и Сазерлендом, и про который можно почитать здесь:

. Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа.

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

Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point.

Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном — она занимает 1 попугай, 1 story point.

Берется следующая задача, сравнивается с первой — она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.

Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point.

Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт.