Схема управления проектами, часть 1: всестороннее сравнение Agile, Scrum, Kanban и Lean

Обзор

Сегодня в разработке программного обеспечения используется множество методологий. Возможно, вы слышали такие модные словечки, как Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming и т. д.

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

Бережливая методология

Истоки бережливого производства и бережливого производства

Термин «бережливое производство» берет свое начало в производстве, где он был придуман для описания производственной модели, основанной на производственной системе Toyota (TPS), первоначально разработанной Сакичи Тойода, Киитиро Тойода и Тайити Оно, которые изначально были вдохновлены Генри Фордом. TPS была ориентирована на философию «полного устранения всех отходов» и произвела революцию в производстве с 1950-х по 1970-е годы. TPS стала известна как «Бережливое производство» в 1990 году, когда была опубликована книга «Машина, изменившая мир».

TPS определила три основных типа потерь в Toyota:

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

  • Излишняя обработка: из-за плохой оснастки или дизайна продукта

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

TPS работала над устранением отходов, применяя эти две основные концепции:

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

По мере развития TPS эти основные принципы и ценности основывались на концепциях дзидока и «точно вовремя» и закреплялись:

• Непрерывное улучшение:
  • Вызов: формирование долгосрочного видения и смелое и креативное решение проблем для реализации мечты.
  • Кайдзен: непрерывное совершенствование бизнес-операций, постоянное стремление к инновациям и развитию, устранение одной муда за раз
  • Genchi Genbutsu : практика genchi genbutsu, обращение к источнику, чтобы найти факты для принятия правильных решений, достижения консенсуса и достижения целей с максимальной скоростью.
• Уважение к людям:
  • Уважение: уважать других и прилагать все усилия, чтобы понять друг друга, брать на себя ответственность и делать все возможное, чтобы построить взаимное доверие.
  • Командная работа: стимулирование личного и профессионального роста, совместное использование возможностей для развития и максимальное повышение индивидуальной и командной производительности.
• Андон: визуальный индикатор состояния или проблемы
• Хейдзунка: означает выравнивание или выравнивание производства.
• Хансей: означает саморефлексию. Чтобы повысить эффективность, работники должны подвергнуть сомнению предположения, лежащие в основе текущих процессов, чтобы найти лучшие.
• Канбан: вывеска, используемая как визуальный инструмент для управления производством.
• Пока-ёкэ: также называется защитой от ошибок или защитой от ошибок.
• Система вытягивания: материал вытягивается на рабочую станцию ​​по мере необходимости.
• Seiri: это принцип, который отражает отходы. Сейри диктует, что ненужное должно быть удалено. Это включает в себя все первоначальные семь отходов TPS.
• Стандартизация: все работы организуются вокруг человеческого движения и создается эффективная производственная последовательность без муда. Это помогает обеспечить качество, постоянный темп и позволяет постоянно совершенствоваться.

На приведенной ниже диаграмме показано, как основные концепции и основные ценности соотносятся друг с другом.

Бережливое управление

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

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

1. Определить ценность: указать ценность с точки зрения конечного потребителя по семейству продуктов.
2. Сопоставьте поток создания ценности: определите все шаги в потоке создания ценности для каждого семейства продуктов, по возможности исключив те шаги, которые не создают ценности.
3. Создайте поток: сделайте так, чтобы шаги по созданию ценности происходили в четкой последовательности, чтобы продукт плавно поступал к покупателю.
4. Установить вытягивание: по мере введения потока позвольте клиентам извлекать выгоду из следующего вышестоящего действия.
5. Стремление к совершенству: по мере определения ценности идентифицируются потоки создания ценности, удаляются ненужные шаги и вводятся потоки и вытягивания, снова начинайте процесс и продолжайте его до тех пор, пока не будет достигнуто состояние совершенства, при котором совершенная ценность создается без потерь.

Эти принципы и другие аспекты управления бережливым производством были формализованы, когда Womack & Jones опубликовали книгу «Бережливое мышление» в 1996 году.

