Основы программной инженерии Методологии разработки программного

Основы программной инженерии Методологии разработки программного обеспечения. Scrum асс. Козополянская Анна Александровна kozopoljanskaja@gmail. com

В ходе разработка программного обеспечения возникают различного рода проблемы. Основными причинами этих проблем являются: Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения. Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы. Недостаток наблюдения. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения.

Для успешного устранения этих проблем необходимо использовать эффективную методологию с хорошей инструментальной поддержкой!!! Для того, чтобы выбрать из большого колличества существующих методологий наиболее эффективную следует учитывать следующие факторы: уровень зрелости процессов компании характеристики конкретного проекта

Модель зрелости процессов организации определяет 5 уровней: 1. Начальный уровень. Процессы начального уровня зрелости, характеризуются хаотичностью, реактивностью, непредсказуемостью. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. 2. Повторяемый уровень. Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение и существует специальная группа обеспечения качества. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности в своей сущности.

3. Определенный уровень. Он характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. 4. Управляемый уровень в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. 5. Оптимизирующий уровень характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения.

Каскадная модель или Модель водопада Данная модель предполагает строго последовательное и однократное выполнение всех фаз проекта с жестким предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. Процесс разработки состоит из последовательных фаз: Анализ требований Проектирование Реализация Тестирование Интеграция Поддержка

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

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

Преимущества итеративной разработки Реализация наиболее важных функций может быть завершена в ходе нескольких первых итераций. После их завершения (то есть намного раньше окончания всего проекта) заказчик сможет начать использование системы. Уже в начале проекта пользователи получают возможность оценить фунциональность системы и ее соответствие своим потребностям. Необходимые изменения и дополнения могут быть сделаны в течение следующих итераций. Основные проектные риски могут быть разрешены на первых итерациях. Например, архитектурное решение, приводящее к неприемлемой производительности может быть обнаружено и исправлено уже в первой итерации. Важно понимать, что все эти преимущества проявляются только при тщательном планировании итераций, в противном случае легко получить ухудшенный вариант модели водопада.

Гибкие методологии – В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto). – На том же семинаре было предложено новое название легковесных методологий – гибкая разработка (agile software development).

Основные принципы манифеста гибких методологий разработки ПО (Agile Manifesto):

Agile подход Итеративность – Движемся к цели короткими шагами Инкрементальность – В конце каждой итерации законченный продукт, полный или частичный отказ от создания дорогостоящих промежуточных артефактов проекта – Возможность получить обратную связь, скорректировать и обработать ожидания заказчика Фокус на взаимодействии и коммуникации Что это дает? минимизация расходов сокращение сроков разработки минимизация рисков

Семейство гибких методологий включает в себя целый набор различных технологий разработки ПО, такие как: RUP (Rational Unified Process) MSF (Microsoft Solutions Framework) XP (Extreme Programming) Open. UP FDD (Feature Driven Development) Scrum

Так какой же метод из всех вышеперечисленных самый лучший и универсальный? При выборе методологии следует учитывать следующие факторы: Характер работы: есть ли четко определенный результат? Разработка веб-сайтов является творческим делом и поэтому подходит для гибкого метода. Разработка транзакционной системы, где есть четко определенный результат, больше подходит для водопадного метода. Тип клиента: согласен ли он работать итеративно, есть ли у него время на проверку и комментирование регулярных итераций? Представление об ИТ в организации: воспринимается ли ИТ как ценный партнер или неизбежное зло? В последнем случае используйте водопадный метод. Внутренний или внешний клиент: является ли ваш клиент внутренним или внешним? Водопадный метод подходит для внешних клиентов, от которых можно потребовать соблюдения подписанного договора, в отличие от внутренних клиентов, способных вынудить вас внести изменения, получив поддержку руководства.

Основные характеристики Scrum Один из “Agile процессов” Самоорганизующиеся команды Продукт разрабатывается серией “спринтов”, каждый не больше месяца Все требования записываются в виде единого списка “бэклога продукта” Использует простые правила для создания гибкой среды разработки проектов

