Презентация на тему Инженерия программного обеспечения. (Лекция 2)

постепенного приближения к цели проекта путем проведения циклов испытаний с корректировкой

последующих, основанных на анализе результатов предыдущих

одна из первых методологий циклического наращивания функциональности и корректировки хода

проекта на основе анализа обратной связи от пользователей (первое упомнание 1986, первое описание Швабером и Джефом Сазерлендом[6] на OOPSLA’96).

разработки, позволяющий в жёстко фиксированные и небольшие по времени

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

функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность

одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель.

упорядоченный по их степени важности, подлежащих реализации. Элементы этого

списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). Резерв проекта открыт для редактирования для всех участников скрам процесса.

выбранную владельцем проекта из резерва проекта. Все функции разбиты

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

спринт. Показывает оставшиеся нерешенные задачи и трудозатраты, необходимые для

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

для спринта — показывает, сколько уже задач сделано("дело выгорело") и

сколько ещё остаётся сделать в текущем спринте.
диаграмма выгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

функциональность, которую добавляют в резерв. Зачастую история имеет следующую

структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам.

быть произведена раньше срока его планового окончания в исключительных

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

метрика оценки сложности истории, которая не учитывает затраты в

человекочасах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL).

- Добавляются к историям спринта. Выполнение каждой задачи оценивается

в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).

- Критерии определяющие степень готовности элемента из журнала пожеланий

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

совещания (Scrum meetings) следит за соблюдением всех принципов скрам,

разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.
владелец проекта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

доверия,
Участвует в митингах в качестве фасилитатора
Устраняет препятствия

Делает проблемы и открытые вопросы видимыми
Отвечает за соблюдение практик и процесса в команде

или представитель заказчика)
Отвечает за формирование product vision
Управляет ROI

Управляет ожиданиями заказчиков и всех заинтересованных лиц
Координирует и приоритизирует Product backlog
Предоставляет понятные и тестируемые требования команде
Взаимодействует с командой и заказчиком
Отвечает за приемку кода в конце каждой итерации

(Stakeholders) — лица, которые инициируют проект и для кого проект

будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

Управляющие (Managers) — люди, которые управляют персоналом.

Эксперты-консультанты (Consulting Experts)

в начале новой итерации Спринта
Из резерва проекта выбираются задачи,

обязательства по выполнению которых за спринт принимает на себя команда;
На основе выбранных задач создается резерв спринт. Каждая задача оценивается в идеальных человеко-часах;
Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
Обсуждается и определяется, каким образом будет реализован этот объём работ;
Продолжительность совещания ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
(первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта;
(вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.

могут наблюдать, но только «свиньи» говорят;
длится не более 15

минут;
проводится в одном и том же месте в течение спринта.
В течение совещания каждый член команды отвечает на 3 вопроса:
Что сделано с момента предыдущего ежедневного совещания?
Что будет сделано с момента текущего совещания до следующего?
Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу,

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

завершения спринта.
Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
Привлекается

максимальное количество зрителей.
Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
Нельзя демонстрировать незавершенную функциональность.
Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

команды высказывают своё мнение о прошедшем спринте.
Отвечают на два

основных вопроса:
Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем?
Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
Ограничена 1—3-мя часами.