Kanban scrum: Разбираемся в Scrum и Kanban

Что такое agile, scrum, kanban и в чем разница?

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

---

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.

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

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

(Из перевода колонки Forbes на Rusbase)

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет.

Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты.

И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский Директор по технологии в онлайн-кинотеатре ivi

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

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Что почитать по теме?

1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
5. K. Schwaber, J. Sutherland “The Scrum Guide”
6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Cover photo by Daria Nepriakhina on Unsplash

что лучше использовать для планирования проекта?

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

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

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

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

Методологии управления проектами дают командам необходимую структуру, которая служит основой для планирования проекта. У каждой из этих методологий есть свои преимущества и недостатки, но две из них позволяют легко представить план проекта в наглядном виде.

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

Что такое скрам-доска?

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

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

За:

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

Против:

• Это итеративная методология, и она требует постоянной обратной связи от участников команды для улучшения процесса.
• Процесс требует высокого уровня доверия внутри команды. Слишком строгое управление может привести к срыву всего проекта.
• Участнику команды может быть сложно уйти во время процесса.
• Если нет жесткого срока, может произойти бесконтрольное расширение работ по проекту.
• Отсутствие прогнозируемых временных рамок и оценки затрат может привести к тому, что понадобится несколько спринтов.
• На участников команды оказывается сильное давление, и им приходится тратить много времени на разработку проекта.

Вы уверены, что скрам вам подойдет? Создайте скрам-доску в Wrike совершенно бесплатно.

Что такое канбан-доска?

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

«Канбан дополняет существующие организационные процессы, постоянно улучшая их, и при этом не меняет полностью системы, которые уже используются в организации», — говорит Джо Гарнер, менеджер проектов в Computer Design & Integration LLC.

Обычно канбан предусматривает применение лекционной доски, на которой перечислены статусы, такие как «Запланировано», «В работе», «На проверке» и т. д. Затем на стикере записываются названия отчетных материалов и размещаются под соответствующими статусами. Когда отчетный материал изменяет свой статус, стикер перемещается по доске с указанными статусами.

За:

• Эта методология часто помогает ускорить работу над проектами, «застрявшими» на этапе выполнения.
• Она отлично подходит для разделения работ по исполнителям.
• Идеальна для создания отчетных материалов, для которых очень важен статус.
• Ее можно внедрить где угодно.
• Рабочая загрузка прозрачна, и ее можно легко изменять (особенно при помощи функции перетаскивания в Wrike).
• Вы можете легко проверить и оценить производительность участников команды.

Против:

• Из-за отсутствия временных ограничений отчетные материалы могут создаваться медленнее.
• Устаревшие данные на канбан-доске могут снизить продуктивность.
• Если вы используете традиционную лекционную доску, трудно отразить текущую работу и процессы на доске.

Не рискуйте, составляя план проекта на лекционной доске. Попробуйте бесплатную версию Wrike, чтобы быть уверенными в доступности (и сохранности) всех ваших планов.

Какая из досок удобнее для планирования проекта?

Ответ на этот вопрос зависит от типа проекта. Вот несколько выводов:

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

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

Теперь, когда вы выбрали правильную методологию, узнайте, как составить план проекта.

Kanban и Scrum: в чем разница и что лучше?

Kanban и Scrum. Непривычные слова, которые в последнее время все чаще звучат в нашем окружении. Что они означают? На самом деле это две разные системы управления проектами в методике Agile. Какая из них подойдет для вашего проекта? Может быть, использовать обе? Сложно и непонятно, но ничего, сейчас разберемся.

Для начала давайте выясним, что вообще они из себя представляют.  

Kanban

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

История Kanban

Kanban как методика была разработана Тайити Оно (Taiichi Ohno) во время его работы в Toyota и направлена на бережливое производство. Сам термин «канбан» –  это комбинация двух японских слов: 看 (Kàn), означающего «знак», и 板 (Bǎn), означающего «доска». Первоначально система Kanban Оно использовала бумажные карточки для отслеживания спроса на заводе Toyota. В основе организации процесса лежал годовой план, вместо угадывания спроса в ход шли прогнозированные месячные и оперативные планы выпуска для каждого подразделения, а также конкретные лимиты на каждом этапе создания.  

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

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

Классическая канбан-доска

Канбан-доски – одна из самых популярных форм визуального управления проектами, эффективная для обеспечения простого и быстрого анализа проекта. За несколько десятилетий существования методика, разработанная Тайити Оно, была оцифрована, адаптирована и усовершенствована, чтобы стать той гибкой системой управления проектами, которую мы знаем сегодня. По своей сути современный Kanban – это онлайн-визуальный метод управления работой.

А так, например, сегодня канбан-доска выглядит в Asana

Преимущества канбан-досок

Из-за своей эффективности в визуализации работы канбан-доски являются ключевым компонентом большинства инструментов управления проектами онлайн.  

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

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

Scrum

Scrum, как и Kanban, представляет собой систему для совместной и высокоэффективной работы. В отличие от Kanban, который основан в основном на визуальной форме управления проектами, Scrum представляет собой полноценный фреймворк.  

История Scrum

Термин Scrum означает «схватка» и пришел из регби. В сфере организации рабочего процесса его использовали Хиротака Такеучи (Hirotaka Takeuchi) и Икудзиро Нонака (Ikujiro Nonaka) в 1986 году в статье для Harvard Business Review «Игра для разработки новых продуктов». 

Вот цитата из этой статьи:

«Компании понимают, что старый последовательный подход к разработке новых продуктов больше не работает. Вместо этого компании в Японии и США используют целостный метод – как и в регби, мяч передается внутри команды, когда она движется по полю как единое целое».

Затем, в 1995 году, Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) опубликовали процесс разработки Scrum, в котором они изложили его методы и принципы. Позднее Швабер и Сазерленд продолжили исследование и уточнение своей методологии, которая приняла окончательную форму в Scrum Guide – живом документе, который они регулярно обновляют. Scrum Guide определяет Scrum не как процесс, технику или окончательный метод, а как структуру, в которой вы можете использовать различные процессы и методы. По словам Швабера и Сазерленда, Scrum помогает командам постоянно улучшать свой продукт, свою команду и общую рабочую среду. Scrum побуждает команды взглянуть на то, насколько эффективны их методы работы, и заставляет развивать и улучшать их.

В офисе команды, использующей Scrum, вполне может висеть подобный листок-памятка

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

Три фазы Scrum

Фаза 1: планирование спринта

Спринт Scrum (также известный как «время цикла» Scrum) обычно длится 2 недели, хотя команды могут работать быстрее. На этапе планирования спринта скрам-мастер и команда изучают объем невыполненных заданий команды и выбирают работу, которую нужно выполнить во время спринта.

Фаза 2: ежедневные встречи по Scrum

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

Фаза 3: ретроспектива спринта

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

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

Преимущества Scrum

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

В Scrum уровень встроенной приоритизации сочетается с четко определенными обязанностями. Таким образом у вашей команды есть заранее установленный и ограниченный объем работы и количество времени для каждого спринта.

Подождите, а что такое Agile?

В статье мы неоднократно использовали термин Agile, но так и не рассказали, что это вообще такое. Сейчас расскажем!

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

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

Не обязательно следовать только одному методу

Разница между Kanban и Scrum

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

Scrum более структурирован, чем Kanban

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

Scrum ограничен по времени

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

Фактически, для команд, которые запускают Scrum на Kanban-досках (или, как их называют в таком случае, Scrum-досках), часто создаются новые доски для каждого спринта. Этому есть две причины. Во первых, команды, которые создают новые доски для каждого спринта, могут начать с чистого листа. Это упрощает для скрам-мастера и всей команды визуализацию работы, которую они должны выполнять для каждого спринта.

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

В отличие от Scrum, у Kanban-досок не всегда бывает дата начала или окончания. Фактически, доски Kanban удобнее использовать для представления текущих процессов: благодаря их гибкости они отлично подходят для управления процессами или творческими запросами без каких-либо конкретных временных рамок.

Столбцы на канбан-доске можно организовывать по-разному

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

Но если вы используете только Kanban, столбцы доски могут быть разнообразными. Например, вы можете создать канбан-доску со столбцами для каждого члена вашей команды, чтобы отслеживать выполняемую ими работу. Или вот другой пример: на канбан-доске могут находиться столбцы, представляющие работу, которая будет выполняться каждый месяц. Словом, столбцы на доске могут быть любыми – в отличие от Scrum, в котором есть более определенные правила.

И Kanban, и Scrum побуждают команды к постоянному совершенствованию

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

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

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

И Kanban, и Scrum могут помочь членам команды сплотиться

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

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

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

Когда использовать Kanban

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

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