Роли в Scrum: - Владелец продукта (Product Owner) - Команда (Scrum Team) - Скрам-мастер (Scrum Master)

Роли в Scrum: Product Owner Владелец продукта (Product Owner) - это человек, отвечающий за формирование списка требований к функциональности продукта. Владелец продукта обладает следующими основными правами и обязанностями: • формирует журнал продукта; • определяет приоритеты функциональности в соответствии с их коммерческой ценностью; • определяет дату и содержание выпусков продукта; • отвечает за коммерческую успешность продукта; • уточняет функциональность и приоритеты после каждого спринта; • принимает (или отклоняет) результаты проекта.

Роли в Scrum: Scrum Team Команда (Scrum Team) – группа, состоящая из пяти–девяти самостоятельных, инициативных разработчиков, непосредственно работающих над реализацией проекта. Команда обладает следующими основными правами и обязанностями: • активно участвует в выборе цели следующей итерации; • имеет право предпринимать все возможные (в рамках проекта) действия ради достижения цели спринта; • обеспечивает принятый уровень качества продукта; • самостоятельно организует себя и свою работу; • демонстрирует результаты работы владельцу проекта.

Роли в Scrum: Scrum. Master Скрам-мастер – человек, являющийся посредником между всеми участниками проекта, чьими основными обязанностями является организация процесса и соблюдение методологии Scrum. Скрам-мастер обладает следующими основными правами и обязанностями: • гарантирует высокую производительность работы команды; • отвечает за обеспечение кооперации между всеми участниками проекта; • отвечает за преодоление всех возникающих организационных и коммуникационных барьеров; • защищает команду от всех нежелательных воздействий извне; • отвечает за соблюдение на проекте всех правил методологии Scrum.

Фазы проекта в Scrum Проект в Scrum имеет три основных фазы: - подготовка (pregame), - разработка (game) - завершение (postgame).

Фазы проекта в Scrum: ПОДГОТОВКА Фаза подготовки состоит из двух основных частей: планирование и разработка архитектуры. На этапе планирования: • разрабатывается журнал продукта, который содержит исчерпывающий список требований к разрабатываемому продукту; • определяет дата и состав релизов; • осуществляется учет возможных рисков; • осуществляется выбор средств разработки; • оцениваются затраты на проект, включая стоимость разработки, маркетинга и вывода продукта на рынок; • подтверждается финансирование проекта в запланированном объеме. На этапе разработки архитектуры: • проводится обзор требований, внесенных в журнал проекта; • архитектура проекта разрабатывается (или уточняется) таким образом, чтобы удовлетворить все требования, внесенные в журнал проекта; • идентифицируются основные проблемы и сложности, которые

Фазы проекта в Scrum: РАЗРАБОТКА В методологии Scrum фаза разработки считается непредсказуемым процессом. Процессы дизайна, анализа и разработки рассматриваются как «черный ящик» и разделяются на относительно короткие итерации. Преимуществом такого вида разработки является возможность адекватного контроля над ходом проекта и своевременного реагирования на текущие результаты проекта. Каждая итерация, которая называется спринт (Sprint), имеет ограничение по времени от двух до четырех недель. Этого времени должно быть достаточно для реализации такого объема функциональности, который значительно влияет на состояние продукта и заметен с точки зрения владельца продукта. После завершения каждого спринта продукт должен оставаться в работоспособном состоянии.

Фазы проекта в Scrum: РАЗРАБОТКА Разделение процесса разработки на спринты позволяет владельцу продукта контролировать и влиять процесс разработки. Однако во время спринта журнал продукта замораживается в целях обеспечения высокой производительности команды и сокращения организационных издержек. Каждый спринт включает в себя следующие основные этапы: • сессия планирования спринта (Sprint Planning Meeting); • основная итерация (включает Daily Scrum Meeting); • демонстрационная сессия (Sprint Review Meeting). Сессия планирования спринта предназначена для формирования журнала спринта, а демонстрационная сессия предназначена демонстрации результатов спринта.

