Методоллогии Agile

1
2. Методологии Agile
Технологии разработки программного обеспечения
() Владислав Лавров, vlavrov.com

2
• «Экстремальное программирование»
(eXtreme Programming, XP)
• Scrum
• Метод разработки динамических систем
(Dynamic Systems Development Method, DSDM)
• «Парное программирование»
(Pair Programming)
• Бережливая разработка программного обеспечения
(Lean Software Development, LSD)
• Crystal Methods
Основные методологии (практики) Agile

3
2.1. Метод «Экстремальное программирование»
(eXtreme Programming, XP)

4
Источник https://ru.wikipedia.org/wiki
Создатели метода XP
Уорд Каннингем
Howard G. Cunningham
Кент Бек
Kent Beck
Мартин Фаулер
Martin Fowler

5
Основные приёмы экстремального программирования
1) Короткий цикл обратной связи (Fine-scale feedback)
• Разработка через тестирование
(Test-driven development, TDD)
• Игра в планирование (Planning game)
• Заказчик всегда рядом (Whole team, Onsite customer)
• Парное программирование (Pair programming)

6
(продолжение)
2) Непрерывный, а не пакетный процесс
• Непрерывная интеграция
(Continuous integration)
• Рефакторинг
(Design improvement, Refactoring)
• Частые небольшие релизы
(Small releases)

7
(продолжение)
3) Понимание, разделяемое всеми
• Простота (Simple design)
• Метафора системы
(System metaphor)
• Коллективное владение кодом (Collective code ownership) или
выбранными шаблонами проектирования (Collective patterns
ownership)
• Стандарт кодирования (Coding standard or Coding conventions)

8
(окончание)
4) Социальная защищённость программиста (Programmer welfare):
• 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

9
2.1.1. Тестирование
Метод XP предполагает написание
автоматических тестов (программный код,
написанный специально для того, чтобы тестировать логику другого
программного кода).
Особое внимание уделяется двум разновидностям тестирования:
• модульное тестирование, или юнит-тестирование модулей;
• функциональное (интеграционное) тестирование.

10
2.1.2. Игра в планирование
Основная цель игры в планирование
в методе XP — быстро сформировать
приблизительный план работы и постоянно
обновлять его по мере того, как условия
задачи становятся всё более чёткими.
Артефакты игры в планирование:
• набор бумажных карточек, на которых записаны пожелания заказчика
(customer stories);
• приблизительный план работы по выпуску следующих одной или нескольких
небольших версий продукта.
www.selfishprogramming.com

11
2.1.3. Заказчик всегда рядом
«Заказчик» в XP — это не тот, кто оплачивает счета, а конечный
пользователь программного продукта.
Метод XP утверждает, что заказчик должен быть всё время на связи и
доступен для вопросов.

12
2.1.4. Парное программирование
• Парное программирование предполагает,
что весь код создается парами программистов,
работающих за одним компьютером.
• Один из них работает непосредственно
с текстом программы, другой просматривает его работу и следит за
общей картиной происходящего. При необходимости клавиатура
свободно передаётся от одного к другому.
• В течение работы над проектом пары не фиксированы: рекомендуется их
перемешивать, чтобы каждый программист в команде имел хорошее
представление о всей системе.
www.selfishprogramming.com

13
2.1.5. Непрерывная интеграция
• Непрерывная интеграция
(CI, англ. Continuous Integration) — это практика
разработки программного обеспечения,
которая заключается в выполнении частых автоматизированных сборок
проекта для скорейшего выявления и решения интеграционных проблем.
• В обычном проекте, где над разными частями системы разработчики
трудятся независимо, стадия интеграции является заключительной. Она
может непредсказуемо задержать окончание работ.
• Переход к непрерывной интеграции позволяет снизить трудоёмкость
интеграции и сделать её более предсказуемой за счет наиболее раннего
обнаружения и устранения ошибок и противоречий.

14
2.1.6. Рефакторинг
• Рефакторинг (refactoring) — это методика улучшения
кода без изменения его функциональности.
• В методе XP рефакторинг является неотъемлемой частью цикла
разработки ПО: разработчики попеременно то создают новые
тесты и функциональность, то выполняют рефакторинг кода для
улучшения его логичности и прозрачности.
• Автоматическое юнит-тестирование позволяет убедиться, что
рефакторинг не разрушил существующую функциональность.

