Скрам

Учитывая эти рекомендации, команда разработки смогла оценить весь бэклог продукта всего за час. При оценке команда основывалась на знаниях о существующей мейнфрейм-версии приложения, над которой работали все участники, и на понимании ранее использованных технологий J2EE и Java и планируемых к применению в веб-версии. Команда разработки, владелец продукта Джули, скрам-мастер Том и менеджер по разработке систем Эд были готовы сравнить данные оценки с ожиданиями руководства: подтверждают ли они, что проект будет выполнен через пять месяцев? Особенно заинтересованным был Эд, поскольку именно он предложил такой срок.

Что означает «готово»

Прежде чем разделять элементы бэклога на спринты для сравнения с ожиданием руководства в пять месяцев, я спросил у команды разработки, какие работы включены в их оценки. Учтены ли задачи по анализу, проектированию, написанию кода? Учтено ли время на модульное тестирование? Учтена ли автоматизация модульных тестов на чем-то вроде JUnit? Время на ревью кода другим разработчиком, его рефакторинг? Предполагалось ли при оценке, что код написан чисто и разборчиво, оформлен согласно командным правилам, удалены временные фрагменты, ненужный код, лишние комментарии? Важно, чтобы все участники команды разработки и заинтересованные лица точно понимали, какие работы учтены при оценке элемента бэклога, чтобы никто не называл и не считал требование «готовым», пока вся необходимая работа не выполнена полностью. Владелец продукта Джули поинтересовалась, почему это так важно обсудить. Я ответил, что состав пунктов этого соглашения влияет на то, насколько ценной будет разработанная функциональность. Например, если команда не выполнила модульное тестирование, мы, вероятно, должны принимать во внимание возможное обнаружение ошибок позже, а значит, выделять больше времени на тестирование приложения, последующее исправление ошибок и повторное тестирование перед внедрением. Если команда проводит рефакторинг кода в рамках реализации каждого требования, то легче исправить ошибки в будущем и приложение в целом легче поддерживать, оптимизировать и дорабатывать.

Джули не знала, что такое JUnit; тогда один из участников команды разработки пояснил ей, что это среда автоматического модульного тестирования, в которой команда может создать набор автоматизированных тестов для приложения. Всякий раз, когда добавляется новый фрагмент кода, команда сразу же узнает, ломает ли он разработанные ранее функции. Джули обрадовалась такой возможности, поскольку хотела получать проверенное и легко поддерживаемое приложение, а не что-то быстро состряпанное. Она всегда предполагала, что команда разработки должна поставлять приложение проверенным, и была рада, что может закрепить это в договоренностях. Я попросил команду переоценить элементы бэклога продукта с учетом услышанных ожиданий Джули. Проведя час за обсуждением влияния этого нового определения «готовности», команда обновила оценки. Затем Джули обсудила бэклог продукта с командой разработки. Какие требования следует взять в работу первыми? Поскольку тестировщики не были частью команды, какую работу пять разработчиков могут выполнить, чтобы передать функционал в тестирование в конце каждого спринта? Какие нефункциональные требования более приоритетны? Результатом этого обсуждения стал упорядоченный бэклог продукта.

Насколько трудно это изменить

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

Все откинулись на стульях. Менеджер по разработке систем Эд пообещал готовую систему через пять месяцев. Учитывая длину наших спринтов в один месяц, грубые расчеты показали, что система будет готова через семь. Никто не произнес вслух, но все знали, что дополнительные два месяца стали следствием нового определения готовности. Оставив первоначальные оценки команды разработки, мы, возможно, получили бы оценку в пять месяцев. Более того, команда, вероятно, реализовала бы в этот срок систему, однако она не соответствовала бы новому определению готовности. Но поскольку теперь Джули понимала, что означает «готово», она понимала и то, что требуется дополнительное время. Взглянув на Джули, я спросил, хочет ли она вернуться к старым оценкам. Джули была расстроена и поинтересовалась, почему мы пообещали срок в пять месяцев, заранее зная, что будем поставлять систему, не отвечающую требованиям. Я ответил, что мы не знали этого и не могли достоверно предсказать срок до сегодняшней сессии планирования.