Подходы к спецификации изменений

33
ПОДХОДЫ К СПЕЦИФИКАЦИИ ИЗМЕНЕНИЙ Делаем осознанный выбор 6/21/22 © Станислав Рождественский 2016 Санкт-Петербург 1

Transcript of Подходы к спецификации изменений

Page 1: Подходы к спецификации изменений

May 1, 2023 1

ПОДХОДЫ К СПЕЦИФИКАЦИИ

ИЗМЕНЕНИЙДелаем осознанный выбор

© Станислав Рождественский 2016 Санкт-Петербург

Page 2: Подходы к спецификации изменений

May 1, 2023 2

В чем проблема со спецификацией изменений?

■ Заказчик: Нам нужно добавить поле на этот экран

■ БА: Хорошо, я посмотрю(…)■ БА: У вас есть документация на

это?■ ПМ: Да.■ БА: Она актуальна?■ ПМ: Процентов на 80…■ БА: А что конкретно не актуально?■ ПМ: Надо смотреть, там были

изменения… мы не обновляли ее полгода.

© Станислав Рождественский 2016 Санкт-Петербург

Page 3: Подходы к спецификации изменений

May 1, 2023 3

Содержание■ Общие понятия■ Подходы к спецификации изменений

– Дельта– Целевое состояние– Параллельный подход– «Тощая» Дельта– «Тощее» Целевое состояние– Комбинированные подход

■ Заключение■ Ваши вопросы

© Станислав Рождественский 2016 Санкт-Петербург

Page 4: Подходы к спецификации изменений

May 1, 2023 4

Изменение – переход объекта из одного состояния в другое с течением времени

Текущее состояние

Целевое состояние

Дельта

© Станислав Рождественский 2016 Санкт-Петербург

Page 5: Подходы к спецификации изменений

May 1, 2023 5

Карта изменений приложения может быть сложнойРазработка: v1.0 v2.0 v3.0

Тестирование: v1.1 v2.1 v3.1

Производство: v1.2 v2.2 v3.2

Время

© Станислав Рождественский 2016 Санкт-Петербург

Page 6: Подходы к спецификации изменений

May 1, 2023 6

Содержание■ Общие понятия■ Подходы к спецификации изменений

– Дельта– Целевое состояние– Параллельный подход– «Тощая» Дельта– «Тощее» Целевое состояние– Комбинированные подход

■ Заключение■ Ваши вопросы

© Станислав Рождественский 2016 Санкт-Петербург

Page 7: Подходы к спецификации изменений

May 1, 2023 7

Спецификация – абстрактное описание реального приложения человеческим языком■ Объяснить требования разработчикам■ Согласовать логику приложения с

заинтересованными лицами■ Определить как тестовые сценарии■ Обеспечить поддержку приложения■ Основа для планирования проекта

Спецификация – это лишь одно из средств достижения целей.

Можно им пользоваться, а можно и нет

© Станислав Рождественский 2016 Санкт-Петербург

Page 8: Подходы к спецификации изменений

May 1, 2023 8

Содержание■ Общие понятия■ Подходы к спецификации изменений

– Дельта– Целевое состояние– Параллельный подход– «Тощая» Дельта– «Тощее» Целевое состояние– Комбинированные подход

■ Заключение■ Ваши вопросы

© Станислав Рождественский 2016 Санкт-Петербург

Page 9: Подходы к спецификации изменений

May 1, 2023 9

Описываем Дельту: СхемаИтерац

ия 1Добавить поле

Нужно всплывающее

окно

Проверить уникальность

логина

Итерация 2

Убрать поле

Добавить чекбокс

Хочу розовое платье

Проверить без учета кейса

Итерация 3

Сделать кнопкойТеперь

модальное окно

Проверить минимальную

длину

Итерация 4Добавить обратно

Нет, голубоеИ

максимальную тоже

Итерация 5

Сделать зеленой кнопкой

Пусть будет отдельная вкладка

Лучше туфли

Автоматический доступ

© Станислав Рождественский 2016 Санкт-Петербург

Page 10: Подходы к спецификации изменений

May 1, 2023 10

Описываем Дельту: Когда и КакКОГДА использовать

■ Основная Цель: загрузить команду

■ Ресурсов БА не хватает

КАК использовать

■ Записывать инкрементальные изменения в трекер

■ Изменения планируются на итерации и связываются с задачами разработчиков

© Станислав Рождественский 2016 Санкт-Петербург

Page 11: Подходы к спецификации изменений

May 1, 2023 11

Описываем Дельту: примерыПример спецификацииТекущее состояние

Пользователь не может ввести пароль менее 6 символов

Изменение