15
2.1.7. Частые небольшие релизы (releases)
• Версии (releases) продукта должны
поступать в эксплуатацию как можно
чаще.
• Работа над каждой версией должна
занимать как можно меньше времени.
• При этом каждая версия должна быть
достаточно осмысленной с точки
зрения полезности для бизнеса.

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

17
2.1.9. Метафора системы
• Метафора системы (system metaphor) — это аналог того,
что в большинстве методик называется архитектурой —
это представление о компонентах системы и их
взаимосвязях между собой.
• Разработчикам необходимо проводить анализ
архитектуры программного обеспечения для того, чтобы
понять, в каком месте системы необходимо добавить
новую функциональность, и с чем будет
взаимодействовать новый компонент.

18
2.1.10. Коллективное владение кодом
• Каждый член команды несёт ответственность
за весь исходный код. Каждый вправе вносить
изменения в любой участок программы.
• За работоспособность кода несет ответственность
последний, кто его изменял
• Все программисты знакомятся со всеми частями кода системы.
• Важное преимущество коллективного владения кодом — в том, что оно
ускоряет процесс разработки, поскольку при появлении ошибки её может
устранить любой программист.

19
2.1.11. Стандарты кодирования
• Стандарт оформления кода
(стандарт кодирования,
стиль программирования) — набор правил
и соглашений, используемых при написании
исходного кода на некотором языке программирования.
• Наличие общего стиля программирования облегчает понимание и
поддержание исходного кода, написанного более чем одним
программистом, а также упрощает взаимодействие нескольких
человек при разработке программного обеспечения.

20
2.1.12. 40-часовая рабочая неделя
• Продолжительность рабочей недели не должна превышать 40
часов. По сравнению с обычной практикой постоянных
переработок, в средне- и долгосрочной перспективе это повышает
производительность проектной команды за счет уменьшения
стресса и переутомления.

21
2.2. Метод Scrum

22
Библиография
Майк Кон.
Scrum. Гибкая разработка ПО.
Пер. с англ. - М. : ООО “И.Д.
Вильямс”, 2011. - 576 с.
Хенрик Книберг.
Scrum и XP: заметки с передовой.
Пер. с англ. 2007. - 94 с.
Борис Вольфсон.
Гибкие методологии разработки.
112 с.

23
Что такое Scrum?
Скрам (Scrum) — это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные и небольшие по
времени итерации, называемые спринтами (sprints), предоставлять
конечному пользователю работающее ПО с новыми возможностями, для
которых определён наибольший приоритет.
Возможности ПО к реализации в очередном спринте определяются в
начале спринта на этапе планирования и не могут изменяться на всём его
протяжении. При этом строго фиксированная небольшая длительность
спринта придаёт процессу разработки предсказуемость и гибкость.

24
Основные элементы Scrum
Роли
· Владелец продукта
· Скрам-мастер
· Команда
Артефакты
· Бэклог продукта
· Бэклог спринта
· Инкремент продукта
Процессы
· Скрам-митинг
· Планирование спринта
· Спринт
· Обзор спринта
· Ретроспектива

25
Роли в Scrum
• Владелец продукта (Product owner, Менеджер продукта) – это
человек, ответственный приоритезацию требований и часто за их
создание.
• Скрам-мастер – член команды, который дополнительно отвечает
за процессы, координацию работы команды и поддержание
социальной атмосферы в команде.
• Команда – 7±2 человек, которые реализуют требования владельца
продукта.

26
Артефакты в Scrum
• Бэклог продукта (Product Backlog) – приоритезированный список
требований с оценкой трудозатрат. Обычно он состоит из бизнес-
требований, которые приносят конкретную бизнес-ценность и
называются элементы бэклога.
• Бэклог спринта (Sprint Backlog) – часть бэклога продукта, с самой
высокой важностью и суммарной оценкой, не превышающей
скорость команды, отобранная для спринта.
• Инкремент (от англ. increment «увеличение») продукта – новая
функциональность продукта, созданная во время спринта
спринта.