При этом даже если вы решите не запускать Scrum, вы все равно можете черпать из него вдохновение. Например, необязательно ограничивать работу спринтами, но сохранение невыполненных задач поможет вашей команде лучше понять задачи и расставить приоритеты. Главный плюс Kanban – вы можете выбрать то, что вам подходит, и выбросить все остальное.

Когда использовать Scrum

Scrum может стать хорошим вариантом расставить приоритеты для всего процесса. Хотя не каждая команда преуспевает в Scrum, вы можете извлечь выгоду из него, если:

• Вы работаете в команде разработчиков продуктов, программного обеспечения или Agile-команде.
• Вам кажется, что ваша команда может выиграть от чуть более жесткой структуры.
• У вас большой объем незавершенной работы.
• Ваша команда мотивирована быстрыми сроками и результатами.
• Кто-то из вашей команды стремится стать скрам-мастером.

Помните: вы всегда можете запустить Scrum на доске Kanban. Чтобы проводить эффективные ежедневные стендап-встречи и ретроспективы спринтов, вам нужен надежный способ визуализации работы по этапам и отслеживания всей вашей незавершенной работы. Канбан-доски могут помочь вам справиться с отставанием в спринте и организовать поток работы во время спринта, чтобы каждый цикл Scrum был успешным.

Kanban против Scrum: что лучше?

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

Однако если вы ищете инструмент, который должен помочь вашей компании в управлении, то лучше выбирать тот, который позволяет просматривать ход работ разными способами. Например, в Asana вариант визуализации «канбан-доска» – это один из четырех способов просмотра работы в дополнение к временной шкале, календарю и списку.

Неважно, используете ли вы Scrum или Kanban-фреймворк – главное, убедитесь, что ваша система управления работой достаточно гибкая, чтобы вы могли выполнять свою работу максимально эффективно.

Как совмещать Scrum и Kanban на практике?

Статья отображается на оригинальном языке.

Scrum framework — легкий процессный фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем. Согласно ежегодному отчёту от State of Agile™ Survey — это самый популярный способ делать Agile. Руководство по Скраму (Scrum Guide) находиться в свободном доступе и его можно почитать/скачать тут.

Kanban Method — метод эволюционных изменений. Был задуман авторами, как альтернативный путь к гибкости — как способ повышения отзывчивости и адаптируемости без какой-либо существенной революции или реорганизации в вашем текущем подходе к работе или политической структуре вашего бизнеса. Официальное руководство по Kanban Method от Kanban University доступно тут.

Последние 11 лет я активно работаю с командами, суммарно за это время примерил на себя 20+ разных ролей в трёх больших компаниях. Практический опыт получилось насобирать от классического менеджера в организационной культуре Контроля до загадочной, до сих пор, для многих в IT, роли Scrum-мастера на несколько команд, в культуре Сотрудничества и Agile.
Сейчас я работаю в роли Scrum-мастера в компании Creatio (Terrasoft) и параллельно уже больше года в роли Agile Coach в компании Scrum Ukraine — провожу обучение и консалтинг по использованию Scrum и Kanban в крупных компаниях.

Работая в разных контекстах с разными людьми, командами, руководителями, стейкхолдерами я немного разобрался с тем, что такое команды, на самом деле. И чем успешные команды отличаются от тех, у которых не очень получается работать вместе, или тех, которые не являются командами вовсе. Работая по Scrum и применяя Kanban-метод, могу с уверенностью сказать, что эти подходы облегчают работу “команд”, фокусируют на важном и при правильном применений обеспечивают высокую эффективность и мотивацию участников. Scrum и Kanban отлично могут уживаться вместе и это не внезапная новость. Есть даже книги описывающие эти комбинации и им не один год, например:
— Corey Ladas — Scrumban: Essays on Kanban Systems for Lean Software Development (2008)
— Ajay Reddy — Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series) (2015)
А организация Scrum.org недавно выпустила Канбан-гайд для скрам команд (Kanban Guide for Scrum Teams), его можно скачать тут.

У меня нет цели пересказывать приведенные выше источники, я поделюсь некоторыми своими кейсами и примерами использования разных подходов. Интересный случай в моей практике был, когда еще в 2015-2016 годах, в течение десятков ретроспектив большой Agile-командой разработки (15-17 человек), мы формализовали отдельные элементы Scrum под себя. Параллельно каждый спринт я собирал десятки разных метрик описывающих происходящее в команде с позиции цифр. Было практично и многообразно.

Как оказалось позже, спустя 2-3 года на сертификации по Kanban (KSD+KMP), все эти инициативы и способы до которых мы догадывались экспериментируя, системно описывает Kanban-метод. Другими словами, то что мы годами называли в команде Scrum’ом оказалось одной из интерпретаций Kanban’а. У меня был приятный шок, мне кажется, я что-то понял в тот момент про суть Канбан-метода. Особенно круто было проверить на своих цифрах подход #NoEstimates, суть которого в отказе от оценок вовсе, как лишней потери времени и усилий оценщиков. Концептуально, за счёт чего можно отказаться от оценок задач, я описал в своей прошлогодней статье.

Осознанный и зрелый Scrum я увидел не так давно, в 2017 году. Тогда, всё сошлось, я прошёл две сертификации (CSPO+CSM) и сразу после этого начал работать в большой продуктовой компании Creatio (Terrasoft) full-time Scrum-мастером сразу в трёх командах. До этого этапа мне встречались лишь отдельные элементы, ивенты, эксперименты, подходы в Scrum-духе и Agile окружении. Тут же я увидел масштабный Scrum, много команд одновременно синхронно и асинхронно работающих над одним продуктом, как часы. У меня появилась возможность быть частью этого сонаправленного движения.

Последние 3.5 года я активно экспериментировал работая в Scrum, в том числе используя Kanban, когда у тебя три команды и каждых две недели происходит три спринта, есть где разгуляться в этом плане. Без моих волшебных Scrum-команд, я бы конечно не справился в одиночку, спасибо им за терпение и поддержку, а моему руководителю и стейкхолдерам за создание возможности этим инициативам случаться 🙂
Мы перепробовали действительно многое: сотни форматов ретро, передизайн внутренних процессов, упрощения и исключения потерь на разных этапах, точечные экспресс-обучения и комплексные тренинги/воркшопы по разным темам, попытки научиться смотреть на систему целиком (System Thinking), ежегодные Futurespective, сессии открытых фидбеков внутри команды, пост-оценивание задач, всевозможные вариации визуализаций, физические и виртуальные доски, определение критериев Advanced Agile команды и т.д.

Когда я пришел работать в Terrasoft (Creatio) в 2017 году, Agile-трансформация уже три года как произошла, Scrum-революция случилась. Все, в большинстве, уже знали что и как делать, зачем нужен тот или другой артефакт, как проводить ивенты, вести роадмап или бэклог, запускать спринты. В первую очередь из-за поддержки, вовлечённости и осознанности в Agile/Scrum руководства на мега-высоком уровне. Помню, кто-то сказал мне тогда из коллег: “Мы не играемся со Scrum’ом — мы так работаем. Это наши правила взаимодействия внутри и между командами.”
Вызов для меня состоял не в революции, а в выстраивании самоорганизованных и зрелых кроссфункциональных фиче-команд для работы в долгую: мы были и есть в фазе Continuous Improvement (Непрерывное совершенствование). Нам нужно было искать способы и подходы для эволюционных изменений. Я начал изучать разные варианты, среди которых были XP, Teal, Kaizen, Kanban, в итоге остановился на последнем, как самом подходящем в моём случае.

Kanban-метод — для меня открылся в первую очередь, как набор из десятков разнообразных идей, принципов, инструментов, потокоориентированости, WiP-лимитов, метрик, графиков, классификаций, которые помогают не останавливаться в развитии процессов и организации в целом. Канбан не требует революций — пользу можно получать сразу, путём маленьких, но регулярных улучшений. Канбан разделяет сервисную парадигму — а это значит что любую Scrum-команду или группу команд, которые делают общий продукт, можно рассматривать как некий сервис, который имеет границы, у которого есть заказчики и есть получатели ценности, которую сервис производит. У такого сервиса есть точка принятия обязательств и точка поставки, а Канбан-метод в свою очередь применяется как способ улучшения качества обслуживания этого сервиса. Это главная идея — всё остальное манёвры.

По сути, Kanban не внедряют, а применяют к процессу, который уже есть. Существует даже правило в сообществе Канбан-практиков, суть которого звучит приблизительно так: “Первое правило настоящего Канбаниста не произносить слово Канбан”. Почему это правило может пригодиться? Дело в том, что у людей с которыми вы работаете, может отличаться восприятие термина “канбан” и вы сможете столкнуться с сопротивлением или пониманием по-своему, еще до начала каких либо действий. Можно использовать отдельные техники и метрики и они будут приносить пользу команде.

