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

Темы лекции: Scrum.

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

http://www.slideshare.net/IgorShkulipa 2

Методологии разработки ПО

http://www.slideshare.net/IgorShkulipa


Методологии разработки ПО

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



Прогнозируемые методологии

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

• Известны запланированные задачи и ресурсы на весь срокпроекта.

• Команда с трудом реагирует на возможные изменения.• План оптимизирован исходя из состава работ и существующих

требований.• Изменение требований может привести к существенному

изменению плана, а также дизайна проекта.

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



Адаптивные методологии

Адаптивные методологии нацелены на преодоление ожидаемойнеполноты требований и их постоянного изменения.

• Когда меняются требования, команда разработчиков тожеменяется.

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

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

декларации о целях проекта, ожидаемых затратах ирезультатах.



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

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

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

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



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 из ProductBacklog. Все функции разбиты по задачам, каждая из которыхоценивается командой. Каждый день команда оценивает объемработы, который нужно проделать для завершения задач.



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 минута


Education

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