Agile – гибкие методологии разработки – История

View Github Repository Open presentation in a new window

kio21

See all presentation from kio21

Agile – гибкие методологии разработки – История

0 1

agile-slides

On Github kio21 / agile-slides

Agile

гибкие методологии разработки

История

— 1950 :  возникновение
  • сверх талантливые люди решали проблемы в несложных программных средах
— 1960 :  выход в свет
  • университеты - "компьютерные курсы"
  • отсутствие персональных средств компиляции
— 1970 :  десятилетие хаоса
  • появление ПК

История

— 1980 :  возрождение
  • вспомогательные средства программирования
  • формальные методы
— 1990 :  совершенствование
  • совершенствование процесса разработки программ
  • 1995 - Scrum
  • 1996 - XP, Lean, Kanban
— 2000 :  развитие
  • гибкие методологии разработки
  • 2001 - agile-манифест

История

— 2010 :  кооперация
  • DevOps - усиление кооперации между группами разработки (DEVelopments) и эксплуатации (OPerations)

Каскадная модель

(Традиционная, или модель Водопад, Waterfall)

  • 1970 - Уинстон Ройс "Управление разработкой крупных программных систем"
  • 70е - 80е - стандарт министерства обороны США

Каскадная модель

Каскадная модель

Минусы

  • Возвращение на предыдущий этап не предусмотрено
  • Чем больше проект тем больше накапливается проблем в процессе разработки
  • При появлении критических ошибок весь проект начинается сначала

Каскадная модель

Плюсы

  • Строгие требования и высокая степень формализации
  • Дисциплиннированность"пишем и правим"
  • 1. Понимание целей 2. Реализация продукта

Спиральная модель

(Spiral model)

  • 1988 - Барри Боэм "Спиральная модель разработки и улучшения ПО"

Спиральная модель

Спиральная модель

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

Спиральная модель

Плюсы

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

Спиральная модель

Минусы

  • Определение момента перехода на следующий этап

Итеративная модель

(Iterative and incremental development, IID)

  • Истоки — 1930е года
  • Принцип разделения на итерации
  • Каждая итерация — мини-проект
  • Важная веха — проект по разработке самолета X-15

Итеративная модель

Плюсы

  • Ранняя обратная связь
  • Возможность "отката"

Итеративная модель

Минусы

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

Гибкие методологии

Итак, что мы имеем. Существующие методики разработки ПО, зачастую принятые в качестве стандартов разработки во многих крупных компаниях и даже странах на государственном уровне, содержали ряд трудноустранимых недостатков. Как-то накопление проблем в крупных проектах для каскадной модели, неопределенность со сроками в спиральной и снижение дисциплинированности в итеративной. Стоимость разработки проектов увеличивалась, количество успешно завершенных в сроки проектов уменьшалось а количество ошибок в них увеличивалось. В этих условиях начали зарождаться группами разработчиков ведомыми увлеченными талантливыми людьми новые методологии, менее строгие в плане формальных требований но позволяющие достигать конкретных результатов и поставленных целей. Эти меодологии стали называться гибкими. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной методологии. Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. При таком длительном консервативном подходе программный продукт может устареть еще до релиза.
  • Принцип разделения на итерации
  • Человеческий фактор
  • Конечный продукт
  • Ограничения по времени

Agile-манифест

Появление гибких методологий не привязано к конкретной дате. Как уже было упомянуто начиная с середины 90х годов они начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Итак, как я уже упомянул в краткой исторической справке, в феврале 2001 года, в штате Юта, на горнолыжном курорте, представители различных гибких методологий разработки собрались вместе и написали манифест гибкой методологии разработки ПО. Созданный Agile-манифест провозгласил философию гибких методологий разработки и задал вектор развития данных методологий. Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану

agilemanifesto.org

Визуализация ценностейманифеста гибкой разработки

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

Гибкие методологии

Термин Agile

Как написано на сайте магифеста, единственное сомнение по поводу термина agile было у Мартина Фаулера и было связано с его произношением. Аргументировал он, будучи бритом, его тем что большинство американцев не знает как произносить это слово.
  • Мартин Фаулер - сомнения по произношению

Agile: произношение

Если у кого-то всё-равно возникают сложности или вопросы по произношению слова agileб можете поискать примеры в интернете. Например на ютубе можно найти много роликов где демонстрируется произношение этого слова. Некоторые из них довольно скучные. Я вот нашел такой ролик с симпатичной тётечкой :-)

sozoexchange.com : AGILE - DP208

Гибкие методологии

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

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

(Extreme Programming, XP)

Практики экстремального программирования можно разделить условно на управленческие и инженерные. К сожалению, в связи с ограниченным количеством времени я не могу подробно остановиться на каждой практике. Добавлю только что обычно инженерны практики активно используются вместе со скрамом. Непрерывная интеграция. Практика непрерывной интеграции заключается в использовании специального программного обеспечения, которое получает свежую версию исходного кода проекта, и производит сборку. В сборку проекта обязательно входит запуск автоматических тестов. Побочным продуктом являются разного рода отчеты о проекте Разработку с тестами. При таком подходе программист пишет код, а затем автоматизированные тесты для него для проверки корректности. Разработка через тестирование. Экстремальное программирование идет дальше и превращает проверку качества в инструмент для создания спецификации и архитектуры. Для этого этап написания тестов переноситься в начала цикла разработки. Стадии: - написание неработающего теста; - минимальными усилиями заставляем тест работать; - рефакторинг – устраняем дублирования и приводим код в порядок; Рефакторинг – это изменения исходного кода без изменения функциональности для улучшения внутреннего качества. Парное программирование. При парном программирование код пишется двумя разработчиками за одним компьютером, причем один из разработчиков играет роль «пилота», а второй роль «штурмана». Пилот (тактика): кодирует, отлаживает, пишет тесты; Штурман (стратег): прорабатывает архитектуру на уровне классов, проводит инспекцию кода, проверяет код на ошибки, придумывает тесты. Простота архитектуры и метафора системы. Поскольку мы работаем итеративно, нам важно иметь максимально простую архитектуру, в которую будет возможно быстро и дешево внести изменения. С другой стороны мы можем для улучшения понимания системы придумать метафору, которая будет ее описывать. Или, в крайнем случае, подобрать понятие из предметной области нашего приложения. Хорошим примером здесь может служить «корзины» в Интернет магазинах или «окна» в графическом интерфейсе операционных систем. Коллективное владение кодом. - обеспечивает кроссфункциональность участников команды; - быстрое распространение знаний между участниками команды. Стандарт кодирования. Для реализации этой практики необходимо использовать стандарты кодирования, чтобы код, написанный разными участниками команды, был одинаков с точки зрения оформления. Проверку на соответствие стандартам лучше всего осуществлять на этапе сборки проекта в автоматическом режиме. 40-часовая рабочая неделя. Это гарантия для команды от перегрузок, одного из вида потерь в бережливом производстве. Надо очень четко понимать, что количество отработанных часов не равно количеству сделанного функционала, как и в любой интеллектуальной и инженерной деятельности.

Канбан (Kanban, 看板)

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

Скрам

Скрам

