Отличие scrum от kanban – Что Лучше Выбрать: Скрам и Канбан Отличия и Разница

Отличие Scrum от Kanban

Команды

В Scrum над задачами работает универсальная многопрофильная команда. По необходимости все специалисты помогают друг другу или даже перехватывают задачи. Средняя численность команды от 5 до 9 человек.

В Kanban команда может быть как многопрофильная, так и нет. Средняя численность команды от 5 до 9 человек.

Доска

В Scrum-доска очищается каждую итерацию. В стандарте имеет 3 столбика: To do, In process, Done.

В Kanban, в свою очередь, доска находится в постоянно заполненном состоянии.

Роли

Никаких должностей, а только роли – такова философия Scrum. Если коснуться только основы, то основные роли в Scrum – Product Owner и Scrum Master, а также, если хотите, Команда.

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

Scrum Master ведёт этот процесс. Он не погоняет кнутом команду, а, наоборот, делает абсолютно всё, чтобы её участники могли эффективно работать.

Что же на счет Kanban? А ничего, нет там ролей. Это не хорошо и не плохо. Довольно часто встречаются команды, которым не нужно и не интересно отыгрывать какие-то роли, а нужно просто брать и работать.

Планирование

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

Реализация

В данном пункте хочется отметить, что ограничения есть и у Kanban, и у Scrum. Правда ограничения не идентичны. В Scrum есть чёткие рамки по времени итерации (1 неделя – 4 недели), а в Kanban можно работать в режиме non-stop. В Kanban, в свою очередь, есть ограничения по количеству задач в статусе, а в Scrum такого нет. В Scrum редко идёт оценка именно по количеству задач, так как задача задаче рознь. Одна задача может занимать 10 минут, а вторая – 4 часа (использование SP).

В заключение

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

Если быть совсем грубым, то можно сказать так: если вам необходимо просто и эффективно работать, выбирайте Kanban. Если всё же есть необходимость в тщательном контроле процесса, развитии команды, точных дат релизов и так далее – выбирайте Scrum.

Мы же предлагаем вам использовать аккумуляцию данных методологий и применять симбиоз. Именно так советуют поступать многие умы человечества в области гибких методологий. В системе управления проектами Scrum Time мы и стремимся к тому, чтобы дать эту возможность. И не просто возможность интегрировать друг в друга, а ещё и управлять: 20% Scrum, 80% Kanban, или как душе угодно.

ru.scrum-time.com

в чем разница и для чего использовать? — Рамблер/новости

Рубрика «Инновации в корпорациях» выходит при поддержке 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-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

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

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

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

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

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

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

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

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

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

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

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

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

Владимир Овелян

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

В зависимости от задач мы применяем разные методы — agile, scrum, kanban.

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

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

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

Виталий Сотников

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

Важный момент: agile-методология — это общее направление, а kanban и scrum — уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

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

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi  Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками «to do», «in progress», «review», «test», «done», где все члены команды наклеивают стикеры с задачами (в колонке «to do»), а по мере их выполнения перемещают в последующие пункты. И счастливый финал — конечный пункт «done». Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

Ирина Черепанова

Директор по продукту uKit Group

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

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

Инга Корягина

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

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

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

Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)

Дж. Сазерленд «Scrum. Революционный метод управления проектами»

Д. Андерсон «Канбан. Альтернативный путь в Agile»

Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»

K. Schwaber, J. Sutherland «The Scrum Guide»

M. Cohn «Agile estimating and planning»

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

Cover photo by Daria Nepriakhina on Unsplash

news.rambler.ru

в чем разница и что выбрать?

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

Две популярные Agile-методологии

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

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

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

Можно смело согласиться со всеми аргументами, ведь действительно:

• Люди важнее инструментов, потому что несколько человек, объединенных вместе и «заряженных» на одну общую цель могут иметь больший потенциал и прийти в итоге к бОльшему результату.
• MVP-подход в разработке: выпускаем минимально-жизнеспособную версию продукта на рынок ASAP. Все «свистелочки» оставляем на потом.
• Слово «заказчик» очень просится поменять на «пользователь». Требования к проекту надо собирать не у заказчика, а у пользователей будущего продукта. Об этом детально написано у Карла Вигерса и Джоя Битти.

Зачастую в последнее время проект — это стартап. В контексте стартапов приходит на ум «customer development» (оригинальную методику замечательно описал Стив Бланк).

По сути, во время customer development мы проверяем наши гипотезы до начала разработки даже прототипа. Наши цели – убедиться в том, что:

— проблемы, решением которых мы занимаемся, существует в жизни пользователя.
— эти проблемы существенные.
— пользователь будет за них платить
— есть рынок, и это не проблема одного человека.
— есть каналы привлечения пользователей (например Facebook Ads, или Googl Adwords), и мы сможем найти такую стоимость привлечения пользователей, которая будет давать нам прибыль (CAC < LTV).

• Пункт про гибкость нужен тогда, когда ваш UX или менеджер проекта меняет требование в задаче, и программист говорит: «У вас там семь пятниц на неделе». Вот в этой точке пространства и времени вы ссылаетесь на пункт про гибкость. А вообще, нужно “копнуть” глубже. Для чего нужна готовность к изменениям? Для того, чтобы уметь реагировать на обратную связь. Вы запустили фичу в продакшн, собрали статистику поведения пользователей, убедились в том, что надо менять какие-то параметры фичи и отправили ее на допроектирование. И вот у вас уже на проде улучшенная версия функции. Чтобы все это сделать, нужно быть готовым к изменениям (это про Agile) и способность эти изменения улавливать (это про аналитику и данные).

Это основные идеи манифеста, но есть еще знаменитые 12 принципов, которые говорят сами за себя. Так что, глубоко «копать» в них не будем, а лучше вернемся к основному вопросу отличия Scrum от Kanban.

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

Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.

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

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

Вот вы заказываете в Москве на Кутузовском новую Toyota Camry на «максималке», и для вас уже делают зеркала в козырьке (выбор «максималки» как раз из-за зеркал в козырьке). Важный момент тут — мы можем менять приоритеты в любой момент. Мы очень быстро можем переключать станок в другой режим.

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

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.

Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

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

Что интересного в Kanban позволяет удачно использовать его и в спринтах? Рассмотрим на примере инструмента для управления проектами Hygger.io.

WIP

Во-первых, это WIP (Work in progress). Мы ставим ограничение на число задач, которые может одновременно делать один сотрудник. Выполнять несколько задач одновременно могли только Наполеон и Цезарь. Мы знаем, как они закончили. Поэтому мы бережем своих людей и спасаем от выгорания: они делают только одну задачу в единицу времени.

А если серьезно, то переключение «с задачи на задачу» у программиста в среднем занимает 15 минут. Пока сделаешь чай, пока полистаешь Habr, прочитаешь требования к новой задаче, вспомнишь где ты остановился и найдешь место в коде. Каждое переключение — это выход из потока, а войти в поток не всегда получается — могут мешать внешние раздражители. Поэтому все строго: одна задача на сотрудника. Как мы это контролируем? Вот здесь должно быть понятно:

Когда мы впервые внедряли Kanban, WIP лимиты сразу же показали узкие места в нашем процессе: в колонке Testing скапливалась большая очередь задач  —  наш тестировщик не справлялся с проверкой задач. Задачи очень долго находились в очереди. В итоге, программисты успевали подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать, о чем там шла речь, снова погружаться в детали. Это все издержки, которые понижали наш КПД. Тогда мы позвали еще одного QA и проблема была решена.

Swimlanes

Во-вторых, это Swimlanes. Представьте себе, что у вас «лег» сайт. Как это часто бывает — в рабочее время. Вы делегируете задачу вашему лиду или devops – «Поднять сайт сию же минуту». А он сейчас делает другую задачу и планирует ее закончить завтра после обеда. Что делать? Бежать к нему и умолять переключиться на блокера? Можно, но так вы скоро получите прозвище «черный лебедь». Поэтому мы используем Swimlanes.

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

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

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

Sub-columns

У вас есть колонка Программирование, а за ней – Тестирование. Когда программист закончил задачу, он ее переносит в Тестирование. И получается, что тестировщик как-бы начал тестировать задачу. Но, на самом деле, тестировщик проверяет другую. Да и вообще, вы поставили ограничение WIP на число задач и после того, как программист перенес задачу на тест, у QA нарушен этот лимит. Стало две задачи.

Допустим, программист не будет переносить задачу на Тестирование и оставит ее в Программировании. Но как ему брать следующую задачу, если у него есть WIP лимит, который он не может нарушить. В таком случае, на помощь приходят Sub-columns. Например, для колонки Программирование делаем под-колонки In progress и Done. И когда программист заканчивает задачу, он переносит ее в Done. Когда тестировщик освободится, он возьмет новую задачу из под-колонки Done колонки Программирование и перенесет ее в свою колонку Тестирование.

Заключение

