Хенрик Книберг - Scrum и XP: заметки с передовой

После первого ежедневного Scrum'a доска задач может выглядеть примерно так:

Как видно, три задачи находятся «в процессе», то есть команда будет заниматься ими сегодня.

Иногда, в больших командах, задача зависает в состоянии «в процессе» потому, что никто не помнит, кто над ней работал. Если такое случается часто, команда обычно принимает меры. Например, отмечает на карточке задачи имя человека, который взялся над ней работать.

Через пару дней доска задач может выглядеть примерно так:

Как видно, мы закончили историю «Депозит» (т. е. она была зафиксирована в системе контроля версий, протестирована, отрефакторена и т. д.) «Автоматическое обновление» сделано частично, «Админка: вход» начат, а «Админка: управление пользователями» еще нет.

У нас возникло 3 незапланированные задачи, как видно справа внизу. Об этом полезно будет вспомнить на ретроспективе.

Вот пример настоящего sprint backlog’а ближе к концу спринта. Он, в самом деле, становится довольно беспорядочным по ходу спринта, но ничего страшного, так как это ненадолго. На каждый новый спринт мы начинаем sprint backlog с чистого листа.

Как работает burndown-диаграмма

Давайте присмотримся к burndown-диаграмме:

Вот о чем она говорит:

• В первый день спринта, 1-го августа, команда определила, что работы осталось примерно на 70 story point’а. Это как раз и есть прогнозируемая производительность на этот спринт.

• 16-го августа работы осталось примерно на 15 story point’а. Пунктирная направляющая показывает, что они на верном пути, то есть в таком темпе они успеют закончить все задачи к концу спринта.

Мы пропускаем выходные по оси X, так как в это время редко что-то делается. Раньше мы их включали, но burndown при этом выглядел странновато, так как он «выравнивался» на выходных, и это походило на повод для беспокойства.

Беглый взгляд на доску задач должен дать возможность любому человеку понять, насколько успешно продвигается итерация. ScrumMaster несёт ответственность за то, чтобы команда принимала соответствующие меры при обнаружении первых тревожных симптомов:

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

Если отслеживание изменений для вас очень важно, тогда возможно подход с доской задач вам вообще не подходит.

И все-таки, я бы предложил вам сначала оценить значение детального отслеживания изменений в спринте. После того как спринт закончен и рабочий код вместе с документацией был отослан заказчику, будет ли кто-нибудь разбираться, сколько историй было закончено на 5й день спринта? Будет ли кто-нибудь волноваться о том, какова была реальная оценка для задачи «Написать приемочный тест для истории Депозит» после того, как история была закончена?

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

Однако мы отказались от этой практики по следующим причинам:

• Оценки в человеко-часах чересчур мелкие, что приводит к появлению большого количества крохотных задач по часу или два, и, как результат, к микроменеджменту (micromanagement).

• Оказалось, что всё равно все оценивают в человеко-днях, а когда нужно получить оценку в человеко-часах, просто умножают дни на шесть. «Хм, эта задача займёт примерно день. Ага, я должен дать оценку в часах. Что ж, значит шесть часов».

• Две разных единицы измерения вводят в заблуждение. «Это оценка в человеко-днях или человеко-часах?»

Поэтому мы используем человеко-дни в качестве основной единицы при оценке времени (мы называем их story point’ы). Наше наименьшее значение — 0.5. Т. е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто.

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

Поэтому мы пытаемся оформить это место как отдельный «уголок обсуждений»

Это и в самом деле полезно. Нет лучшего способа посмотреть на систему в целом, чем стать в уголок обсуждений, посмотреть на обе стены, а потом сесть за компьютер и пощелкать последний билд системы (в случае, если вам повезло, и у вас внедрена практика «непрерывной интеграции» системы (см. стр. 62 «Как мы сочетаем Scrum с XP»)

«Стена проектирования» — это просто большая доска, на которой развешены самые важные для разработки наброски и распечатки (блок-схемы, эскизы интерфейса, модели предметной области и т. п.)

На фотографии: ежедневный Scrum в вышеупомянутом уголке.

Хммммм… Эта burndown диаграмма выглядит подозрительно красивой и гладкой, правда? Но команда настаивает на том, что это правда: o)

Когда приходит время расставить столы и рассадить команду, есть одно правило, которое сложно переоценить.

Усадите команду вместе!

Чуть поясню, что я имею в виду:

Усадите команду вместе!

Людям не нравится переезжать. По крайней мере, в тех компаниях, в которых работал я. Они не хотят собирать все свои вещички, выдергивать шнуры из компьютера, переносить весь свой скарб на другой стол, и снова втыкать все шнуры. Чем меньше расстояние, тем больше недовольство. «Да ладно, шеф, НА КОЙ ЧЕРТ меня пересаживать всего на 5 метров вправо»?

Но когда мы строим эффективную команду по Scrum’у другого выхода нет. Просто соберите команду вместе. Даже если придется им угрожать, самому переносить все их имущество, и самому вытирать застарелые следы от чашек на столах. Если для команды нет места — найдите место. Где угодно. Даже если придется посадить команду в подвале. Передвиньте столы, подкупите офис-менеджера, делайте всё, что нужно. Но как бы то ни было, соберите команду вместе.

Как только вы соберете всю команду вместе, результат появится незамедлительно. Уже после первого спринта команда согласится, что это была хорошая идея — собраться всем в одном месте (по моему опыту так и есть, хотя нет никаких гарантий, что команда не окажется слишком упрямой, чтобы это признать).