Системная и программная инженерия Лекция 1 Гибкие методологии разработки ПО Миронов А.Н., старший преподаватель кафедры МОСИТ Гибкая методология разработки Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профилей Гибкая методология разработки Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает: • Планирование • Анализ требований • Проектирование • Программирование • Тестирование • Документирование По окончании каждой итерации переоценку приоритетов разработки. команда выполняет Гибкая методология разработки Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, команда включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Гибкая методология разработки Основной метрикой agile-методов является рабочий продукт. Преимущества: • Agile-методы уменьшают объём письменной документации по сравнению с другими методами. • Получение быстрого результата и молниеносная реакция на изменение требований Гибкая методология разработки Недостатки: • Отсутствует единое управление требованиями и архитектуры • Задачи решаются простейшим способом, что приводит к снижению качества продукта и накоплению дефектов !?? Катастрофические «авралы» с массовым рефакторингом и переделками практически на каждой очередной итерации Принципы Agile Основные ценности: • люди и взаимодействие важнее процессов и инструментов; • работающий продукт важнее исчерпывающей документации; • сотрудничество с заказчиком важнее согласования условий контракта; • готовность к изменениям важнее следования первоначальному плану. Принципы Agile Основные принципы: • Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. • Изменение требований приветствуется, даже на поздних стадиях разработки. • Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. Принципы Agile Основные принципы: • На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. • Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. • Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Принципы Agile Основные принципы: • Работающий продукт — основной показатель прогресса. • Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. • Простота — искусство минимизации лишней работы — крайне необходима. Принципы Agile Основные принципы: • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. • Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы На самом деле, все используют Agile, просто не знают об этом Гибкая методология разработки Методики Agile: • • • • экстремальное программирование Scrum FDD Lean Экстремальное программирование Экстрема́льное программи́рование (Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.) Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. 12 основных приемов XP Короткий цикл обратной связи (Fine-scale feedback) • Разработка через тестирование (Test-driven development) • Игра в планирование (Planning game) • Заказчик всегда рядом (Whole team, Onsite customer) • Парное программирование (Pair programming) Непрерывный, а не пакетный процесс • Непрерывная интеграция (Continuous integration) • Рефакторинг (Design improvement, Refactoring) • Частые небольшие релизы (Small releases) 12 основных приемов XP Понимание, разделяемое всеми • Простота проектирования (Simple design) • Метафора системы • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) • Стандарт оформления кода (Coding standard or Coding conventions) Социальная защищённость программиста (Programmer welfare): • 40-часовая рабочая неделя (Sustainable pace, Fortyhour week) Feature driven development Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки. Feature driven development FDD включает в себя пять базовых видов деятельности: • разработка общей модели; • составление списка необходимых функций системы; • планирование работы над каждой функцией; • проектирование функции; • реализация функции Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Feature driven development • Объектное моделирование области. • Разработка по функции. Любая функция, которая слишком сложна для разработки в течение двух недель, разбивается на меньшие подфункции • Индивидуальное владение классом (кодом). • Команда по разработке функций (свойств). • Проверка кода (англ. code review) • Конфигурационное управление. • Регулярная сборка. • Обозримость хода работ и результатов Lean Бережли́вая разрабо́тка програ́ммного обеспече́ния — методология разработки программного обеспечения, использующая методы концепции бережливого производства. Lean Основные принципы: • Исключение потерь. • Акцент на обучении. • Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов. • Предельно быстрая доставка заказчику. • Мотивация команды.. • Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг. • Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать мало, ошибаться быстро; учиться стремительно». Scrum Scrum— фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе и предназначен для разработки продуктов высокой ценности в запутанной среде. Scrum Определения Scrum: • Спринт • Журнал пожеланий проекта • Журнал пожеланий спринта • Диаграмма сгорания задач (Burndown chart) Canban Scrum Основные роли (Core roles) в методологии скрам («Свиньи») • Скрам-мастер (Scrum Master) — проводит совещания и следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрампроцесса. • Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Руководитель проекта скорее относится к владельцу продукта и не должен фигурировать в качестве скраммастера. Scrum Основные роли (Core roles) в методологии скрам («Свиньи») • Команда Разработки (Development Team) — кроссфункциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта. Scrum team Product owner Scrum Дополнительные роли (Ancillary roles) в методологии скрам («Куры») • Пользователи (Users) • Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review). • Управляющие (Managers) — люди, которые управляют персоналом. • Эксперты-консультанты (Consulting Experts) Собрания Scrum Планирование спринта (Sprint Planning Meeting) • Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда; • На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах; • Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи; • Обсуждается и определяется, каким образом будет реализован этот объём работ; • Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и т. п. • (первая часть совещания) Участвует владелец продукта и скрам команда: выбирают задачи из бэклога продукта; • (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта. Планирование спринта (Sprint Planning Meeting) Собрания Scrum Собрания Scrum Ежедневное совещание (Daily Scrum meeting) • • • • начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более 15 минут; проводится в одном и том же месте в течение спринта. В течение совещания каждый член команды отвечает на 3 вопроса: • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта? • Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта? • Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.) Собрания Scrum Скрам над скрамом (Scrum of Scrums) Проводится после ежедневного скрам-совещания. Позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам-совещании плюс следующие вопросы: • Что каждая команда сделала с момента предыдущего ежедневного совещания? • Что каждая команда сделает к следующему ежедневному совещанию? • Есть ли проблемы, мешающие или замедляющие работу каждой команды? • Нужно ли другой команде сделать что-то из задач вашей команды? Собрания Scrum Обзор итогов спринта (Sprint review meeting) Проводится в конце спринта. • Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам. • Привлекается максимальное количество зрителей. • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). • Нельзя демонстрировать незавершенную функциональность. • Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта. Собрания Scrum Ретроспективное совещание (Retrospective meeting) Проводится в конце спринта. • Члены команды высказывают своё мнение о прошедшем спринте. • Отвечают на два основных вопроса: • Что было сделано хорошо в прошедшем спринте? • Что надо улучшить в следующем? • Выполняют улучшение процесса разработки (обсуждают варианты решения проблем, фиксируют удачные решения и вызвавшегося владельца решения). • Ограничена тремя часами для спринта любой длины. Scrum poker Покер планирования— техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения. Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Карты в колодах должны быть пронумерованы. Обычно колода содержит карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; Scrum poker Покер планирования— техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения. Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Scrum poker Каждому участнику обсуждения выдаётся по одной колоде карт. Все колоды идентичны друг другу. Обсуждение проводится следующим образом. 1. Менеджер продукта представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков. 2. Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт означают относительные единицы сложности. 3. Каждый участник называет свою карту и переворачивает её. 4. Участникам с высокими и низкими оценками даётся возможность высказаться и обосновать свою оценку. 5. Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус. 6. Выступления участников повторяются вновь и вновь. Карты пронумерованы так, что чем больше число, тем больше неопределённость. Системная и программная инженерия Лекция 1 Гибкие методологии разработки ПО Миронов А.Н., старший преподаватель кафедры МОСИТ
