Методологии разработки программного обеспечения

1.

Методологии разработки программного
обеспечения.

2.

План лекции
●Методологии разработки программного обеспечения

3.

Модели разработки ПО
Классические модели разработки ПО:
● Waterfall (Каскадная)
● V-модель
● Итерационная
● Инкрементная
● Спиральная
● Agile (семейство гибких методологий)

4.

Модели разработки ПО
Waterfall (Каскадная)
Модель процесса разработки ПО, в
которой процесс разработки выглядит как
поток, последовательно проходящий фазы
анализа требований, проектирования,
реализации, тестирования, интеграции и
поддержки:
● Последовательное прохождение стадий,
каждая из которых должна завершиться
полностью до начала следующей.
● Небольшие проекты.
● Четкие требования.
● Четкие сроки.
● Каждая фаза четко распланирована.

5.

Модели разработки ПО
V-модель
V-модель фокусируется на методе
водопада, который следует строгим,
пошаговым этапам:
● Последовательное выполнение этапов.
● Каждому этапу разработки
соответствует этап тестирования.
● На спуске нужно думать о том, что
будет происходить на параллельной
поднимающийся стадии.
● Тестирование возникает на первых
этапах цикла, что позволяет
минимизировать риски.

6.

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

7.

Модели разработки ПО
Итерационная модель
● Выполнение работ параллельно с
непрерывным анализом полученных
результатов и корректировкой предыдущих
этапов работы.
Проект при этом подходе в каждой фазе
развития проходит повторяющийся цикл:
Планирование — Реализация — Проверка —
Оценка.
Можно начинать проект без конкретных
требований.
Каждая итерация на выходе имеет готовую
рабочую версию продукта.
Возможен ранний выход продукта на рынок.

8.

Модели разработки ПО
Спиральная
● Данная модель прекрасно сочетает в себе
прототипирование и проектирование по
стадиям. И из восходящей и нисходящей
концепций в эту модель было взято все лучшее.
● Результат достигается в кратчайшие сроки.
● При изменении требований не придется
начинать все с «нуля».
● Но у этой модели есть один существенный
недостаток: невозможность регламентирования
стадий выполнения.

9.

Модели разработки ПО
Преимущества и недостатки моделей

10.

Модели разработки ПО
Преимущества и недостатки моделей

11.

Методологии разработки
Методология разработки
Это набор готовых правил, методов и средств, которые используются для
организации, планирования и контроля процессов разработки
Agile
Гибкая методология разработки - это
концепция разработки программного
обеспечения, которая базируется на
Agile манифесте

12.

Методологии разработки
Agile Manifesto

13.

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

14.

Методологии разработки
Роли в Scrum:
Владелец Продукта (Product Owner)
Руководитель (ScrumMaster)
Команда (Scrum Team)
Артефакты:
Бэклог продукта (Product Backlog)
Спринт бэклог (Sprint Backlog)
Берндаун чарт (Burn Down Chart)
Ритуалы:
Планирование спринта (Sprint Planning)
Ежедневный скрам (Daily Scrum)
Демо (Demo)
Ретроспектива спринта (Retrospective)

15.

Методологии разработки
Гибкая модель разработки. Agile Scrum
Sprint - период времени(2-4 недели), по истечении
которого демонстрируется фактически работающий
продукт с новой функциональностью.

16.

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

17.

Методологии разработки
Руководитель (ScrumMaster)
Человек, ответственный за поддержку команды, уточнение
организационной структуры и процессов Agile.
Scrum master иногда называют посредником
(project facilitator).

18.

Методологии разработки
Команда (Scrum Team)

19.

Методологии разработки
Артефакты:
1. Бэклог продукта (Product Backlog)
2. Спринт бэклог (Sprint Backlog)
3. Скрам доска (Scrum Board)
4. Берндаун чарт (Burn Down Chart)

20.

Методологии разработки
Артефакты. Бэклог продукта (Product Backlog):
Это список требований к функциональности,
упорядоченный по их степени важности.
Элементы этого списка называются - user story

21.

Методологии разработки
Артефакты. Спринт бэклог (Sprint Backlog)
Содержит User Stories, выбранную Product Owner-ом из
Product Backlog.
Все User Story разбиты по задачам(tasks), каждая из
которых оценивается скрам-командой

22.

