Agile, Scrum и Kanban: что, черт возьми, на самом деле означают эти слова?

Когда разработчик программного обеспечения слышит новости о «новой среде JavaScript» или «новой IDE», ему не нужно задавать дополнительные вопросы, чтобы уточнить, о чем идет речь. Но если он услышит о «новом agile-фреймворке», он, скорее всего, кивнет в стиле Гомера-Симпсона, делая вид, что знает, о чем идет речь, но у него будет один и только один вопрос: что, черт возьми, делает «agile-фреймворк»? иметь в виду?

В современной среде разработки программного обеспечения мы все чаще слышим такие слова, как «agile», «scrum» и «kanban», и часто они используются неправильно. В этой статье я попытаюсь объяснить и прояснить некоторые из этих терминов.

Гибкий

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

«Аджайл» относится к «гибкой разработке программного обеспечения», подходу к разработке, который следует принципам гибкой разработки. Но что, черт возьми, такое «гибкие принципы»? Взгляните на Agile Manifesto и на 12 принципов Agile, которые закладывают основы гибкой разработки. Из Манифеста:

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

Но почему так важно следовать этим принципам в нашей работе?

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

Скрам

Если вы говорите о «гибких» методах, не зная, что они означают, вы можете оступиться и сказать вещи, которые раскроют вас перед собеседником, знающим предмет: «Скрам и другие гибкие методологии».

Scrum — это не методология, хотя мы все слышали, что ее так называют чаще, чем количество убийств в «Игре престолов» . Scrum не даст ответа на каждый вопрос и не предоставит вам точную процедуру реагирования на каждую ситуацию, с которой вы сталкиваетесь. И, вероятно, в результате этой неправильной интерпретации большинство реализаций схватки также ошибочны: команды не получают ценности. В результате получается, пожалуй, самое глупое утверждение о скраме: «Скрам не работает».

Что такое скрам? Руководство по Scrum определяет скрам как:

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

Скрам состоит из следующих ролей: Владелец продукта, Скрам-мастер, Команда разработки.

Также есть четыре церемонии Scrum: совещание по планированию, ежедневный Scrum, обзор спринта, ретроспектива спринта.

И три артефакта: Бэклог Продукта, Бэклог Спринта, Инкремент Продукта.

Проекты Scrum организованы в регулярные временные рамки, которые мы называем спринтами. Обычно они длятся две недели.

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

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

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

Scrum — это ценность , которая доставляется конечным пользователям. Если вы действительно используете скрам, вам нужно приносить что-то ценное каждый спринт. Ценность можно измерить, и команда также вынуждена проверять препятствия и адаптироваться, чтобы приносить больше пользы в следующей итерации.

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

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

Канбан

Когда вы говорите о схватке и канбане, из толпы часто задают вопрос: «Что лучше, скрам или канбан?» И вы не будете знать, что ответить, потому что это все равно, что сравнивать яблоки и апельсины или спрашивать: «Что лучше, блины или пиво?» Оба лучше.

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

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

Столбцы представляют состояние задачи в процессе разработки. Самый простой пример состоит из трех столбцов: «Сделать», «Выполняется» и «Готово». Таким образом, задачи добавляются в «To Do», перемещаются в «In Progress» при начале разработки и считаются «Done» при перемещении в последнюю колонку. Но, конечно, это может быть сложнее:

Бэклог → Определение спецификации → Готово к разработке → Разработка → Проверка кода → Тестирование → Развернуто (→ Никто на самом деле не использует → Полностью удалено).

Каждый столбец может иметь подстолбцы; например, «Разработка» может быть разделена на «Планирование» и «Кодирование»; «Тестирование» можно разделить на «модульное тестирование» и «интеграционное тестирование» и так далее. При необходимости колонки могут быть посвящены специалистам. Команда определяет столбцы и этапы в соответствии со своими потребностями. В соответствии с философией «вытягивания» задачи должны входить в рабочий процесс только тогда, когда на них есть немедленная потребность.

Цель этой доски — визуализировать рабочий процесс , что является первой ключевой практикой в ​​канбане. На самом деле канбан можно делать вообще без доски! Это может быть простой список задач в листе Google с разными цветами фона, указывающими на состояние задачи, или это могут быть диаграммы Ганта, диаграммы, таблицы… Это может быть даже набор сегментов в вашем офисе, где каждый представляет состояние задачи, и где мячи используются в качестве задач. Просто визуализируйте рабочий процесс и обеспечьте прозрачность всего процесса.

Другой важный принцип заключается в том, чтобы уменьшить размер пакета ваших усилий . Упрощенно это означает избегать многозадачности. Это может означать сокращение объема задач, над которыми вы работаете одновременно. Если у вас в команде три дизайнера, команда может установить максимальное количество задач в столбце «Проектирование» равным трем.

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

Что я должен использовать?

Скрам и канбан не исключают друг друга и на самом деле не сопоставимы. В скраме есть определенные роли, в то время как канбан говорит: «Какого черта, сохраните свои текущие роли и обязанности». Scrum заставит вас изменить способ работы; Канбан позволяет вам начать с существующего процесса. В скраме четкий график событий прописывается фреймворком; в канбане нет событий. Тем не менее, у них много общего: оба ориентированы на ценность, членов команды уважают как «боссов» системы, и, по сути, у них одна и та же миссия: постоянно устранять потери и устранять препятствия.

Но вопрос: «Что мне использовать в моем конкретном проекте и с моей конкретной командой?» имеет гораздо больше смысла. Канбан не требует значительных изменений процесса и культуры, и в большинстве случаев его легче внедрить, чем скрам. Scrum, с другой стороны, предлагает значительно больше структур для управления процессом, что может устранить большую часть накладных расходов, пока все находятся на одной странице.

Но прелесть обоих в том, что ни один из них не является строгим набором правил. Ничто не мешает вам выбирать лучшие элементы scrum для вас, такие как ежедневная встреча или обзор. И нет никаких причин, по которым вы не можете внедрить канбан-доску в скрам.

Скрам зарекомендовал себя как очень эффективная структура, когда вся команда хорошо ее понимает. Однако, по моему опыту, мне трудно работать в схватке с некоторыми клиентами. Процесс и культурные изменения, необходимые для правильной реализации Scrum, могут быть слишком большими (особенно когда имеешь дело с кем-то, кто считает, что создает новый Google!). С другой стороны, канбан более гибок и не заставляет людей меняться. Некоторые авторы также говорят, что канбан — это хороший путь к гибкости и предлагает более легкое внедрение схватки. Другие говорят, что использование схватки должно в конечном итоге привести к канбану.

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