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

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

2. В чем проблема со спецификацией
изменений?
■ Заказчик: Нам нужно добавить поле
на этот экран
■ БА: Хорошо, я посмотрю
(…)
■ БА: У вас есть документация на это?
■ ПМ: Да.
■ БА: Она актуальна?
■ ПМ: Процентов на 80…
■ БА: А что конкретно не актуально?
■ ПМ: Надо смотреть, там были
изменения… мы не обновляли ее
полгода.
22-Apr-16 © Станислав Рождественский 2016 Санкт-Петербург 2

3. Содержание
■ Общие понятия
■ Подходы к спецификации изменений
– Дельта
– Целевое состояние
– Параллельный подход
– «Тощая» Дельта
– «Тощее» Целевое состояние
– Комбинированные подход
■ Заключение
■ Ваши вопросы
22-Apr-16 3© Станислав Рождественский 2016 Санкт-Петербург

4. Изменение – переход объекта из одного
состояния в другое с течением времени
22-Apr-16 4
Текущее
состояние
Целевое
состояние
Дельта
© Станислав Рождественский 2016 Санкт-Петербург

5. Карта изменений приложения может
быть сложной
22-Apr-16 5
Разработка: v1.0 v2.0 v3.0
Тестирование: v1.1 v2.1 v3.1
Производство: v1.2 v2.2 v3.2
Время
© Станислав Рождественский 2016 Санкт-Петербург

6. Содержание
■ Общие понятия
■ Подходы к спецификации изменений
– Дельта
– Целевое состояние
– Параллельный подход
– «Тощая» Дельта
– «Тощее» Целевое состояние
– Комбинированные подход
■ Заключение
■ Ваши вопросы
22-Apr-16 6© Станислав Рождественский 2016 Санкт-Петербург

7. Спецификация – абстрактное описание
реального приложения человеческим языком
■ Объяснить требования разработчикам
■ Согласовать логику приложения с заинтересованными лицами
■ Определить как тестовые сценарии
■ Обеспечить поддержку приложения
■ Основа для планирования проекта
22-Apr-16 7
Спецификация – это лишь одно из средств достижения целей.
Можно им пользоваться, а можно и нет
© Станислав Рождественский 2016 Санкт-Петербург

8. Содержание
■ Общие понятия
■ Подходы к спецификации изменений
– Дельта
– Целевое состояние
– Параллельный подход
– «Тощая» Дельта
– «Тощее» Целевое состояние
– Комбинированные подход
■ Заключение
■ Ваши вопросы
22-Apr-16 8© Станислав Рождественский 2016 Санкт-Петербург

9. Описываем Дельту: Схема
Итерация
1
Добавить поле
Нужно всплывающее
окно
Проверить
уникальность логина
Итерация
2
Убрать поле
Добавить чекбокс
Хочу розовое платье
Проверить без учета
кейса
Итерация
3
Сделать кнопкой
Теперь модальное
окно
Проверить
минимальную длину
Итерация
4
Добавить обратно
Нет, голубое
И максимальную тоже
Итерация
5
Сделать зеленой
кнопкой
Пусть будет
отдельная вкладка
Лучше туфли
Автоматический
доступ
22-Apr-16 9© Станислав Рождественский 2016 Санкт-Петербург

10. Описываем Дельту: Когда и Как
КОГДА использовать
■ Основная Цель: загрузить
команду
■ Ресурсов БА не хватает
КАК использовать
■ Записывать
инкрементальные
изменения в трекер
■ Изменения планируются на
итерации и связываются с
задачами разработчиков
22-Apr-16 10© Станислав Рождественский 2016 Санкт-Петербург

