"Рассказывайте истории, не пишите их" - совет от Гойко Аджича | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

"Рассказывайте истории, не пишите их" - совет от Гойко Аджича

16 лют. 2018

Глава книги Гойко Аджича и Дэвида Эванса: "Пятьдесят быстрых идей улучшить ваши пользовательские истории" в редакции Алексея Кривицкого.

Книга издаётся на русском языке в середине 2018 года.

Рассказывайте истории, не пишите их

Пользовательские истории зачастую ошибочно воспринимаются как легковесные требования, выдвигаемые стейкхолдерами команде разработки проекта. Такое непонимание оборачивается тем, что пользовательские истории собираются в инструменте управления выполнением задач, а представители бизнеса записывают туда массу деталей. За редким исключением, когда сам представитель бизнеса является ещё и техническим экспертом, обладающим перспективным видением данного продукта, такое разделение труда не позволяет организациям воспользоваться преимуществами пользовательских историй.

Чтобы всё стало предельно ясно – если некая команда пассивно получает документы в порядке передачи информации, вне зависимости от того, как они называются, существуют ли на бумаге, в wiki, или в системе электронных запросов – это не настоящая работа с пользовательскими историями. Организации с таким процессом не получат всей полноты преимуществ итеративной разработки.

Пользовательские истории подразумевают совершенно иную модель: требования путём сотрудничества. Передачи информации сменяются частым вовлечением и дискуссиями. Когда доменная и техническая информация распределена среди разных людей, дискуссия между стейкхолдерами и командами разработки часто приводит к появлению хороших вопросов, возможностей и идей продукта. Если требования просто записаны и переданы , этого обсуждения не происходит. Даже если такие документы и называются историями, ко времени их поступления команде все важные решения уже приняты.

Эффективные дискуссии о нуждах пользователей, требованиях и решениях приобретают ключевую важность при коротких фазах разработки: здесь просто ни у кого нет времени, чтобы сесть и задокументировать всё. Конечно, и в случае более продолжительных фаз разработки такое сплошное документирование срабатывает лишь изредка, но там людям хотя бы удаётся притворяться, что они его выполняют. Если же фазы разработки измеряются неделями или днями, притворяться уже некогда. Когда один человек пишет и документирует детализированные истории, весь груз анализа, понимания и координации валится ему на плечи. Так не справиться с быстрым ритмом перемен, поэтому возникает узкое место. По сути, весь такой трубопровод двигается со скоростью одного этого человека, а он всегда слишком занят.

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

Ключевые преимущества

Дискуссии позволяют представителям бизнеса не просто объяснить, чего они хотят, но еще и убедиться в том, что члены команды разработки продукта понимают это правильно. Недопонимания между разными ролями становятся главной проблемой любой передачи информации. Объяснение истории лицом к лицу предотвращает с пробелами в знаниях.

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

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

Как сделать, чтобы это работало

Есть несколько общих причин записывать детализированные истории. Большинство этих потребностей можно удовлетворить без передач документов.

Вот наиболее распространённые поводы:

  • Когда нормативные требования или политическое окружение требует формальных подписей, записанные детали служат в качестве отчёта о том, что было утверждено.
  • Когда разным стейкхолдерам приходится согласовывать или утверждать планы, полезно иметь что-то записанное для рассылки. Географически разнесённые организации зачастую испытывают такую потребность.
  • Если истории зависят от специальных знаний людей, недоступных для участия в обсуждениях историй, тогда записанные детали – хороший способ передать свои знания.
  • Когда зависимость от третьих сторон или существующие системы требуют длительного анализа и исследования, участие в этом всей команды было бы потерей времени. Записанные детали – хороший способ отразить итоги такого исследования.

Наиболее распространённое оправдание для передачи документов - это необходимость формального утверждения рамок проекта. Не вдаваясь в то, насколько это формальное утверждение правильно или неправильно - если вам нужно его иметь - отложите подписание на время после обсуждений историйи. Подписывайте истории по мере их обсуждения. Мы работали с несколькими командами в регулируемых средах, где условия процесса требовали, чтобы спонсор бизнеса утверждал объём работы. В таких случаях бизнес спонсор подписывал спецификации с примерами, полученными в результате совместной проработки и анализа историй.

Если же финальный объём должен быть утверждён разными стейкхолдерами, организуйте эту беседу за несколько дней до реализации истории, а затем свяжитесь со стейкхолдерами. Например, команда, с которой мы работали в одной страховой компании, нуждалась в получении деталей, утверждённых всеми национальными менеджерами, поэтому они обсуждали детали за неделю до итерации. После чего и владелец продукта собирал результаты этих дискуссий, дорабатывал их до спецификаций и рассылал всем стейкхолдерам для согласования.

Эффективные команды с зависимостью от третьих сторон или же те, что полагаются на знания внешних специалистов, обычно выделяют одного-двух человек для исследования такого рода зависимостей за неделю-две перед началом реализации истории. Результаты таких исследований – прекрасная отправная точка для дискуссий в рамках анализа истории.

Некоторые команды анализируют истории в группе дважды: сначала за неделю или две перед итерацией, чтобы собрать открытые вопросы и сфокусировать предварительное раисследование, а во второй раз – непосредственно перед итерацией для коммуникации и согласования деталей. В таких случаях детали собираются тем же средством управления задачами, что и эти истории, однако команды рассматривают их как заметки для начала дискуссии, а не формальные требования для подписания.

Рекомендовані заходи

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Дмитро Незабитовський  

Дводенний курс з основ Agile, Scrum фреймворку та Kanban-методу. Курс сертифікаційний, після закінчення учасники отримують іменні сертифікати ICAgile Certified Professional (ICP): Scrum & Kanban.

Рекомендовані статті

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності