Agile: оценка и планирование проектов - [86]
Я предлагаю командам ставить большую галочку в колонке «Тесты готовы», когда они определят общие тесты для истории. Помимо этого я рекомендую не перемещать много карточек в четвертую колонку «В работе» до тех пор, пока не определены тесты. Возможно, колонка «Тесты готовы» и не нужна, однако она служит наглядным напоминанием команде, которая пытается сделать правилом определение приемочных тестов до кодирования функции.
В колонку «В работе» помещают карточки, которые разработчики взяли в работу. Обычно разработчик берет карточку из колонки «Для разработки», ставит на ней свои инициалы и перемещает в колонку «В работе». Это происходит в тот день, когда разработчик завершает предыдущую работу и определяет, что ему делать дальше. Никто не должен брать более одной или двух карточек зараз. Это помогает поддерживать стабильный поток выполняемой работы и сокращает издержки, связанные с переключением с одной задачи на другую. Для напоминания об этом, когда команда устанавливает доску задач, я настаиваю на том, чтобы ширина колонки «В работе» составляла одну карточку. Колонка «Для разработки» обычно делается шире (шире, чем показано на рис. 20.1) по той причине, что карточки нередко приклеиваются по четыре в ряд.
Колонку «На проверку» можно делать, а можно и не делать, но я считаю ее полезной, особенно в тех случаях, когда работаешь с командой, осваивающей agile-подход. В идеале каждый тест продумывается, а каждая карточка задачи составляется во время планирования итерации. В этом случае при завершении задачи программирования («Кодирование пользовательского интерфейса») ее карточку удаляют с доски задач (или перемещают в последнюю колонку «Выполнено»). В этот момент кто-то может взять связанную с этой задачей карточку тестирования («Тестирование пользовательского интерфейса»). Вместе с тем бывает, что разработчик считает задачу выполненной, но хочет, чтобы кто-нибудь взглянул на нее свежим взглядом и проверил. В таких ситуациях и когда нет связанной задачи тестирования карточку задачи помещают в колонку «На проверку».
Разработчикам разрешается изменять оценку любой карточки задачи на доске в любой момент. Например, если я начинаю работать с карточкой и понимаю, что оценка «два часа» ошибочна, то иду к доске задач, зачеркиваю «два» и заменяю, скажем, на «шесть». Если, по моему мнению, оценка еще больше, то я могу разделить эту задачу и заменить ее на две или три карточки задач, каждая со своей собственной оценкой. Последняя колонка доски задач — это просто сумма часов работы, остающихся в функции или истории. Я обычно суммирую часы для каждого ряда по утрам. Суммарные показатели используются для построения диаграммы выгорания итерации, которая является вторым инструментом отслеживания прогресса итерации.
Многие команды, начинающие переход к agile-подходу при разработке, сталкиваются с большим числом унаследованных ошибок. Дело не только в большом списке ошибок, которые необходимо устранять «при случае», но и в том, что ошибки продолжают появляться с высокой частотой. У команд, переходящих на agile-процесс, возникает вопрос, что с ними делать. Доска задач — удобный инструмент, помогающий приступить к устранению этой проблемы.
В качестве примера того, как доска задач может помочь, рассмотрим случай, когда владелец продукта включает задачу «Устранить 10 старых ошибок» в новую итерацию. Владелец продукта выбирает 10 ошибок, а разработчики составляют карточку задачи (с оценкой) для каждой из них. Эти карточки размещают в один ряд в колонке «Для разработки» доски задач. В процессе осуществления итерации разработчики занимаются этим десятком ошибок точно так же, как другими задачами. Теперь предположим, что пользователь находит новую ошибку в середине итерации. Если новой ошибке присваивается более высокий приоритет, чем у оставшихся в колонке «Для разработки», то владелец продукта может перенаправить эквивалентный объем работы на устранение новой ошибки.
Такой подход позволяет команде заниматься устранением унаследованных дефектов со скоростью, устанавливаемой владельцем продукта. Команда может выделить как 40 часов на устранение ошибок, так и все 100. Владелец продукта решает, сколько итераций следует посвятить устранению ошибок вместо разработки новых функций. Затем владелец продукта и команда совместно выбирают ошибки, подходящие по размеру для такого времени.
Диаграммы выгорания итерации
Построение диаграммы выгорания релиза — отличный способ понять, оторвался проект от плана или нет. В зависимости от длины итераций создание диаграммы выгорания может быть полезным и применительно к итерациям. Если вы работаете с однонедельными итерациями, то диаграмма не нужна. К тому моменту, когда тренд на диаграмме выгорания станет видимым, однонедельная итерация уже закончится. Однако мой опыт показывает, что диаграммы выгорания очень полезны, когда длина итерации составляет две недели и более. Диаграмма выгорания итерации показывает оставшиеся часы по дням, как видно на рис. 20.2.
Для построения диаграммы выгорания итерации просто суммируйте все часы на вашей доске задач один раз в день и наносите результат на график. Если у команды магнитно-маркерная доска задач, то я обычно строю диаграмму выгорания от руки на ее краю. Если доска задач пробковая, то я прикалываю к ней большой лист бумаги и строю диаграмму выгорания на нем.
