Встречи:

Планирование спринта (Sprint Planning Meeting)

• Происходит в начале новой итерации Спринта.

• Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;

• На основе выбранных задач создается Sprint Backlog. Каждая задача оценивается в идеальных человеко-часах;

• Обсуждается и определяется, каким образом будет реализован этот объём работ;

• Продолжительность совещания ограничено сверху 4-8 часами

Ежедневное совещание (Daily Scrum meeting)

• начинается точно вовремя;

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

• длится не более 15 минут;

• проводится в одном и том же месте в течение спринта.

• В течение совещания каждый член команды отвечает на 3 вопроса:

1. Что сделано с момента предыдущего ежедневного совещания?

2. Что будет сделано с момента текущего совещания до следующего?

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

Обзор итогов спринта / Демонстрация (Sprint review meeting / Demo Meeting)

• Проводится после завершения спринта.

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

• Привлекается максимальное количество зрителей.

• Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).

• Нельзя демонстрировать незавершенную функциональность.

• Ограничена 4-мя часами.

Ретроспективное совещание (Retrospective Meeting)

• Проводится после завершения спринта.

• Члены команды высказывают своё мнение о прошедшем спринте.

• Отвечают на два основных вопроса:

1. Что было сделано хорошо в прошедшем спринте?

2. Что надо улучшить в следующем?

• Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

• Ограничена 1—3-мя часами.

3.) Выявление требований к программному обеспечению. Способы представления требований

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

Виды требований по уровням

Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).

Функциональные требования — определяют «как» реализовать продукт. Описывается в системной спецификации (system requirement specification, SRS).

Методы выявления требований

• Интервью, опросы, анкетирование

• Мозговой штурм, семинар

• Наблюдение за производственной деятельностью, «фотографирование» рабочего дня

• Анализ нормативной документации

• Анализ моделей деятельности

• Анализ конкурентных продуктов

• Анализ статистики использования предыдущих версий системы

Проверка требований

Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

Анализ требований

Требования склонны к проблемам двусмысленности, неполноты, и несогласованности. Их устранение на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки. Анализ требований направлен на решение данных проблем.

Документирование требований

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

В зарубежной и российской практике встречаются следующие типы документов требований:

• Концепция программы (Vision)

• Спецификация программного обеспечения (англ. Software Requirements Specification, SRS). За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

• Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

Изменение требований

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