Методологии разработки
Пользовательские истории (User Story) — способ описания требований к
разрабатываемой системе, сформулированных как одно или более
предложений на повседневном или деловом языке пользователя.
Пользовательские истории используются гибкими методологиями
разработки программного обеспечения для спецификации требований.
Иными словами, User Story — это короткая формулировка намерения,
описывающая что-то, что система должна делать для пользователя.
Пользовательская история фиксирует короткую формулировку функции
на карточке или, возможно, с помощью онлайн-средства.

23.

Методологии разработки
Оценка User Story
Все User Story разбиты по задачам, каждая из которых
оценивается скрам-командой в Story Points.
½, 1, 2, 3, 5, 8, 13, 21
Оценка объёма работ, необходимого для реализации
истории по сравнению с другими story .
Приблизительно соответствует числу
«идеальных человеко-часов».

24.

Методологии разработки
Артефакты. Scrum board

25.

Методологии разработки
Артефакты. Берндаун чарт (Burn Down Chart)
Диаграмма, показывающая количество сделанной и
оставшейся работы.
Обновляется ежедневно с тем, чтобы в простой форме
показать подвижки в работе над спринтом.
График должен быть общедоступен.

26.

Методологии разработки
Артефакты. Берндаун чарт (Burn Down Chart)

27.

Методологии разработки
Ритуалы:
1. Планирование спринта (Sprint Planning)
2. Ежедневный скрам (Daily Scrum)
3. Демо (Demo)
4. Ретроспектива спринта (Retrospective)

28.

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

29.

Методологии разработки
Ритуалы. Планирование спринта (Sprint Planning)
Происходит в начале новой итерации Спринта.
Из Backlog-a проекта выбираются задачи, которые команда
должны выполнены за спринт.
На основе выбранных задач формируется
Sprint Backlog.
Каждая задача оценивается в идеальных человеко-часах.
При необходимости задача разбивается на подзадачи.

30.

Методологии разработки
Ритуалы. Ежедневный скрам (Daily Scrum)
Что было сделано с момента предыдущего митинга до
момента этого митинга?
Что планируете делать с момента этого митинга до
момента следующего митинга?
Какие проблемы препятствуют выполнению
запланированного?

31.

Методологии разработки
Ритуалы. Демо (Demo)
Проводится после завершения спринта.
Команда демонстрирует что было сделано за Спринт.
Все члены команды участвуют в демонстрации
(один человек на демонстрацию или каждый показывает,
что сделал за спринт).

32.

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

33.

Методологии разработки
Kanban
● Визуализация разработки.
● Ограничение работ, выполняющихся
одновременно, на каждом этапе
разработки.
● Измерение времени цикла (среднее
время на выполнение одной задачи) и
оптимизация процесса.
● Возможность вносить изменения в
процессе разработки.
● Основан на принципе Точно-в-срок.
● WIP - Work in progress - распределение
ресурсов, чтобы не возникало простоев.

34.

Методологии разработки
Scrum
Kanban
Ограниченные по времени итерации
Ограничение по времени итерации не обязательны
Команда должна выполнить определенный фиксированный объем
работ во время итерации
Выполнение фиксированного объема работ не требуется
По умолчанию используется метрика «Velocity» для улучшения и
планирования процесса
По умолчанию используется метрика «Lead time» для улучшения и
планирования процесса
Кросс-функциональные команды обязательны
Кросс-функциональные команды не обязательны, допускаются
специализированные команды
Элементы распределены так, чтоб их можно было завершить за один
спринт
Количество элементов не указывается
Burndown диаграмма обязательна к применению
Обязательные диаграммы не требуются
Бэклог спринта ограничен косвенно (каждый спринт)
Бэклог точно ограничен (для каждой рабочей итерации)
Эстимация обязательна
Эстимация не обязательна
Нельзя добавлять элементы в текущую итерацию
Можно добавлять элементы, если осталось свободное время
Бэклог спринта назначен одной конкретной команде
Канбан доска может быть доступна нескольким командам или
участникам проекта
Обязательны 3 роли (PO/SM/Team)
Обязательные роли отсутствуют
Доска скрама обновляется после каждого спринта
Канбан доска дополняется
Приоритезация бэклога обязательна
Приоритезация бэклога не обязательна

35.

Спасибо за внимание!