Бережливая разработка программного обеспечения

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

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

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

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

Это общее разочарование привело к тому, что различные лидеры мысли пытались улучшить Waterfall. Ранние примеры включают быструю разработку приложений (RAD), которая была направлена ​​на сокращение потерь за счет сокращения требований и этапов проектирования за счет быстрой разработки прототипа и сотрудничества с бизнесом для дальнейшей разработки требований. Был также переход к итеративной разработке, когда небольшой проект завершался, а функции добавлялись в непрерывных итерациях. Хотя эти методологии помогли, они не решили основные проблемы, связанные с Waterfall.

В 1990-х и начале 2000-х несколько авторов опубликовали книги о применении принципов бережливого производства к разработке программного обеспечения. Доктор Роберт Шаретт опубликовал «Бережливую разработку программного обеспечения» в 1993 году и «12 принципов бережливой разработки программного обеспечения» в 2003 году.

Том и Мэри Поппендик опубликовали книгу «Бережливая разработка программного обеспечения: набор инструментов Agile» в 2003 году. В этой книге подробно описаны семь принципов бережливой разработки, которые напрямую связаны с семью формами потерь в бережливом производстве. Сходства и различия между двумя разными публикациями по Lean и Agile (обсуждаемыми в следующем разделе) показаны на диаграмме ниже.

Различия между Lean и Agile

По словам доктора Шаретта, одно из основных различий между Lean и Agile заключается в том, что Agile работает снизу вверх, а Lean — сверху вниз.

Гибкая структура

Истоки Agile и манифест Agile

Примерно в то же время, когда Шаретт и Поппендики опубликовали свои книги, была создана Agile Framework, помогающая решать те же проблемы. В феврале 2001 года группа пионеров Agile встретилась на печально известном собрании Snowbird в Сноуберде, штат Юта, чтобы попытаться найти решение.

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

Манифест Agile гласит:

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

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

То есть, хотя элементы справа имеют ценность, мы больше ценим элементы слева».

С ценностями манифеста согласуются 12 принципов, лежащих в основе Agile-манифеста:

«Мы следуем этим принципам:

1. Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуйте меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
3. Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, отдавая предпочтение более коротким временным рамкам.
4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
7. Работающее программное обеспечение является основным мерилом прогресса. Гибкие процессы способствуют устойчивому развитию.
8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота — искусство максимизировать количество невыполненной работы — имеет важное значение.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение».

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

Agile-принципы, применяемые к разработке программного обеспечения

Agile — это зонтичная структура, которая применяется к любому процессу, применяющему набор ценностей и принципов Agile.

Некоторые примеры:

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

Скрам

Краткая история Scum

Scrum — это фреймворк, в котором применяются принципы Agile, изобретенные по отдельности несколькими людьми, некоторые из которых подписали Манифест Agile:

• Хиротака Такеучи и Икуджиро Нонака впервые ввели термин «Scrum» в контексте производства в своем официальном документе «Игра в разработку нового продукта». опубликовано в 1986 году в Harvard Business Review.
• Джефф Сазерленд, Джон Скумниоталес и Джефф МакКенна внедрили Scrum в Easel Corporation в 1993 году.
• Кен Швабер использовал то, что впоследствии стало Scrum, в своей компании Advanced Development Methods в 1990-х годах.

Швабер и Сазерленд сотрудничали на протяжении 1990-х годов, разрабатывая и совершенствуя структуру в контексте разработки программного обеспечения, выступая на различных конференциях. Швабер работал с Майком Бидлом, чтобы описать этот метод в книге «Гибкая разработка программного обеспечения с помощью Scrum» в 2001 году.

Швабер создал оба основных центра сертификации Scrum:

• Scrum Alliance: создан в 2001 году. Организовал серию аккредитаций Certified Scrum .
• Scrum.org: создан в 2009 году после того, как Швабер покинул Scrum Alliance. Настройте параллельную серию аккредитации Professional Scrum .

