Agile канбан что это
Перейти к содержимому

Agile канбан что это

  • автор:

Agile, Scrum и Kanban: в чем суть и как это работает

Agile, Scrum, Kanban – в последние годы эти термины переживают пик популярности, (по крайней мере в украинском социуме). Все больше людей стало интересоваться гибкими методологиями управления проектами и их особенностями. И это неудивительно, ведь по ним можно эффективно работать в любой отрасли, но особенно хорошо они подходят для ИТ. Но в чем суть каждой? И чтобы вы не путались в терминах, давайте разберемся как их успешно использовать.

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile. Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

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

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

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

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

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

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

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

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

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

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

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

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

В 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 — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Scrum и Kanban на практике

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

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

Что выбрать — Scrum или Kanban

Отметим, что каждая методология решает свою проблему. Поэтому все зависит от целей и ожиданий от проекта. К примеру, вы создаете новый удобный мессенджер. Если вы используете принцип Kanban, вы прописываете детальный план, чтобы создать идеальный продукт, — и через год разработки получаете желаемое. Kanban — строгая последовательность задач, равномерная загруженность, четкость на каждом этапе. А если у вас нет конкретного плана? Тогда, на помощь приходит метод Scrum, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.

Agile канбан что это

МЕРОПРИЯТИЯ

Всероссийский хакатон по биометрии

Комментарии

Популярные По порядку
Не удалось загрузить комментарии.

ВАКАНСИИ

Преподаватель на курс БД SQL в Proglib.Academy
по итогам собеседования

Методист-педагогический дизайнер в Proglib.Academy
по итогам собеседования

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

�� ТОП-14 российских аналогов Jira и систем управления проектов

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

Бесплатные книги по управлению проектами для новичков и профи

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

Как найти ментора в IT-сфере и откуда начать поиски?

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

Kanban: что это, как работает и причем тут Agile

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

Что такое Kanban

Kanban — инструмент управления проектами с этапами работы и подвижными карточками.

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

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

Помимо организации системной работы по Agile, Kanban помогает:

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

Чем Kanban отличается от Scrum

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

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

Kanban — это, скорее, набор инструментов, а не четкое руководство. Вы можете сформулировать собственные этапы работы, например, добавить несколько стадий проверки продукта — тестировщиками, продакт-менеджером, CEO компании.

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

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

Менеджмент и взаимодействие

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

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

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

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

Представьте: однажды руководитель отдела торговли обнаруживает, что на этапе «В процессе» замедлилось движение телефонных продаж. Он собирает сотрудников, выясняет причины «затора», интересуется пожеланиями специалистов и принимает решение. Допустим, дело в слабой подготовке менеджеров. Тогда руководитель привлекает более опытных наставников, поручает им пересмотреть скрипты и обучить коллег. Затем он следит, улучшается ли ситуация на доске после внедрения изменений.

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

Несмотря на различия методик, Kanban и Scrum можно применять одновременно. Так, канбан-доска станет прекрасной визуализацией для поиска проблем в Scrum-команде.

Преимущества Kanban в разработке и управлении проектами

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

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

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

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

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

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

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

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

Как можно применить Kanban вне сферы разработки программного обеспечения

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

Оформите воронку продаж в виде доски. Она будет выглядеть как пространство с несколькими столбцами.

Каждый из них — этап, который проходят новые и постоянные клиенты компании.

  • «Регистрация»;
  • «Оценка сделки»;
  • «Переговоры»;
  • «Подписание договора»;

Заявку каждого нового клиента оформляют в виде отдельной карточки — для этого в CRM есть кнопка «Добавить». В задаче указывают источник, который привел клиента, его контакты, подробности заказа, данные ответственного менеджера.

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

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

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

Попробуйте CRM Битрикс24

CRM возьмет под контроль все каналы коммуникаций с клиентами и автоматизирует продажи в вашем бизнесе.

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

  1. Директор маркетингового отдела и ключевые специалисты отбирают площадки для продвижения и команду.
  2. Руководство настраивает этапы на канбан-доске — от создания креатива до запуска, тестирования и анализа.
  3. Каждый канал продвижения оформляют в виде отдельной карточки, например «Объявление в соцсети», «Реклама у блогера», «Телереклама». Чтобы различать задачи, для рекламных площадок используют разные цвета.
  4. На каждый этап и каждую задачу выделяют определенное время. Например, создание и согласование креатива будет занимать неделю, запуск — три дня, наблюдение и анализ результатов — месяц.
  5. Специалисты приступают к выполнению задач. Дизайнеры готовят объявления, SMM-менеджеры — посты для социальных сетей, операторы и монтажеры — ролики для видеохостингов.
  6. Руководители наблюдают за выполнением задач и следят, чтобы на доске не образовывалось узких мест.

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

Частые вопросы

Что такое Kanban и как он отличается от других Agile-методологий?

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

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

Главное отличие Kanban от методологий Agile и Scrum — в универсальности. Техника подойдет и для команд с четкой иерархией, и для тех, где все сотрудники равны. Kanban дополняет Scrum.

