Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

922 views

Published on

Доклад Станислава Рождественского на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург
www.analystdays.com

Published in: Education
  • Be the first to comment

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

  1. 1. ПОДХОДЫ К СПЕЦИФИКАЦИИ ИЗМЕНЕНИЙ Делаем осознанный выбор 22-Apr-16 © Станислав Рождественский 2016 Санкт-Петербург 1
  2. 2. В чем проблема со спецификацией изменений? ■ Заказчик: Нам нужно добавить поле на этот экран ■ БА: Хорошо, я посмотрю (…) ■ БА: У вас есть документация на это? ■ ПМ: Да. ■ БА: Она актуальна? ■ ПМ: Процентов на 80… ■ БА: А что конкретно не актуально? ■ ПМ: Надо смотреть, там были изменения… мы не обновляли ее полгода. 22-Apr-16 © Станислав Рождественский 2016 Санкт-Петербург 2
  3. 3. Содержание ■ Общие понятия ■ Подходы к спецификации изменений – Дельта – Целевое состояние – Параллельный подход – «Тощая» Дельта – «Тощее» Целевое состояние – Комбинированные подход ■ Заключение ■ Ваши вопросы 22-Apr-16 3© Станислав Рождественский 2016 Санкт-Петербург
  4. 4. Изменение – переход объекта из одного состояния в другое с течением времени 22-Apr-16 4 Текущее состояние Целевое состояние Дельта © Станислав Рождественский 2016 Санкт-Петербург
  5. 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. 6. Содержание ■ Общие понятия ■ Подходы к спецификации изменений – Дельта – Целевое состояние – Параллельный подход – «Тощая» Дельта – «Тощее» Целевое состояние – Комбинированные подход ■ Заключение ■ Ваши вопросы 22-Apr-16 6© Станислав Рождественский 2016 Санкт-Петербург
  7. 7. Спецификация – абстрактное описание реального приложения человеческим языком ■ Объяснить требования разработчикам ■ Согласовать логику приложения с заинтересованными лицами ■ Определить как тестовые сценарии ■ Обеспечить поддержку приложения ■ Основа для планирования проекта 22-Apr-16 7 Спецификация – это лишь одно из средств достижения целей. Можно им пользоваться, а можно и нет © Станислав Рождественский 2016 Санкт-Петербург
  8. 8. Содержание ■ Общие понятия ■ Подходы к спецификации изменений – Дельта – Целевое состояние – Параллельный подход – «Тощая» Дельта – «Тощее» Целевое состояние – Комбинированные подход ■ Заключение ■ Ваши вопросы 22-Apr-16 8© Станислав Рождественский 2016 Санкт-Петербург
  9. 9. Описываем Дельту: Схема Итерация 1 Добавить поле Нужно всплывающее окно Проверить уникальность логина Итерация 2 Убрать поле Добавить чекбокс Хочу розовое платье Проверить без учета кейса Итерация 3 Сделать кнопкой Теперь модальное окно Проверить минимальную длину Итерация 4 Добавить обратно Нет, голубое И максимальную тоже Итерация 5 Сделать зеленой кнопкой Пусть будет отдельная вкладка Лучше туфли Автоматический доступ 22-Apr-16 9© Станислав Рождественский 2016 Санкт-Петербург
  10. 10. Описываем Дельту: Когда и Как КОГДА использовать ■ Основная Цель: загрузить команду ■ Ресурсов БА не хватает КАК использовать ■ Записывать инкрементальные изменения в трекер ■ Изменения планируются на итерации и связываются с задачами разработчиков 22-Apr-16 10© Станислав Рождественский 2016 Санкт-Петербург
  11. 11. Описываем Дельту: примеры Пример спецификации Текущее состояние Пользователь не может ввести пароль менее 6 символов Изменение Увеличить минимальную длину пароля до 8 символов Целевое состояние Пользователь не может ввести менее 8 символов Инструменты ■ Трэкер (Jira,TFS,YouTrack и т.п.) ■ Отдельная страница на вики для каждого изменения / пакета, сгруппированные по релизам ■ ДокументWord для каждого изменения / пакета, хранящиеся в папках по релизам в системе контроля версий 22-Apr-16 11© Станислав Рождественский 2016 Санкт-Петербург
  12. 12. Описываем Дельту: За и Против для БА Плюсы ■ Не обязательно иметь полное актуальное описание системы ■ Не нужно тратить время на описание смежного функционала (восстановление требований) Минусы ■ Много артефактов (меньшего размера), которыми надо упралять ■ Стандартные форматы требований не подходят (напр. варианты использования) ■ Сложно отслеживать влияние изменений на смежный функционал 22-Apr-16 12 Если у вас нет полного актуального описания системы – придется использовать Дельту © Станислав Рождественский 2016 Санкт-Петербург
  13. 13. Описываем Дельту: Плюсы для команды ■ Каждый мой запрос записан ■ Маленькие документы приходят на проверку 22-Apr-16 13 Заказчик ■ Легко управлять набором изменений в каждой итерации ■ Можно отследить, сколько времени затрачено на изменения изначальных требований Руководитель Проекта ■ Можно проверять только то, что изменилось Тестирование ■ Ясно, что делать в этой итерации ■ Документы заморожены на каждый релиз Разработка © Станислав Рождественский 2016 Санкт-Петербург
  14. 14. Описываем Дельту : Минусы для команды ■ Как я могу принять правильное решение, если не вижу полного контекста системы? 22-Apr-16 14 Заказчик ■ Какое состояние конечное? Когда закончится поток изменений? Руководитель проекта ■ НепонятенТестовый Сценарий ■ Нужен цикл регрессионного тестирования Тестирование ■ Как мне влезать в чужой код низкого качества, если я не знаю, как он должен работать? Разработка © Станислав Рождественский 2016 Санкт-Петербург
  15. 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. 16. Описываем Целевое Состояние: Когда и Как КОГДА использвоать ■ Есть полное актуальное описание системы или время его подготовить ■ 80% системы не будет меняться ■ Основные цели: согласовать требования с Заинтересованными Лицами + поддержка приложения КАК использовать ■ Когда приходит изменение, выпускается новая версия описания системы ■ Аккуратно записываем изменения между версиями документа 22-Apr-16 16 • Новые функции всегда записываются в форме Целевого Состояния © Станислав Рождественский 2016 Санкт-Петербург
  17. 17. Описываем Целевое Состояние: Примеры Пример Спецификации ВИ-1 v2 Вход в систему Основной поток: 1. Ввести Имя пользователя 2. Ввести Пароль 3. Нажать Enter Альтернативный поток 1: 1. Если пользователь ввел Пароль менее 8 символов, отображается сообщение об ошибке 2. Пользователь изменяет пароль Инструменты ■ ДокументыWord в системе контроля версий (SharePoint, SVN и т.п.) ■ Вики портал ■ Специализированная система управления требвоаниями (напр. Enterprise Architect) 22-Apr-16 17© Станислав Рождественский 2016 Санкт-Петербург
  18. 18. Описываем Целевое Состояние : +/- для БА ЗА ■ В результате получаем полное описание системы ■ Легче отслеживать влияние на смежный функционал ■ Легче сделать небольшое изменение к описанному функционалу ПРОТИВ ■ Большие затраты на подготовку полного пакета документации на каждую итерацию ■ Поддержка больших документов ■ Если одно изменение затрагивает различный функционал – нужно переписывать разные части документа ■ Если изменение переносится в следующий релиз – сложно поддерживать актуальность документа 22-Apr-16 18© Станислав Рождественский 2016 Санкт-Петербург
  19. 19. Целевое Состояние : Плюсы для команды ■ Я вижу полное описание продукта, который получу 22-Apr-16 19 Заказчик ■ Финальное состояние продукта понятно ■ Легче осуществлять долгосрочное планирование Руководитель проекта ■ Есть основа для тестовых сценариев ■ Регрессионные дефекты выявляются раньше Тестирование ■ Я понимаю, как это код должен работать Разработка © Станислав Рождественский 2016 Санкт-Петербург
  20. 20. ■ А что здесь поменялось? ■ Что конкретно нужно делать в этой итерации? ■ Почему вы не можете заморозить требования? Целевое Состояние : Минусы для команды ■ Нужно проверять большие документы ■ Если было много изменений, то непонятно, почему сейчас так работает 22-Apr-16 20 Заказчик ■ Как сопоставить требования с планом по релизам? ■ Сколько времени мы потратили на запросы на изменения к основному функционалу? Руководитель Проекта Тестирование Разработка © Станислав Рождественский 2016 Санкт-Петербург
  21. 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. Параллельный подход ЗА ■ Закрывает все цели и потребности ПРОТИВ ■ Нужно больше времени БА для каждого изменения ■ Риск рассинхронизации двух потоков документации 22-Apr-16 22 Один из способов работы с трудностями Параллельного Подхода: держать один из потоков “тощим” © Станислав Рождественский 2016 Санкт-Петербург
  23. 23. Параллельны подход: «Тощая» Дельта Трэкер изменений ВИ-1 v2 Вход в систем у Основной поток: 1. Ввести Имя пользователя 2. Ввести Пароль 3. Нажать Enter Альтернативный поток 1: 1. Если пользователь ввел Пароль менее 8 символов, отображается сообщение об ошибке 2. Пользователь изменяет пароль Описание системы 22-Apr-16 23 Текущее состояние ВИ-1 v1 Изменение Изменить минимальную длину Пароля, как описано в ВИ-1 v2 Целевое состояние ВИ-1 v2 © Станислав Рождественский 2016 Санкт-Петербург
  24. 24. Параллельный подход: «тощее» Целевое состояние Трэкер изменений ВИ-1 Вход в систему См. требования в: ID-123 – первоначальные требования ID-234 – Изменения в Релизе 1 ID-345 – Изменения в Релизе 2 ID-456 – Изменения в Релизе 3 Карта требований 22-Apr-16 24 Текущее состояние Пользователь не может ввести пароль менее 6 символов Изменение Увеличить минимальную длину пароля до 8 символов Целевое состояние Пользователь не может ввести менее 8 символов © Станислав Рождественский 2016 Санкт-Петербург
  25. 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. 26. Комбинированный подход ЗА ■ Не обязательно иметь полное актуальное описание системы ■ Сохраняется история изменений ■ Легче управлять загрузкой БА: когда в потоке новых требований пауза, можно обновлять описание системы ПРОТИВ ■ Нужно ли поддерживать актуальное описание системы для каждой среды (разработка, тестирование, производство)? каждой версии приложения? ■ Если не запланировать время на описание системы – остается чистая Дельта 22-Apr-16 26© Станислав Рождественский 2016 Санкт-Петербург
  27. 27. Комбинированный подход КОГДА использовать ■ Большая часть системы будет меняться ■ Ресурсов БА не хватает ■ Необходимо поддерживать разные версии приложения параллельно КАК использовать ■ Записываем изменения в трэкер и назначаем на релизы ■ Группируем изменения по функциональным модулям, напр. даем ссылки на соответствующий раздел описания системы ■ Периодически «накатываем» изменения на описание системы в порядке их реализации 22-Apr-16 27© Станислав Рождественский 2016 Санкт-Петербург
  28. 28. Содержание ■ Общие понятия ■ Подходы к спецификации изменений – Дельта – Целевое состояние – Параллельный подход – «Тощая» Дельта – «Тощее» Целевое состояние – Комбинированные подход ■ Заключение ■ Ваши вопросы 22-Apr-16 28© Станислав Рождественский 2016 Санкт-Петербург
  29. 29. Спецификация изменений в Водопаде и Гибких методологиях Целевое состояние Дельта Водопад • Поддержка больших документов на протяжении проекта • Обычно, «тощая» Дельта все равно нужна • Как часть Управления изменениями, записываем все запросы в Трэкер • Готовим описание системы только к крупным релизам, можно аутсорсить техническому писателю Гибкие (SCRUM) • Если История не принята заказчиком и требует изменений – оно возвращается в бэклог • Если нет Дефектов, только изменения – история принимается • Для изменения создается новая история, ссылающаяся на старую 22-Apr-16 29© Станислав Рождественский 2016 Санкт-Петербург
  30. 30. Чем больше и сложнее проект – тем труднее поддерживать актуальное Целевое Состояние 22-Apr-16 30 Размер / Сложность / Длительность проекта ДельтаЦелевое © Станислав Рождественский 2016 Санкт-Петербург
  31. 31. Можно менять подход на протяжении жизненного цикла проекта 22-Apr-16 31 Время проекта ДельтаЦелевое На этапе первичного сбора требований для нового функционала просто описывать Целевое состояние Чем больше приходит изменений, тем сложнее поддерживать описание системы Поток изменений уменьшается и пора подумать о поддержке системы © Станислав Рождественский 2016 Санкт-Петербург
  32. 32. Как изменить подход? Параллельный / Комбиниро- ванный Целевое состояниеДельта 22-Apr-16 32 Обратный инжиниринг требований для конкретного релиза Перестаем обновлять описание системы Приостанавливаем обновление Описания Системы, записываем только изменения Добавляем все изменения в последнюю версию описания системы Сравнение Версий позволяет получить Дельту из Описания системы. Но это не удобно для большого потока изменений © Станислав Рождественский 2016 Санкт-Петербург
  33. 33. Содержание ■ Общие понятия ■ Подходы к спецификации изменений – Дельта – Целевое состояние – Параллельный подход – «Тощая» Дельта – «Тощее» Целевое состояние – Комбинированные подход ■ Заключение ■ Ваши вопросы 22-Apr-16 33 Станислав Рождественский Бизнес аналитик, ДатаАрт, Санкт-Петербург Email: stigro@gmail.com Skype: stasroj LinkedIn: https://ru.linkedin.com/in/sirojdestvensky © Станислав Рождественский 2016 Санкт-Петербург

×