Подход впервые описали Хиротака Такэути[1] и Икудзиро Нонака[2] в статье The New Product Development Game (Гарвардский Деловой Обзор[3], январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Злые проблемы, справедливые решения»[4] ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такэути и Нонакой.
  • Хиротака Такэути и Икудзиро Нонакастатья The New Product Development Game
  • Небольшие команды из специалистов различного профиля
  • Scrum - толкотня, схватка вокруг мяча в регби

Скрам: драка за мяч в регби

Регби Кубок Европейских наций России - Грузия 9:23 Сборная России по регби встретилась с командой Грузии на Центральном стадионе в Сочи 23 февраля. После развала СССР, грузины являются сильнейшими на постсоветском регбийном пространстве. Впервые национальные команды суверенных государств встретились на поле 20 лет тому назад – весной 1993 года. За два десятилетия "медведи" ни разу не смогли одержать верх в этих поединках. Как для россиян, так и для грузин эти встречи всегда носят принципиальный характер.

Регби, Кубок Европейских наций, России - Грузия, 23 февраля 2013

Скрам: основатели

Кен Швабер[5] в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом[6] на OOPSLA’96[7] (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом[8] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM» Ken Schwaber and Jeff Sutherland

Джеф Сазерленд и Кен Швабер

Скрам: выход в свет

In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation.[4] Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. Швабер объединил усилия с Майком Бидлом[8] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM»[9].
  • 1995 - Объектно-ориентированное программирование, системы, языки и приложения. (OOPSLA '95) Остин, штат Техас
  • 2001 - «Гибкая разработка ПО со Скрам», Кен Швабер и Майк Бидл
  • Официальное «Руководство по Скраму» - scrum.org

Скрам: одной фразой

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

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

Скрам: ещё одной фразой

Или ещё одной фразой :-) Скрам - это фрэймворк для управления процессом создания продукта высокого качества. Поэтому скрам ещё называют управленческим фрэймворком.

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

Скрам: одной схемой

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

Элементы скрам

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

Скрам Команда

Для начала дам краткое определение каждого термина, чтобы все знали о чем идет речь.
  • Владелец Продукта (Product Owner)человек, отвечающий за комплектацию спринтов и за приоретизацию задач
  • Команда Разработчиков (Development Team)люди, непосредственно реализующие инкремент спринта
  • Скрам Мастер (Scrum Master)человек в команде, отвечающий за Скрам

Артефакты

  • Журнал Продукта (Product Backlog)список требований, по выполнении которых разработка продукта будет считаться завершенной
  • Журнал Спринта (Sprint Backlog)часть журнала продукта отобранная для спринта
  • Инкремент продукта (Increment)новая функциональность продукта, созданная во время спринта

Мероприятия

  • Спринт (Sprint)одна полная итерация процесса разработки
  • Планирование Спринта (Sprint Planning)отбор задач на спринт
  • Ежедневные Скрамы (Daily Scrum)ежедневная планерка для всей команды
  • Обзор Спринта (Sprint Review)встреча в конце спринта для показа владельцу функционала продукта, сделанного за спринт
  • Ретроспектива Спринта (Sprint Retrospective)обсуждение результатов спринта

Скрам Команда

Владелец Продукта

Speaker notes.
  • Один человек
  • Определяет требования к продукту, знает, каким он должен быть в итоге
  • Определяет дату релиза
  • Корректирует приоритеты на каждой итерации
  • Принимает работу

Владелец Продукта

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

Команда Разработчиков

Команда Разработчиков состоит из профессионалов, выполняющих работу по разработке потенциально “готового” к выпуску Инкремента продукта в конце каждого Спринта. Инкремент создают только члены Команды Разработчиков. Команды Разработчиков являются структурированными и уполномоченными организацией самим организовывать и управлять своей работой. Эта синергия усиливает продуктивность и эффективность работы Команды Разработчиков. Командам Разработчиков присущи следующие характеристики: Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности; Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта; Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений; Отдельные члены Команды Разработчиков могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым. У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа
  • Самоуправляемы
  • Кроссфункциональны
  • Одна должность - Разработчик
  • Ответственность лежит на всей Команде Разработчиков
  • У Команды Разработчиков нет структурных подразделений

Команда Разработчиков

Размер

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

от 5 до 9 человек

Скрам Мастер

Speaker notes.
  • Понимание Скрама всеми участниками
  • Понимает и практикует гибкие методы разработки и управления
  • При необходимости проводит мероприятия Скрама
    • Планирование и запуск Спринта
    • Обзор и ретроспектива Спринта
  • Мониторинг социальных аспектов команды и поддержание командного духа

Мероприятия

Спринт

Скрам проекты развиваются сериями "спринтов", другими словами - итерациями Типичная продолжительность – от 2 до 4 недель с жестким ограничением по времени
  • Скрам проекты развиваются сериями "спринтов"
  • Типичная продолжительность – от 2 до 4 недель с жестким ограничением по времени
  • Постоянная продолжительность спринта привносит ритм в разработку
  • Продукт проектируется, разрабатывается и тестируется на протяжении одного спринта

Спринт: параллельная разработка

Speaker notes.

Никаких изменений в течении спринта

Speaker notes.
  • Планируйте длительность спринта исходя из соображения о том, как долго вы можете работать, не внося изменения в план работ

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

  • Команда выбирает из Бэклога Продукта требования, которые они могут реализовать за спринт
  • Создается Бэклог Спринта
  • Задачи идентифицируются и оцениваются (1-16 часов)
  • Все делается командой, а не Скрам Мастером
  • Учитывается высокоуровневая архитектура приложения

Ежедневный скрам

  • Характеристики
    • Ежедневно
    • 15 минут
    • Стоя
  • Не для решения проблем
    • Приглашены все желающие
    • Только участники команды могут говорить (владелец продукта - тоже часть команды)
  • Скрам Мастер лишь ведет собрание

Каждый отвечает на три вопроса

  • Это НЕ статусный отчет Скрам Мастеру
  • Это обязательства перед коллегами

Обзор Спринта

  • Команда представляет, что было сделано за спринт
  • Фокус на результат, а не процесс
  • Обычно принимает форму демонстрации
  • Неформально
    • Максимум 2 часа на подготовку
    • Без слайдов
  • Вся команда участвует
  • Приглашены все, кому может быть интересно

Обзор Спринта: обратная связь

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

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:  Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;  Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;  Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
  • Периодический пересмотр того, что работает, а что нет
  • Обычно 15-30 минут
  • После каждого спринта
  • Участвует вся команда
  • Можно пригласитьВладельца Продукта

Структура ретроспективы

Каждый отвечает на три вопроса

Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса. Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения. Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале Другой вариант, что мы хотим: Начать, Продолжить, Прекратить Что было сделано хорошо? Что можно улучшить? Какие улучшения будем делать?
  • Основное правило«В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»

Артефакты

Артефакты

Журнал продукта

Определении важности (приоритета) и оценки истории пользователя - отдельная наука.
  • Список требованийоформляются в виде историй пользователя
    • Уникальный числовойидентификатор истории
    • Название историипользователя
    • Важность
    • Оценка (сторипоинты)

Журнал продукта: планирование

Speaker notes.
  • Конфликт при выборе размера Журнала Продукта

Метод накатывающей волны

«rolling wave planning»

Speaker notes.
  • Большие куски функциональности, в дальнейшем будут разбиты на маленькие
  • Называются «эпиками» («epic»)

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

Покер-планирование

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

Покер-планирование

  • Выбор эталонной задачи в 1 сторипоинт
    • простая и понятная для команды
    • типичная для данного проекта
    • небольшого размера
  • Для оценки используетсядискретная логарифмическая шкала

Покер-планирование: раунд 1

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

Покер-планирование: раунд N

  • Начинают обсуждение обычно с крайних оценок
  • Срам Мастер следит за временем

Покер-планирование: консенсус

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

Покер-планирование: расклад

Как осуществляется мониторинг прогресса?

Диаграмма сгорания

(Sprint burndown chart)

Доска задач

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

Доска задач

Команда делает задачи по важности, начиная с самых верхних, доводя их до статуса «Готово».
  • Команда делает задачи по важности,начиная с самых верхних,доводя их до статуса «Готово»

Доска задач

Если все истории пользователей удалость реализовать, то в завершении спринта доска будет выглядеть так:
  • Вид диаграммы в конце спринта,если удалось реализовать все истории

Доска задач

Еще одним способом использования доски является следующий подход:  Истории пользователей берутся достаточно большие (3-7 на спринт) и располагаются в отдельном столбце;  Истории пользователей разбиваются на небольшие продуктовые задачи, которые и передвигаются по состояниям по соответствующей дорожке.
  • Достаточно большие истории в отдельном столбце
  • Истории разбиваются на небольшие задачи

Использованные материалы