27
История пользователя включает:
• Уникальный числовой идентификатор истории – обычно совпадает с
идентификатором истории пользователя из трекера, которым пользуется
команда. Этот идентификатор позволяет точно сказать, о какой истории
пользователя в данный момент идет речь.
• Название истории пользователя – короткое (примерно до 10 слов)
описание функционала с точки зрения пользователя, сформулированное
в виде тройки «Роль», «Действие», «Цель».
• Важность – уникальный числовой приоритет истории пользователя, чем
она выше, тем раньше данную историю необходимо сделать.
• Оценка – числовая относительная оценка истории пользователя по
специальной шкале.

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

29
Процессы в Scrum. Скрам-митинг.
• Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка)
– собрание членов команды (с возможностью приглашения
владельца продукта) для синхронизации деятельности команды и
обозначения проблем.
• Каждый член команды отвечает на три вопроса:
1. Что было сделано с предыдущего скрам-митинга?
2. Какие есть проблемы?
3. Что будет сделано к следующему скрам митингу?

30
Процессы в Scrum. Планирование спринта
• Основным результатом планирования спринта является бэклог
спринта – список задач, которые команда планирует реализовать в
рамках спринта.
• Поскольку длина спринта в Scrum жестко фиксирована, то команда
определяет количество элементов бэклога (объем работ), которые
она может реализовать.

31
Процессы в Scrum. Обзор спринта
• Обзор спринта (также часто используется термин «демонстрация»
или сокращенно «демо») – показ владельцу продукта (и
заинтересованным лицам) работающего функционала продукта,
сделанного за спринт.
• Демонстрация результатов работы не только мотивирует команду,
но и подталкивает реализовывать задачи полностью.
• Основная задача проведения обзора спринта заключается в
получении обратной связи.

32
Получение обратной связи в Scrum *
* Источник: Б.Вольфсон. Гибкие методологии разработки.

33
Процессы в Scrum. Ретроспектива
• Ретроспективу проводят после обзора спринта спустя небольшое
количество времени, чтобы оперативно получить обратную связь
(feed back).
• Традиционным является формат по сбору данных, который
заключается в ответах каждого участника на три вопроса:
1. Что было сделано хорошо?
2. Что можно улучшить?
3. Какие улучшения будем делать?

34
Общая схема Scrum *

35
2.3. Метод разработки динамических систем

36
Метод разработки динамических систем
• Методика основана на концепции быстрой разработки
приложений (Rapid Application Development, RAD).
• Цель метода – сдать готовый проект вовремя и уложиться в
бюджет, но в то же время регулируя изменения требований к
проекту во время его разработки.

37
Основные принципы DSDM
1. Вовлечение пользователя
2. Команда должна быть уполномочена принимать важные для проекта
решения без согласования с начальством.
3. Частая поставка версий результата.
4. Главный критерий - как можно более быстрая поставка программного
обеспечения, которое удовлетворяет текущим потребностям рынка.
5. Разработка - итеративная и инкрементная.
6. Любые изменения во время разработки - обратимы.
7. Требования устанавливаются на высоком уровне прежде, чем начнётся
проект.
8. Тестирование интегрировано в жизненный цикл разработки.
9. Взаимодействие и сотрудничество между всеми участниками необходимо
для его эффективности.

38
Стадии работы DSDM
• Стадия 1 – Предпроектная
• Стадия 2 – Жизненный цикл проекта
• Стадия 3 – Постпроектная

39
Жизненный цикла проекта DSDM
• Этап 1: Исследование реализуемости
• Этап 2: Исследование экономической целесообразности
• Этап 3: Создание функциональной модели
• Этап 4: Проектирование и разработка
• Этап 5: Реализация

40
2.4. Метод «Парное программирование»
(Pair Programming)

41
2.4. Метод «Парное программирование»
(Pair Programming)
• Исходный код создаётся парами людей, программирующих одну
задачу, сидя за одним рабочим местом.
• Один программист («ведущий») управляет компьютером и, в
основном, думает над кодированием в деталях.
• Другой программист («штурман») сосредоточен на картине в целом
и непрерывно просматривает код, производимый первым
программистом.
• Время от времени они меняются ролями, обычно, каждые полчаса.

42
Парное программирование.
Роли разработчиков при работе в паре *

43
2.5. Метод «Бережливая разработка программного
обеспечения (Lean Software Development, LSD)

44
2.6. Метод «Crystal Methods»

Методоллогии Agile

More Related Content

What's hot

Viewers also liked

Similar to Методоллогии Agile

More from Ural Federal University named after First President of Russia B.N. Yeltsin

Методоллогии Agile