Презентация Алексея Борисова на конференции Analyst Days-3, 24 мая 2014, Москва www.analystdays.com

1. Agile команда и не-Agile
заказчик. Что делать?
Алексей Борисов
ООО «Дойче Банк»

2. О докладчике
•АлексейБорисов
ООО«ДойчеБанк»
• Руководитель профессии
“Функциональный Аналитик”
• Руководитель подразделения aналитиков
• В прошлом аналитик, ПМ, разработчик
•15 лет в ИТ
• Доклад отражает личное мнение и взгляды
автора и может не совпадать с мнением и
позицией ООО «Дойче Банк»

3. Содержание
Agileкомандаи не-Agileзаказчик.Что
делать?
•Причины и последствия
•Что Делать?
•Некоторые прикладные практики

4. Специфика окружения
•Enterprise Software
•Внутренний заказчик
•Распределенные команды
•Разработкавнутреннимикомандамии
вендором

5. Так бывает
•Цель проекта too high-level
• Заказчик ожидает точных оценок и
дат закрытия фаз
•Команда
•OptionA.Требуетпредельно детальную
постановку задачи
•Option B. We are agile (no dates , no
phases)

6. Ожидания от аналитика
•Командазапрашиваетдеталидля
оценки
•Детали недоступны на
момент запроса оценки
•Заказчик ожидает оценку
сложности
•Команда дает оценку “в птичках ”,
она непонятна заказчику

7. Методологии – ищем
Silver Bullet
• Waterfall– like
•Фаза анализатребованийотделенаотразработки
•Четкиеграницымеждуфазами
•Формальности (полноедокументирование,формальныйsign offитд)
•Agile
•Люди и взаимодействие важнее процессов и инструментов
•Работающий продукт важнее исчерпывающей документации
•Сотрудничество с заказчиком важнее согласования условий контракта
•Готовность к изменениям важнее следования первоначальному плану
•Вывод
•Back Doors
•Silver Bullet отсутствует (Captain Obvious)

8. Что делать?
• Принять тезис “Silver Bullet отсутствует”
•Процесс должен мотивировать к
производственной дисциплине
•УправлениеScope-ом
•Управлениеизменениями спервыхднейпроекта
•Гибкость
•Scope меняется; итерации; избегать излишнего формализма
•Практики
•Далее в докладе

9. Практики
•Бизнес требования
• УправлениеScope-ом
• Живойдокумент
•BaselinevsSignoff
•Принцип“GoodEnough”
•[Agile]“Честный”DoDиретроспектива
•Интеграциявциклрелиза
•Артефакты:Концепт->Требования->Продуктив
•Несоздавайтеартефактов,невстроенныхвпроцесс

10. Бизнес требования
•Бизнес требования должны быть
сформулированы
•Если бизнес требований нет –
сформулируете их
• Бизнес требования – это не описание
решения
•Получили объемный
неструктурированный BRD – не
поленитесь, сделайте Summary

11. Scope итерации
•Содержит scope items (aka features)
•Опубликован
•Доступен команде
•Фиксируется (snapshots)
•Один источник Scope-a
•История изменений

12. Живой документ
• Простой контроль версий и авторства
требования
•Живой документ до момента baseline
•Фиксируем Baseline в виде сохраненной
копии
•Sign off только, если работает для данной
команды

13. Baseline vs Sign off

14. Принцип “Good Enough”
Требования полны
Понятны вне контекста
Содержат минимум
умолчаний
Full Enough
Detailed Enough
Умолчания возможны,
если они приняты
командой
•Уровень полноты и качества требований должен
соответствовать договоренностям в команде
•Договаривайтесь!
•Избегайте “Ideal World Assumption”

15. Спринты, DoD
и ретроспектива
•“Честный” Definition of Done (DoD)
•DoD определен; опубликован; команда следует DoD
•DoD включает QA
•Ретроспектива: практика внедрена и
не является формальностью
•Scope items не мигрируют из спринта в спринт
•Аналитик помогает команде при оценке
результата спринта (DoD) и проведении
ретроспективы

16. Интеграция
в цикл релиза
Major Release #X
UAT sign off, GCMs
Development (sprints)
Functional testing (sprints)
Next Release Scope definition,
Functional Analysis of next release
items
Ongoing Functional analysis of Release scope items
Release
start date
Release
end date
UAT
start dateScope freeze
date
New requests capture, initial analysis
Scope review and update (regular)
Sprint1 Sprint2 Sprint3 Sprint4 Sprint5
DEV
QA
FA for spr2 FA for spr3 Stabilization Sprints
Bug-fixing, next release items
development
SIT, Regression, UAT testing

17. Артефакты
•Бизнес требования (summary)
•[Концепт]
•Scope итерации
•Детальные требования
•Acceptance критерии
•ИнтеграциясQA
•Не создавайте артефактов, не
встроенных в процесс разработки

18. Рискованные паттерны
•Не определена цель, бизнес требования
• Только динамический Scope
• Требования только в трекере
•Отсутствие итераций
•Не определен DoD
•Разработка потребованиям кдалекому
будущему
•Сложные для восприятия артефакты
•IdealWorldAssumption

19. Какие средства
использовать?
•ПредложенныепрактикиToolAgnostic
• Практический опыт внедрения с
использованием средств из стека
Atlassian
•Предлагайте ваш вариант

20. В качестве заключения
•Подумайте,апотомделайте.Слепо
следоватьметодологиямопасно.
•В каждой из методологий есть много
рекомендаций, которые вам подойдут.
Выбирайте подходящие.
• Критерий выбора – результат.
•В итоге заказчику нужно решение, а
не процесс или набор артефактов.

21. Спасибо за внимание
Алексей Борисов
Borisovav80@gmail.com
Ваши вопросы?