Как создать доску Kanban и какие элементы в нее включить?

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

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

Как часто следует проводить совещания и обзоры, работая по доске Kanban?

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

Как можно интегрировать Kanban с другими Agile-методологиями, такими как Scrum?

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

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

Что в итоге

  • Kanban, как и Agile и Scrum позволяет организовать гибкую разработку продукта и сократить время выполнения задач.
  • Наглядность — главная ценность Kanban-доски. Она показывает рабочий процесс как систему взаимосвязанных шагов и помогает отследить статус каждой задачи.
  • Методы Agile, Kanban и Scrum можно внедрить с помощью специализированного программного обеспечения (планировщика, CRM) или обычной доски. Главное — точно определить этапы работы и своевременно менять статус задач.
  • Kanban позволяет быстро выявлять слабые места в рабочем процессе — скопление задач на том или ином этапе, пропущенные сроки. Это называется управлением потоком.
  • Метод Kanban применяют в IT, рекламе, продажах и в других digital-проектах. Если грамотно подберете инструмент, получите все необходимое для успешной работы команды.

Scrum/Agile/Kanban/Lean — как выравнивать процессы, убирать посредников, максимизировать ценность

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

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

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

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

Но давайте вернемся ближе к нашему времени, в начало двадцатого века. В Европе и США идет бурное развитие промышленности, предприятия ищут возможности для повышения эффективности. В США Фредерик Тейлор начал свои подробные исследования в области научной организации труда и менеджмента, а его ученик Генри Гант изучал менеджмент на примере постройки кораблей во время Первой мировой войны и предложил свою диаграмму, состоящую из отрезков (задач) и точек (завершающих задач или вех), как средство для представления длительности и последовательности задач в проекте.

Нам они известны как “Диаграммы Ганта” или Каскадная модель. Они совершили настоящую революцию в управлении проектами в 20-х годах XX века. Диаграммами пользовались во многих грандиозных инженерных проектах, например при строительстве дамбы Гувера и при строительстве сети скоростных магистралей США.

Необходимость перехода к современным методам управления проектами

С момента массового появления в 1980-е годы персональных компьютеров, стало проще создавать самые разнообразные и сложные диаграммы — делать их по настоящему комплексными.Они превращались в подлинные художественные произведения. Абсолютно каждый шаг проекта детально размечен. Любая стадия. Всякая дата. Диаграммы Ганта производят глубокое впечатление. Но есть одна единственная проблема: они всегда неправильны.

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

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

Практически у всех разработчиков того времени встречались одни и те же проблемы:

  • Проекты всегда превышали бюджеты;
  • Реализация проекта всегда превышала первоначальные сроки и зачастую вообще не доходила до завершения;
  • Готовое ПО неэффективно выполняло заявленную функцию;
  • Финальный результат был низкого качества;

Scrum

В 1995 году Кеном Швабером и Джеффом Сазерлендом на OOPSLA 95 в Остине была представлена новая сформулированная и задокументированная методология ведения проектов при разработке ПО. Назвали ее Scrum (Схватка — термин взятый из регби).

Ее разработкой и внедрением Д. Сазерленд занимался во время своей работы в компании Easel в 1993 году. Перед ним стояла задача в очень сжатые сроки создать абсолютно новую линейку ПО. Он решил отказаться от каскадной модели ведения проекта и занялся поиском оптимального решения.

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

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

Итак давайте рассмотрим основные принципы Scrum:

  • Работа короткими циклами (Спринт). Проект разделяют на части, которые называют Спринтами. Продолжительность Спринта от 1 до 4 недель. За это время команда берет на себя некоторое количество задач. Которые она стремится выполнить в этот временной отрезок.
  • Гибкость. После окончания каждого спринта, команда собирается для обсуждения и выявления слабых и сильных моментов, учитывает их и при необходимости корректирует Бэклог (список задач).
  • Постоянное взаимодействие с заказчиком. В составе Scrum-команды есть «Владелец продукта», человек который взаимодействует с заказчиком, показывает ему результаты работы, уточняет потребности и его пожелания. Благодаря этому взаимодействию удается оперативно изменять и уточнять реальные потребности заказчика.
  • Командная работа. В команду обычно входите не более 6-10 человек с необходимыми для выполнения проекта компетенциями и навыками.

Гибкость Agile методик

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

Ценности и принципы Agile:

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

К основные методологиям Agile относятся Scrum, Kanban и Lean. Scrum мы уже рассмотрели, а что из себя представляют Kanban и Lean. Они тоже пришли к нам из Японии, и родственны философии бизнеса Кайдзен и Тойоту.

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

Что касается Lean, то это больше философия и набор методик для создания бизнеса и подхода к разработке. Она подробно описана в книге Lean startup Эрика Риса.

Характерно для Lean:

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

Основные преимущества Scrum в сравнении с каскадным методом

В чем же отличие Scrum от Каскадной системы управления проектом?

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *