Общие темы. Тема 03.

Темы лекции: Scrum.
Тренер: Игорь Шкулипа, к.т.н.

http://www.slideshare.net/IgorShkulipa 2
Методологии разработки ПО

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

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

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

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

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

Итеративная разработка
Итеративная разработка — выполнение работ параллельно с непрерывным
анализом полученных результатов и корректировкой предыдущих этапов
работы.
Проект при этом подходе в каждой фазе развития проходит повторяющийся
цикл: Планирование — Реализация — Проверка — Оценка (plan-do-check-
act).
В ходе разработки всегда выявляются дополнительные требования или
изменяются выявленные ранее. Также появляются новые ограничения,
связанные с принятыми техническими решениями. В наиболее полной мере
их удается учесть именно в итерационной разработке, поскольку именно при
таком подходе руководство проекта в полной мере готово к изменениям.

RUP
Rational Unified Process (RUP) — методология разработки программного
обеспечения, созданная компанией Rational Software.
В основе RUP лежат следующие основные принципы:
• Ранняя идентификация и непрерывное (до окончания проекта)
устранение основных рисков.
• Концентрация на выполнении требований заказчиков к
исполняемой программе (анализ и построение модели
прецедентов).
• Ожидание изменений в требованиях, проектных решениях и
реализации в процессе разработки.
• Компонентная архитектура, реализуемая и тестируемая на ранних
стадиях проекта.
• Постоянное обеспечение качества на всех этапах разработки
проекта (продукта).
• Работа над проектом в сплочённой команде, ключевая роль в
которой принадлежит архитекторам.

RUP

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

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

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

Прозрачность
• Значимые аспекты процесса должны быть видимы тем, кто отвечает
за его результат.
• Прозрачность требует, чтобы эти аспекты определялись общими
стандартами.
• Все наблюдатели должны разделять одно и тоже понимание
видимого.
• Все участники процесса должны пользоваться его общей
терминологией.
• Те, кто выполняет работу и принимает рабочий продукт, должны
иметь общие критерии “Готовности”.

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

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

Основные термины
• Роли
• Scrum Master
• Product Owner
• Scrum Team
• Артефакты
• Product Backlog
• Sprint Backlog
• Sprint Burndown chart
• Мероприятия
• Спринт (Sprint)
• Планирование спринта
• Daily Scrum Meeting (Stand-up)
• Planning Poker, Story points
• Обзор спринта (Демо)
• Ретроспектива спринта

Product Owner
Product Owner - это человек, отвечающий за разработку продукта.
Product Owner - это единая точка принятия окончательных решений
для команды в проекте, именно поэтому это всегда один человек, а
не группа или комитет.
Обязанности Product Owner:
• Отвечает за формирование product vision
• Управляет ожиданиями заказчиков и всех заинтересованных лиц
• Координирует и приоритизирует Product backlog
• Предоставляет понятные и тестируемые требования команде
• Взаимодействует с командой и заказчиком
• Отвечает за приемку кода в конце каждой итерации

Скрам Мастер
Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам
Мастер является интерфейсом между менеджментом и командой.
Основные обязанности Скрам Мастера:
• Создает атмосферу доверия,
• Участвует в митингах в качестве фасилитатора
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в команде
• Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс
команды при помощи Sprint Backlog, отмечая статус всех задач в
спринте.

Команда
В методологии Scrum команда является самоорганизующейся и
самоуправляемой. Команда берет на себя обязательства по
выполнению объема работ на спринт перед Product Owner. Работа
команды оценивается как работа единой группы. В Scrum вклад
отдельных членов проектной команды не оценивается, так как это
разваливает самоорганизацию команды.
Обязанности команды:
• Отвечает за оценку элементов Product backlog
• Принимает решение по дизайну и имплементации
• Разрабатывает софт и предоставляет его заказчику
• Отслеживает собственный прогресс (вместе со Скрам
Мастером)
• Отвечает за результат перед Product Owner
• Типичный размер команды - 7 плюс минус 2.

Product Backlog
Приоритезированный список имеющихся на данный момент бизнес-
требований и технических требований к системе

User Story
User Story - простые, краткие, ясные описания функциональных
возможностей, которые будут важны для пользователя или
заказчика
Шаблон: Как <Кто> я хочу <Что>, чтобы <Зачем>
Пример:
Как человек планирующий отпуск, я хочу иметь возможность увидеть
список отелей, чтобы иметь возможность выбрать лучший на мой
взгляд вариант

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

