Читаем Чистый Agile. Основы гибкости полностью

• Ценность (Valuable). Клиенты хотят видеть, что у истории есть определенная измеримая ценность.

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

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

Количественное измерение ценности можно проводить без формальностей. Некоторым командам может вполне подойти шкала приоритетов «высокий — средний — низкий», кому-то больше понравится десятибалльная шкала. Не имеет значения, какую шкалу использовать, главное — уметь чувствовать разницу между историями, ценность которых значительно отличается.

• Поддаваемость оценке (Estimable). Пользовательская история должна быть достаточно конкретной, чтобы разработчики могли сделать прогноз.

История «программа должна быть быстрой» не поддается оценке, потому что быстрота не имеет предела. Это сопутствующее требование, которое относится ко всем историям.

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

Не нужно, чтобы одна история огромным одеялом накрывала всю команду в течение целой итерации. Желательно, чтобы в итерации было примерно то же количество историй, что и разработчиков в команде. Если в команде 8 разработчиков, нужно подбирать от 6 до 12 историй для каждой итерации. Вы ведь не хотите завязнуть на одном этапе, верно? Это скорее совет, чем правило.

• Тестируемость (Testable). Клиенты должны четко назвать тесты, позволяющие подтвердить, что история выполнена.

Как правило, эти тесты пишут QA-специалисты. Тесты должны быть автоматизированы, с их помощью выполняется проверка историй на завершенность. Подробнее об этом вы узнаете позже. А пока что не забывайте, что каждая история должна быть достаточно конкретной, чтобы можно было подобрать необходимые тесты.

Но, может, это идет вразрез с принципом обсуждаемости? Нет, потому что когда мы пишем историю, то не обязаны знать, какие тесты нужны. Когда возникнет необходимость, тогда и будет написан тест. Хотя я еще не знаю всех нюансов истории вход, я уверен, что ее можно протестировать, потому что вход — это конкретное действие. А теперь посмотрим на историю пригодный к эксплуатации. Ее никак не протестируешь. И даже никак не оценишь. Действительно, прогнозируемость и тестируемость идут рука об руку.

Оценка историй

Существует множество способов оценки историй. Большинство из них — разновидности подхода Wideband Delphi[38].

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

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

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

Покер планирования[39] — похожий способ, но там нужны карты. Существует много популярных колод карт для такого покера. В большинстве из них применяется что-то вроде рядов Фибоначчи. В одной распространенной колоде содержатся такие карты:? 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 и ∞. Если у вас такая колода, мой совет — уберите оттуда большую часть карт.

Преимущество рядов Фибоначчи в том, что с помощью них можно провести оценку больших историй. Например, вы можете взять 1, 2, 3, 5 и 8, благодаря чему получите восьмикратный размер.

Перейти на страницу:

Все книги серии Библиотека программиста

Программист-фанатик
Программист-фанатик

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

Чед Фаулер

Программирование, программы, базы данных / Программирование / Книги по IT

Похожие книги

1С: Бухгалтерия 8 с нуля
1С: Бухгалтерия 8 с нуля

Книга содержит полное описание приемов и методов работы с программой 1С:Бухгалтерия 8. Рассматривается автоматизация всех основных участков бухгалтерии: учет наличных и безналичных денежных средств, основных средств и НМА, прихода и расхода товарно-материальных ценностей, зарплаты, производства. Описано, как вводить исходные данные, заполнять справочники и каталоги, работать с первичными документами, проводить их по учету, формировать разнообразные отчеты, выводить данные на печать, настраивать программу и использовать ее сервисные функции. Каждый урок содержит подробное описание рассматриваемой темы с детальным разбором и иллюстрированием всех этапов.Для широкого круга пользователей.

Алексей Анатольевич Гладкий

Программирование, программы, базы данных / Программное обеспечение / Бухучет и аудит / Финансы и бизнес / Книги по IT / Словари и Энциклопедии
1С: Управление торговлей 8.2
1С: Управление торговлей 8.2

Современные торговые предприятия предлагают своим клиентам широчайший ассортимент товаров, который исчисляется тысячами и десятками тысяч наименований. Причем многие позиции могут реализовываться на разных условиях: предоплата, отсрочка платежи, скидка, наценка, объем партии, и т.д. Клиенты зачастую делятся на категории – VIP-клиент, обычный клиент, постоянный клиент, мелкооптовый клиент, и т.д. Товарные позиции могут комплектоваться и разукомплектовываться, многие товары подлежат обязательной сертификации и гигиеническим исследованиям, некондиционные позиции необходимо списывать, на складах периодически должна проводиться инвентаризация, каждая компания должна иметь свою маркетинговую политику и т.д., вообщем – современное торговое предприятие представляет живой организм, находящийся в постоянном движении.Очевидно, что вся эта кипучая деятельность требует автоматизации. Для решения этой задачи существуют специальные программные средства, и в этой книге мы познакомим вам с самым популярным продуктом, предназначенным для автоматизации деятельности торгового предприятия – «1С Управление торговлей», которое реализовано на новейшей технологической платформе версии 1С 8.2.

Алексей Анатольевич Гладкий

Финансы / Программирование, программы, базы данных