Майк Кон - Agile: оценка и планирование проектов

• Если пользователю отказали в доступе, на его адрес направляется электронное письмо о том, что была совершена попытка использовать его учетные данные для получения доступа.

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

Разбивайте большую историю на более мелкие, если маленькие истории имеют разные приоритеты.

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

• Программирование пользовательского интерфейса.

• Написание среднего яруса.

Избежать этого соблазна лучше всего помогает рекомендация Ханта и Томаса (Hunt and Thomas, 1999) применить к системе так называемый подход «трейсер буллет» (tracer bullet). Трейсер буллет затрагивает все слои функции. Это может означать поставку частично реализованного пользовательского интерфейса, среднего яруса и базы данных. Поставка связного подмножества всех слоев функции почти всегда лучше поставки одного полного слоя. Это дает нам следующее правило:

Не разбивайте большую историю на задачи. Вместо этого постарайтесь применить ко всей истории подход «трейсер буллет».

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

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

После всех этих рекомендаций по разбивке историй может показаться, что все пользовательские истории, с которыми предстоит работать, должны быть как можно меньше. Это не так. Для команд, работающих двухнедельными итерациями, приемлема разбивка историй на такие части, на реализацию которых требуется примерно от двух до пяти дней. (Истории можно по-прежнему оценивать в пунктах, однако к тому моменту, когда команда доберется до разбивки, она уже будет знать, сколько пунктов или идеальных дней эквивалентно сроку два — пять дней.) Истории должны быть немного меньше однонедельной итерации и могут быть, но необязательно, немного крупнее для более продолжительных итераций. Истории с такими приблизительными размерами лучше всего укладываются в короткие итерации agile-проектов.

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

Иногда очень полезно разбить на части историю, которая не укладывается в одну итерацию из-за того, что она либо слишком велика для целой итерации, либо велика для оставшегося в планируемой итерации времени. Также полезно разбивать большие истории, когда требуется более точная оценка, чем та, которую можно получить для целой истории.

Историю можно разбивать по типу данных, которые она поддерживает. Ее также можно разбивать на основе предусматриваемых операций. Распространенной практикой является подход к разбивке на основе CRUD-операций (создание, чтение, редактирование и удаление). Историю можно уменьшить с помощью выделения сквозных функций, таких как безопасность, регистрация и обработка ошибок. Также это можно сделать через игнорирование целевой производительности во время той итерации, в которой реализуется функционал истории. Целевую производительность можно выделить в самостоятельную историю и реализовать позднее. Многие истории описывают две и более потребности. Если такие потребности имеют разный приоритет, разбивайте истории по ним.

Избегайте разбивки историй на задачи разработки, которые обязательны для реализации функции. Разбивка работы на обязательные задачи настолько привычна для нас, что мы начинаем автоматически разбивать на них пользовательские истории. Избегайте увеличения размера большой истории в результате включения в нее связанных изменений, которые не требуются для реализации этой пользовательской истории.

Наконец, помните, что иногда полезно объединять пользовательские истории, особенно в случае устранения ошибок, которые бывают слишком мелкими сами по себе.

1. Есть ли в вашем текущем или другом проекте пользовательские истории, которые трудно поддаются разбивке? Как бы вы подошли к их разбивке теперь?

2. К каким проблемам, на ваш взгляд, приводит разбивка истории на задачи с последующей придачей этим задачам статуса пользовательских историй?

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