11. Описываем Дельту: примеры
Пример спецификации
Текущее
состояние
Пользователь не может
ввести пароль менее 6
символов
Изменение Увеличить
минимальную длину
пароля до 8 символов
Целевое
состояние
Пользователь не может
ввести менее 8 символов
Инструменты
■ Трэкер (Jira,TFS,YouTrack и т.п.)
■ Отдельная страница на вики для
каждого изменения / пакета,
сгруппированные по релизам
■ ДокументWord для каждого
изменения / пакета, хранящиеся в
папках по релизам в системе
контроля версий
22-Apr-16 11© Станислав Рождественский 2016 Санкт-Петербург

12. Описываем Дельту: За и Против для БА
Плюсы
■ Не обязательно иметь полное
актуальное описание системы
■ Не нужно тратить время на
описание смежного функционала
(восстановление требований)
Минусы
■ Много артефактов (меньшего
размера), которыми надо упралять
■ Стандартные форматы требований
не подходят (напр. варианты
использования)
■ Сложно отслеживать влияние
изменений на смежный
функционал
22-Apr-16 12
Если у вас нет полного актуального описания системы –
придется использовать Дельту
© Станислав Рождественский 2016 Санкт-Петербург

13. Описываем Дельту: Плюсы для команды
■ Каждый мой запрос записан
■ Маленькие документы приходят
на проверку
22-Apr-16 13
Заказчик
■ Легко управлять набором
изменений в каждой итерации
■ Можно отследить, сколько
времени затрачено на изменения
изначальных требований
Руководитель Проекта
■ Можно проверять только то, что
изменилось
Тестирование
■ Ясно, что делать в этой итерации
■ Документы заморожены на
каждый релиз
Разработка
© Станислав Рождественский 2016 Санкт-Петербург

14. Описываем Дельту : Минусы для команды
■ Как я могу принять правильное
решение, если не вижу полного
контекста системы?
22-Apr-16 14
Заказчик
■ Какое состояние конечное? Когда
закончится поток изменений?
Руководитель проекта
■ НепонятенТестовый Сценарий
■ Нужен цикл регрессионного
тестирования
Тестирование
■ Как мне влезать в чужой код
низкого качества, если я не знаю,
как он должен работать?
Разработка
© Станислав Рождественский 2016 Санкт-Петербург

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
22-Apr-16 15© Станислав Рождественский 2016 Санкт-Петербург

16. Описываем Целевое Состояние: Когда и Как
КОГДА использвоать
■ Есть полное актуальное описание
системы или время его
подготовить
■ 80% системы не будет меняться
■ Основные цели: согласовать
требования с Заинтересованными
Лицами + поддержка приложения
КАК использовать
■ Когда приходит изменение,
выпускается новая версия
описания системы
■ Аккуратно записываем изменения
между версиями документа
22-Apr-16 16
• Новые функции всегда записываются в форме Целевого
Состояния
© Станислав Рождественский 2016 Санкт-Петербург

17. Описываем Целевое Состояние: Примеры
Пример Спецификации
ВИ-1 v2
Вход в
систему
Основной поток:
1. Ввести Имя пользователя
2. Ввести Пароль
3. Нажать Enter
Альтернативный поток 1:
1. Если пользователь ввел
Пароль менее 8 символов,
отображается сообщение об
ошибке
2. Пользователь изменяет
пароль
Инструменты
■ ДокументыWord в системе
контроля версий (SharePoint,
SVN и т.п.)
■ Вики портал
■ Специализированная
система управления
требвоаниями (напр.
Enterprise Architect)
22-Apr-16 17© Станислав Рождественский 2016 Санкт-Петербург

18. Описываем Целевое Состояние : +/- для БА
ЗА
■ В результате получаем полное
описание системы
■ Легче отслеживать влияние на
смежный функционал
■ Легче сделать небольшое
изменение к описанному
функционалу
ПРОТИВ
■ Большие затраты на подготовку
полного пакета документации на
каждую итерацию
■ Поддержка больших документов
■ Если одно изменение затрагивает
различный функционал – нужно
переписывать разные части
документа
■ Если изменение переносится в
следующий релиз – сложно
поддерживать актуальность
документа
22-Apr-16 18© Станислав Рождественский 2016 Санкт-Петербург