Увеличить минимальную длину пароля до 8 символов

Целевое состояние

Пользователь не может ввести менее 8 символов

Инструменты■ Трэкер (Jira, TFS, YouTrack и

т.п.)■ Отдельная страница на

вики для каждого изменения / пакета, сгруппированные по релизам

■ Документ Word для каждого изменения / пакета, хранящиеся в папках по релизам в системе контроля версий© Станислав Рождественский 2016 Санкт-Петербург

Page 12: Подходы к спецификации изменений

May 1, 2023 12

Описываем Дельту: За и Против для БА

Плюсы■ Не обязательно иметь

полное актуальное описание системы

■ Не нужно тратить время на описание смежного функционала (восстановление требований)

Минусы■ Много артефактов

(меньшего размера), которыми надо упралять

■ Стандартные форматы требований не подходят (напр. варианты использования)

■ Сложно отслеживать влияние изменений на смежный функционал

?

Если у вас нет полного актуального описания системы – придется использовать Дельту

© Станислав Рождественский 2016 Санкт-Петербург

Page 13: Подходы к спецификации изменений

May 1, 2023 13

Описываем Дельту: Плюсы для команды

■ Каждый мой запрос записан■ Маленькие документы

приходят на проверку

Заказчик■ Легко управлять набором

изменений в каждой итерации

■ Можно отследить, сколько времени затрачено на изменения изначальных требований

Руководитель Проекта

■ Можно проверять только то, что изменилось

Тестирование

■ Ясно, что делать в этой итерации

■ Документы заморожены на каждый релиз

Разработка© Станислав Рождественский 2016 Санкт-Петербург

Page 14: Подходы к спецификации изменений

May 1, 2023 14

Описываем Дельту : Минусы для команды

■ Как я могу принять правильное решение, если не вижу полного контекста системы?

Заказчик■ Какое состояние конечное?

Когда закончится поток изменений?

Руководитель проекта

■ Непонятен Тестовый Сценарий

■ Нужен цикл регрессионного тестирования

Тестирование

■ Как мне влезать в чужой код низкого качества, если я не знаю, как он должен работать?

Разработка

?

© Станислав Рождественский 2016 Санкт-Петербург

Page 15: Подходы к спецификации изменений

May 1, 2023 15

Описываем Целевое Состояние: схемаИтерац

ия 1ВИ-1 v1ВИ-2 v1ВИ-3 v1ВИ-4 v1ВИ-5 v1

Итерация 2

ВИ-1 v2ВИ-2 v1ВИ-3 v2ВИ-4 v1ВИ-5 v2

Итерация 3

ВИ-1 v2ВИ-2 v2ВИ-3 v2ВИ-4 v1ВИ-5 v3

Итерация 4

ВИ-1 v3ВИ-2 v2ВИ-3 v2ВИ-4 v1ВИ-5 v4

Итерация 5

ВИ-1 v4ВИ-2 v2ВИ-3 v3ВИ-4 v1ВИ-5 v5

© Станислав Рождественский 2016 Санкт-Петербург

Page 16: Подходы к спецификации изменений

May 1, 2023 16

Описываем Целевое Состояние: Когда и Как

КОГДА использвоать■ Есть полное актуальное

описание системы или время его подготовить

■ 80% системы не будет меняться

■ Основные цели: согласовать требования с Заинтересованными Лицами + поддержка приложения

КАК использовать■ Когда приходит изменение,

выпускается новая версия описания системы

■ Аккуратно записываем изменения между версиями документа

• Новые функции всегда записываются в форме Целевого Состояния

© Станислав Рождественский 2016 Санкт-Петербург

Page 17: Подходы к спецификации изменений

May 1, 2023 17

Описываем Целевое Состояние: ПримерыПример СпецификацииВИ-1 v2 Вход в систему

Основной поток:1. Ввести Имя пользователя2. Ввести Пароль3. Нажать Enter

Альтернативный поток 1:1. Если пользователь ввел Пароль менее 8 символов, отображается сообщение об ошибке2. Пользователь изменяет пароль

Инструменты■ Документы Word в

системе контроля версий (SharePoint, SVN и т.п.)

■ Вики портал■ Специализированная

система управления требвоаниями (напр. Enterprise Architect)

© Станислав Рождественский 2016 Санкт-Петербург

Page 18: Подходы к спецификации изменений

May 1, 2023 18

Описываем Целевое Состояние : +/- для БАЗА■ В результате получаем

полное описание системы■ Легче отслеживать

влияние на смежный функционал

■ Легче сделать небольшое изменение к описанному функционалу

ПРОТИВ■ Большие затраты на подготовку

полного пакета документации на каждую итерацию

