Методоллогии Agile
Download as PPTX, PDF0 likes819 views
Документ описывает различные методологии Agile разработки программного обеспечения, включая экстремальное программирование, Scrum и метод разработки динамических систем. Представлены основные принципы, практики и преимущества каждой методологии, такие как короткие циклы обратной связи, непрерывная интеграция и коллективное владение кодом. Также отмечены ключевые роли и артефакты в Scrum, а также принципы работы в методе DSDM.
Методоллогии Agile
- 1. 1 2. Методологии Agile Технологии разработки программного обеспечения () Владислав Лавров, vlavrov.com
- 2. 2 • «Экстремальное программирование» (eXtreme Programming, XP) • Scrum • Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) • «Парное программирование» (Pair Programming) • Бережливая разработка программного обеспечения (Lean Software Development, LSD) • Crystal Methods Основные методологии (практики) Agile () Владислав Лавров, vlavrov.com
- 3. 3 2.1. Метод «Экстремальное программирование» (eXtreme Programming, XP) () Владислав Лавров, vlavrov.com
- 4. 4 Источник https://ru.wikipedia.org/wiki Создатели метода XP () Владислав Лавров, vlavrov.com Уорд Каннингем Howard G. Cunningham Кент Бек Kent Beck Мартин Фаулер Martin Fowler
- 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)
- 8. 8 Основные приёмы экстремального программирования (окончание) () Владислав Лавров, vlavrov.com 4) Социальная защищённость программиста (Programmer welfare): • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)
- 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 часов. По сравнению с обычной практикой постоянных переработок, в средне- и долгосрочной перспективе это повышает производительность проектной команды за счет уменьшения стресса и переутомления.
- 21. 21 2.2. Метод Scrum () Владислав Лавров, vlavrov.com
- 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. Какие улучшения будем делать?
- 34. 34 Общая схема Scrum * () Владислав Лавров, vlavrov.com * Источник: Б.Вольфсон. Гибкие методологии разработки.
- 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: Реализация
- 40. 40 2.4. Метод «Парное программирование» (Pair Programming) () Владислав Лавров, vlavrov.com
- 41. 41 2.4. Метод «Парное программирование» (Pair Programming) () Владислав Лавров, vlavrov.com • Исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. • Один программист («ведущий») управляет компьютером и, в основном, думает над кодированием в деталях. • Другой программист («штурман») сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. • Время от времени они меняются ролями, обычно, каждые полчаса.
- 42. 42 Парное программирование. Роли разработчиков при работе в паре * () Владислав Лавров, vlavrov.com * Источник: Б.Вольфсон. Гибкие методологии разработки.
- 43. 43 2.5. Метод «Бережливая разработка программного обеспечения (Lean Software Development, LSD) () Владислав Лавров, vlavrov.com
- 44. 44 2.6. Метод «Crystal Methods» () Владислав Лавров, vlavrov.com