3 denys gobov - change request specification the knowledge base or the task for the team
1.
2. Специфицируем изменения: постановка задачи
или база знаний?
Станислав Рождественский,
Лидер сообщества бизнес-аналитиков, DataArt
Денис Гобов,
Лидер сообщества бизнес-аналитиков, DataArt
3. Разрешите представиться
Денис Гобов
▪ 16 лет опыта в системном и бизнес-анализе
▪ Senior Business Analyst компании DataArt
▪ Вице-президент Киевского отделения IIBA
▪ Консультант и тренер
▪ CBAP® & PMI-PBA ® & CPRE-FL® & ICP-BVA® & BCS BAF®
▪ Канд. техн. наук
▪ Лучший бизнес-аналитик, Ukrainian IT Awards-2013/2016
4. Задачи аналитика
С точки зрения бизнес-аналитика
• Понять текущее состояние: проблемы и возможности
• Определить желаемое состояние заказчика
• Определить стратегию перехода
С точки зрения команды:
• Поставить задачу на разработку
+
• Рассказать как это все работает
5. История из жизни
• Заказчик: Нам нужно добавить поле на этот
экран
• БА: Хорошо, я посмотрю
(…)
• БА: У вас есть документация на это?
• ПМ: Да.
• БА: Она актуальна?
• ПМ: Процентов на 80…
• БА: А что конкретно не актуально?
• ПМ: Надо смотреть, там были изменения…
мы не обновляли ее полгода.
6. Изменение
Есть одна неизменная вещь в этом мире – это изменение
Текущее
состояние
Целевое
состояние
Дельта
Текущее
состояние
Целевое
состояние
Дельта
7. Это волшебное слово «Спека»
Спецификация – документ, который содержит полное и четкое описание разрабатываемого
продукта
• Поставить задачу разработчикам
• Согласовать логику приложения с заинтересованными лицами
• Определить тестовые сценарии
• Использовать при планировании проекта
• Обеспечить поддержку приложения
Спецификация – это лишь одно из средств достижения целей.
Можно им пользоваться, а можно и нет
8. Подходы к спецификации требований
• Дельта – Постановка задачи
• Целевое состояния - База знаний
• Параллельный подход – «И нашим и вашим»
• «Тощая дельта»
• «Тощее целевое состояние»
• Комбинированные подходы
9. «Дельта»: Схема
Спринт 1
Добавить поле
Нужно
всплывающее
окно
Проверить
уникальность
логина
Спринт 2
Убрать поле
Добавить
чекбокс
Проверить без
учета кейса
Спринт 3
Сделать
кнопкой
Теперь
модальное
окно
Проверить
минимальную
длину
Спринт 4
Добавить
обратно
И
максимальную
тоже
Итерация 5
Сделать
зеленой
кнопкой
Пусть будет
отдельная
вкладка
Автоматический
доступ
10. «Дельта»: Когда и как?
КОГДА
• Основная Цель: загрузить
команду
• Ресурсов БА не хватает
КАК
• Записывать инкрементальные изменения в
трекер
• Изменения планируются на итерации и
связываются с задачами разработчиков
• Формат: User Story + Acceptance criteria
11. «Дельта»: За и Против для БА
Плюсы
• Не обязательно иметь полное
актуальное описание системы
• Не нужно тратить время на
описание смежного функционала
(восстановление требований)
Минусы
• Нет общей картины
• Много артефактов (меньшего размера),
которыми надо управлять
• Сложно отслеживать влияние изменений
на смежный функционал
Если у вас нет полного актуального описания системы –
придется использовать Дельту
12. «Дельта»: Плюсы для команды
• Каждый мой запрос записан
• На утверждение приходят
небольшие артефакты
Заказчик
• Легко управлять набором изменений в
каждой итерации
• Можно отследить, сколько времени
затрачено на изменения изначальных
требований
Руководитель Проекта
• Можно проверять только то,
что изменилось
Тестирование
• Ясно, что делать в этой итерации
• Документы заморожены на каждый
релиз
Разработка
13. «Дельта»: Минусы для команды
• Как я могу принять
правильное решение, если
не вижу полного контекста
системы?
Заказчик
• Какое состояние конечное? Когда
закончится поток изменений?
Руководитель Проекта
• Непонятен Тестовый
Сценарий
• Нужен цикл регрессионного
тестирования
Тестирование
• Как мне влезать в чужой код низкого
качества, если я не знаю, как он
должен работать?
Разработка
15. «Целевое состояние»: Когда и как?
КОГДА
• Есть полное актуальное описание
системы или время его подготовить
• 80% системы не будет меняться
• Основные цели: согласовать
требования с Заинтересованными
Лицами + поддержка приложения
КАК
• Когда приходит изменение, выпускается
новая версия описания системы
• Аккуратно записываем изменения между
версиями документа
16. «Целевое состояние»: За и Против для БА
Плюсы
• В результате получаем полное
описание системы
• Легче отслеживать влияние на
смежный функционал
• Легче сделать небольшое
изменение к описанному
функционалу
Минусы
• Большие затраты на подготовку полного пакета
документации на каждую итерацию
• Поддержка больших документов
• Если одно изменение затрагивает различный
функционал – нужно переписывать разные части
документа
• Если изменение переносится в следующий релиз
– сложно поддерживать актуальность документа
17. «Дельта»: Плюсы для команды
• Я вижу полное описание
продукта, который получу
Заказчик
• Финальное состояние продукта
понятно
• Легче осуществлять долгосрочное
планирование
Руководитель Проекта
• Есть основа для тестовых
сценариев
• Регрессионные дефекты
выявляются раньше
Тестирование
Я понимаю, как это код должен работать
Разработка
18. «Дельта»: Минусы для команды
• Нужно проверять большие
документы
• Если было много изменений,
то непонятно, почему сейчас
так работает
Заказчик
• Как сопоставить требования с планом
по релизам?
• Сколько времени мы потратили на
запросы на изменения к основному
функционалу?
Руководитель Проекта
• А что здесь поменялось?
• Что конкретно нужно делать в этой итерации?
• Почему вы не можете заморозить требования?
Тестирование Разработка
19. «Параллельный подход»: Схема
Итерация 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
Спринт 1
Добавить поле
Нужно
всплывающее
окно
Проверить
уникальность
логина
Спринт 2
Убрать поле
Добавить чекбокс
Проверить без
учета кейса
Спринт 3
Сделать кнопкой
Теперь модальное
окно
Проверить
минимальную
длину
Спринт 4
Добавить обратно
И максимальную
тоже
Итерация 5
Сделать зеленой
кнопкой
Пусть будет
отдельная
вкладка
Автоматический
доступ
20. «Параллельный подход»: За и Против
Плюсы
• Закрывает все цели и потребности
Минусы
• Нужно больше времени БА для каждого
изменения
• Риск рассинхронизации двух потоков
документации
Один из способов работы с трудностями Параллельного
Подхода: держать один из потоков “тощим”
21. «Параллельный подход»: «Тощая» Дельта
Трекер изменений
ВИ-1 v2
Вход в
систему
Основной поток:
1. Пользователь вводить логин и пароль
2. Пользователь инициирует выполнение
3. Система подтверждает корректность
данных
Альтернативный поток 1:
3.1. Пользователь ввел Пароль менее 8
символов
3.1.1 Система отображает сообщение
об ошибке и просит сменить пароль
Описание системы
Текущее
состояние
ВИ-1 v1
Изменение Изменить
минимальную длину
Пароля, как описано
в ВИ-1 v2
Целевое
состояние
ВИ-1 v2
22. «Параллельный подход»: «Тощее» ЦС
Трекер изменений Описание системы
Текущее
состояние
Пользователь не может
ввести пароль менее 6
символов
Изменение Увеличить
минимальную длину
пароля до 8 символов
Целевое
состояние
Пользователь не может
ввести менее 8
символов
ВИ-1
Вход в
систему
См. требования в:
ID-123 – первоначальные
требования
ID-234 – Изменения в Релизе 1
ID-345 – Изменения в Релизе 2
ID-456 – Изменения в Релизе 3
23. «Комбинированный подход»: Схема
Текущее
состояние
ВИ-1 v1
ВИ-2 v1
ВИ-3 v1
ВИ-4 v1
ВИ-5 v1
Итерация 1
Убрать поле
Нарисовать чекбокс
Нужно розовое
платье
Проверять без
учета регистра
Итерация 2
Сделать кнопкой
Переделать в
модальное окно
Проверять
минимальный
размер
Итерация 3
Добавить обратно
Нет, голубое
Проверять
максимальный
размер
Целевое
состояние
ВИ-1 v1
ВИ-2 v2
ВИ-3 v2
ВИ-4 v2
ВИ-5 v2
24. «Комбинированный подход»: За и Против
Плюсы
• Не обязательно иметь полное
актуальное описание системы
• Сохраняется история изменений
• Легче управлять загрузкой БА: когда
в потоке новых требований пауза,
можно обновлять описание системы
Минусы
• Нужно ли поддерживать актуальное описание
системы для каждой среды (разработка,
тестирование, производство)? каждой версии
приложения?
• Если не запланировать время на описание
системы – остается чистая Дельта
25. «Комбинированный подход»: За и Против
Когда
• Большая часть системы будет
меняться
• Ресурсов БА не хватает
• Необходимо поддерживать разные
версии приложения параллельно
Как
• Записываем изменения в трекер и назначаем на
релизы
• Группируем изменения по функциональным
модулям, напр. даем ссылки на соответствующий
раздел описания системы
• Периодически «накатываем» изменения на
описание системы в порядке их реализации
27. Меняем «коней» на переправе
Время проекта
ДельтаЦелевое
На этапе первичного
сбора требований для
нового функционала
просто описывать
Целевое состояние
Чем больше приходит
изменений, тем сложнее
поддерживать описание
системы
Поток изменений
уменьшается и пора
подумать о поддержке
системы