Работая с любым уже существующим процессом вы можете применять Канбан-метод, даже если этот процесс организован по Scrum. В самом Scrum фреймворке уже заложены идеи из Kanban-метода, и наоборот. Просто эти идеи описаны или существуют не для всех в явном виде. Приведу примеры: один продукт для одной команды — чем не WiP limit = 1 для кол-ва продуктов над которыми работает команда в один момент времени? Или как формируется Sprint Backlog из Product Backlog — чем не вытягивающий принцип Kanban, который используют в Scrum? Definition of Done — чем не формализация для однозначного понимания пересечения точки поставки? Непрерывный процесс Product Backlog Refinement (PBR) — микс UpStream и DownStream только явно не прописанный в Scrum Guide? И т.д. и т.п.

Про практики и примеры такого осознанного применения Kanban-метода в рамках Scrum’а я буду рассказывать на нашем вебинаре.

Ссылка на Miro-доску с вебинара

Различия и сходства между методологиями Kanban и Scrum

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

Канбан и Скрам — сходства

Сходство между Kanban и Scrum:

• Оба являются Agile.
• Оба используют планирование вытягивания.
• Оба ограничивают WIP, Kanban на уровне задач и Scrum на уровне спринта.
• Обе используют прозрачность в процессе разработки.
• Оба сосредоточены на выпуске освобождаемого программного обеспечения на раннем этапе.
• Оба основаны на самоорганизующихся командах.
• Оба требуют разбить работу на части.
• В обоих методах план выпуска постоянно оптимизируется на основе эмпирических данных (Scrum — Velocity, Kanban — Lead Time / Cycle Time).

Канбан и Скрам — отличия

Различия между Kanban и Scrum заключаются в следующем:

№	Scrum	Kanban
1	Scrum предписывает роли.	В Kanban роли необязательны.
2	Отставание продукта должно быть приоритетным.	Приоритизация является необязательной.
3	Спринт должен быть коробочным. Вы можете выбрать длину спринта, но, как только он будет выбран, для всех спринтов будет сохранена одинаковая длина.	Время-боксированные итерации являются необязательными.
4	Команде Scrum необходимо зафиксировать определенный объем работы для спринта.	Обязательство не является обязательным.
5	Назначены межфункциональные команды.	Кросс-функциональные команды являются необязательными. Разрешены специальные команды.
6	Использует скорость в качестве показателя по умолчанию для планирования и улучшения процесса.	Использует время выполнения (время цикла) в качестве показателя по умолчанию для планирования и улучшения процесса.
7	Элементы, такие как истории, тесты должны быть разбиты так, чтобы они могли быть выполнены в пределах одного спринта.	Никакого определенного размера предмета не предписывается.
8	Спринт показывает, какие задачи должны выполняться во время текущего спринта. Эти задачи отображаются на плате Scrum. Область спринта фиксирована. WIP ограничен за единицу времени (WIP-предел — скорость).	Задачи определяются на уровне рабочего процесса. WIP ограничен для каждого состояния рабочего процесса.
9	Дополнения / изменения не могут быть выполнены в спринте.	Дополнения / изменения могут быть выполнены, если лимит WIP не пересек.
10	Новая доска Scrum устанавливается в начале каждого спринта.	Доска Канбана постоянна.
11	Необходимо проводить ежедневные встречи.	Ежедневные встречи не являются обязательными.
12	Предписываются графики выгорания.	Никакой конкретной карты не предписывается.

Kanban vs. Scrum

Следующие преимущества могут помочь вам выбрать между Kanban и Scrum:

• Вам нужно выбрать Kanban, если у вас уже есть рабочие процессы, и вы хотите улучшить, не нарушая всю систему, тогда как вам нужно выбрать Scrum, если вы хотите внедрить новый процесс в организации.
• Вы можете использовать Kanban в разработке продукта с Feature Driven Development для отслеживания рабочих потоков в потоке создания ценности, тогда как Scrum можно использовать для разработки на каждой итерации.
• Вам нужно определить границы WIP в Kanban явно, тогда как вам нужно определить длину спринта в схватке, которая подразумевает ограничения WIP.
• И Kanban и Scrum адаптивны, но Scrum более предписывающий, чем Kanban.
• Канбан накладывает только два правила: визуализировать рабочий процесс и ограничивать WIP, тогда как Scrum накладывает больше ограничений, таких как спринты с отложенными по времени спринтами.
• Канбан ведет к совершенствованию организационного процесса, как в области управления, так и развития. Kanban также поддерживает операции по техническому обслуживанию. Scrum приводит к высокой пропускной способности в небольших командах разработчиков. Это не способствует развитию рабочих процессов разработки и сопровождения, которые более продолжительны с непредсказуемостью по размеру рабочих единиц и изменениями. Scrum не делает акцент на оптимизации управленческой деятельности.
• В Kanban вы можете выбрать, когда делать планирование, улучшение процесса и выпуск. Вы можете выполнять эти действия регулярно или по требованию. Итерация Scrum — это один единственный спринт Sprint, объединяющий три различных вида деятельности: планирование, улучшение процесса и выпуск (если требуется).

Таким образом, Kanban и Scrum являются эффективными инструментами в их конкретных контекстах. Вы можете комбинировать Kanban и Scrum для получения максимальной выгоды от обоих.

Адаптация Kanban и Scrum вместе

Вы можете использовать Kanban и Scrum вместе, реализуя те характеристики, которые будут соответствовать вашим потребностям. Перед тем, как приспособиться к ним, необходимо рассмотреть их ограничения. Например, Scrum требует Time-boxed Sprints, и если вы покончите с ними, вы не можете сказать, что реализовали Scrum. Оба дают вам базовый набор ограничений для управления собственным улучшением процесса.

Kanban против scrum | JIRA

Раскройте ключевые моменты при выборе между scrum или kanban, и что делать, если вы не можете решить.

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

Легко указать на различия между практиками scrum и kanban, но только на поверхностном уровне. Хотя практики отличаются, принципы в основном одинаковы. Оба фреймвока помогут вам создавать лучшие продукты (и услуги) с меньшим количеством головной боли.

ТВИИТ:

Не спрашивайте: «kanban против scrum». Вместо этого спросите «kanban или scrum» или даже «kanban и scrum». Используйте больше принципов, чем практики.

Итак, где мы были?

 

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

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

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

	Scrum	Kanban
Ритм	Регулярные спринты с фиксированной длиной (например, 2 недели)	Непрерывный поток
Методология релиза	В конце каждого спринта	Непрерывное предоставление
Роли	Владелец продукта, мастер Scrum, команда разработчиков	Не требует ролей
Ключевые метрики	Скорость	Время управления, время цикла, WIP
Философия изменений	Команды не должны вносить изменения во время спринта.	Изменения могут произойти в любое время

Scrum: структурированный Agile подход

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

Ритм Scrum

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

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

Методология релиза

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

Scrum роли

Scrum имеет три четко определенные роли.

• Владелец продукта отстаивает интересы клиента, управляет списком необходимых требований (backlog) продукта и помогает расставить приоритеты в работе, проделанной командой разработчиков.
• Scrum -мастер помогает команде оставаться основанной на принципах scrum.
• Команда разработчиков выбирает работу, которая должна быть выполнена, предоставляет приращения и демонстрирует коллективную ответственность.

Кто управляет командой Scrum? Ну никто. Scrum-команды самоорганизуются, и все равны, несмотря на разные обязанности. Команда объединена целью предоставления значимости для клиентов.

Ключевые метрики

Скорость — количество сюжетных точек, выполненных в спринте, — является центральной метрикой для scrum-команд. Он определяет будущие обязательства по спринту или объем работы, выполняемой командой Scrum в будущих спринтах. Если команда набирает в среднем 35 сюжетных точек за спринт (скорость = 35), то она не согласится на список необходимых требований (backlog) в спринте, содержащий 45 точек.

Изменение философии

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

Для получения дополнительной информации о методологиях Scrum см. Что такое Scrum?

Kanban: постоянное совершенствование, гибкие процессы

Kanban помогает визуализировать вашу работу, лимитирует работу в процессе выполнения (WIP) и быстро переводит работу с «Выполнение» на «Готово».

ВИДЕО

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

Ритм Kanban

Kanban основан на непрерывной структуре рабочего процесса, которая позволяет командам быть гибкими и готовыми адаптироваться к меняющимся приоритетам. Рабочие элементы, представленные в виде карточек, организованы на доске kanban, где они переходят от одного этапа рабочего процесса (столбца) к следующему.

Распространенными этапами рабочего процесса являются «Выполнение», «Выполняется», «Рассматривается», «Заблокировано» и «Готово». Но это скучно.