Фазы проекта в Scrum: РАЗРАБОТКА Итерация считается успешно завершенной, если полностью реализована вся запланированная функциональность и в журнале спринта не осталось незавершенных задач. В этом случае проводятся демонстрационная сессия и анализ производительности команды, после чего начинается следующая итерация. План спринта может оказаться неадекватным и команда может прийти к выводу, что она не сможет реализовать все включенные требования. Также возможна ситуация, в которой команда может получить возможность реализовать требования, не включенные в текущий спринт. В этом случае команда имеет право, проконсультировавшись с владельцем проекта, включить или исключить некоторые требования из текущего спринта.

Фазы проекта в Scrum: РАЗРАБОТКА Спринт может быть прерван в скрам-мастером в следующих случаях: • техническое решение, принятое на этапе планирования спринта, оказалось неработоспособным; • резко изменилось положение на рынке; • из спринта исключено слишком много требований, и его результаты будут ничтожны с точки зрения владельца проекта; • работоспособность команды заблокирована по организационным причинам.

Фазы проекта в Scrum: ЗАВЕРШЕНИЕ На этой стадии осуществляются такие действия, как: - доведение пользовательской документации; - сертификация; - подготовка маркетинговых материалов.

Scrum сессии: - Сессия планирования спринта (Sprint Planning Meeting) - Ежедневная скрам-сессия (Daily Scrum Meeting) - Демонстрационная сессия (Sprint Review Meeting)

Сессия планирования спринта проводится в начале каждого спринта. Данная сессия обычно имеет ограничение по времени в восемь часов и состоит из двух сегментов по четыре часа каждый. Первый сегмент предназначен для определения цели спринта на основе журнала продукта, а второй сегмент предназначен для формирования журнала спринта. На сессии планирования спринта присутствуют скрам- мастер, владелец продукта и команда.

Сессия планирования спринта Во время первого сегмента сессии команда указывает набор требований, которые она могла бы, гипотетически, реализовать в течение спринта. Команда также имеет право давать рекомендации относительно включения требований в спринт, но право включения требования в планируемый спринт полностью принадлежит владельцу продукта. Однако за командой сохраняется право контролировать объем работ, назначенных на планируемый спринт.

Сессия планирования спринта Результатом второго сегмента является список конкретных действий, которые необходимо выполнить для реализации требований, назначенных на спринт. Этот список называется журналом спринта. Журнал спринта может быть неполным, но должен быть достаточно подробным для того, чтобы команда сразу могла начать работу. Во время спринта КРАЙНЕ НЕЖЕЛАТЕЛЬНО вносить изменения в журнал спринта. Поэтому необходимо планировать длительность спринта исходя из соображения о том, как долго можно работать, не делая поправок Владелец продукта обязан присутствовать второго сегмента сессии и отвечать на все вопросы, возникающие у команды. Однако в течение второго сегмента команда действует полностью самостоятельно.

Ежедневная скрам - сессия В течение основной итерации ежедневно проводится так называемая скрам-сессия (Daily Scrum Meeting). Данная сессия имеет ограничение по времени в 15 минут, независимо от размеров команды. Основной целью ежедневной скрам-сессии является повышение дисциплины и фокусировка команды на целях спринта. Рекомендуется проводить скрам-сессию в одном и том же месте в одно и тоже время. На скрам-сессии в обязательном порядке должны присутствовать все члены команды, однако в любом случае крам-мастер начинает скрам-сессию точно в назначенное время, независимо от того, сколько членов команды присутствует.

