9. Сначала определим цели
• заказчик получает то,
что ему,
действительно,
необходимо
(что еще?)
• постановка задач для
разработчиков
• минимизация
количества доработок
• разумные сроки
реализации
11. Проблемы при работе с требованиями
• «расплывчатые» требования
• излишняя детализация задач, поступающих от
заказчика
• «как не поломать то, что уже работает хорошо»
• неверные предположения, «мы думали, а
оказалось…»
• противоречивые требования
• ожидаемые сроки разработки превышают те, что
необходимы заказчику
13. «Расплывчатые» требования
• нет четкой формулировки
задачи
• недостаточно ясно изложены
цели
• много «белых пятен»
• в формулировке требований
много сравнений («хотим как
там»), которые не дают
полной картины того, что
необходимо
15. «Расплывчатые» требования:
• добраться до непосредственных
пользователей будущего функционала,
раскрыть предполагаемые сценарии
использования
• «заполнение пробелов» на основе знаний о
бизнес-процессах заказчика, на основе уже
работающего функционала
• несколько «точек» обратной связи (первичные
требования, раннее тестирование,
«макетный» вариант)
как добиться четкости?
17. Избыточность информации:
• много допустимых вариантов
– какой выбрать?
• детали, которые сказываются
на сроках или сложно
совместимы с уже
реализованным
функционалом
19. Избыточность информации:
как отсеять лишнее
и не потерять нужное?
понять, кем и для чего будет
использоваться будущий функционал
отделить наиболее важную часть
функционала от деталей
отдать пользователям
и получить отзывы
разобраться с деталями
(доработать, отказаться от них,
вынести в отдельный функционал)
21. «Как не поломать то, что уже работает»
• найти решение, которое минимально меняет уже
работающий функционал, надстройка вместо
переделки
• анализ того, что может быть затронуто
(в т. ч. подключение разработчиков, общение с
командами смежных систем)
• раннее тестирование, в т. ч. пользователями
• постепенный переход к новому (сначала
реализуется сама возможность, затем поэтапно
переключаемся на новое и отказываемся от
старого) –> минимизация риска
23. Неверные предположения: последствия
• срок разработки превысил ожидаемый
• сделали, как хотел заказчик, но в итоге оказалось не
то, что ему реально было нужно
• заказчика не устраивают какие-либо параметры,
которые изначально не предусмотрели (скорость
работы, связь с другими системами)
• небольшая доработка выросла в переделку
значительной части системы
• возникли срочные непредвиденные доработки для
доведения до рабочего состояния
• пользователям недоступны все возможности
функционала или не предусмотрены все нужные
сценарии
24. Неверные предположения: причины
• заказчик указал не все сценарии
• функционал разработан с учетом того, что будет
запущен в эксплуатацию другой функционал или
стороннее ПО, а второе отложилось
• предоставлены ошибочные данные об объеме
данных
25. Неверные предположения: как избежать?
• выяснить у заказчика, что может повлиять в
будущем (переход на новую систему и др.)
• предварительное нагрузочное тестирование на
раннем этапе разработки
• ранний фидбэк, передать «макетный» вариант
или минимальный рабочий вариант
• найти «точки риска» и путь, при котором
возможные доработки будут минимальны
27. Противоречивые требования:
• доработка уже работающего
функционала или корректировка
бизнес-процесса под новый
функционал (не всегда
возможно)
• поиск альтернативного пути,
который решит потребности
заказчика
• компромиссное решение
(выделить детали, от которых
можно отказаться)
как найти выход?
29. А что со сроками реализации?
заказчик: «хочу
за такой срок»
30. А что со сроками реализации?
• отсеивание не очень критичных доработок,
которые «ударяют по срокам»
• определение оптимальной последовательности
выполнения задач
• расстановка приоритетов
• при необходимости реализовать альтернативный
быстрый вариант, позже перейти на более
правильный вариант
33. Итеративный поход
можно первую версию отдать раньше,
доработки реализовать позже
пользователи могут раньше начать
использовать функционал,
выигрыш по срокам
34. Итеративный поход
уточнение требований
в процессе разработки
гибкость при работе с требованиями,
уменьшение риска того,
что заказчик получит не то,
что ему было реально необходимо
36. К чему стремимся в итоге?
• исчерпывающая формулировка
задач для разработчиков
• точная оценка затрат,
запланированных для решения
каждой задачи
• минимизация возможных
доработок после передачи
заказчику реализованного
функционала
• и, главное, оправдание ожиданий
заказчика в разумные сроки.