Лучшая часть Kanban — это создание пользовательских столбцов для работы вашей команды. Моя команда отправляет контент, поэтому наши столбцы (упрощенно) переходят от «Список необходимых требований (backlog)», к «Приоритету», к «Готовому плану», к «Написанию», «Проектированию», «Техническому обзору» и «Предоставлению». Наша доска помогла нам узнать, что мы отправляем около одного контента в неделю, и где есть наши узкие места (глядя на вас Технический обзор!).

Методология релиза

В kanban обновления выпускаются всякий раз, когда они готовы, без регулярного графика или заранее определенных сроков.

Теоретически, kanban не предписывает фиксированное время для предоставления задачи. Если задача будет выполнена раньше (или позже), ее можно будет выпустить по мере необходимости, не дожидаясь этапа релиза, такого как обзор спринта.

Роли Kanban

Вся команда владеет доской kanban. Некоторые команды привлекают Agile тренера, но, в отличие от scrum, не существует ни одного «мастера kanban», который бы поддерживал все в порядке. Коллективная ответственность всей команды — сотрудничать и выполнять задачи на доске.

Ключевые метрики

Время выполнения и время цикла являются важными метриками для команд kanban. Сделка со средним количеством времени, которое требуется для выполнения задачи от начала до конца. Улучшение времени цикла указывает на успех kanban-команд.

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

Еще один способ устранения узких мест — использование лимитов работы в процессе (WIP). Лимит WIP ограничивает количество карточек, которые могут быть в одном столбце одновременно. Когда вы достигнете своего лимита WIP, инструмент, такой как Jira Software, закроет этот столбец, и команда начнет разбираться в этих элементах, чтобы продвинуть их вперед.

Изменение философии

Рабочий процесс kanban может измениться в любое время. Новые рабочие элементы могут быть добавлены в список необходимых требований (backlog), а существующие карточки могут быть заблокированы или удалены все в зависимости от приоритетов. Кроме того, в случае изменения способностей команды можно повторно откалибровать лимит WIP и соответствующим образом настроить рабочие элементы. Это все о гибкости (flexible) в kanban.

Для получения дополнительной информации о методологиях kanban см. Что такое kanban?

Scrum инструменты против kanban инструментов

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

Как только вы настроитесь на принципы scrum и будете довольны структурой scrum, пришло время найти инструмент scrum, который хорошо вам подходит. То же самое касается kanban. Мы предвзяты, но, как инструмент разработки программного обеспечения номер 1, используемый Agile командами, мы считаем, что программное обеспечение Jira подойдет вам.

Kanban против Scrum: Что делать, если вы не можете выбрать?

Scrum и kanban являются «гибкими (Agile ) по книгам». Они работают в проверенной и истинной манере, с которой, честно говоря, трудно спорить. Заимствуя из другой знаменитой ключевой фразы, вы можете сказать, что «никто не становится уволенным за выбор scrum».

Но ваше решение не должно быть таким черным и белым. Сотни команд используют гибридные модели, на которые влияют как scrum так и kanban. Мы решили помочь командам сделать это в программном обеспечении Jira и недавно выпустили проекты следующего поколения.

Проекты следующего поколения позволяют командам выбирать Agile функции, которые имеют для них смысл; будь то scrum, kanban или смесь того и другого. Вместо реализации одного подхода в первый день, проекты следующего поколения позволяют постепенно использовать все более и более мощные функции по мере того, как вы узнаете, что работает для вашей команды (а что нет).

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

Независимо от того, что вы выберете, придерживайтесь его некоторое время. Возьмите всю работу сделанную из списка необходимых требований (backlog), сделанную полностью, а затем спросите свою команду, что прошло хорошо, а что — плохо. Пробуя scrum и kanban и задавая эти вопросы, вы на пути к гибкому (Agile ) блаженству.

По материалам Agile Coach «Kanban vs. Scrum»

метод Канбан для Скрам-команд 💎 — OnAgile Consulting

Ключевые идеи из «Руководства по использованию Канбан для Скрам-команд» от Scrum.Org

Зачем создали это руководство

Созданное руководство не заменяет и не уменьшает значимости никакой из частей руководства по Cкраму. Оно создано с тем, чтобы предложить инструменты для скрам-команды, открывающие дополнительные пути оптимизации их процесса.

Канбан фокусируется на оптимизации рабочего потока поставки ценности (Value Delivery Workflow) через визуализацию, ограничение количества незавершенной работы (Work in Progress) и использование pull-принципа в управлении потоком.

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

Поток поставки ценности

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

• Где начинается работа и где она полностью заканчивается (старт-финиш)?
• Что такое единица работы (для скрам-команд это, как правило, элемент бэклога продукта, PBI)?
• Какие активности происходят с единицами работы на пути от старта до финиша?
• Какие правила перехода единицы работы из одного состояния в другое?
• Как можно ограничить количество незавершенной работы, и на чем это ограничение основывается?
• Различаются ли единицы работы с точки зрения ожиданий (владельца продукта, заинтересованных лиц, клиентов, заказчика) по времени их реализации? Если да, то какие виды работ команда будет выполнять и какие прогнозы давать по каждому из них?

Практики Канбана

Для оптимизации рабочего потока поставки ценности скрам-команда использует следующие практики:

• Визуализацию рабочего потока;
• Ограничение количества незавершенной работы;
• Активное управление незавершенной работой;
• Инспекция и адаптация определения рабочего потока.

Визуализация рабочего потока

Визуализируйте не только базовые активности «To Do — In Progress — Done», а все без исключения работы в потоке поставки ценности, включая проектирование продукта и наполнение бэклога продукта. Визуализируйте также и фазы ожидания следующего этапа. Это сделает заметными для команды образуемые очереди и, следовательно, простои. Выделяйте заблокированные работы особым образом, чтобы не пропустить их во время ежедневного скрама. Все это позволит вывести понимание текущего процесса и его недостатков на новый уровень, а также стимулировать процессные улучшения прямо по ходу работы в спринте.

Ограничение количества незавершенной работы (Work in Progress)

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

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

Суть ограничения количества незавершенной работы сводится к управлению эффективностью всего потока поставки ценности, а не отдельных его частей (субоптимизация может негативно влиять на эффективность работы всей системы в целом). Ограничения подбираются командой эмпирическим путем, на основе анализа таких метрик, как Cycle/Lead Time, Throughput (см. ниже).

Активное управление незавершенной работой

Активное управление незавершенной работой включает:

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

Инспекция и адаптация рабочего потока

Руководство по Cкраму содержит минимальный набор предписаний для организации рабочего процесса, а также инструкций для определения специфичных для каждого контекста правил (например, Definition of Done, которое создает скрам-команда).

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

Метрики и аналитика

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

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

Скрам и его события вместе с рабочим потоком

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

Метрики рабочего потока могут помогать команде в формировании прогноза на следующий спринт.

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

Во время ревью спринта команда может дополнить знания о своей скорости (Velocity) полученными метриками о времени цикла (Cycle Time) и пропускной способности (Throughput) рабочего потока для обсуждения и адаптации дальнейших продуктовых планов и стратегии.

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

Источник находится по ссылке: https://www.scrum.org/resources/kanban-guide-scrum-teams.

Scrum против. Канбан: узнай разницу

Что такое Scrum?

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

Что такое Канбан?

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

Зачем нужен Scrum?

Методология

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

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

Зачем нужен Канбан?

Методология

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

Когда использовать Scrum?

Методология

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

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

Когда использовать Канбан?

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

Канбан-доски

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

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

Процесс Scrum

Процесс Scrum побуждает членов команды оценивать, что работает, а что нет. Общение — важная часть процесса схватки. Это осуществляется посредством встреч под названием Events . События Scrum включают:

Ежедневный Scrum:

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

Совещание по планированию спринта

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

Ретроспектива спринта

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

Канбан-процесс

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

Четыре принципа метода Канбан представлены ниже:

1.Визуализировать работу

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

2. Ограничить незавершенное производство

Это позволяет членам команды сократить время, затрачиваемое элементом на перемещение по системе Канбан.

3. Ориентация на расход

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

4. Постоянное совершенствование

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

Scrum против Канбан