Со временем было создано несколько фреймворков/органов по сертификации для масштабирования фреймворка Scrum на более крупные команды и проекты, поскольку Scrum изначально был разработан для небольших команд (7 плюс-минус 2 члена):

• SAFe: масштабируемая гибкая структура
• LeSS: крупномасштабный скрам
• Scrum@scale: Scrum at Scale, созданный Джеффом Сазерлендом.

Скрам-ценности

Согласно Scrum Alliance:

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

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

Обзор Скрама

Работа делится на короткие ограниченные по времени итерации, называемые спринтами, которые обычно длятся 1-3 недели. Это резко контрастирует с детальным планированием Waterfall. Работа, запланированная на текущий спринт, выбирается из списка приоритетных задач, называемых Журналом работы по продукту (система вытягивания, хейдзунка), и фиксируется после начала спринта. Цель состоит в том, чтобы иметь работающее программное обеспечение в конце каждого спринта, что обеспечивает быструю обратную связь.

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

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

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

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

Скрам Роли

Скрам имеет три роли:

• Скрам-мастер : Скрам-мастер — это лидер-слуга Скрам-команды. Они являются наставниками команды, которые помогают наладить совместную работу, устраняют препятствия, внедряют и защищают процесс Scrum, а также защищают команду. Обычно это означает, что они организуют и облегчают ритуалы спринта, следят за тем, чтобы владелец продукта имел должным образом расставленные по приоритетам и ухоженные невыполненные работы, следили за тем, чтобы на команду не оказывалось давление с целью переусердствовать спринтом, следили за тем, чтобы объем не добавлялся к спринту. sprint, гарантирует соблюдение определения готовности. Они не назначают задачи членам команды (Genchi Genbutsu) и не несут ответственности за выполнение проекта.
• Владелец продукта : владелец продукта — это «единственная сгибаемая шея», ответственная за доставку продукта. Владелец продукта определяет видение того, что он хочет создать, и передает это видение команде и организации. Владелец продукта владеет требованиями бизнеса и рынка и расставляет приоритеты во всей работе, которую необходимо выполнить, создавая и управляя бэклогом продукта. Они решают, какие функции и когда отправлять. Они работают с командой и другими заинтересованными сторонами, чтобы убедиться, что все понимают элементы в бэклоге продукта. Они принимают или отклоняют работу, выполненную в спринте, на демонстрации спринта.
• Член команды : Скрам-команда — это самоорганизующаяся межфункциональная команда, обычно состоящая из пяти-семи человек. Все в проекте работают вместе и помогают друг другу и не обязательно связаны отдельными ролями, такими как архитектор, программист, дизайнер или тестировщик. Все вместе выполняют комплекс работ. Скрам-команда планирует, сколько работы они могут выполнить в каждом спринте, и владеет планом (Генчи Генбуцу).

Scrum Flow, мероприятия и церемонии

Как обсуждалось выше, у Scrum есть определенный поток и набор ритуалов и действий. Ход спринта следующий.

Планирование спринта:

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

Обычно это делается с помощью следующих действий:

• Мощность спринта: команда определяет мощность спринта с учетом количества дней, количества членов команды, праздников и т. д.
• Цели спринта: владелец продукта определяет цели спринта. Крайне важно, чтобы бэклог продукта был расставлен по приоритетам в соответствии с целями (т. е. соответствующие истории были наверху) и подготовлен.
• Выбор работы: истории или задачи вытягиваются из верхней части бэклога в спринт до тех пор, пока не будет достигнута расчетная мощность. По мере поступления историй владелец продукта будет объяснять историю и отвечать на вопросы команды, обновляя историю по мере необходимости, пока у владельца продукта и команды Scrum не будет хорошего общего понимания истории. После того, как это действие будет завершено, у команды будет предложенный первоначальный объем спринта.
• Разбивка задач: Скрам-команда подробно обсуждает каждую историю, уделяя особое внимание планированию того, как они будут завершать историю и учитывать все критерии приемлемости и DoD. Они составят список подзадач, необходимых для завершения истории. После того, как список подзадач составлен, оценка истории пересматривается и при необходимости обновляется.
• Обязательства по спринту: после того, как все истории разбиты на части и оценки обновлены, пересматривается предлагаемый первоначальный объем спринта. Истории могут быть удалены из спринта и возвращены в бэклог, и/или могут быть добавлены дополнительные истории. Как только это будет сделано, ТОЛЬКО Скрам-команда (а не Скрам-мастер или владелец продукта) обязуется завершить работу в спринте, и спринт начинается.

