Что означает «готово»
Прежде чем разделять элементы бэклога на спринты для сравнения с ожиданием руководства в пять месяцев, я спросил у команды разработки, какие работы включены в их оценки. Учтены ли задачи по анализу, проектированию, написанию кода? Учтено ли время на модульное тестирование? Учтена ли автоматизация модульных тестов на чем-то вроде JUnit? Время на ревью кода другим разработчиком, его рефакторинг? Предполагалось ли при оценке, что код написан чисто и разборчиво, оформлен согласно командным правилам, удалены временные фрагменты, ненужный код, лишние комментарии? Важно, чтобы все участники команды разработки и заинтересованные лица точно понимали, какие работы учтены при оценке элемента бэклога, чтобы никто не называл и не считал требование «готовым», пока вся необходимая работа не выполнена полностью. Владелец продукта Джули поинтересовалась, почему это так важно обсудить. Я ответил, что состав пунктов этого соглашения влияет на то, насколько ценной будет разработанная функциональность. Например, если команда не выполнила модульное тестирование, мы, вероятно, должны принимать во внимание возможное обнаружение ошибок позже, а значит, выделять больше времени на тестирование приложения, последующее исправление ошибок и повторное тестирование перед внедрением. Если команда проводит рефакторинг кода в рамках реализации каждого требования, то легче исправить ошибки в будущем и приложение в целом легче поддерживать, оптимизировать и дорабатывать.
Джули не знала, что такое JUnit; тогда один из участников команды разработки пояснил ей, что это среда автоматического модульного тестирования, в которой команда может создать набор автоматизированных тестов для приложения. Всякий раз, когда добавляется новый фрагмент кода, команда сразу же узнает, ломает ли он разработанные ранее функции. Джули обрадовалась такой возможности, поскольку хотела получать проверенное и легко поддерживаемое приложение, а не что-то быстро состряпанное. Она всегда предполагала, что команда разработки должна поставлять приложение проверенным, и была рада, что может закрепить это в договоренностях. Я попросил команду переоценить элементы бэклога продукта с учетом услышанных ожиданий Джули. Проведя час за обсуждением влияния этого нового определения «готовности», команда обновила оценки. Затем Джули обсудила бэклог продукта с командой разработки. Какие требования следует взять в работу первыми? Поскольку тестировщики не были частью команды, какую работу пять разработчиков могут выполнить, чтобы передать функционал в тестирование в конце каждого спринта? Какие нефункциональные требования более приоритетны? Результатом этого обсуждения стал упорядоченный бэклог продукта.
Насколько трудно это изменить
Пришло время запланировать, что команда будет делать в течение первого и следующих спринтов. Мы подсчитали, сколько времени в среднем участники команды разработки были доступны каждый месяц, и сложили эти числа, чтобы понять, сколько времени команда могла посвятить каждому спринту. Затем, начиная с верхней части бэклога продукта, мы определили, сколько элементов может быть потенциально включено в первый спринт. Спускаясь вниз по бэклогу, мы оценивали потенциальное содержимое следующего спринта, пока весь бэклог продукта не оказался размечен на спринты. Поучилось семь спринтов.
Все откинулись на стульях. Менеджер по разработке систем Эд пообещал готовую систему через пять месяцев. Учитывая длину наших спринтов в один месяц, грубые расчеты показали, что система будет готова через семь. Никто не произнес вслух, но все знали, что дополнительные два месяца стали следствием нового определения готовности. Оставив первоначальные оценки команды разработки, мы, возможно, получили бы оценку в пять месяцев. Более того, команда, вероятно, реализовала бы в этот срок систему, однако она не соответствовала бы новому определению готовности. Но поскольку теперь Джули понимала, что означает «готово», она понимала и то, что требуется дополнительное время. Взглянув на Джули, я спросил, хочет ли она вернуться к старым оценкам. Джули была расстроена и поинтересовалась, почему мы пообещали срок в пять месяцев, заранее зная, что будем поставлять систему, не отвечающую требованиям. Я ответил, что мы не знали этого и не могли достоверно предсказать срок до сегодняшней сессии планирования.
Поскольку Эд согласовал с руководством, что проект будет завершен через пять месяцев, теперь он должен был ему объяснить, что ошибся. Я подбодрил его: это не должно стать проблемой, потому что именно Джули платила за систему и она понимала, почему оценка выросла с пяти месяцев до семи. Кроме того, насколько всем нам известно, команда может закончить и раньше пяти месяцев, и позднее. Сейчас это лишь непроверенный прогноз. На данный момент мы не можем быть уверены, но к концу первого спринта узнаем немного больше, когда появится представление о том, насколько быстро команда разработки может превращать элементы бэклога в рабочую «готовую» функциональность. Тогда мы сможем скорректировать количество спринтов, необходимое для реализации бэклога продукта. В качестве альтернативы для повышения скорости работы команды мы могли бы дополнительно привлечь людей, уже знакомых с существующей мейнфрейм-версией приложения. Эти и другие варианты Джули, команда разработки, Том и Эд смогут обсудить в конце каждого спринта.
Эд был крайне недоволен таким подходом. Раньше он всегда придерживался своих первоначальных оценок, и команда никогда его не подводила. И хотя он согласился, что теперь обладал более полной информацией о проекте, чем раньше, культура в MegaBank была такой, что, как только вы произносите «пять месяцев», именно это и запоминается. Эд повернулся к команде и сказал: «Послушайте, я знаю, что сейчас мы точнее понимаем объем работы, но это по-прежнему лишь оценка. Впереди у нас пять месяцев. Вы меня никогда не подводили, и я рассчитываю, что и в этот раз не подведете».
Последовало глубокое молчание. Позже один участник команды поделился со мной, что просьба Эда прозвучала так, будто все осталось по-прежнему, называем мы это скрамом или нет. Итеративно-инкрементальная разработка? Никаких возражений. Но по мере необходимости все равно придется халтурить и срезать углы. Эд не желал говорить своему руководству, что разработка программного обеспечения комплексна, а любая оценка – это просто оценка. Вместо этого в MegaBank будет преобладать культура веры в то, что можно предсказать будущее, и никогда не появится необходимость корректировать прогнозы. Планирование спринта выявило, что до сих пор команда жертвовала качеством, чтобы поддержать это убеждение. Джули услышала, как Эд сказал команде разработки, что дата важнее качества и что участники должны во что бы то ни стало уложиться в изначально озвученный срок, несмотря на ее просьбу предоставить качественный продукт.
Извлеченные уроки
Скрам прост в применении. Проект работы над приложением для учета денежных переводов начался с двухдневного события по планированию спринта, который я описал ранее. Тем не менее, чтобы получить все преимущества от использования, скрам требует от компании многочисленных организационных и культурных изменений. В этом проекте MegaBank мы столкнулись с культурой управления, воспринимающей предварительную оценку в качестве жесткого контракта. Эд не хотел бороться с этим заблуждением, но скрам предоставил ему, Тому, Джули и команде новые возможности для этого. Каждое событие по обзору спринта позволяет увидеть разницу между оценками и реальностью, а также между тем, что команда думала, что она может сделать, и тем, что она фактически сделала. На каждом обзоре спринта у руководства есть шанс уточнить свои ожидания.