Скрам	Канбан
Scrum делает упор на планирование . Он начинается с планирования спринта и заканчивается ретроспективой спринта.Проводится много встреч, которые помогают убедиться, что команда придерживается следующих шагов, приоритетов и уроков предыдущих спринтов.	Канбан открыт для внесения изменений на ходу. Значит жесткости меньше и вещи могут часто меняться .
Рекомендуется сбор измерений времени , выполненных во время спринтов	Канбан рекомендует графики , чтобы получить обзор прогресса команды с течением времени.
Scrum больше не требует обязательств от команд.Вместо этого речь идет о целях и прогнозах спринта.	Канбан полагается на временные рамки и прогнозирует .
Он делает упор на планирование, поэтому оценка играет очень важную роль в Scrum	Канбан не имеет обязательных требований для оценки.
Каждый человек имеет свою роль и обязанности.	№ устанавливает роли, поэтому гибкость с точки зрения индивидуальных обязанностей.
Продолжительность итераций / спринтов фиксирована. Эта продолжительность варьируется от 2 недель до 1 месяца.	Канбан — это , не основанный на продолжительности . Это измеряется относительно продолжительности цикла.
Команды должны выполнить определенного объема работы.	Обязательство не требуется Необязательно для команд.
В этом методе важны межфункциональные группы , поскольку они могут справиться с любыми сбоями, которые могут вызвать узкое место в разработке программного обеспечения.	Наличие специализированной команды важно.
Невозможно добавить элементы к текущим итерациям.	Новые позиции могут легко добавить , если имеется дополнительная емкость.
Бэклог спринта принадлежит только одной команде .	Несколько команд могут использовать доску Канбан.
Результатами являются , определяемые спринтами , которые должны быть выполнены и готовы к рассмотрению.	Продукты и процессы поставляются непрерывно по мере необходимости. Таким образом, процесс тестирования и проверки идет одновременно.
Метод разработки программного обеспечения Scrum фокусируется на отставании .	Канбан-метод полностью фокусируется на информационной панели процесса .
Каждый член команды имеет определенную роль в Скрам-мастере определяет сроки, владелец продукта устанавливает цели и задачи, а члены команды проводят работу по разработке.	Для команды нет заранее определенных ролей. Тем не менее, может все еще быть менеджер проекта; команда поощряется к сотрудничеству и работает вместе.
Лучшее для проектов с изменяющимся приоритетом .	Идеально подходит для команд со стабильным приоритетом , который вряд ли изменится со временем.
Измеряет производство с использованием скорости через спринты.	Измеряет производство, используя время цикла или точное время, необходимое для выполнения одной полной части проекта.
Scrum требует полного перехода от традиционной модели к модели Agile Scrum, которая будет реализована в проекте.	Канбан не допускает кардинальных изменений в проекте.
Это идеальный метод для проектов с сильно различающимися приоритетами .	Лучше всего подходит для команд со стабильным приоритетом .
В Scrum вся команда t сосредоточена на совместной работе и выполнении задачи для обеспечения качественной разработки.	Команды работают над достижением цели и сокращают время, необходимое для завершения всего процесса. Таким образом, сокращение временного цикла является здесь самым большим показателем успеха.
Scrum акцент на его графиках ; новые элементы не могут быть добавлены к текущим итерациям.	Канбан по своей природе более итеративен, так как не имеет определенных таймфреймов . Так что новые элементы могут добавляться постоянно, когда появляется дополнительная емкость.
Всего работа выполняется партиями / спринтами .	Весь проект выполняется по перемещению однопоточных рабочих элементов на потоков.
Мастер Scrum действует как решатель проблем.	Канбан поощряет каждый член команды является лидером и разделяет ответственность между ними всеми.
Scrum предписывает итераций с временными рамками .	Канбан фокусируется на , планирующем другую продолжительность для отдельной итерации.
Scrum помогает фирмам экономить время и деньги .	Канбан-метод фокусируется на постоянном улучшении , производительности и эффективности.
Достигните стабильной и последовательной связи производительности на всех уровнях.	Члены команды с большей вероятностью достигнут своих целей намного легче из-за визуального характера досок Канбан.
Проект закодирован и протестирован во время спринта. Обзор	Члены команды с большей вероятностью достигнут своих целей намного легче из-за визуального характера досок Канбан.
легче приспособиться к постоянным изменениям из-за коротких спринтов и регулярной обратной связи.	Это , предназначенный для регулярного, стабильного вывода , серьезные изменения в потребительском спросе могут привести к сбою Канбан.
Общая стоимость проекта минимальна, что может привести к более быстрому и более дешевому результату .	Если задача оценена неправильно, общая стоимость проекта никогда не будет точной .В таких случаях задача может быть распределена на несколько спринтов.
Эта методология требует только опытных членов команды . Итак, если команда состоит из людей, не являющихся экспертами, проект не может быть завершен в срок.	Нет. Особые временные рамки назначаются для каждой фазы, поэтому члены команды никогда не понимают, сколько времени они могут потратить на каждую фазу.
В этом методе Agile Scrum легче доставить качественный продукт в запланированное время.	Он разработан для регулярных, стабильных выпусков, серьезных изменений в потребительском спросе могут привести к падению Канбан.
План проекта никогда не помешает , даже если член команды покинет команду.	Если кто-то из членов команды уйдет во время разработки, это может повредить развитию проекта. .
Ежедневные встречи иногда расстраивают членов команды.	Устаревшая доска Kanban может привести к проблемам в процессе разработки.
Крупные проекты можно легко разделить на легко управляемые спринты.	Только хорошо работает с небольшими командами , поэтому не подходит для больших команд.

Заключение:

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

Выбор правильного подхода для вашей команды

Agile, Lean, Scrum, Kanban: все эти термины используются для описания очень похожих подходов к управлению проектами, и, что усугубляет путаницу, часто используются как взаимозаменяемые.Люди называют церемонии Scrum церемониями Agile, а для Scrum используют доски Kanban. Если вы новичок в Agile, это быстро сбивает с толку.

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

Что такое Agile?

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

Agile был разработан в 2001 году группой из 17 разработчиков программного обеспечения, которые называли себя «Agile Alliance». В течение двух дней эти разработчики написали The Agile Manifesto, набор руководящих принципов, которые поощряют такие вещи, как постоянный прогресс и сотрудничество по документированию процессов и переговорам по контрактам.

До выпуска The Agile Manifesto большинство проектов разработки программного обеспечения следовали Waterfall, методологии управления проектами, при которой все требования к проектам создавались и оценивались до начала разработки.Команды разработчиков берут на себя обязательство выполнить определенный объем работы за определенное время.

Это создало несколько проблем:

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

Agile Alliance считает, что лучший подход к разработке — это совместная работа команд со спонсорами проекта в течение срока разработки, сбор требований и создание кода с использованием итеративного подхода.

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

Что такое скрам?

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

Scrum предоставляет структуру, которую спонсоры проектов и разработчики программного обеспечения могут использовать для совместной работы и соблюдения руководящих принципов Agile. Он был разработан Кеном Швабером и Джеффом Сазерлендом, двумя членами Agile Alliance, и описан в The Scrum Guide.

Команда Scrum состоит из трех ролей:

• Владелец продукта: Владелец продукта — представитель заинтересованных сторон проекта, который доступен на протяжении всего процесса разработки, чтобы ответить на вопросы, проверить выполненную работу и определить приоритеты требований. Участие владельца продукта в команде разработчиков помогает командам придерживаться стремления Agile к расширению сотрудничества.
• Скрам-мастер: Скрам-мастер руководит командой разработчиков, заставляет всех сосредоточиться на своей работе, учит других в команде о Скраме и руководит всеми встречами Скрама.Он / она действует как руководитель команды, следя за тем, чтобы все работало гладко и все следовали правилам Scrum.
• Команда разработчиков: Группа разработчиков — это группа из трех-девяти разработчиков, которые несут ответственность за выполнение работы, описанной и отнесенной к приоритетам Владельцем продукта.

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

Пользовательские истории всегда следуют определенному формату: Как [кто], я хочу [что], так что [почему]. Например:

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

Разработка завершается итерацией, называемой Sprint — периодом от одной недели до одного месяца, когда команда сосредотачивается на установленном запланированном объеме работы.Эта работа планируется во время церемонии Scrum под названием Sprint Planning , где команды принимают решение и планируют работу для любого количества пользовательских историй, которые, по их мнению, могут быть выполнены во время спринта.

Во время спринта команды Scrum проводят ежедневное собрание Scrum в начале каждого дня, на котором каждый член команды разработчиков отвечает на три вопроса:

• Над чем вы работали вчера?
• Над чем ты будешь работать сегодня?
• Есть ли какие-либо препятствия, мешающие вам завершить работу?

В конце каждого спринта команда проводит две встречи.Первый — это Sprint Review , где команда разработчиков демонстрирует работу, выполненную во время спринта, владельцу продукта для утверждения. Второй — это ретроспектива Sprint Retrospective , где команда стремится улучшить свои будущие спринты, отвечая на три вопроса:

• Что прошло хорошо во время этого спринта?
• Что пошло не так?
• Что мы должны сделать по-другому в следующем спринте?

Скрам не только помогает командам практиковать Agile, но и гарантирует, что все работают в постоянном темпе на протяжении всего проекта, выполняемая работа — именно то, что хотят спонсоры проекта, а команды постоянно улучшаются в течение всего проекта. проект.

Что такое канбан?