Общий объем работы или объем работ, выделенных для спринта, измеряется в баллах.

Выполнение спринта

Во время спринта члены команды берут рабочие элементы (пользовательские истории, задачи и т. д.) из верхней части списка дел спринта для работы. Различные члены команды будут работать над различными рабочими элементами или их подзадачами. Они будут обновлять статус элемента, когда это необходимо, перемещая его из одного столбца в другой (как правило, «Делать»> «Выполняется»> «Тестирование»> «Готово» или какой-либо его вариант) на доске Scrum, пока это не будет сделано.

Прогресс отслеживается с помощью диаграммы выгорания, которая показывает объем выполненной и оставшейся работы, измеряемый в баллах. Оставшиеся баллы истории показаны на оси Y, а оставшееся время показано на оси X. Диаграмма выгорания обновляется, когда истории завершены.

Ежедневно Скрам-мастер фокусируется на:

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

Ежедневный стендап

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

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

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

Завершение спринта

Скрам-мастер организует две церемонии закрытия спринта перед планированием следующего спринта.

Демонстрация спринта

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

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

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

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

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

Управление бэклогом продукта

Создание бэклога продукта

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

Уход за невыполненными работами

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

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

Оценка сюжетных баллов

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

Шкала Фибоначчи (1, 2, 3, 5, 8, 13, 21…) — это наиболее часто используемая шкала, в которой каждое приращение примерно в два раза больше предыдущего (т. е. пятибалльная история более или менее вдвое больше предыдущей). большой, как рассказ из трех пунктов). Иногда используются другие масштабы, такие как размеры футболок (XS, S, M, L, XL) или даже рыбы (песок, золотая рыбка, форель, тунец, кит и т. д.). Подойдет любая шкала, позволяющая сравнивать размер чего-либо относительно другого.

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

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

Оценка Story Points проводится во время подготовительных совещаний, а иногда и во время планирования спринта с помощью Planning Poker:

1. У каждого члена команды/оценщика есть набор карточек.
2. Элементы невыполненной работы обсуждаются по одному, как описано выше.
3. После того, как пункт был полностью обсужден, каждый оценщик в частном порядке выбирает карточку для представления своей оценки.
4. Когда все оценщики сделали свои оценки, они одновременно раскрывают свои карты.
   • Если все оценки совпадают, оценщики выбирают другой элемент невыполненной работы и повторяют тот же процесс.
   • Когда оценки различаются, оценщики обсуждают вопрос, чтобы прийти к консенсусу.

Преимущества оценки по пунктам:

• Быстрый: оценки относятся к уже завершенным элементам невыполненной работы по продукту.
• Достаточно точный: достаточно точный, чтобы дать обзор масштаба, спланировать будущую работу, расставить приоритеты и управлять ожиданиями.
• Охватывает неопределенность: сюжетные точки указывают неизвестный диапазон времени. Выбор из определенной последовательности точек истории, подобной Фибоначчи, позволяет зафиксировать неопределенность.
• Командный спорт: вовлекает всех (разработчиков, дизайнеров, QA, продакт-менеджеров). Использует несколько точек зрения для определения объема работы, но только члены команды, выполняющие работу, могут ее оценить
• Измеряет скорость команды: измеряет, сколько работы команда выполняет за спринт, по сравнению с количеством времени, затраченным на выполнение работы. По мере того, как команда совершенствуется, они будут быстрее завершать истории того же размера, что приводит к более высокой скорости создания сюжетных точек с течением времени.

