SlideShare a Scribd company logo
Agile команда и не-Agile
заказчик. Что делать?
Алексей Борисов
ООО «Дойче Банк»
О докладчике
•АлексейБорисов
ООО«ДойчеБанк»
• Руководитель профессии
“Функциональный Аналитик”
• Руководитель подразделения aналитиков
• В прошлом аналитик, ПМ, разработчик
•15 лет в ИТ
• Доклад отражает личное мнение и взгляды
автора и может не совпадать с мнением и
позицией ООО «Дойче Банк»
Содержание
Agileкомандаи не-Agileзаказчик.Что
делать?
•Причины и последствия
•Что Делать?
•Некоторые прикладные практики
Специфика окружения
•Enterprise Software
•Внутренний заказчик
•Распределенные команды
•Разработкавнутреннимикомандамии
вендором
Так бывает
•Цель проекта too high-level
• Заказчик ожидает точных оценок и
дат закрытия фаз
•Команда
•OptionA.Требуетпредельно детальную
постановку задачи
•Option B. We are agile (no dates , no
phases)
Ожидания от аналитика
•Командазапрашиваетдеталидля
оценки
•Детали недоступны на
момент запроса оценки
•Заказчик ожидает оценку
сложности
•Команда дает оценку “в птичках ”,
она непонятна заказчику
Методологии – ищем
Silver Bullet
• Waterfall– like
•Фаза анализатребованийотделенаотразработки
•Четкиеграницымеждуфазами
•Формальности (полноедокументирование,формальныйsign offитд)
•Agile
•Люди и взаимодействие важнее процессов и инструментов
•Работающий продукт важнее исчерпывающей документации
•Сотрудничество с заказчиком важнее согласования условий контракта
•Готовность к изменениям важнее следования первоначальному плану
•Вывод
•Back Doors
•Silver Bullet отсутствует (Captain Obvious)
Что делать?
• Принять тезис “Silver Bullet отсутствует”
•Процесс должен мотивировать к
производственной дисциплине
•УправлениеScope-ом
•Управлениеизменениями спервыхднейпроекта
•Гибкость
•Scope меняется; итерации; избегать излишнего формализма
•Практики
•Далее в докладе
Практики
•Бизнес требования
• УправлениеScope-ом
• Живойдокумент
•BaselinevsSignoff
•Принцип“GoodEnough”
•[Agile]“Честный”DoDиретроспектива
•Интеграциявциклрелиза
•Артефакты:Концепт->Требования->Продуктив
•Несоздавайтеартефактов,невстроенныхвпроцесс
Бизнес требования
•Бизнес требования должны быть
сформулированы
•Если бизнес требований нет –
сформулируете их
• Бизнес требования – это не описание
решения
•Получили объемный
неструктурированный BRD – не
поленитесь, сделайте Summary
Scope итерации
•Содержит scope items (aka features)
•Опубликован
•Доступен команде
•Фиксируется (snapshots)
•Один источник Scope-a
•История изменений
Живой документ
• Простой контроль версий и авторства
требования
•Живой документ до момента baseline
•Фиксируем Baseline в виде сохраненной
копии
•Sign off только, если работает для данной
команды
Baseline vs Sign off
Принцип “Good Enough”
Требования полны
Понятны вне контекста
Содержат минимум
умолчаний
Full Enough
Detailed Enough
Умолчания возможны,
если они приняты
командой
•Уровень полноты и качества требований должен
соответствовать договоренностям в команде
•Договаривайтесь!
•Избегайте “Ideal World Assumption”
Спринты, DoD
и ретроспектива
•“Честный” Definition of Done (DoD)
•DoD определен; опубликован; команда следует DoD
•DoD включает QA
•Ретроспектива: практика внедрена и
не является формальностью
•Scope items не мигрируют из спринта в спринт
•Аналитик помогает команде при оценке
результата спринта (DoD) и проведении
ретроспективы
Интеграция
в цикл релиза
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
Артефакты
•Бизнес требования (summary)
•[Концепт]
•Scope итерации
•Детальные требования
•Acceptance критерии
•ИнтеграциясQA
•Не создавайте артефактов, не
встроенных в процесс разработки
Рискованные паттерны
•Не определена цель, бизнес требования
• Только динамический Scope
• Требования только в трекере
•Отсутствие итераций
•Не определен DoD
•Разработка потребованиям кдалекому
будущему
•Сложные для восприятия артефакты
•IdealWorldAssumption
Какие средства
использовать?
•ПредложенныепрактикиToolAgnostic
• Практический опыт внедрения с
использованием средств из стека
Atlassian
•Предлагайте ваш вариант
В качестве заключения
•Подумайте,апотомделайте.Слепо
следоватьметодологиямопасно.
•В каждой из методологий есть много
рекомендаций, которые вам подойдут.
Выбирайте подходящие.
• Критерий выбора – результат.
•В итоге заказчику нужно решение, а
не процесс или набор артефактов.
Спасибо за внимание
Алексей Борисов
Borisovav80@gmail.com
Ваши вопросы?

More Related Content

More from SQALab

Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
SQALab
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
SQALab
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
SQALab
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
SQALab
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
SQALab
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
SQALab
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
SQALab
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
SQALab
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
SQALab
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
SQALab
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
SQALab
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
SQALab
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
SQALab
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
SQALab
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
SQALab
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
SQALab
 
Истинная сила тестировщика - информация
Истинная сила тестировщика - информацияИстинная сила тестировщика - информация
Истинная сила тестировщика - информация
SQALab
 
Автоматизация тестирования встроенного ПО
Автоматизация тестирования встроенного ПОАвтоматизация тестирования встроенного ПО
Автоматизация тестирования встроенного ПО
SQALab
 
Правильный подход к составлению профиля нагрузочного тестирования
Правильный подход к составлению профиля нагрузочного тестированияПравильный подход к составлению профиля нагрузочного тестирования
Правильный подход к составлению профиля нагрузочного тестирования
SQALab
 
Sustainable Test Automation: Collaborate within Team
Sustainable Test Automation: Collaborate within TeamSustainable Test Automation: Collaborate within Team
Sustainable Test Automation: Collaborate within Team
SQALab
 

More from SQALab (20)

Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 
Истинная сила тестировщика - информация
Истинная сила тестировщика - информацияИстинная сила тестировщика - информация
Истинная сила тестировщика - информация
 
Автоматизация тестирования встроенного ПО
Автоматизация тестирования встроенного ПОАвтоматизация тестирования встроенного ПО
Автоматизация тестирования встроенного ПО
 
Правильный подход к составлению профиля нагрузочного тестирования
Правильный подход к составлению профиля нагрузочного тестированияПравильный подход к составлению профиля нагрузочного тестирования
Правильный подход к составлению профиля нагрузочного тестирования
 
Sustainable Test Automation: Collaborate within Team
Sustainable Test Automation: Collaborate within TeamSustainable Test Automation: Collaborate within Team
Sustainable Test Automation: Collaborate within Team
 

Agile команда и не-Agile заказчик. Что делать?

  • 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 только, если работает для данной команды
  • 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 Ваши вопросы?