Канбан был первоначально разработан Тайити Оно, промышленным инженером Toyota, для создания более эффективного производственного процесса. Позже он был применен к разработке программного обеспечения Дэвидом Дж. Андерсоном в его книге 2010 года Канбан: Успешные эволюционные изменения для вашего технологического бизнеса .

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

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

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

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

Еще одна ключевая особенность Канбана — это лимитов незавершенной работы (WIP) . Предположим, например, что ваша команда разработчиков серверной части работает намного быстрее, чем группа разработчиков интерфейса. Команда внешнего интерфейса может оказаться в очереди с десятками задач, в то время как ваши тестировщики будут сидеть без дела.

Пределы

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

Чтобы удалить этот блокировщик, другие члены команды могут помочь очистить очередь разработки внешнего интерфейса, или это может послужить сигналом того, что ваша команда несбалансирована: вам нужно меньше разработчиков внутреннего интерфейса и больше разработчиков интерфейса.

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

Канбан против Scrum

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

Выбор подходящей методологии для вашей команды требует учета нескольких различных факторов:

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

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

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

Scrum и Kanban вне разработки программного обеспечения

Хотя Scrum и Kanban уходят корнями в разработку программного обеспечения, философия и основы методологий полезны во многих различных отраслях и дисциплинах.

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

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

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

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

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

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

Выбор правильных инструментов Scrum и Kanban

Есть множество инструментов на выбор, если ваша команда практикует Scrum и / или Kanban. Некоторые из них относятся к Scrum и имеют функции для церемоний, связанных с Scrum, например, Sprint Planning и Release Planning, а также используют терминологию Scrum, такую ​​как User Stories и Sprints.

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

Инструменты

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

Очевидно, что инструменты Канбан разработаны для метода Канбан и хорошо работают с ним. Но они подходят и для Scrum. Многие команды запускают Scrum с использованием доски Kanban — практику, которую иногда называют ScrumBan.

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

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

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

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

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

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

Начните создавать более гибкие команды и процессы

По своей сути Agile ориентирован на постоянное совершенствование.Для Agile Alliance улучшения, которые они стремились внести, были сосредоточены на сотрудничестве, гибкости и поэтапной доставке. Но возможно, это не те улучшения, которые нужны вашей команде. И если да, то ничего страшного.

Когда я работал владельцем продукта, я слышал, как люди бесчисленное количество раз говорили: «Если вы делаете X, вы не Agile». Но сам по себе Agile — это не система, основанная на правилах; это система принципов. И эти принципы могут применяться любой командой любым удобным для них способом, если целью является постоянное улучшение.

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

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

Scrum VS Канбан

Scrum и Kanban являются гибкими практиками / фреймворками.С годами они развивались для решения конкретных проблем, связанных с организацией работы.

Статья по теме: Ключевые ценности и принципы Agile Manifesto

Многие команды и организации часто использовали комбинацию практик как из схватки, так и из канбана, иногда для работы в своих интересах, иногда не так сильно. Таким образом, часто возникают вопросы: когда мы должны использовать scrum, а когда мы должны использовать kanban? Могут ли scrum и kanban использоваться как взаимозаменяемые для любого проекта? Или есть взаимодополняющие практики в обоих случаях, которые можно использовать в сочетании?

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

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

№	Атрибут	Скрам	Канбан
1	Рабочий цикл	Итерации. В Scrum есть спринты, в которых команда следует циклу «планирование-выполнение-проверка-действие» (PCDA). Сложную итеративную работу, такую ​​как разработка нового продукта или функции, лучше выполнять с помощью Scrum.	Непрерывный поток. В рабочем цикле канбана, как только одно завершается, команда берется за другое. Канбан лучше подходит для непрерывной работы, такой как поддержка и услуги.
2	WIP — в работе	Лимиты WIP устанавливаются командой Scrum для каждого спринта, и новая работа берется только после того, как вся работа будет завершена. Если командам нужно чувство выполненного долга / завершения / завершения, используйте схватку.	Лимит незавершенного производства действует. Как только закончится какая-то работа, беру новую. Если команды продолжают работать над одним делом за другим, используйте канбан.
3	Inspect-Adapt (Эмпиризм)	Каждый спринт — это возможность проверить и адаптироваться. При необходимости проработайте циклы через несколько спринтов для импровизации. Если работа постоянно развивается и требует импровизации, используйте схватку.	Нет специального механизма для проверки и адаптации. Работа течет в одном направлении. Если работа является разовой и не требует проверки и адаптации, используйте канбан.
4	Прозрачность (эмпиризм)	Артефакты в схватке включают отставание продукта, отставание спринта, приращение. Соответственно обеспечить прозрачность требований, реализации и результатов. Если требования необходимо отслеживать отдельно от отслеживания незавершенной работы, используйте scrum.	Нет особых артефактов для прозрачности. Канбан-доска обеспечивает некоторую прозрачность. Многие команды используют бэклог продукта (из схватки) в сочетании с досками канбан. Если нужно отслеживать только реализацию, используйте канбан.
5	Планировка	Конкретные события для планирования спринта и дня — планирование спринта и ежедневный скрам. Используйте схватку, если требуется дисциплинированное планирование через равные промежутки времени.	Нет ассигнований на планирование работ. Команды применяют свой собственный ритм и подход к планированию. Канбан-планирование пользователя может быть периодическим или по мере необходимости.
6	Ответственность	Ответственность в схватке развивает фокус ответственности, например: Владелец продукта для бизнеса, разработчики для домена и мастер схватки для препятствий. Если командам нужны люди, сосредоточенные на этих обязанностях, используйте схватку.	В канбане нет ответственности, такой как владелец продукта, разработчик и т. Д. Он предполагает группу людей, работающих над задачами. Если команда — это просто группа людей с определенным опытом, используйте канбан.
7	Заинтересованная сторона / Заказчик	Scrum имеет активное участие заинтересованных сторон и клиентов — по крайней мере, один раз за спринт во время мероприятия по обзору спринта. Если работа инновационная, творческая или новая и требует обратной связи / взаимодействия с заинтересованными сторонами и клиентами, используйте схватку.	Канбан не позволяет привлечь заинтересованные стороны или клиентов. Многие команды применяют подход «проверки спринта» раз в месяц. Если работа в основном повседневная и не требует частого взаимодействия с заинтересованными сторонами, используйте канбан.

Статья по теме: Сотрудничество между командами с использованием различных моделей процессов

======

Об авторе

Scrum Alliance Certified Scrum Trainer® Пунита Дэйв работает со scrum и другими гибкими практиками почти 20 лет и успешно трансформировал более 100 крупных, средних и малых компаний и обучил более 6000 человек.Она расширила границы гибкости и схватки за пределы программного обеспечения: оборудование, центры обработки данных, финансы, маркетинг, медицина, пищевая промышленность и недвижимость. Она по-прежнему страстно желает изменить способ работы организаций, бизнеса и людей.

Канбан против Scrum — в чем разница? • Asana

Вы слышали эти термины раньше: Kanban и Scrum . Но что именно они означают? Разве схватка не является термином регби?

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

Канбан

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

Прочтите: Руководство по канбан-доскам для новичков

История Канбан

Канбан-метод был первоначально разработан Тайити Оно во время его работы в Toyota как методология бережливого производства. В японском языке канбан — это комбинация двух слов: 看 (Kàn), означающего знак, и 板 (Bǎn), означающего «доска». Первоначально система Канбан Оно использовала бумажные карточки для отслеживания спроса на заводе Toyota. Вместо того, чтобы пытаться предугадывать спрос и производить для этого ожидаемого спроса, его метод Канбана производил и повторно поставлял продукты в результате потребительского спроса .

Канбан сегодня

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

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

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

Прочтите: 3 способа визуализации плана проекта: сроки, календари и доски

Преимущества досок Канбан

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

Канбан-доски — это гибкий способ для вашей команды визуализировать незавершенную работу. Традиционно столбцы на доске Канбан отображают этапы работы (например,g., To do, In progress и Done), поэтому они являются популярными инструментами визуального управления проектами для команд, которые выполняют текущие процессы и проекты, такие как творческие запросы или проекты по отслеживанию ошибок. Но вы также можете настроить свои собственные столбцы на доске Канбан, чтобы представлять все, что угодно. Вы можете создавать столбцы на основе исполнителя задачи, «зоны ответственности» и ответственности или срока выполнения.

Благодаря своей эффективности для визуализации работы, доски Канбан являются ключевым компонентом большинства инструментов управления проектами.Если вы хотите выбрать подходящий инструмент управления проектами для своей команды, убедитесь, что он предлагает Канбан в качестве представления. А еще лучше поищите инструмент, который позволяет просматривать работу разными способами. Например, в Asana представление досок (или канбан) — это один из четырех способов просмотра работы в дополнение к представлению временной шкалы, представлению календаря и представлению списка.