Оценка в Story Points
Story Point показывает размер задачи, основываясь на том:
• Насколько сложная задача
• Насколько она объемная
Это, обычно, относительная оценка:
• Логин: 2.
• Поиск: 8.
Поинты – это абстрактная величина («Эта задача приблизительно
такая же как та задача, поэтому давайте оценим эту в столько же
поинтов»

Как подсчитать Story Points
Размер = Усилие х Сложность х Неопределенность
Сколько времени займет сделать? Насколько сложно сделать? Сколько
неопределенности в требованиях и реализации?

Planning Poker
• Каждому оценивающему дается колода карт
• Product Owner или Скрам Мастер читает историю, и она кратко
обсуждается
• Каждый оценивающий выбирает карту, которая соответствует его
оценке
• Карты переворачиваются, так чтобы все могли видеть их
• Обсуждаются различия в оценке (особенно радикальные)
• Переоценивание до тех пор пока не сократятся разбежности

Спринт
Длительность составляет от 1 недели до 1 месяца.
• Короткие спринты обеспечивают быстрый feedback проектной
команде от заказчика.
• Каждый спринт представляет собой маленький "водопад".
• Содержание спринта должно быть фиксированным.
• Sprint Backlog не может быть изменен никем, кроме команды.

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

Sprint Burndown Chart

Планирование спринта
В начале каждого спринта проводится планирование спринта. В
планировании спринта участвуют заказчики, пользователи,
менеджмент, Product Owner, Скрам Мастер и команда.
Планирование спринта, митинг первый
Участники: команда, Product Owner, Scrum Master, пользователи,
менеджемент
Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -
функциональность, которая будет разработана в течение следующего
спринта для достижения цели спринта.
Планирование спринта, митинг второй
Участники: Скрам Мастер, команда
Цель: определить, как именно будет разрабатываться определенная
функциональность для того, чтобы достичь цели спринта. Для каждого
элемента Sprint Backlog определяется список задач и оценивается их
продолжительность. В Sprint Backlog появляются задачи

Остановка спринта (Sprint Abnormal Termination)
Остановка спринта производится в исключительных ситуациях.
Спринт может быть остановлен до того, как закончатся отведенное
количество дней.
• Спринт может остановить команда, если понимает, что не
может достичь цели спринта в отведенное время.
• Спринт может остановить Product Owner, если необходимость в
достижении цели спринта исчезла.
После остановки спринта проводится митинг с командой, где
обсуждаются причины остановки спринта.
После этого начинается новый спринт: производится его
планирование и стартуются работы.

Daily Scrum Meeting
Предназначен для того, чтобы все члены команды знали, кто и чем
занимается в проекте.
Длительность этого митинга строго ограничена и не должна
превышать 15 минут.
Цель митинга - поделиться информацией. Он не предназначен для
решения проблем в проекте. Все требующие специального
обсуждения вопросы должны быть вынесены за дейли скрама.
• Что сделано вчера?
• Что будет сделано сегодня?
• С какими проблемами столкнулся?
Скрам Мастер собирает все открытые для
обсуждения вопросы в виде Action Items

Демо
Проводится после завершения спринта.
Команда демонстрирует прирост функциональности продукта
всем заинтересованным лицам.
Привлекается максимальное количество зрителей.
Все члены команды участвуют в демонстрации
(один человек на демонстрацию или каждый
показывает, что сделал за спринт).
Нельзя демонстрировать незавершенную
функциональность.
Ограничена четырьмя часами в зависимости
от продолжительности спринта и прироста
функциональности продукта.

Ретроспективное совещание (Retrospective meeting)
• Проводится после завершения спринта.
• Члены команды высказывают своё мнение о прошедшем спринте.
• Отвечают на два основных вопроса:
• Что было сделано хорошо в прошедшем спринте?
• Что надо улучшить в следующем?
• Выполняют улучшение процесса разработки (решают вопросы и
фиксируют удачные решения).
• Ограничено одним—тремя часами.

Kanban
KANBAN, тянущая система, pull system - наиболее распространенная
разновидность системы "точно в срок" - система, обеспечивающая
организацию непрерывного материального потока при отсутствии
запасов: производственные запасы подаются небольшими
партиями непосредственно в нужные точки производственного
процесса, минуя склад, а готовая продукция сразу отгружается
покупателям. Порядок управления производством продукции -
обратный: от i-той стадии на (i - 1)-ой.

Kanban
Средством передачи информации в системе Kanban являются
специальные карточки (“kanban", в переводе с японского языка,
- карточка).
Применяют два вида карточек:
• карточки производственного заказа, в которых указывается
количество деталей, которое должно быть изготовлено на
предшествующей стадии производства. Карточки
производственного заказа отправляются с i-той стадии
производства на (i - 1)-ый этап и являются основанием для
формирования производственной программы (i - 1)-ого участка;
• карточки отбора, в которых указывается количество материальных
ресурсов (компонентов, деталей, полуфабрикатов), которое
должно быть взято на предшествующем участке обработки
(сборки). Карточки отбора показывают количество материальных
ресурсов, фактически полученных i-тым производственным
участком от (i - 1)-ого.

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

Kanban Board
Канбан разработка крутится вокруг визуальной доски, которая
используется для управления незаконченной работой.
В Agile пользовательские истории часто располагают на доске с
колонками, представляющими собой стадии, через которые
проходит история, например, "разработка" или "тестирование".

Упрощенный вариант Канбан-доски

Критерии готовности (Definition of Done)
«Критерии готовности» включают в себя ряд действий, которые
нужно выполнить для того, чтобы сократить дополнительные
действия между тем, когда команда говорит «мы сделали», и
заказчик говорит «заверните, я беру».
Если между этими двумя моментами вам нужно сделать ещё много
действий, то задумайтесь о том, каков же «Definition of Done» в
вашей команде.

Definition of Almost Done

Игра «3 спринта»
2 Команды
• Product Owner
• Scrum Master
• Команда разработки
PO наполняет
беклог
продукта
новыми User
Story
Планиро-
вание
спринта
2 минуты
Спринт
7 минут Демо
2 минуты
Ретроспектива
1 минута

Общие темы. Тема 03.

More Related Content

What's hot

Viewers also liked

Similar to Общие темы. Тема 03.

More from Igor Shkulipa

Общие темы. Тема 03.