Nokia Networks была одной из первых европейских компаний, которая внедрила гибкую разработку.
Бас Водде (Bas Vodde), agile-коуч, который консультировал компанию, заметил такую закономерность: команды понимали культуру Agile поверхностно и рассказывали про «свой» Scrum или XP только в некоторых метриках: сколько спринтов запланировали или какие итерации закончились раньше. Вместе с другими тренерами Бас решил, что нужно развивать Agile «вглубь, а не вширь».
Они создали два слайда, которые использовали среди agile-коучей компании:
«Вы не разрабатываете итеративно, когда...»
- итерации длиннее 2-6 недель,
- спецификации опережают программирование,
- нет тестирования,
- в конце итерации код не работоспособный,
- ждёте план и точные оценки к началу проекта,
- план итерации не отражает фактическую работу.
«Вы не соответствуете Scrum, когда...»
- среди членов команды мало сотрудничества,
- за код существует только индивидуальная ответственность,
- прогресс измеряется временем и отчетами, а не рабочим кодом,
- сборка выполняется раз в три недели.
Классический вариант The Nokia Test появился, когда Джефф Сазерленд увидел эти слайды и создал вопросник на их основе.
Данный тест — это способ проверить, использует ли команда Scrum. Например, когда команда считает, что работает по Scrum, но на самом деле перенимает лишь отдельные техники, такие, как разработка по спринтам. Из-за этого опросник также получил название "Scrum, but..."
Инструкция
Каждый в команде получает лист бумаги или распечатку с вопросами, также это может быть google-форма. Формат в данном случае не принципиален.
Во всех разделах, кроме первого, можно отмечать несколько пунктов. Суммарно по каждой оценке будет не более 10 баллов. Затем оценки суммируются в общий балл, от 0 до 100.
Чтобы оценить команду в целом, считается среднее арифметическое из оценок каждого участника.
The Nokia Test на русском
В последней редакции теста вопросы переработал Дэн Гриниг для Citrix. Он переписал их в формате пользовательских историй, которые начинаются так: «Как команда, мы...» В русском переводе это звучит не всегда благозвучно, поэтому от некоторых конструкций нам пришлось отказаться.
Ниже представлен литературный перевод, так как при точном следовании за автором команде труднее понять суть вопроса.
Оценка 1. Итерации
Перед тем, как наша команда принимается за работу над итерацией, мы знаем длительность нашего спринта, поэтому можем размерено построить свою работу для поставки ценности.
Выберите один пункт, который характеризует длительность вашего спринта:
- Переменная длительность, спринт обычно длится от 4 до 6 недель. (2)
- Переменная длительность, спринт обычно длится до 4 недель. (4)
- Спринт всегда длится 1 календарный месяц. (5)
- Спринт всегда длится 4 недели. (6)
- Спринт всегда длится 3 недели. (8)
- Спринт всегда длится 2 недели или менее. (10)
Оценка 2. Тестирование во время спринта
Как команда, мы принимаем коллективную ответственность за все тестирование, поэтому по завершении спринта продукт можно запускать сразу.
Выберите, какие из утверждений можно применить к работе вашей команды:
- Команда создает несколько unit-тестов за спринт. (1)
- Команда создает unit-тесты для каждой истории в спринте. (1)
- Команда тестирует каждую историю перед ревью спринта. (2)
- Команда тестирует каждую историю сразу после написания кода. (2)
- У команды есть автоматические тесты для каждой новой истории. (2)
- Команда запускает автоматические тесты каждые 24 часа. (2)
Оценка 3. Истории спринта
Как команда, мы начинаем работу только после того, как для каждого PBI определены критерии готовности, так что мы можем быстро генерировать бизнес-ценность.
- Требования к спринту задокументированы. (1)
- Требования выражаются в независимых, хорошо приоретизированных историях. (1)
- Истории строятся по формуле «Я, как <роль>, могу сделать <...>, чтобы получить <...>. (2)
- У историй прописаны приёмочные тесты. (2)
- У команды есть прописанные критерии состояния «Готово». (2)
- У команды есть прописанные критерии состояния «Сделано». (2)
Оценка 4. Владелец продукта
У нас есть один владелец продукта, который помогает команде понять и приоритизировать ценность продукта, так что мы создаем долгосрочные выгоды.
- Это один человек, который расставляет приоритеты. (2)
- Владелец продукта вмешивается в работу команды только на scrum-событиях. (2)
- Владелец продукта посещает все планирования, грумминги, ревью и большинство стендапов. (2)
- Владелец продукта создает бэклог продукта, истории из которого оценивает команда перед планированием спринта. (1)
- PO поддерживает актуальную дорожную карту продукта с учетом скорости команды. (1)
- PO мотивирует команду закрыть технический долг. (2)
Оценка 5. Бэклог продукта
У нашей команды есть бэклог, отсортированный по ценности, так что мы можем сфокусироваться на работе, чтобы принести наибольшую ценность бизнесу при наименьших усилиях.
- Команда обслуживает бэклоги нескольких продуктов. (1)
- Команда работает только с одним бэклогом продукта. (2)
- Владелец продукта регулярно обсуждает диаграмму сгорания историй с командой и корректирует приоритеты, основываясь на показателях скорости команды. (1)
- Команда может объяснить ROI каждой истории. (1)
- Владелец продукта определяет ценность историй бэклога, чтобы расставить их по значимости. (2)
- Владелец продукта оценивает выше создание простых прототипов, чтобы раньше проверить ценность. (2)
Оценка 6. Оценка задач
Мы стараемся уходить от статистической предвзятости и ведём прозрачную статистику, так что стейкхолдеры могут делать прогнозы выпуска и зарабатывать больше денег.
- Команда соглашается с оценкой работы до выполнения. (1)
- Владелец продукта, scrum-мастер и не-разработчики не дают оценки работы. (1)
- Представители и команда разработки выбирают оценку с помощью покерного планирования. (1)
- Только команда разработки выбирает оценку с помощью покерного планирования. (2)
- Команда использует эталонные задачи, чтобы выставить оценку. (2)
- Актуальная скорость команды практически совпадает с ожидаемой, отклоняясь менее, чем на 20%. (2)
Оценка 7. Сжигание задач в спринте
Как команда, мы знаем свой прогресс по завершению историй из бэклога, поэтому участники могут помочь с высокоприоритетными незаконченными задачами.
- Команда знает, что такое Burndown. (1)
- Команда ежедневно проверяет задачи и учитывает, сколько задач выполнено. (1)
- Задачи имеют оценки по часам или поинтам (или команда выполняет задачи примерно одного размера). (2)
- Таски, части одной истории, «сжигаются» только после их полного завершения. (2)
- История «сжигается» только после её полного завершения. (2)
- Все члены команды знают историческую скорость команды. (1)
- Команда выполняет задачи из бэклога спринта примерно с той же скоростью, что обычно, или быстрее. (1)
Оценка 8. Ретроспектива
Как команда, мы следим за тем, как выполняем работу, так что мы можем постоянно совершенствоваться.
- Команда проводит ретроспективы не реже одного раза в 2 месяца. (2)
- Команда проводит ретроспективы после каждого спринта. (2)
- В ретроспективе участвуют только команда и scrum-мастер. Команда иногда приглашает PO и других экспертов. (2)
- Команда использует стикеры или другие инструменты, чтобы вся команда принимала участие в обсуждении и могла отслеживать последующие действия. (2)
- Команда ставит в топ бэклога улучшение процесса разработки в следующем спринте. (2)
Оценка 9. Scrum-мастер
Scrum-мастер в нашей команде грамотно руководит scrum-процессом, устраняет препятствия, обеспечивает прозрачность, поэтому мы можем хорошо сфокусироваться.
- SM глубоко понимает Scrum и концепцию разработки по Agile. (2)
- SM не делает никаких задач из бэклога спринта. (1)
- SM следует тем же правилам, что установлены командой. (1)
- SM видит препятствия на ранней стадии и поддерживает команду. (2)
- SM ведет список затруднений в работе и думает, что из этого приоритетнее решить. (1)
- SM делает прогресс и успехи команды очевидным для посторонних. (2)
- SM хорошо взаимодействует со своей командой, другими командами, менеджерами, стейкхолдерами и PO. (1)
Оценка 10. Команда
Мы работаем над выпуском программного обеспечения как одна команда, поэтому можем быстрее выпустить ПО для пользователей и быстрее адаптироваться.
- Размер команды без учета SM и PO составляет от 3 до 7 человек. (2)
- Члены команды добровольно разбирают задачи. (2)
- По крайней мере два члена команды могут выполнить каждую задачу из спринта. (2)
- Команда коллективно принимает цель и бэклог спринта. (1)
- Команда коллективно борется со сложностями в спринте. (1)
- Команда сокращает технический долг каждый спринт. (2)
Когда разумно применять этот тест?
Раньше The Nokia Test применялся Сазерлендом для аттестации. Но, как и у каждой попытки измерить нефизические показатели, у этого теста есть слабые стороны. Можно назвать это спецификой его применения:
- Тест подходит для определения того, насколько команда знакома со Scrum и как глубоко.
- Тест лучше работает для молодых команд или команд со средним опытом, так как сработанные команды могут не набрать высокий балл, потому что отказались от каких-то ритуалов. При этом они остаются гибкими и не противоречат ценностям Agile.
- Часть вопросов субъективна. Например, просьба оценить знания scrum-мастера в предмете. Команда может это сделать только по ощущениям, но не по компетенции.
- Тест охватывает большое количество тем, поэтому показывает общее состояние Scrum. Анализ и выделение отдельных слабых областей, где есть преграды, проводит коуч или scrum-мастер.
- Тест направлен на команды по разработке ПО, для других случаев нужно изменять некоторые вопросы.
The Nokia Test не является полноценным инструментом, его нужно дополнять. Он отражает только ядро, тесты такого характера необходимы для общей оценки команды. Компании, которые «пытались работать по Scrum» и сочли его неподходящим, зачастую не работали по этому фреймворку на самом деле.
В любом случае, будет не лишним провести этот тест со своей командой на следующей ретроспективе.