Прочтите: четыре способа визуализации работы в Asana

Scrum

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

История Scrum

Термин «Scrum» первоначально использовался при разработке продукта Хиротакой Такеучи и Икуджиро Нонака в их статье The New New Product Development Game , опубликованной в Harvard Business Review в 1986 году. В статье они рассказывают о схватке:

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

Затем, в 1995 году, Кен Швабер и Джефф Сазерленд опубликовали процесс разработки SCRUM, в котором они изложили методы и принципы современного Scrum. Швабер и Сазерленд продолжили исследование и уточнение своей методологии Scrum, наиболее известное из которых было в их Scrum Guide — живом документе, который они регулярно обновляют. Руководство по Scrum определяет Scrum «не как процесс, технику или окончательный метод. Скорее, это структура, в которой вы можете использовать различные процессы и методы.По словам Швабера и Сазерленда, Scrum помогает командам постоянно улучшать свой продукт, свою команду и общую рабочую среду. Скрам делает это, побуждая команды взглянуть на то, насколько эффективны их методы работы, и заставляет команды постоянно развиваться и улучшать их.

Scrum сегодня

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

• Фаза 1: Планирование спринта . Спринт Scrum обычно длится 2 недели, хотя команды могут работать быстрее или короче. На этапе планирования спринта Скрам-мастер и команда изучают список невыполненных продуктов и выбирают работу, которую нужно выполнить в ходе спринта.

• Фаза 2: Ежедневные встречи Scrum . В ходе Скрама (также известного как «время цикла» Скрама) команды обычно быстро собираются каждый день, чтобы проверить прогресс и убедиться, что объем назначенной работы соответствует требованиям.

• Этап 3: Ретроспектива спринта . Когда Scrum закончен, Scrum Master проводит ретроспективное собрание спринта, чтобы оценить, какая работа была сделана, направить любую незавершенную работу обратно в список невыполненных работ и подготовиться к следующему спринту.

Прочтите: Асана для Agile и Scrum

Цель Scrum — не создать что-то за две недели, выпустить и никогда больше этого не увидеть.Скорее, Скрам подразумевает «постоянное совершенствование», когда команды делают небольшие шаги к более крупным целям. Разбивая работу на более мелкие части и работая над ними, Scrum помогает командам лучше расставлять приоритеты и более эффективно выполнять работу.

Преимущества Scrum

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

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

Подождите, а что такое Agile?

Когда мы говорим о Канбан и Скрам, часто встречается третий часто используемый термин: Agile .

Agile-команды часто запускают Scrum и используют доски Kanban, но полезно рассматривать Agile как более широкий, общий термин. Подобно тому, как вы можете использовать доску Канбан без использования Скрама, у вас также может быть команда Agile, которая не использует Скрам и не использует доски Канбан. Думайте об Agile как о философии управления проектами. Следовать методологии Agile — значит верить в итеративную и поэтапную разработку, которая поможет командам реагировать на изменения и справляться с неопределенностью. И Канбан, и Скрам являются подмножествами методологии Agile.

Узнать больше: Управляйте своими гибкими проектами с помощью лучшего гибкого инструмента управления

Разница между Канбан и Скрам

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

Скрам более определен, чем Канбан

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

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

Scrum ограничен по времени

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

Фактически, для команд, которые запускают Scrum на Kanban-досках (или, как их иногда называют, Scrum-досках), они часто создают новую доску для каждого Scrum-спринта. Причина этого двоякая:

1. Команды, которые создают новые доски для каждого спринта, могут начинать с чистого листа. Это упрощает для Scrum Master и Scrum-команды визуализацию новой работы, которую они должны выполнять для каждого спринта.

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

В отличие от Scrum, доски Kanban не обязательно должны иметь дату начала или окончания. Фактически, в Asana мы чаще всего используем доски Kanban для представления текущих процессов. Благодаря гибкости этих визуальных досок они отлично подходят для управления процессами набора работы или творческими запросами без каких-либо конкретных временных рамок.

Столбцы на доске Канбан могут быть организованы по-разному.

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

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

И Канбан, и Скрам побуждают команды к непрерывному совершенствованию

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

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

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

Как Канбан, так и Скрам могут помочь командам сотрудничать

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

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

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

Когда использовать Канбан

Нет точного правила, когда вашей команде следует использовать Канбан, Скрам или другую форму визуального управления проектами.Однако хороший способ решить, подходит ли вам Канбан:

• Вашей команде нужна визуальная система управления проектами

• Вам нужен быстрый способ понять, где находится проект

• Вы не работаете в группе разработчиков, продуктов или программного обеспечения

• Вы выполняете текущие процессы и проекты

• Большая часть вашей работы выполняется не за короткие периоды времени

Даже если вы выберете Чтобы не запускать фреймворк Scrum, вы все равно можете черпать из него вдохновение.Например, вы не хотите, чтобы ваша работа ограничивалась двухнедельными спринтами, но сохранение невыполненных задач поможет вашей команде лучше понять задачи и расставить приоритеты. Лучшая часть Канбана — это то, что вы можете выбрать то, что вам подходит, и выбросить все остальное.

Когда использовать Scrum

Scrum может быть мощным способом организовать и расставить приоритеты для всего процесса. Хотя не каждая команда преуспевает в Scrum, вы можете извлечь выгоду из Scrum, если:

• Вы работаете в команде инженеров, разработчиков продуктов, программного обеспечения или Agile

• Вы думаете, что ваша команда могла бы получить немного больше жесткая структура

• У вас большой объем невыполненной работы

• Ваша команда мотивируется быстрыми сроками и результатами

• Кто-то в вашей команде стремится стать мастером Scrum

Помните: вы всегда можете запустить Scrum на доске Kanban.Чтобы проводить эффективные ежедневные стендап-встречи и звездное планирование и ретроспективы спринтов, вам нужен надежный способ визуализации работы по этапам и отслеживания всей вашей незавершенной работы. Канбан-доски могут помочь вам справиться с отставанием в спринте и организовать поток работы во время спринта, поэтому каждый цикл Scrum будет успешным.

Канбан против Scrum: что лучше?

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

Самое важное — найти фреймворк и инструмент, которые подойдут именно вам. Итак, используете ли вы Scrum или Kanban-фреймворк, убедитесь, что ваша система управления работой достаточно гибкая, чтобы поддерживать вашу команду, чтобы вы могли выполнять свою работу наилучшим образом.

Простая разбивка каждой сложной методологии

Развитие гибкого управления проектами внесло новое значение в термины Канбан и Скрам.Эти термины часто встречаются, но все еще есть много людей, которые не уверены в том, что означает каждый фреймворк и каковы основные различия между ними.

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

Часто это приводит к давним спорам (что на самом деле не , а ): Канбан или Скрам?

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

Итак, как узнать, какой из них лучше всего подходит для вас, вашей команды и ваших проектов? Давайте разберем эти два стиля еще дальше, чтобы понять, что лучше всего подойдет вам:

Вид доски Канбан

Используйте доски канбан в Teamwork, чтобы наметить рабочий процесс, быстро увидеть статус задач и автоматизировать процессы.

Что такое Канбан?

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

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

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

Чаще всего вы увидите следующие этапы рабочего процесса: To Do , In Progress , In Review и Done (или Completed).

Как выглядит Канбан в действии

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

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

Упрощенная версия доски Канбан может выглядеть так:

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

Гибкость подхода Канбан позволяет легко непрерывно добавлять новые рабочие элементы или уточнять готовые результаты — когда это позволяет емкость.

Используя приведенный выше пример, как только копия веб-сайта перемещается в В обзоре , проектирование страницы с информацией и другие нерешенные задачи затем перемещаются в столбец Выполняется .Если выясняется, что готовую копию веб-сайта, необходимую для каркасов, необходимо повторно посетить, задача просто перемещается обратно в столбец To-Do с новыми запросами.

Как измеряется Канбан

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

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

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

Где лучше всего работает метод Канбан?

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

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

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

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

Попробуй Teamwork сегодня бесплатно!

Что такое Scrum?

Scrum — это метод управления проектами, который позволяет командам использовать строгие периоды времени, чтобы сосредоточиться на конкретных задачах. Скрам разбивается на спринты, которые длятся от одного дня до четырех недель — в зависимости от объема задач.

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

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

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

Как выглядит Scrum в действии

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

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

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

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

Как измеряется метод Scrum

Scrum часто измеряется скоростью или, проще говоря, количеством задач, которые могут быть выполнены в любом заданном спринте. По сути, каждой задаче назначается точка (точки), которые затем суммируются и используются для измерения того, как долго должен быть спринт и сколько нужно выполнить за это время.

