Agile scrum гибкие методология разработки по

• Название: Agile scrum гибкие методология разработки по
• Анкор: Scrum
• Дата: 06.04.2022
• Размер: 4.94 Mb.
• Имя файла: SCRUM.pptx
• Тип: Документы; #446721

Agile / SCRUM

Гибкие методология разработки ПО

© Валерий Студенников

Курс «Менеджмент разработки ПО»

Валерий Студенников // обо мне

Со-основатель, ex-технический директор и ex-руководитель разработки и ex-архитектор технической инфраструктуры REG.RU

Со-основатель и ex-президент спортивно-туристического клуба «ВелоСамара»

Со-основатель и президент самарской региональной федерации каякинга и sup-серфинга

Со-основатель Electron Bikes (производство электровелосипедов под заказ)

https://vk.com/vstudennikov

Telegram: @xtrueman

[e-mail]

Выставление итоговой отметки (зачёта)

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

«Формула успеха» или какие факторы влияют на автомат (в порядке убывания приоритета):

Командное: Как команда показывала себя на командных встречах (которые проводятся во время лабораторных работ)

обязательное присутствие всех членов команды на общих встречах (на практических занятиях)!

Личное: Участие на "менеджерских" ролях в команде (scrum master, product owner, SDM, SRM, project manager и т.д.)
Командное: Насколько команде удалось продвинуться в разработке продукта
Командное + менеджерское: Насколько команда правильно создавала все артефакты, требующиеся процессом
Личное: Оценка вклада участника команды другими членами команды
Личное: Отчёт каждого члена команды о своей работе за спринт.


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

В случае, если «формула успеха» показывает неутешительные значения — устный зачёт по теории.

Как разработчики разрабатывают ПО?

Водопадные процессы

Недостатки:

Долго ждать от идеи до готового продукта

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

Очень не любит изменения требований к продукту

Изменения вносить очень дорого и сложно

Большие риски

На выходе можем получить совсем не то, что хотел заказчик

Дорого

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

Как снизить риски с помощью итеративной разработки

Модель Кеневин (Cynefin) 5 типов сложности / запутанности систем

Как действуем?

Простые системы — действуем по инструкции
Сложные — классическое управление проектами, водопадные модели разработки
Запутанные — Scrum, Agile и т.п.
Хаотичные — быстрое принятие рискованных решений

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

Ценности Agile:

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

В 2001 года 17 человек собрались на горнолыжном курорте в США). То, что родилось в ходе этой встречи, назвали Agile Manifesto. Были собраны представители, придерживающиеся различных методологий разработки: XP, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и другие тяжеловесы мира разработки софта.

Принципы Agile

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

SCRUM за 5 минут

Scrum: определение

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

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

Основную цель Agile и Scrum часто формулируют как сокращение Time2Market — времени выпуска на рынок новых продуктов / времени их поставки потребителю.

Главные особенности Scrum:

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

Заинтересованные лица (Stakeholders)

Все заинтересованные в продукте лица:

Заказчики
Потенциальные пользователи
Всех кого коснётся использование продукта
«Лицо, дающее обратную связь Владельцу Продукта и Скрам-команде в целом по видению, Бэклогу Продукта и Инкрементам. Нередко участвует в Обзоре спринта. Зачастую является частью организации, которая разрабатывает продукт»

Команда (Team)

самоорганизующаяся и самоуправляемая

сами решают, кто, что, когда и как делает

работа команды оценивается как работа единой группы внутри Scrum Team нет подкоманд и иерархий размер: 7 ± 2 человека, чем меньше — тем лучше кроссфункциональная

в неё входят люди с дополняющими навыками — разработчики, аналитики, тестировщики, дизайнеры, devops и т.п.;
T-Shape

нет заранее определённых ролей и специализаций в команде команда сидит в одном месте или находится в постоянном тесном контакте онлайн (colocation)
работает вместе, помогая друг другу члены команды признают наличие проблем и просят друг друга о помощи

Команда (Team)

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

Вся Scrum Team несет ответственность за создание ценного, полезного Increment в каждом Sprint.

Кроссфункциональность : T-Shaped

I-shaped — умеет только что-то одно

T-shaped — умеет всего понемногу, но что-то умеет лучше

Объясним на примере создания текста для сайта:

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

Кроссфункциональность :: Bus factor

bus factor проекта (команды) — это мера сосредоточения информации среди отдельных членов проекта;