Ежедневная скрам - сессия Во время скрам-сессии скрам-мастер последовательно опрашивает всех членов команды. Каждый член команды обязан ответить на следующие вопросы: • что он сделал для проекта со времени прошлой скрам-сессии; • что он собирается сделать для проекта до следующей скрам- сессии; • что мешает ему работать над проектом максимально эффективно. Во время скрам-сессии члены команды не должны углубляться в обсуждение дизайна, ошибок и прочих технических или организационных проблем. Скрам-мастер отвечает за управление процессом блиц-опроса. В каждый момент скрам-сессии говорит не более одного человека.

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

Демонстрационная сессия В конце презентации все представители менеджмента последовательно опрашиваются на предмет любых замечаний и предложений по поводу текущего спринта и всего проекта в целом. По итогам презентации и обсуждения, владелец продукта может инициировать дискуссию по добавлению в журнал продукта новых требований и изменению приоритетов. Ответственностью скрам-мастера является выбор участников демонстрационной сессии, решение организационных вопросов, связанных с проведением сессии и назначение даты следующей демонстрационной сессии.

Документы Методология Scrum требует наличия всего трех типов формальных документов: - журнала продукта (Product Backlog); - журнала спринта (Sprint Backlog); - график спринта (Sprint Burndown Chart).

Журнал продукта (Product Backlog) Журнал продукта содержит список требований к продукту, отсортированных по значимости. Журнал продукта должен включать функциональные и технические требования, необходимые для реализации продукта. Самые приоритетные из требований должны быть достаточно детально прописаны, чтобы команда могла их проанализировать и предоставить грубую оценку трудозатрат, необходимых для их реализации. Журнал продукта может дополняться, изменяться и уточняться в течение всего проекта.

Пример Product Backlog

Журнал спринта (Sprint Backlog) Журнал спринта содержит детализированный список задач, выполнение которых необходимо для реализации требований, которые включены в текущий спринт. Рекомендуется проводить разбивку на задачи таким образом, чтобы выполнение одной задачи занимало не больше двух дней. После завершения детализации, оценка трудозатрат по журналу спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, то команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем работ будет перенесен на следующую итерацию.

Пример Sprint Backlog Активности Пн Вт Ср Чт Пт Сделать интерфейс пользователя Сделать логику Протестировать логику Написать руководство пользователя Вынести утилиты в общий класс

График спринта (Sprint Burndown Chart) График спринта показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Этот график позволяет всем участникам проекта осуществлять анализ текущей ситуации и своевременно реагировать на отклонения. Во время сессии планирования команда формирует журнал спринта, который содержит список задач, выполнение которых необходимо для успешного завершения итерации. Сумма оценок трудозатрат по всем задачам в журнале спринта является общим объемом работы, который необходимо выполнить за итерацию. После завершения каждой задачи скрам-мастер пересчитывает оставшийся объем работ и отмечает это на графике спринта. Итерация считается успешной, если в журнале спринта не осталось незавершенных задач и график спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя.

Пример графика спринта

Что дает использование Scrum технологии? Прозрачность процесса, ежедневное отображение хода выполнения работ Предсказуемость сдачи релизов и выполнения проекта Повышение качества продукта: лучшее соответствие ожиданиям пользователей, уменьшение количества ошибок, за счёт их раннего обнаружения Увеличение продуктивности за счёт полного использования потенциала командной работы и фокусировки на производительности команды, а не на индивидуальной продуктивности Самоорганизация команды повышает мотивацию и обеспечивает обратную связь для корректировки процесса. Значительно уменьшает нагрузку на менеджмент.

В пятницу 09. 11. 2012, с 12: 00 – 15: 00 в ХНУРЕ состоится встреча с Сандером Хугендорном Директор по технологиям компании Capgemini. Ответственен за платформу разработки Capgemini — Accelerated Delivery Platform (ADP). Известный специалист в области методологий Agile, автор ряда публикаций и книг по UML и методологиям Agile. Тема – Ведение проектов с помощью методологии Agile. Докладчик – один из ведущих участников конференции NET Work - Харьков, 11 ноября. http: //network-ua. com/ Семинар на Английском языке.