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

Три симптома, которые указывают на низкоманевренный Scrum

В большинстве случаев это означает, что ваши Scrum-команды состоят исключительно из сотрудников ИТ-отдела.

1. У ваших Scrum-команд есть “Определение Готовности”, которое требует полного «дизайна», прежде чем элемент может быть спланирован в Спринте.
2. После того, как ваши Scrum-команды отметят элемент задолженности как «Готово», он должен подождать внедрения в бизнес, прежде чем он станет действительно полезным
3. Ваши спринты занимают две недели, но фактическое время от идеи до проверки составляет более двух месяцев.

Звучит знакомо? В результате многие в «бизнесе» просто пожимают плечами, когда вы упоминаете Scrum - для них мало что изменилось. Помимо команд, которые производят больше шума и нелепо обклеивают стены квадратными кусками самоклеющейся цветной бумаги, мало что изменилось.

Три причины, почему вы должны смотреть на всю цепочку создания стоимости (гибкость бизнеса)

1. Ответственность. Возможность создавать реальные межфункциональные команды сводит к минимуму количество хэндоверов, очередей и времени ожидания. Время обучения может сократиться до длины спринта, что увеличит гибкость и уменьшит риск.
2. Качество обратной связи. Эти команды могут по-настоящему взять на себя ответственность за решение проблемы, поскольку они могут общаться и проверять фактических пользователей и клиентов. Качество и точность обратной связи возрастают, потому что расстояние минимизировано. Оптимальное время: меньше времени между каждым этапом процесса и, следовательно, меньше времени между решением и проверкой (обратная связь). Оптимальное расстояние: меньше расстояния между принимающим решение / разработчиком / потребителем; меньше передач, меньше знаний теряется при переводе. Как сокращенное время, так и уменьшенное расстояние повышают качество обратной связи и, возможно, объем знаний. Решение проблем клиента заключается в том, чтобы сочувствовать и понимать боль клиента - разница между личными отзывами и чтением о действиях пользователя в билете Jira невероятна. Дополнительными преимуществами являются высоко мотивированные команды, поскольку теперь они испытывают влияние своей работы, а не просто получают отчеты об этом.
3. Управление ценностями. Только с учетом полной цепочки создания стоимости могут быть приняты краткосрочные и долгосрочные решения об инвестициях и потенциальной прибыли. Только тогда, когда можно будет узнать полную стоимость инвестиций (затраченное время на элемент задолженности) за единицу времени, мы действительно сможем принять наилучшие возможные решения о том, куда инвестировать, где разместить наши образованные ставки.

Тематическое исследование: UX в Scrum

Многие команды, с которыми мы работали, боролись с ролью и местом UX (User Experience) в Scrum. Когда должна работать UX? Куда должен быть привлечен специалист по UX? В спринт? В качестве части усовершенствования бэклога продукта? Должен ли UX-специалист быть частью «проектной подгруппы», работающей над спринтом, чтобы убедиться, что бэклог постоянно совершенствуется (вместе с бизнес-аналитиком и общим архитектором)? Этот шаблон «отдельной команды» приводит к тому, что «подгруппа по доставке» сводится к корыстию владеющих кодом программистов и тестировщиков, хотим ли мы этого? Или UX-специалист может быть частью самоорганизующейся Scrum Team, как части команды разработчиков, тесно сотрудничающей с их коллегами по разработке, владельцем продукта (если он есть) и заинтересованными сторонами?

Как и в любой другой части процесса разработки продукта, мы должны стараться применять UX-инструменты торговли точно в срок и с достаточной детализацией в зависимости от ситуации. Некоторая исследовательская работа будет частью уточнения журнала невыполненных работ, в то время как более детальная Ux-разработка будет проводиться в тесной взаимосвязи с фактической технической разработкой, то есть проверка A/B может проводиться на этапе тестирования в спринте (или вскоре после окончания спринта), насколько это возможно.

Давайте посмотрим на 3 подхода к исследованию требований UX

