2. 2
• «Экстремальное программирование»
(eXtreme Programming, XP)
• Scrum
• Метод разработки динамических систем
(Dynamic Systems Development Method, DSDM)
• «Парное программирование»
(Pair Programming)
• Бережливая разработка программного обеспечения
(Lean Software Development, LSD)
• Crystal Methods
Основные методологии (практики) Agile
() Владислав Лавров, vlavrov.com
5. 5
Основные приёмы экстремального программирования
() Владислав Лавров, vlavrov.com
1) Короткий цикл обратной связи (Fine-scale feedback)
• Разработка через тестирование
(Test-driven development, TDD)
• Игра в планирование (Planning game)
• Заказчик всегда рядом (Whole team, Onsite customer)
• Парное программирование (Pair programming)
6. 6
Основные приёмы экстремального программирования
(продолжение)
() Владислав Лавров, vlavrov.com
2) Непрерывный, а не пакетный процесс
• Непрерывная интеграция
(Continuous integration)
• Рефакторинг
(Design improvement, Refactoring)
• Частые небольшие релизы
(Small releases)
7. 7
Основные приёмы экстремального программирования
(продолжение)
() Владислав Лавров, vlavrov.com
3) Понимание, разделяемое всеми
• Простота (Simple design)
• Метафора системы
(System metaphor)
• Коллективное владение кодом (Collective code ownership) или
выбранными шаблонами проектирования (Collective patterns
ownership)
• Стандарт кодирования (Coding standard or Coding conventions)
9. 9
2.1.1. Тестирование
() Владислав Лавров, vlavrov.com
Метод XP предполагает написание
автоматических тестов (программный код,
написанный специально для того, чтобы тестировать логику другого
программного кода).
Особое внимание уделяется двум разновидностям тестирования:
• модульное тестирование, или юнит-тестирование модулей;
• функциональное (интеграционное) тестирование.
10. 10
2.1.2. Игра в планирование
() Владислав Лавров, vlavrov.com
Основная цель игры в планирование
в методе XP — быстро сформировать
приблизительный план работы и постоянно
обновлять его по мере того, как условия
задачи становятся всё более чёткими.
Артефакты игры в планирование:
• набор бумажных карточек, на которых записаны пожелания заказчика
(customer stories);
• приблизительный план работы по выпуску следующих одной или нескольких
небольших версий продукта.
www.selfishprogramming.com
11. 11
2.1.3. Заказчик всегда рядом
() Владислав Лавров, vlavrov.com
«Заказчик» в XP — это не тот, кто оплачивает счета, а конечный
пользователь программного продукта.
Метод XP утверждает, что заказчик должен быть всё время на связи и
доступен для вопросов.
12. 12
2.1.4. Парное программирование
() Владислав Лавров, vlavrov.com
• Парное программирование предполагает,
что весь код создается парами программистов,
работающих за одним компьютером.
• Один из них работает непосредственно
с текстом программы, другой просматривает его работу и следит за
общей картиной происходящего. При необходимости клавиатура
свободно передаётся от одного к другому.
• В течение работы над проектом пары не фиксированы: рекомендуется их
перемешивать, чтобы каждый программист в команде имел хорошее
представление о всей системе.
www.selfishprogramming.com
13. 13
2.1.5. Непрерывная интеграция
() Владислав Лавров, vlavrov.com
• Непрерывная интеграция
(CI, англ. Continuous Integration) — это практика
разработки программного обеспечения,
которая заключается в выполнении частых автоматизированных сборок
проекта для скорейшего выявления и решения интеграционных проблем.
• В обычном проекте, где над разными частями системы разработчики
трудятся независимо, стадия интеграции является заключительной. Она
может непредсказуемо задержать окончание работ.
• Переход к непрерывной интеграции позволяет снизить трудоёмкость
интеграции и сделать её более предсказуемой за счет наиболее раннего
обнаружения и устранения ошибок и противоречий.
14. 14
2.1.6. Рефакторинг
() Владислав Лавров, vlavrov.com
• Рефакторинг (refactoring) — это методика улучшения
кода без изменения его функциональности.
• В методе XP рефакторинг является неотъемлемой частью цикла
разработки ПО: разработчики попеременно то создают новые
тесты и функциональность, то выполняют рефакторинг кода для
улучшения его логичности и прозрачности.
• Автоматическое юнит-тестирование позволяет убедиться, что
рефакторинг не разрушил существующую функциональность.
15. 15
2.1.7. Частые небольшие релизы (releases)
() Владислав Лавров, vlavrov.com
• Версии (releases) продукта должны
поступать в эксплуатацию как можно
чаще.
• Работа над каждой версией должна
занимать как можно меньше времени.
• При этом каждая версия должна быть
достаточно осмысленной с точки
зрения полезности для бизнеса.
16. 16
2.1.8. Простота проектирования
() Владислав Лавров, vlavrov.com
• В процессе работы условия задачи могут неоднократно
измениться, а значит, разрабатываемый продукт
не следует проектировать заблаговременно
целиком и полностью.
• Попытка детально спроектировать систему в самом начале работы является напрасной тратой
времени.
• Проектирование — это настолько важный процесс, что его необходимо выполнять постоянно в
течение всего времени работы над проектом.
• Проектирование должно выполняться небольшими этапами, с учётом постоянно изменяющихся
требований.
• В каждый момент времени следует пытаться использовать наиболее простой дизайн, который
подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются
17. 17
2.1.9. Метафора системы
() Владислав Лавров, vlavrov.com
• Метафора системы (system metaphor) — это аналог того,
что в большинстве методик называется архитектурой —
это представление о компонентах системы и их
взаимосвязях между собой.
• Разработчикам необходимо проводить анализ
архитектуры программного обеспечения для того, чтобы
понять, в каком месте системы необходимо добавить
новую функциональность, и с чем будет
взаимодействовать новый компонент.
18. 18
2.1.10. Коллективное владение кодом
() Владислав Лавров, vlavrov.com
• Каждый член команды несёт ответственность
за весь исходный код. Каждый вправе вносить
изменения в любой участок программы.
• За работоспособность кода несет ответственность
последний, кто его изменял
• Все программисты знакомятся со всеми частями кода системы.
• Важное преимущество коллективного владения кодом — в том, что оно
ускоряет процесс разработки, поскольку при появлении ошибки её может
устранить любой программист.
19. 19
2.1.11. Стандарты кодирования
() Владислав Лавров, vlavrov.com
• Стандарт оформления кода
(стандарт кодирования,
стиль программирования) — набор правил
и соглашений, используемых при написании
исходного кода на некотором языке программирования.
• Наличие общего стиля программирования облегчает понимание и
поддержание исходного кода, написанного более чем одним
программистом, а также упрощает взаимодействие нескольких
человек при разработке программного обеспечения.
20. 20
2.1.12. 40-часовая рабочая неделя
() Владислав Лавров, vlavrov.com
• Продолжительность рабочей недели не должна превышать 40
часов. По сравнению с обычной практикой постоянных
переработок, в средне- и долгосрочной перспективе это повышает
производительность проектной команды за счет уменьшения
стресса и переутомления.
22. 22
Библиография
() Владислав Лавров, vlavrov.com
Майк Кон.
Scrum. Гибкая разработка ПО.
Пер. с англ. - М. : ООО “И.Д.
Вильямс”, 2011. - 576 с.
Хенрик Книберг.
Scrum и XP: заметки с передовой.
Пер. с англ. 2007. - 94 с.
Борис Вольфсон.
Гибкие методологии разработки.
112 с.
23. 23
Что такое Scrum?
() Владислав Лавров, vlavrov.com
Скрам (Scrum) — это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные и небольшие по
времени итерации, называемые спринтами (sprints), предоставлять
конечному пользователю работающее ПО с новыми возможностями, для
которых определён наибольший приоритет.
Возможности ПО к реализации в очередном спринте определяются в
начале спринта на этапе планирования и не могут изменяться на всём его
протяжении. При этом строго фиксированная небольшая длительность
спринта придаёт процессу разработки предсказуемость и гибкость.
24. 24
Основные элементы Scrum
() Владислав Лавров, vlavrov.com
Роли
· Владелец продукта
· Скрам-мастер
· Команда
Артефакты
· Бэклог продукта
· Бэклог спринта
· Инкремент продукта
Процессы
· Скрам-митинг
· Планирование спринта
· Спринт
· Обзор спринта
· Ретроспектива
25. 25
Роли в Scrum
() Владислав Лавров, vlavrov.com
• Владелец продукта (Product owner, Менеджер продукта) – это
человек, ответственный приоритезацию требований и часто за их
создание.
• Скрам-мастер – член команды, который дополнительно отвечает
за процессы, координацию работы команды и поддержание
социальной атмосферы в команде.
• Команда – 7±2 человек, которые реализуют требования владельца
продукта.
26. 26
Артефакты в Scrum
() Владислав Лавров, vlavrov.com
• Бэклог продукта (Product Backlog) – приоритезированный список
требований с оценкой трудозатрат. Обычно он состоит из бизнес-
требований, которые приносят конкретную бизнес-ценность и
называются элементы бэклога.
• Бэклог спринта (Sprint Backlog) – часть бэклога продукта, с самой
высокой важностью и суммарной оценкой, не превышающей
скорость команды, отобранная для спринта.
• Инкремент (от англ. increment «увеличение») продукта – новая
функциональность продукта, созданная во время спринта
спринта.
27. 27
История пользователя включает:
() Владислав Лавров, vlavrov.com
• Уникальный числовой идентификатор истории – обычно совпадает с
идентификатором истории пользователя из трекера, которым пользуется
команда. Этот идентификатор позволяет точно сказать, о какой истории
пользователя в данный момент идет речь.
• Название истории пользователя – короткое (примерно до 10 слов)
описание функционала с точки зрения пользователя, сформулированное
в виде тройки «Роль», «Действие», «Цель».
• Важность – уникальный числовой приоритет истории пользователя, чем
она выше, тем раньше данную историю необходимо сделать.
• Оценка – числовая относительная оценка истории пользователя по
специальной шкале.
28. 28
() Владислав Лавров, vlavrov.com
Историю пользователя удобно размещать на стикере,
который прикрепляется на доску.
номер в трекере задач
важность
оценка
29. 29
Процессы в Scrum. Скрам-митинг.
() Владислав Лавров, vlavrov.com
• Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка)
– собрание членов команды (с возможностью приглашения
владельца продукта) для синхронизации деятельности команды и
обозначения проблем.
• Каждый член команды отвечает на три вопроса:
1. Что было сделано с предыдущего скрам-митинга?
2. Какие есть проблемы?
3. Что будет сделано к следующему скрам митингу?
30. 30
Процессы в Scrum. Планирование спринта
() Владислав Лавров, vlavrov.com
• Основным результатом планирования спринта является бэклог
спринта – список задач, которые команда планирует реализовать в
рамках спринта.
• Поскольку длина спринта в Scrum жестко фиксирована, то команда
определяет количество элементов бэклога (объем работ), которые
она может реализовать.
31. 31
Процессы в Scrum. Обзор спринта
() Владислав Лавров, vlavrov.com
• Обзор спринта (также часто используется термин «демонстрация»
или сокращенно «демо») – показ владельцу продукта (и
заинтересованным лицам) работающего функционала продукта,
сделанного за спринт.
• Демонстрация результатов работы не только мотивирует команду,
но и подталкивает реализовывать задачи полностью.
• Основная задача проведения обзора спринта заключается в
получении обратной связи.
32. 32
Получение обратной связи в Scrum *
() Владислав Лавров, vlavrov.com
* Источник: Б.Вольфсон. Гибкие методологии разработки.
33. 33
Процессы в Scrum. Ретроспектива
() Владислав Лавров, vlavrov.com
• Ретроспективу проводят после обзора спринта спустя небольшое
количество времени, чтобы оперативно получить обратную связь
(feed back).
• Традиционным является формат по сбору данных, который
заключается в ответах каждого участника на три вопроса:
1. Что было сделано хорошо?
2. Что можно улучшить?
3. Какие улучшения будем делать?
35. 35
2.3. Метод разработки динамических систем
(Dynamic Systems Development Method, DSDM)
() Владислав Лавров, vlavrov.com
36. 36
Метод разработки динамических систем
(Dynamic Systems Development Method, DSDM)
() Владислав Лавров, vlavrov.com
• Методика основана на концепции быстрой разработки
приложений (Rapid Application Development, RAD).
• Цель метода – сдать готовый проект вовремя и уложиться в
бюджет, но в то же время регулируя изменения требований к
проекту во время его разработки.
37. 37
Основные принципы DSDM
() Владислав Лавров, vlavrov.com
1. Вовлечение пользователя
2. Команда должна быть уполномочена принимать важные для проекта
решения без согласования с начальством.
3. Частая поставка версий результата.
4. Главный критерий - как можно более быстрая поставка программного
обеспечения, которое удовлетворяет текущим потребностям рынка.
5. Разработка - итеративная и инкрементная.
6. Любые изменения во время разработки - обратимы.
7. Требования устанавливаются на высоком уровне прежде, чем начнётся
проект.
8. Тестирование интегрировано в жизненный цикл разработки.
9. Взаимодействие и сотрудничество между всеми участниками необходимо
для его эффективности.
38. 38
Стадии работы DSDM
() Владислав Лавров, vlavrov.com
• Стадия 1 – Предпроектная
• Стадия 2 – Жизненный цикл проекта
• Стадия 3 – Постпроектная
39. 39
Жизненный цикла проекта DSDM
() Владислав Лавров, vlavrov.com
• Этап 1: Исследование реализуемости
• Этап 2: Исследование экономической целесообразности
• Этап 3: Создание функциональной модели
• Этап 4: Проектирование и разработка
• Этап 5: Реализация
41. 41
2.4. Метод «Парное программирование»
(Pair Programming)
() Владислав Лавров, vlavrov.com
• Исходный код создаётся парами людей, программирующих одну
задачу, сидя за одним рабочим местом.
• Один программист («ведущий») управляет компьютером и, в
основном, думает над кодированием в деталях.
• Другой программист («штурман») сосредоточен на картине в целом
и непрерывно просматривает код, производимый первым
программистом.
• Время от времени они меняются ролями, обычно, каждые полчаса.