Оценка выпуска и отслеживание

Оценка по пунктам также используется в контексте планирования выпуска с использованием следующего метода:

1. Перечислите все истории, которые нужно измерить
2. Расположите их по порядку от меньшего к большему
   • Возьмите первую и вторую пользовательскую историю.
   • Решите, что больше, и поместите большее ниже
   • Затем возьмите следующий и решите, где он подходит относительно двух других.
   • Повторяйте процесс, пока все истории не окажутся в списке (в порядке от наименьшего к наибольшему).
3. Размер историй

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

Артефакты и термины Scrum

• Бэклог продукта: список невыполненных работ для данного продукта, который может включать функции (истории), технические задачи, всплески и дефекты.
• Выгорание релиза: графическая диаграмма, используемая для отображения прогресса на уровне релиза и прогнозирования, когда релиз будет завершен, с помощью Sprint Velocity. Завершенные баллы истории показаны на оси Y, а спринты показаны на оси X.
• Бэклог спринта: список невыполненных работ, в котором перечислены все рабочие элементы, которые необходимо выполнить в данном спринте. Содержание бэклога спринта согласовывается на совещании по планированию спринта.
• Скрам-доска: доска в виде таблицы, на которой отслеживается ход работы, выделенной для спринта. Статусы отображаются вверху в вертикальных столбцах, и рабочие элементы перемещаются по каждому статусу, пока они не будут выполнены. Скрам-доска заполняется во время совещания по планированию спринта и сбрасывается в конце спринта.
• Спринтерское выгорание: графическая диаграмма, показывающая объем выполненной и оставшейся работы, измеренный в баллах за время спринта. Оставшиеся баллы истории показаны на оси Y, а оставшееся время показано на оси X.
• Скорость спринта: количество баллов, которое команда Scrum набирает за спринт.
• Бэклог препятствий: список препятствий, которые необходимо устранить скрам-мастеру, чтобы команда могла продолжать работу. Когда член команды заблокирован, он добавляет элемент в журнал препятствий, чтобы обеспечить видимость для команды и Scrum Master.
• Эпопея: Эпопея — это большая работа, состоящая из нескольких связанных пользовательских историй.
• Пользовательская история. Пользовательская история — это описание функции программного обеспечения с точки зрения конечного пользователя. Пользовательская история описывает тип пользователя, чего он хочет и почему. Пользовательская история помогает создать упрощенное описание требования и включает критерии приемлемости. Пользовательские истории создаются и поддерживаются владельцем продукта.
• Задача: задача — это часть работы, введенная скрам-мастером или членом команды, которая может быть прямо или косвенно связана с пользовательскими историями. Обычно они носят технический характер и включают критерии приемлемости.
• Всплеск: Всплеск — это особый тип задачи, который используется, когда вам нужно провести исследование, создать прототип и/или спроектировать до того, как вы сможете решить, как реализовать или оценить пользовательскую историю.
• Подзадача: Подзадача — это задача, которая вводится как шаг реализации для завершения пользовательской истории или задачи. Обычно они вводятся командой во время совещания по планированию спринта.
• Оценки Story Point: относительная шкала оценки размеров, основанная на шкале Фибоначчи (1, 2, 3, 5, 8, 13, 21…)
• Критерии приемлемости: список специфических для истории элементов, подлежащих тестированию, включенных в каждую историю, которые должны быть завершены, прежде чем владелец продукта примет историю как завершенную.
• Определение готовности (DoD): список общих шагов или критериев, которые должны быть выполнены, прежде чем любая история может считаться выполненной. Команда соглашается с этим и документирует это, чтобы его не нужно было указывать в каждой истории.

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

Основным преимуществом Scrum является применение ценностей и принципов Agile, а также концепций Lean, таких как Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System и итерации. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Канбан

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.