1. Исследования вне Scrum Team
2. Исследования как часть усовершенствования бэклога (до планирования работ)
3. Исследования внутри спринта

1. Исследования вне Scrum Team

Распространенный сценарий - это когда исследование UX проводится вне Scrum Team или, по крайней мере, вне Development Team. Эксперты UX взаимодействуют с (потенциальными) клиентами, чтобы выяснить, почему они должны использовать продукт. Какую «работу» призван делать продукт? Эти встречи часто раскрывают интересную информацию о мире пользователя, повторяющиеся паттерны, фильтры, предположения и предубеждения. Этот тип исследования делается путем общения с клиентами или, что еще лучше - наблюдения за клиентами, чтобы создать сочувствие и действительно участвовать в их точке зрения.

Отделяя исследование UX от реализации, большая часть этой «теплой», эмпирической информации теряется при переводе во время передачи. Сжимая несколько дней взаимодействия и наблюдения в усовершенствовании бэклога или фиксируя его в письменной документации, эта потеря неизбежна. Хуже того, когда эта информация хранится в бэклоге в течение более длительного периода времени, пока она не будет обработана, данные устаревают и, возможно, перестают быть наиболее точным описанием потребностей клиента. Благодаря этим переключениям и более длительному промежутку времени между исследованием и внедрением, этот подход имеет очень низкую способность адаптироваться или получать прибыль от появляющихся идей.

Пересмотр спринта использует UX в качестве заинтересованной стороны для предоставления обратной связи команде Scrum о том, как они интерпретируют свои выводы и анализ потребностей клиентов. Основываясь на показанном варианте продукта, специалист по UX может спроектировать и провести дальнейшие исследования, которые возвращаются в журнал бэклога продукта, по крайней мере, на один спринт позже. Расстояние между начальным исследованием и (UX) обратной связью составляет около 3–4 спринтов как минимум, следовательно, точность и качество являются низкими. Основное внимание уделяется тому, насколько текущий вариант продукта отличается от того, что пользователь действительно хочет или в чем нуждается.

2. Исследования как часть усовершенствования бэклога

Большая часть потерь хэндоверов может быть уменьшена, если исследование выполнено членами Scrum Team. Чем меньше переключений, тем ближе к реальному развитию как по времени, так и по расстоянию связи. Тем не менее, разделение разработки и исследований приводит к небольшим перераспределениям ресурсов и времени ожидания, например, с дополнительными вопросами и появлением новых идей.

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

3. Исследования внутри спринта

Как говорят на голландском, «zit dicht op de bal» (держите мяч близко). Это означает, что не только фактическая команда разработчиков может быть вовлечена в исследование: потенциально исследование является частью фактической разработки, поэтому субъекты (заинтересованные стороны), участвующие в исследовании, находятся в доступности спринта, и возникающие идеи могут быть немедленно повторно проверены или внедрены, как только они появляются. Никаких переключений и почти нет времени ожидания при адаптации из появляющихся идей.

Sprint Review предназначен для реальных пользователей, работающих над инновациями и улучшениями нереализованной ценности, поскольку уже доказано (частично), что предоставленные функции соответствуют потребностям клиентов и скорректированы в процессе разработки. Расстояние между исследованиями и отзывами пользователей составляет от одного дня до нескольких спринтов, в основном - в течение одного спринта. Точность воспроизведения высока, поскольку в Sprint были внесены изменения, которые лучше соответствуют потребностям пользователей. Основное внимание почти полностью сфокусировано на следующих шагах.

Вывод: оптимизируйте все с помощью вовлечения Scrum

Scrum не решает вашу проблему, или, как однажды объяснил Кен Швабер: «Scrum похож на вашу тещу: он очень хорошо указывает на ваши ошибки». Многие организации чувствуют, что Scrum замедлил их, потому что выявляет проблемы, которые давно скрыты. Благодаря применению мышления «Inclusive Scrum» вся система, включая UX, оптимизирована для сложной работы, а не только для разработки.

No Comments