Подводя итоги, хочу отметить, что Scrum — гибкая методика разработки, а Kanban — еще более. Всему свое время и место. Если это разработка нового продукта, то на старте разработки и до релиза лучше использовать Scrum, так как он делает разработку более контролируемой по срокам. Также в Scrum много коммуникаций в команде: ребята обсуждают весь бэклог спринта перед стартом, задают вопросы авторам задачи (UX, продакт-менеджерам, бизнес-аналитикам), оценивают задачи сообща с помощью Planning poker. Scrum помогает детально погрузить команду в суть продукта.

А после релиза продукта начинается совсем другая жизнь: начинает идти обратная связь от пользователей продукта, нужно быстро на нее реагировать. Вы начинаете работать над HADI циклами — вам нужно постоянно проверять различные гипотезы, где на гипотезу может банально влиять цвет кнопки. Вы начинаете измерять и оптимизировать метрики продукта, например, Pirate Metrics (AARRR) и так далее. Все увеличивает ваш цикл разработки, вы начинаете делать много маленьких задач в непредсказуемой последовательности. И для этого как раз идеально подходит Kanban.

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

А на чем вы остановили свой выбор: Scrum и Kanban? Делитесь своими примерами и наблюдениями в комментариях!

Автор: HumanoIT

Источник

www.pvsm.ru

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

4. Временные рамки

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

Каждый спринт состоит из четырех последовательных этапов:

• Планирование. Команда проверяет задачи в общем списке задач по проекту и выстраивает их по приоритету. На спринт берут столько задач, по мнению команды, сколько успеют сделать.
• Выполнение. Участники команды работают одновременно, например: программист создает код, в это время тестировщик пишет к нему тесты, а технический писатель – документацию.
• Релиз. К моменту каждого релиза, продукт должен быть работоспособным, полезным для пользователя и более совершенным, чем до спринта.
• Ретроспектива. Члены команды вместе обсуждают спринт и возникшие в процессе проблемы. Совместно думают, как повысить качество работы и сделать в следующем спринте больше.

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

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

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

В Kanban же не требуются обязательные встречи-отчеты. Они могут проводиться раз в месяц или неделю.

В Kanban методологии проект делится не на универсальные спринты, а на этапы выполнения конкретных задач, например: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и т.д. Данные этапы могут быть различной длины. Новые задачи можно добавлять в любое время. Если нужно срочно что-то сделать, то команда не будет ждать следующего этапа для выполнения срочного задания. Задача может находится в работе столько, сколько потребуется для нее времени, до тех пор пока команда не завершит ее или не отменит.

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

training.qatestlab.com

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

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

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

В этой статье мы рассмотрим различия между Scrum, Kanban и XP.

На высоком уровне есть три варианта гибкой методологии:

Процесс Scrum

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

Доска канбан

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

• Визуализирование рабочего процесса.
• Это можно сделать, используя стену карты или планшет Канбан, со столбцами на доске, представляющими состояния или этапы рабочего процесса, и карты, представляющие рабочие элементы.
• Ограничение выполняемыой работы.
• Ограничение незавершенного производства является краеугольным камнем Канбана. Например, если команда работает сразу по пяти позициям и не добивается прогресса, то мы должны сократить это число до двух или трех, чтобы можно было управлять работой и прогрессом. Выберите наиболее важные, наиболее ценные рабочие элементы. Всегда работайте над следующей самой важной вещью.
• Управление потоком.
• Весь смысл внедрения системы Канбана заключается в том, чтобы добиться позитивных изменений. Прежде чем вы сможете создать это изменение, вы должны знать, что нужно изменить. Необходимо отслеживать, измерять и сообщать поток работы через каждое состояние или шаг, чтобы оценить положительные или отрицательные эффекты пошаговых и эволюционных изменений.
• Ясность процесса.
• Обеспечение четкого понимание механизма процесса для достижения рационального, объективного обсуждения вопросов и упрощения консенсуса в отношении предложений по улучшению. Примером политики, которую вы можете сделать явной, является определение «сделано». Фактически, вы можете иметь определение «сделано» для каждого шага вашего рабочего процесса, то есть перед тем, как элемент сможет быть готов к движению вперед, он должен соответствовать определенным критериям.
• Улучшение совместной работы.

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

Экстремальное программирование

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

Многие правила для этой гибкой методологии разработаны специально для решения вопросов кодирования, проектирования и тестирования. Возьмите планирование, например: традиционный проект делает планирование наперед; XP рекомендует планировать выпуск на высоком уровне, но планировать каждую итерацию в начале спринта (или каждые две недели).