Если команда набирает в среднем 40 очков за спринт, скорость спринта составляет 40. Спринт с более чем 40 очками должен проходить в течение более длительного периода времени или наоборот, если набирается меньше очков.

Где лучше всего работает метод Scrum?

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

Канбан против Scrum: в чем реальные различия?

При настройке «один на один» Канбан против Скрама становится более простым решением в зависимости от вашего конкретного проекта, команды или рабочего процесса.

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

Канбан-профи

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

• Ограничивает объем незавершенной работы для обеспечения качества

• Управляет потоком проекта

• Устанавливает циклы обратной связи

• Улучшает взаимодействие в команде

• Гибкость, чтобы проекты могли вращаться в зависимости от приоритетов

Канбан-минусы

• Нет строгих обязанностей, что затрудняет сосредоточение команд на приоритетах

  55

Доски могут быть очень сложными и запутанными

• Нет временных параметров

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

Скрам-профессионалы

• Короткие спринты могут привести к периодам крайней сосредоточенности и выполнения задач

• Делит сложные задачи на более мелкие, управляемые действия

• Легко достигать быстрых результатов для повышения мотивации команды

• У каждого члена команды есть четкое представление о том, что происходит

• Целенаправленный рабочий процесс

Недостатки Scrum

• Члены команды должны быть очень сосредоточены во время спринта

• Обычно возникают проблемы со скоростью, если они идут медленнее члены команды

• Требуется много ресурсов планирования и ресурсов для измерения, отслеживания и управления спринтами

• Не гибкий для команд, если приоритеты меняются в середине спринта

Выберите метод, который лучше всего подходит для вас и вашей команды

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

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

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

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

Наш универсальный инструмент позволяет визуализировать задачи проекта в формате Канбан. и могут планировать спринты и управлять ими как часть метода Scrum. Возможность выбрать лучший подход для вашей команды в зависимости от проекта — эффективный способ обеспечить правильное управление вашими проектами каждый раз.

Agile vs Scrum vs Kanban Взвешивая различия

ФОТО: Shutterstock

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

В чем разница между Agile, Scrum и Kanban?

Agile — это общий термин, используемый для описания методологии управления проектами, которая разбивает большие сложные проекты на более мелкие управляемые части. Гибкое управление проектами использовалось при разработке программного обеспечения для ускорения завершения проектов, но теперь мы видим, что эти методы применяются во множестве отраслей. «Agile — это набор руководящих принципов, разработанных в 2001 году и опубликованных как Agile Manifesto.С другой стороны, Scrum и Kanban — это две методологии, которые считаются гибкими. Или, другими словами, если вы хотите работать гибко, Scrum и Kanban — это два способа сделать это ». сказал Николас Кэрриер, ассоциированный партнер лондонской компании Prophet.

И Scrum, и Kanban — это две разные гибкие методологии управления проектами с «тонкими» различиями. Но Кэрриер отметил, что обе методологии имеют общие черты: «Оба метода используют физическую доску или цифровую репликацию одной, где люди перемещают работу примерно между тремя категориями: 1) работа [которая должна быть выполнена], 2) работа, которая выполняется, и 3) работа, которая была завершена.”

Статья по теме: 16 лучших программных платформ для управления корпоративными проектами

Так в чем разница между Scrum и Kanban?

Несмотря на то, что и Scrum, и Kanban имеют схожие черты, часто ошибочно считают, что обе методологии — это две стороны одной медали. Но это далеко не так, поскольку обе гибкие методологии совершенно разные. По словам Джессики Д’Амато, вице-президента по управлению проектами в Атланте, Джорджия, методология Scrum разбивает ограниченные по времени рабочие периоды цикла разработки, называемые спринтами, которые обычно длится две недели.на основе Dragon Army.

«Руководители проектов планируют, какие инициативы будут реализованы в течение двухнедельных спринтов, а также проводят ежедневные встречи (также называемые стендапами), чтобы узнать с командой, как продвигается проект. Менеджеры также используют эти стендапы. для демонстрации новых выпусков клиенту перед запуском », — сказал Д’Амато.

В Scrum есть как минимум три предписанные роли:

• Владелец продукта — лицо, занимающее эту роль, отвечает за первоначальное планирование, приоритизацию задач и коммуникации
• Скрам-мастер — исполнитель этой роли отвечает за надзор за процессом во время спринта.
• Члены команды — лица, выполняющие задания в спринте.

Scrum имеет более предопределенную структурированную структуру, в то время как Канбан менее так, как продолжает Д’Амато. «Канбан менее структурирован и основан на списке (также известном как невыполненная работа) элементов, которые необходимо выполнить. Канбан не имеет установленных временных рамок, когда элементы должны быть выполнены. Вместо этого эта методология управляется приоритетом элементов (т. Е. Тикетами / карточки) на канбан-доске.Доска имеет разные столбцы, которые позволяют менеджерам знать статус элемента, над которым работает, включая текущие, незавершенные и завершенные задачи.”

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

Статья по теме: Как цифровое рабочее место меняет управление проектами и их выполнение

Agile за и против

Гарнер объясняет, как гибкие методологии, такие как Scrum и Kanban, обеспечивают поэтапный и итеративный подход к завершению проекта, в отличие от традиционных методов управления проектами, которые следуют линейному подходу (также известному как каскадная доставка).«[Agile] фокусируется на том факте, что бизнес-требования постоянно меняются, и необходимо создать продукт, который будет потребляться и отправляться в небольших готовых к выпуску единицах. [Кроме того], он ориентирован на сильную командную работу, подотчетность и прозрачные [каналы связи], чтобы продукт соответствовал целям клиента и компании ».

Но поскольку Гарнер подчеркивает, как гибкое управление обеспечивает гибкость и возможности для постоянного улучшения, он добавил, что это преимущество может повлиять на окончательную дату поставки и конечный продукт из-за всех изменений.«Проблема, которая возникает перед командами цифровой трансформации, заключается в том, что руководители часто верят в преимущества гибкой разработки [будь то ориентированность на клиента или итеративная работа и т. Д.], Но у них недостаточно ресурсов [для выполнения работы]. Что часто Результатом этого несоответствия между навыками и ожиданиями является стресс от команд, которые пытаются работать дешевле и быстрее, используя те же неагибкие методы, что и раньше, и, следовательно, в конечном итоге выполняют работу низкого качества », — сказал Кэрриер.

Scrum Плюсы и минусы

Бриджмохан Бхавсар, менеджер по доставке в Оук-Брук, штат Иллинойс.на основе Indusa, прокомментировал, как Scrum может обеспечить «высокую прозрачность и видимость проектов» и обеспечивает большую гибкость для адаптации к изменениям. Гарнер добавил к этому, упомянув, как Scrums может помочь «четко определить роли», способствовать «лучшему сотрудничеству» и может помочь завершить проект намного быстрее. «Мы используем Scrum даже в чисто стратегических проектах. Это позволяет заинтересованным сторонам бизнеса из множества [таких как] отделов маркетинга, операций и технологий [быть] привыкшими к более частым контактам, более совместному принятию решений и большему совместному владению результатами », — сказал Кэрриер.

Напротив, Бхавсар отметил, что разбивка сложных задач на более мелкие части может привести к «плохо определенным задачам» и «риску увеличения объема работ» (т.е. когда требования к проекту возрастают из-за отсутствия направления).

Плюсы и минусы канбана

«Канбан — это скорее модель для представления изменений посредством дополнительных улучшений. Этот процесс [обеспечивает] визуальное представление того, что вы делаете сейчас. Доска Канбан играет важную роль в отображении рабочего процесса, но помогает в оптимизации задач между разными командами» — сказал Бхавсар.

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

Какой выбрать?

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

Bhavsar предлагает решить, хотите ли вы, чтобы ваши проекты выполнялись быстрее или вы хотите улучшить общий процесс. «Я бы посоветовал попробовать Scrum, если вы просто хотите работать быстрее. Если вы хотите улучшить свой производственный процесс, используйте Kanban. Если ваши проекты требуют более линейного рабочего процесса, внедрите Waterfall», — сказал Бхавсар.

Agile, Scrum, Kanban: что это такое?

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

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

Проворный

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

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

Люди и взаимодействие над процессами и инструментами
Рабочее программное обеспечение над исчерпывающей документацией
Сотрудничество с клиентами над переговорами по контракту
Реагирование на изменения вместо следования плану

Принципы

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

Agile — это основа для мышления и принятия решений.

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

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

Agile Manifesto — это результат различного опыта и практических решений, появившихся на протяжении десятилетий.

Скрам

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

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

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

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

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

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

Есть также четыре церемонии Scrum: Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

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

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

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

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

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

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

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

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

Канбан

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

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

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

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

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

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

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

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

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

Что мне использовать?

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

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

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

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

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

.