■ Поддержка больших документов■ Если одно изменение затрагивает

различный функционал – нужно переписывать разные части документа

■ Если изменение переносится в следующий релиз – сложно поддерживать актуальность документа

© Станислав Рождественский 2016 Санкт-Петербург

Page 19: Подходы к спецификации изменений

May 1, 2023 19

Целевое Состояние : Плюсы для команды

■ Я вижу полное описание продукта, который получу

Заказчик■ Финальное состояние

продукта понятно■ Легче осуществлять

долгосрочное планирование

Руководитель проекта

■ Есть основа для тестовых сценариев

■ Регрессионные дефекты выявляются раньше

Тестирование

■ Я понимаю, как это код должен работать

Разработка© Станислав Рождественский 2016 Санкт-Петербург

Page 20: Подходы к спецификации изменений

May 1, 2023 20

■ А что здесь поменялось?■ Что конкретно нужно делать в этой итерации? ■ Почему вы не можете заморозить требования?

Целевое Состояние : Минусы для команды

■ Нужно проверять большие документы

■ Если было много изменений, то непонятно, почему сейчас так работает

Заказчик■ Как сопоставить

требования с планом по релизам?

■ Сколько времени мы потратили на запросы на изменения к основному функционалу?

Руководитель Проекта

Тестирование Разработка

?

© Станислав Рождественский 2016 Санкт-Петербург

Page 21: Подходы к спецификации изменений

May 1, 2023 21

ВИ-1 v1ВИ-2 v1ВИ-3 v1ВИ-4 v1ВИ-5 v1

ВИ-1 v2ВИ-2 v1ВИ-3 v2ВИ-4 v1ВИ-5 v2

ВИ-1 v2ВИ-2 v2ВИ-3 v2ВИ-4 v1ВИ-5 v3

ВИ-1 v3ВИ-2 v2ВИ-3 v2ВИ-4 v1ВИ-5 v4

ВИ-1 v4ВИ-2 v2ВИ-3 v3ВИ-4 v1ВИ-5 v5

Параллельный подход: СхемаИтерац

ия 1Добавить поле

Нужно всплывающее окно

Проверить уникальность пароля

Итерация 2Убрать поле

Нарисовать чекобокс

Хочу розовое платье

Проверить без учета регистра

Итерация 3

Сделать кнопкой

Теперь модальное окно

Проверить мин. размер

Итерация 4

Добавить обратно

Нет, голубое

Проверить макс. размер

Итерация 5

Сделать зеленой кнопкой

Пусть будет отдельна страница

Лучше новые туфли

Автоматический доступ

Дел

ьты

Цел

евое

со

стоя

ние

© Станислав Рождественский 2016 Санкт-Петербург

Page 22: Подходы к спецификации изменений

May 1, 2023 22

Параллельный подходЗА■ Закрывает все цели и

потребности

ПРОТИВ■ Нужно больше

времени БА для каждого изменения

■ Риск рассинхронизации двух потоков документации

Один из способов работы с трудностями Параллельного Подхода: держать один из потоков “тощим”

© Станислав Рождественский 2016 Санкт-Петербург

Page 23: Подходы к спецификации изменений

May 1, 2023 23

Параллельны подход: «Тощая» Дельта

Трэкер измененийВИ-1 v2 Вход в систему

Основной поток:1. Ввести Имя пользователя2. Ввести Пароль3. Нажать Enter

Альтернативный поток 1:1. Если пользователь ввел Пароль менее 8 символов, отображается сообщение об ошибке2. Пользователь изменяет пароль

Описание системыТекущее состояние

ВИ-1 v1

Изменение

Изменить минимальную длину Пароля, как описано в ВИ-1 v2

Целевое состояние

ВИ-1 v2

© Станислав Рождественский 2016 Санкт-Петербург

Page 24: Подходы к спецификации изменений

May 1, 2023 24

Параллельный подход: «тощее» Целевое состояние

Трэкер измененийВИ-1 Вход в систему

См. требования в:ID-123 – первоначальные требованияID-234 – Изменения в Релизе 1ID-345 – Изменения в Релизе 2ID-456 – Изменения в Релизе 3

Карта требованийТекущее состояние

Пользователь не может ввести пароль менее 6 символов

Изменение

Увеличить минимальную длину пароля до 8 символов

Целевое состояние

Пользователь не может ввести менее 8 символов

© Станислав Рождественский 2016 Санкт-Петербург

Page 25: Подходы к спецификации изменений

May 1, 2023 25

Комбинированный подход: СхемаТекуще

е состоян

иеВИ-1 v1

ВИ-2 v1

ВИ-3 v1