Экстремальное программирование основано на 12 принципах:

1. Процесс планирования работы над проектом

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

2. Малые релизы

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

3. Общая методология

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

4. Простой дизайн

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

5. Тестирование

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

6. Рефакторинг

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

7. Парное программирование

Весь код написан двумя программистами, работающими на одном ПК.

8. Коллективная собственность

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

9. Непрерывная интеграция

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

10. 40-часовая неделя

Команда XP не работает сверхурочно, чтобы команда оставалась хорошо отдохнувшей, внимательной и эффективной.

11. Клиент в доступности

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

12. Стандарт кодирования

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

Тем временем, хочу напомнить, что эффективный тестировщик очень ценен на рынке труда, поэтому стать успешным в этой сфере Вам помогут наши курсы тестировщиков.

imprium.ru

Методы управления проектами: Scrum vs Kanban

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

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

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

Основная цель гибких методов – сведение к минимуму рисков за счет деления работы на итерации (длительность от 1 недели до месяца). Каждая из них представляет собой проект в миниатюре. К концу итерации он должен быть готов к выпуску. Также при завершении очередного временного отрезка команда проводит переоценку приоритетов разработки.

Agile-методы делятся на различные подходы: Scrum, FDD, экстремальное программирование, Kanban, DSDM. Сегодня сравним наиболее популярные из них – Scrum и Kanban.

Что такое Scrum?

Scrum (в переводе с английского «схватка») – свод правил, на которых строится весь процесс работы. В 1986 году впервые о таком подходе было рассказано Хиротака Такэути и Икудзиро Нонака. Они опубликовали его в Harvard Business Review (Гарвардском бизнес-обзоре). Дальше направление дополнили и внедрили в работу Джеф Сазерленд и Кен Швабер.

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

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

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

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

• Важные термины. Резерв проекта – перечень требований к функциональности объекта разработки. Резерв спринта – список функциональных возможностей из резерва проекта, необходимых заказчику. Пункты расставлены в зависимости от важности.  

• В процессе разработки определяются роли: Product Owner, ScrumMaster и Scrum-команда. Первый отвечает за интересы заказчиков. Второй проводит встречи для обсуждения, отслеживает соблюдение установленных принципов и параметров работы и решает возникающие вопросы и противоречия. Группа квалифицированных специалистов выполняет задачи проекта.

                                            ​

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

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

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

Что такое Kanban?

Kanban (в переводе с японского kan – «видимый, визуальный», ban – «карточка, доска»). Впервые этот термин применил и описал Тайити Оно в своей книге «Производственная система Тойоты», 1953 год. Основа подхода – снижение количества выполняемых в данный момент задач.

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

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

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

• Количество задач уменьшается за счет увеличения числа пунктов в каждой из них.

• Ограничение на числа задач на конкретном этапе. Вы сами можете изменять количество задач. Это позволит быстро выявить и решить любой «затор» или недостаток работы.

• Непрерывный поток. Задачи попадают в очередь в порядке приоритета. Поэтому работа никогда не прекращается.

                                             
Главная задача Kanban – это уменьшение времени прохождения задачи от начала до стадии готовности.

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

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

Вместо итогов: сравнение подходов

Параметр	Scrum	Kanban
Задачи	Оговариваются заранее	Могут изменяться на любом этапе
Встречи	Обязательны в начале и конце итерации	Проводятся только по завершению задачи или не проводятся совсем
Самый важный параметр	Скорость выполнения задачи	Время на выполнение задачи
Команды	Разрозненные элементы	Максимально сплоченные
Добавление задач	Только в новой итерации	На любом этапе
Роли	Обязательно ScrumMaster, Scrum-команда и Product Owner	Определяются условно или не требуются
Ограничения	Нет ограничений за 1 спринт	По количеству работ в один временной промежуток
Этапы работы	Всегда: сделать, выполняется, сделано	Нет фиксированных этапов

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

suhorukov.com

Agile, Kanban, Scrum — как HR’у разобраться во всём этом и начать применять

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

Что такое Agile?

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

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

Мы уже писали про 10 принципов и практик Agile, сегодня разберемся поподробнее в таких agile-подходах, как scrum и kanban.

Что такое Scrum?

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

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

Так как все спринты всегда одинаковые, в работе команды появляется ритм, это важный аспект методологии.

Спринт состоит из четырех последовательных этапов.

