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

1,183 views

Published on

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

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,183
On SlideShare
0
From Embeds
0
Number of Embeds
652
Actions
Shares
0
Downloads
35
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

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

×