19. Целевое Состояние : Плюсы для команды
■ Я вижу полное описание продукта,
который получу
22-Apr-16 19
Заказчик
■ Финальное состояние продукта
понятно
■ Легче осуществлять долгосрочное
планирование
Руководитель проекта
■ Есть основа для тестовых
сценариев
■ Регрессионные дефекты
выявляются раньше
Тестирование
■ Я понимаю, как это код должен
работать
Разработка
© Станислав Рождественский 2016 Санкт-Петербург

20. ■ А что здесь поменялось?
■ Что конкретно нужно делать в этой итерации?
■ Почему вы не можете заморозить требования?
Целевое Состояние : Минусы для
команды
■ Нужно проверять большие
документы
■ Если было много изменений, то
непонятно, почему сейчас так
работает
22-Apr-16 20
Заказчик
■ Как сопоставить требования с
планом по релизам?
■ Сколько времени мы потратили на
запросы на изменения к
основному функционалу?
Руководитель Проекта
Тестирование Разработка
© Станислав Рождественский 2016 Санкт-Петербург

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
Сделать зеленой кнопкой
Пусть будет отдельна
страница
Лучше новые туфли
Автоматический доступ
22-Apr-16 21
Дельты
Целевое
состояние
© Станислав Рождественский 2016 Санкт-Петербург

22. Параллельный подход
ЗА
■ Закрывает все цели и
потребности
ПРОТИВ
■ Нужно больше времени БА
для каждого изменения
■ Риск рассинхронизации
двух потоков документации
22-Apr-16 22
Один из способов работы с трудностями Параллельного Подхода:
держать один из потоков “тощим”
© Станислав Рождественский 2016 Санкт-Петербург

23. Параллельны подход: «Тощая»
Дельта
Трэкер изменений
ВИ-1 v2
Вход в
систем
у
Основной поток:
1. Ввести Имя пользователя
2. Ввести Пароль
3. Нажать Enter
Альтернативный поток 1:
1. Если пользователь ввел
Пароль менее 8 символов,
отображается сообщение об
ошибке
2. Пользователь изменяет
пароль
Описание системы
22-Apr-16 23
Текущее
состояние
ВИ-1 v1
Изменение Изменить минимальную
длину Пароля, как
описано в ВИ-1 v2
Целевое
состояние
ВИ-1 v2
© Станислав Рождественский 2016 Санкт-Петербург

24. Параллельный подход: «тощее» Целевое
состояние
Трэкер изменений
ВИ-1
Вход в
систему
См. требования в:
ID-123 – первоначальные
требования
ID-234 – Изменения в Релизе
1
ID-345 – Изменения в Релизе
2
ID-456 – Изменения в
Релизе 3
Карта требований
22-Apr-16 24
Текущее
состояние
Пользователь не может
ввести пароль менее 6
символов
Изменение Увеличить
минимальную длину
пароля до 8 символов
Целевое
состояние
Пользователь не может
ввести менее 8
символов
© Станислав Рождественский 2016 Санкт-Петербург

25. Комбинированный подход: Схема
Текущее
состояние
ВИ-1 v1
ВИ-2 v1
ВИ-3 v1
ВИ-4 v1
ВИ-5 v1
Итерация
1
Убрать поле
Нарисовать чекбокс
Нужно розовое
платье
Проверять без учета
регистра
Итерация
2
Сделать кнопкой
Переделать в
модальное окно
Проверять
минимальный размер
Итерация
3
Добавить обратно
Нет, голубое
Проверять
максимальный размер
Целевое
состояние
ВИ-1 v1
ВИ-2 v2
ВИ-3 v2
ВИ-4 v2
ВИ-5 v2
22-Apr-16 25© Станислав Рождественский 2016 Санкт-Петербург