фактор означает количество участников проекта, после потери которых («попадания» которых под автобус, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

Bus-factor 1 — очень плохо!

Большие риски! Что делать? T-shape-иться.

Командная динамика: модель Такмана

При формировании команды или при замене/добавлении туда людей команда проходит этапы:

Forming
Storming
Norming
Performing

Не каждый может быть членом scrum-команды

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

— «Что ты делаешь?» — спросил странник. — «Хозяин приказал носить наверх камни, вот я и ношу», — сердито ответил человек. Пошел странник выше в гору и увидел другого человека, тоже с камнем. — «А ты что делаешь?» — поинтересовался он. — «Да здесь рядом стену новую строят — там камни нужны, за них деньги платят», — тяжело дыша ответил второй человек. Забрался еще выше странник и встретил третьего человека, толкавшего наверх камень. Камень был тяжелым, но глаза человека светились радостью. И ему странник задал тот же вопрос: — «Что ты делаешь?» — «Я строю храм», — спокойно ответил тот.»
Не каждый человек, не каждый разработчик может быть членом scrum-команды:

Нужны высокие soft skills
Нужна готовность работать в команде
Нужна готовность общаться с заказчиком, помогать в продуктовых исследованиях, общаться с пользователями
Быть вовлечённым в разработку продукта


PO — человек, отвечающий за разработку продукта

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

PO — это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет

Хотя у PO может быть своя команда (аналитиков, продуктологов и т.п.) — команда PO
Это позволяет избежать проблемы множественности заказчиков

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

Владелец продукта:

Отвечает за формирование концепции продукта (Product Vision)
Работает с заинтересованными лицами (Stakeholders)
Принимает готовое
Рассчитывает ROI (бизнес-эффект)
Ведёт беклог продукта (Product backlog)

Выставляет приоритеты

Инициатор изменений (может в т.ч. «уволить» команду)
Постоянно делится информацией
Обеспечивает ресурсами

Скрам-мастер (Scrum Master)

SM — один из членов команды

он может быть разработчиком, тестировщиком, аналитиком и т.д.

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

например, если команде нужен новый сервер, то именно скрам-мастер вступит в бой с бюрократическими силами компании.

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

Скрам-мастер (Scrum Master)

Помогает внедрять скрам
Отвечает за процесс (как)
Учитель
Наставник / коуч
Модератор (на всех встречах)
Сторожевой пёс (бдит соблюдение процессов)
Защитник (команды)
Устраняет помехи (для команды)

События Scrum

Разработка ведётся итерациями (спринтами).

Sprint — это контейнер для всех остальных событий:

Вначале спринта: Планирование спринта (Sprint Planning)
Ежедневно: Стендап / Дейли (Standup, Daily meeting, Daily scrum)
В конце спринта: Демо / Ревью спринта (Demo, Sprint Review)
В конце спринта: Ретроспектива (Sprint Retrospective)

Итерация / спринт (Sprint)

В конце каждой итерации (спринта) демонстрируется полностью доделанная за итерацию функциональность (product increment).
Длина итерации — от 1 до 4 недель. Типичная длина итерации — 2 недели.

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

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

Примеры

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

Итерация / спринт (Sprint)

В конце итерации есть готовый инкремент продукта (product increment).
Фичи, которые начинаются в эту итерацию, в ней же и доделываются

Разработка фичи включает тестирование и исправление найденных багов

Команда соблюдает приоритеты фич, установленные PO
В большинстве случаев команда делает то, что было запланировано: иногда чуть больше, иногда чуть меньше
Команда сообщает PO, когда отстаёт от плана итерации

В случае отставания от плана команда предпринимает корректирующие действия

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

Планирование итерации / спринта (sprint planning)

Встреча, на которой команда и PO планируют итерацию.
PO ставит цели спринта и представляет фичи (пользовательские истории, user stories)
Команда декомпозирует фичи на технические задачи и совместно оценивает их.
Итоговый план таймбоксится, то есть в него включаются только те фичи, которые команда планирует успеть сделать в итерации

Для таймбоксинга спринта используется Скорость (Velocity) команды

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

PO и члены команды участвуют все (очень желательно, лично)
Результат встречи — цель спринта (sprint goal) и план итерации (sprint backlog)
User story декомпозируются на тех. задачи.
Все технические задачи имеют оценки
Все члены команды согласны с тем, что план может быть выполнен за итерацию
Каждая фича имеет приоритет внутри итерации
На планировании итерации технические задачи не назначаются на конкретных людей

В ходе Sprint Planning рассматриваются следующие темы:

Почему этот Sprint ценен? Product Owner предлагает, как можно повысить ценность и практичность продукта в текущем Sprint. Затем вся Scrum Team совместно определяет цель спринта Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц
Что может быть готово в этом Sprint? Developers обсуждают с Product Owner, какие элементы Product Backlog выбрать для включения в текущий Sprint. Предварительно проводят оценку трудоёмкости в Story points с помощью Planning Poker.
Как будет выполняться выбранная работа? Developers для каждого выбранного элемента Product Backlog планируют работу, необходимую для создания Increment. Это делается путем декомпозиции элементов Product Backlog на более мелкие задачи продолжительностью не более одного дня.

Sprint Goal, выбранные элементы Product Backlog, плюс план их реализации вместе называются Sprint Backlog.

Пользовательские истории (User Story)

User Story (пользовательская история) — короткая формулировка намерения пользователя и что продукт должен сделать для него.

Для чего применяется User Story?

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

Дейли / стендап (Daily scrum)

Стендап / Дейли (Standup, Daily meeting, Daily scrum).

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

Проводит митинг скрам-мастер. Он спрашивает по кругу всех членов команды, задавая 3 вопроса:

1. Что сделано вчера

2. Что будет сделано сегодня?

3. С какими проблемами столкнулся / нужна ли помощь?

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

Дейли / стендап (Daily scrum)

Проводится в одно и то же время в одном и том же месте
Длительность — не более 15 минут
Начинается и заканчивается вовремя (дисциплина!)
Все члены команды участвуют и отвечают на 3 вопроса
Стендап не прерывается
Члены команды сами выбирают задачи на стендапе

Скрам-мастер не раздаёт задачи!

Члены команды обращаются друг к другу, а не отчитываются перед скрам-мастером или менеджером

Демо (Demo) / Ревью спринта (Sprint Review)

Цель демо — рассказать PO и всем Stakeholders о прогрессе и получить с них обратную связь.
Демо проводится в конце каждой итерации.
Команда показывает результаты своей работы, последовательно показывая сделанные фичи / пользовательские истории.
Показывается работающая система (не презентации и не написанные классы)
Показываются только сделанные фичи (не доделанные — не показываются)
Все заинтересованные лица приглашаются на демо
Команда получает от заинтересованных лиц обратную связь
PO корректирует Product backlog в соответствии с пожеланиями заинтересованных лиц

Ретроспектива спринта (Sprint Retrospective)

Цель Sprint Retrospective — запланировать повышение качества и эффективности.

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

Артефакты Scrum

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

Все должны иметь доступ к артефактам.

Product Backlog
Sprint Backlog
Product Increment
Доска задач (Task Board)
Графики / диаграммы

Burndown chart
График скорости команды Velocity

Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum Team.

Product Backlog продукта может включать:

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

Приверженность: Product Goal (цель продукта)

содержит фичи (user story), а не технические задачи виден каждому обновляется перед планированием спринта
PO управляет и координирует backlog
PO понимает все фичи / пользовательские истории из бэклога

Product Backlog Grooming

Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовности в течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning.
Уточнение Product Backlog (Backlog Grooming) — это процесс разбиения элементов Product Backlog на более мелкие и конкретные элементы, и их дальнейшего уточнения. Это деятельность по добавлению деталей, таких как описание, порядок и размер. Оценку размера элементов производят Developers, которые будут выполнять работу.
Product Owner может влиять на Developers, помогая им понять элементы и обсуждая компромиссы.

План итерации / бэклог спринта (Sprint Backlog)

Sprint Backlog состоит из Sprint Goal (почему), набора выбранных на Sprint элементов Product Backlog (что), а также осуществимого плана действий по поставке Increment (как).

План итерации — набор фич (user story) и задач (на которые фичи декомпозируются), которые команда собирается выполнить в итерацию.

План итерации поддерживается командой в актуальном состоянии в течение итерации.

Чеклист:

Все видят план итерации
Для каждой фичи из бэклога указаны критерии приёмки / сценарий демонстрации
Каждая фича на плане декомпозируется в технические задачи
Оценки и приоритеты задач при необходимости корректируются членами команды в течение итерации
Члены команды регулярно актуализируют план

Приверженность: Sprint Goal (цель спринта)

Цель спринта (Sprint Goal)

Цель спринта (Sprint Goal) — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal, она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для ее достижения.
Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum Team работать совместно, а не над отдельными инициативами.
Sprint Goal создается во время Sprint Planning, а затем добавляется в Sprint Backlog.
Разработчики помнят о Sprint Goal в ходе работы над задачами Sprint.
Если работа не соответствует ожиданиям, они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal.

Инкремент продукта (Product Increment)

Increment — это конкретная ступенька к достижению Product Goal.
Каждый Increment является дополнением ко всем предыдущим.
Чтобы предоставить ценность, Increment должен быть пригодным для использования.
В рамках одного Sprint можно создать несколько Increments. Итоговые Increments представляются в ходе Sprint Review
Increment может быть поставлен заинтересованным лицам еще до окончания Sprint. Sprint Review не должно считаться единственным моментом для поставки ценности.
Работа не может считаться частью Increment, если она не соответствует определению готовности (Definition of Done)

Определение готовности (Definition of Done)

Определение готовности (критерии готовности) — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту.
В момент, когда элемент Product Backlog стал соответствовать определению готовности, рождается Increment.

Примеры DoD для User Story:

Написаны и пройдены unit-тесты
Проведено Code review
Функциональные тесты пройдены
Написана краткая справка для пользователя по фиче
Фича / страница добавлена в меню сайта / приложения

User Story

User Story

User Story — это ответы на 3 вопроса, связанные в одно предложение:

Что это за пользователь?
Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
Зачем это ему?

Пример Epic / User story / Тех. задач

Продукт — новая операционная система (базовый софт) для смартфона.

SMS-сообщения

Функция набора и отправки сообщений

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

Просмотр входящих сообщений

Разработать виджет прокрутки
Реализовать поддержку свайпа

Поиск сообщений по тексту

Мини-поисковый движок на основе нейросетей


Звонки

…

…


Поддержка устанавливаемых приложений

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

Разработать формат файла-контейнера для приложений

Примеры epic / user-story для интернет-магазина

Админка (backoffice)

Просмотр списка заказов
Изменение статуса заказа

Каталог товаров на сайте

Список категорий товаров
Список товаров в категории
Карточка товара

Заказ (wizard заказа)

Положить товар в корзину
Управление корзиной
Ввод адреса
Выбор способа доставки

Хорошие / плохие примеры user story

Пример про торт:

«Я как пользователь, хочу съесть торт, чтобы съесть торт»
Я как голодный муж, пришедший с работы, хочу что-нибудь поесть, чтобы утолить голод, потому что очень голоден

Может быть можно быстрее / проще можно удовлетворить эту потребность?
Может быть пока нарезать салат и отварить сосиски?

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

Доска задач (Task Board)

Физическая или электронная доска, на которой отражены задачи с их статусами. Пространство доски поделено на колонки:

To Do (sprint backlog)

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

In Progress — для задач, которые находятся в работе.

Обязательно отмечается ответственный (ответственные).

Done — для сделанных задач, готовых к Демо
Любые дополнительные колонки:

Тестирование
Code review
Написание документации
И т.п.

Производительность / скорость команды (Velocity)

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

Скорость рассчитывается после каждой итерации
В расчёте скорости учитываются только те фичи, которые удовлетворяютт критерию готовности (definition of done)
Скорость используется для планирования итерации и долгосрочного планирования

Диаграмма сгорания (Burndown chart)

Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в story points по дням спринта.

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

Scrum — это не для всех

Чтобы Scrum был выгоден, нужно немало условий. В частности:

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

Scrum без Agile: карго-культ Scrum

«СкрамНо» — у нас Скрам, но… (мы не делаем того и того)

Зачастую переход к Scrum ассоциируется исключительно с 4-мя встречами (ежедневный скрам, планирование, обзор и ретроспектива спринта) и со Scrum-досками. Формально все вроде бы соблюдают методику, но вот про ценности Agile забывают. Дмитрий Павлов в своей статье «Антипаттерны Agile-команд» называет подобное поведение «Scrum-турбацией». Например, демонстрационная часть обзора спринта превращается в отчет руководству. Начальник может на обзоре просто ругать команду за несоответствие между ТЗ и результатом — вместо того, чтобы вместе с командой договориться о следующих шагах и стимулировать команду следовать потребностям бизнеса. А ведь одна из задач обзора спринта как раз в том, чтобы наладить сотрудничество между теми, кто создает продукт и теми, кто его будет использовать или продавать.

Ваши вопросы?