ВИ-4 v1

ВИ-5 v1

Итерация 1Убрать поле

Нарисовать чекбокс

Нужно розовое платье

Проверять без учета регистра

Итерация 2

Сделать кнопкой

Переделать в модальное окно

Проверять минимальный

размер

Итерация 3

Добавить обратно

Нет, голубое

Проверять максимальный

размер

Целевое

состояниеВИ-1 v1

ВИ-2 v2

ВИ-3 v2

ВИ-4 v2

ВИ-5 v2

© Станислав Рождественский 2016 Санкт-Петербург

Page 26: Подходы к спецификации изменений

May 1, 2023 26

Комбинированный подходЗА■ Не обязательно иметь

полное актуальное описание системы

■ Сохраняется история изменений

■ Легче управлять загрузкой БА: когда в потоке новых требований пауза, можно обновлять описание системы

ПРОТИВ■ Нужно ли поддерживать

актуальное описание системы для каждой среды (разработка, тестирование, производство)? каждой версии приложения?

■ Если не запланировать время на описание системы – остается чистая Дельта

© Станислав Рождественский 2016 Санкт-Петербург

Page 27: Подходы к спецификации изменений

May 1, 2023 27

Комбинированный подходКОГДА использовать■ Большая часть системы

будет меняться■ Ресурсов БА не хватает■ Необходимо поддерживать

разные версии приложения параллельно

КАК использовать■ Записываем изменения в

трэкер и назначаем на релизы■ Группируем изменения по

функциональным модулям, напр. даем ссылки на соответствующий раздел описания системы

■ Периодически «накатываем» изменения на описание системы в порядке их реализации

© Станислав Рождественский 2016 Санкт-Петербург

Page 28: Подходы к спецификации изменений

May 1, 2023 28

Содержание■ Общие понятия■ Подходы к спецификации изменений

– Дельта– Целевое состояние– Параллельный подход– «Тощая» Дельта– «Тощее» Целевое состояние– Комбинированные подход

■ Заключение■ Ваши вопросы

© Станислав Рождественский 2016 Санкт-Петербург

Page 29: Подходы к спецификации изменений

May 1, 2023 29

Спецификация изменений в Водопаде и Гибких методологиях

Целевое состояние Дельта

Водопад

• Поддержка больших документов на протяжении проекта

• Обычно, «тощая» Дельта все равно нужна

• Как часть Управления изменениями, записываем все запросы в Трэкер

• Готовим описание системы только к крупным релизам, можно аутсорсить техническому писателю

Гибкие (SCRUM)

• Если История не принята заказчиком и требует изменений – оно возвращается в бэклог

• Если нет Дефектов, только изменения – история принимается

• Для изменения создается новая история, ссылающаяся на старую

© Станислав Рождественский 2016 Санкт-Петербург

Page 30: Подходы к спецификации изменений

May 1, 2023 30

Чем больше и сложнее проект – тем труднее поддерживать актуальное Целевое Состояние

Размер / Сложность / Длительность проекта

Дель

таЦе

лево

е

© Станислав Рождественский 2016 Санкт-Петербург

Page 31: Подходы к спецификации изменений

May 1, 2023 31

Можно менять подход на протяжении жизненного цикла проекта

Время проекта

Дель

таЦе

лево

е

На этапе первичного сбора требований для нового функционала просто описывать Целевое состояние

Чем больше приходит изменений, тем сложнее поддерживать описание системы

Поток изменений уменьшается и пора подумать о поддержке системы

© Станислав Рождественский 2016 Санкт-Петербург

Page 32: Подходы к спецификации изменений

May 1, 2023 32

Как изменить подход?Параллель

ный / Комбиниро-

ванный

Целевое состояниеДельта

Обратный инжиниринг требований для конкретного релиза

Перестаем обновлять описание системы

Приостанавливаем обновление Описания Системы, записываем только изменения

Добавляем все изменения в последнюю версию описания системы

Сравнение Версий позволяет получить Дельту из Описания системы. Но это не удобно для большого потока изменений© Станислав Рождественский 2016 Санкт-Петербург

Page 33: Подходы к спецификации изменений

May 1, 2023 33

Содержание■ Общие понятия■ Подходы к спецификации изменений

– Дельта– Целевое состояние– Параллельный подход– «Тощая» Дельта– «Тощее» Целевое состояние– Комбинированные подход

■ Заключение■ Ваши вопросы

Станислав РождественскийБизнес аналитик, ДатаАрт, Санкт-Петербург

Email: [email protected]: stasroj

LinkedIn: https://ru.linkedin.com/in/sirojdestvensky

© Станислав Рождественский 2016 Санкт-Петербург