26. Комбинированный подход
ЗА
■ Не обязательно иметь полное
актуальное описание системы
■ Сохраняется история изменений
■ Легче управлять загрузкой БА:
когда в потоке новых требований
пауза, можно обновлять описание
системы
ПРОТИВ
■ Нужно ли поддерживать
актуальное описание системы для
каждой среды (разработка,
тестирование, производство)?
каждой версии приложения?
■ Если не запланировать время на
описание системы – остается
чистая Дельта
22-Apr-16 26© Станислав Рождественский 2016 Санкт-Петербург

27. Комбинированный подход
КОГДА использовать
■ Большая часть системы будет
меняться
■ Ресурсов БА не хватает
■ Необходимо поддерживать
разные версии приложения
параллельно
КАК использовать
■ Записываем изменения в трэкер и
назначаем на релизы
■ Группируем изменения по
функциональным модулям, напр.
даем ссылки на соответствующий
раздел описания системы
■ Периодически «накатываем»
изменения на описание системы в
порядке их реализации
22-Apr-16 27© Станислав Рождественский 2016 Санкт-Петербург

28. Содержание
■ Общие понятия
■ Подходы к спецификации изменений
– Дельта
– Целевое состояние
– Параллельный подход
– «Тощая» Дельта
– «Тощее» Целевое состояние
– Комбинированные подход
■ Заключение
■ Ваши вопросы
22-Apr-16 28© Станислав Рождественский 2016 Санкт-Петербург

29. Спецификация изменений в Водопаде и
Гибких методологиях
Целевое состояние Дельта
Водопад
• Поддержка больших документов
на протяжении проекта
• Обычно, «тощая» Дельта все
равно нужна
• Как часть Управления
изменениями, записываем все
запросы в Трэкер
• Готовим описание системы только к
крупным релизам, можно
аутсорсить техническому
писателю
Гибкие
(SCRUM)
• Если История не принята
заказчиком и требует изменений
– оно возвращается в бэклог
• Если нет Дефектов, только
изменения – история принимается
• Для изменения создается новая
история, ссылающаяся на старую
22-Apr-16 29© Станислав Рождественский 2016 Санкт-Петербург

30. Чем больше и сложнее проект – тем труднее
поддерживать актуальное Целевое Состояние
22-Apr-16 30
Размер / Сложность / Длительность проекта
ДельтаЦелевое
© Станислав Рождественский 2016 Санкт-Петербург

31. Можно менять подход на протяжении
жизненного цикла проекта
22-Apr-16 31
Время проекта
ДельтаЦелевое
На этапе
первичного сбора
требований для
нового
функционала
просто описывать
Целевое состояние
Чем больше приходит
изменений, тем сложнее
поддерживать описание
системы
Поток изменений
уменьшается и пора
подумать о поддержке
системы
© Станислав Рождественский 2016 Санкт-Петербург

32. Как изменить подход?
Параллельный
/ Комбиниро-
ванный
Целевое
состояниеДельта
22-Apr-16 32
Обратный инжиниринг
требований для конкретного
релиза
Перестаем обновлять
описание системы
Приостанавливаем обновление
Описания Системы,
записываем только изменения
Добавляем все
изменения в
последнюю версию
описания системы
Сравнение Версий позволяет получить
Дельту из Описания системы. Но это не
удобно для большого потока изменений
© Станислав Рождественский 2016 Санкт-Петербург

33. Содержание
■ Общие понятия
■ Подходы к спецификации изменений
– Дельта
– Целевое состояние
– Параллельный подход
– «Тощая» Дельта
– «Тощее» Целевое состояние
– Комбинированные подход
■ Заключение
■ Ваши вопросы
22-Apr-16 33
Станислав Рождественский
Бизнес аналитик, ДатаАрт, Санкт-Петербург
Email: stigro@gmail.com
Skype: stasroj
LinkedIn: https://ru.linkedin.com/in/sirojdestvensky
© Станислав Рождественский 2016 Санкт-Петербург