• Планирование. Проверка и выбор приоритетных задач в бэклоге [журнале оставшейся работы, которую необходимо выполнить команде]. Отбор задач, которые можно успеть сделать за время спринта.
• Выполнение. Параллельная работа всей команды над задачами.
• Релиз. Представление результатов работы команды. В идеале, к моменту каждого релиза проект должен быть полезным для пользователя и готовым к использованию.
• Ретроспектива. Обсуждение результатов и возникших проблем спринта. Все вместе думают, как улучшить работу и сделать в следующем спринте больше.

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

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

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

Что такое Kanban?

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

Так как в kanban нет отдельных ролей, вся команда едина, а процесс делится не на спринты, а на стадии выполнения конкретных задач.

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

Из-за отсутствия спринтов появляются свои особенности:

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

Доска — это сердце kanban- и scrum-разработки. Их используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.

Доска расчерчивается на столбцы, каждый из них — этап, на котором находится задача. Например, «Разработка», «Тестирование», «Релиз» и т.д. По доске перемещаются карточки, это задачи. На каждой карточке есть описание задачи, её вес и приоритет.

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

Доски могут быть физическими и электронными. Физическая — доска на стене со столбцами и липкими листочками. А электронная доска — приложение, которое всегда под рукой. При работе с удаленными сотрудникам, электронная доска — единственный выход. Must-have приложения для работы по Agile методологиям: Jira, Trello и Confluence.

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

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

Итак, что всё это значит для HR?

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

Несколько примеров того, как традиционные подходы к управлению персоналом меняются при использовании Agile-подхода:

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

Эти изменения коснулись уже многих отраслей: ритейл (Gap), фармацевтика (Pfizer), страхование (Cigna), инвестиции (OppenheimerFunds), потребительские товары (P&G) и бухгалтерский учет (Большая аудиторская четверка). Цель — обеспечить постоянную и быструю обратную связь, чтобы сделать рабочие группы гибче и помочь им на ходу исправлять ошибки, повышать эффективность и последовательно улучшать продукт.

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

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

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

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

Рекрутмент. Процессы рекрутинга также становятся более гибкими. Например, в GE с 2015 году над заявками на найм работает межфункциональная группа. В зависимости от нужд компании в нее могут входить менеджеры по найму. Отдельный менеджер представляет интересы внутренних стейкхолдеров, которым надо срочно найти специалиста. А весь процесс контролируется scrum-мастером.

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

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

Обучение и развитие. Внедрение agile-подходов в эти области позволяет сотрудникам быстрее получать новые навыки и адаптироваться под меняющийся бизнес.

IBM использует карьерного коуча Watson Career Coach на основе искусственного интеллекта. Бот отвечает на вопросы сотрудника по развитию карьеры в компании: куда можно двигаться, какие навыки развивать, что делать, чтобы оставаться востребованным и продвигаться по карьерной лестнице. Через общение бот узнает о предпочтениях и интересах работника и на основе анализа дает советы по построению карьеры или переквалификации.

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

Подробнее об опыте внедрения Agile-подходов в мировых компаниях читайте в статье Harvard Business Review.

Как внедрять в работу

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

1. Есть настольная игра getkanban, попробуйте найти её и поиграть вместе с коллегами. В интернете можно найти много разных аналогов игры, доступных для печати.
2. Если вам понравилась игры и вы смогли уловить суть методологии, попробуйте ее на небольшом новом проекте. Поделите его на мелкие задачи, в идеале равные по времени выполнения. Приоритезируйте каждую задачку.
3. Разделите процесс на стадии, которые будет проходит каждая задача. Самый просто вариант: Запланирована → В работе → Завершена. Возможный вариант для рекрутеров: Создание вакансии —> Поиск кандидатов—> Тестовое задание —> Собеседование —> Оффер —> Адаптация . Статусы зависят от того, что именно вы делаете.
4. Проставьте ограничения на статус задач так, как подсказывает логика. Количество задач должно зависеть от числа рекрутеров в вашей команде.
5. Проведите первое совещание. Обсудите, как организуете работу. Когда будете планировать процесс, а когда собираться на совещания и подводить итоги.

6.Перенесите несколько задач из бэклога в «Запланировано» и запускайте процесс.

7. Следите, чтобы карточки-задачи перемещались между колонками, когда задача перешла из одного статуса в другой.
8. Не забывайте фиксировать среднее время выполнения задачи. Добавляя карточку на доску, пишите на ней время начала работы, а снимая — время завершения.
9. Продумывайте, как сокращать среднее время выполнения задачи.
10. Не пропускайте ретроспективные собрания с обсуждением хода работы над проектом и возможностями улучшить работу.

Заключение

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

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

blog.potok.io