Книга: Пользовательские истории. Искусство гибкой разработки ПО
Размер имеет значение
Размер имеет значение
В предыдущей главе мы остановились на торте Сидни и идее разделения больших тортов на маленькие тортики. Но программный продукт – несколько менее осязаемая вещь, и, в отличие от торта, его нельзя измерить в дюймах, сантиметрах, унциях или граммах.
Изначальная идея заключалась в том, что пользователь или другое лицо, которое в чем-то нуждается, может записать свою потребность на карточке, а затем мы можем это обсудить. Тот, от кого поступил запрос, не заботился о том, много ли времени потребуется на решение его проблемы, – он просто сформулировал потребность как она есть.
С точки зрения пользователя размер истории верен, если он удовлетворяет его потребность.
Когда приходит время писать код, можно оценить значительные преимущества программирования, тестирования и интеграции программного продукта по небольшим частям. Если я смогу вскоре увидеть и протестировать маленькие части, значит, смогу и судить о том, как быстро продвигается наша разработка и каков ее уровень качества. Если я могу разделить что-то большое на много маленьких частей, членам моей команды легче брать в работу и выпускать эти части одновременно. Можно взять за правило делить истории на части такого размера, чтобы на их программирование и тестирование требовалось не более нескольких дней.
С точки зрения команды разработки, размер истории верен, если программирование и тестирование занимает не более пары дней.
Но с точки зрения бизнеса может быть более разумно предъявлять пользователям и заказчикам программное обеспечение, содержащее набор нескольких функциональностей. Если вы выпускаете совершенно новый продукт, первая версия может быть довольно большой. Эту версию я ранее называл минимально жизнеспособным решением, и основной целью его разработки было получение особых результатов от выделенной группы пользователей. В идеале бизнес должен стремиться к тому, чтобы почаще и побольше выпускать таких продуктов, размер которых оптимален для пользователей или для получения результатов, отвечающих потребностям бизнеса. Но если вашим продуктом пользуется большая разношерстная группа клиентов и у вас нет инфраструктуры или бизнес-модели, поддерживающей более последовательный процесс релиза, то, конечно, ваши бизнес-релизы могут быть довольно большими.
С точки зрения бизнеса размер истории верен, если он позволяет бизнесу достичь желаемых результатов.
Я мог бы сказать, что правильного размера историй не существует, но это не так. Правильный размер – тот, который соответствует проходящему обсуждению.
Эти большие истории содержат много меньших, которые, в свою очередь, содержат много еще меньших историй. В зависимости от того, с кем вы говорите, возможно, придется перевести обсуждение на более высокий уровень.
- Размер имеет значение
- Истории похожи на камни
- Эпики – большие камни, которыми иногда кидаются в людей
- Группу историй организует тема
- Забудьте все эти термины и сконцентрируйтесь на изложении историй
- Начните с возможностей
- Найдите минимально жизнеспособное решение
- Погрузитесь в детали каждой истории во время разработки
- Продолжайте обсуждать в процессе разработки
- Оценивайте каждую часть
- Оценивайте с участием пользователей и заказчиков
- Оценивайте вместе с ключевыми партнерами
- Выпустите релиз и продолжайте оценивать
- Имеет ли размер значение?
- Размер кэша второго уровня
- 5.1. Значение налоговых соглашений в международном налоговом праве
- Размеры изображения имеют существенное значение
- Размер (толпы) имеет значение: социальная поддержка
- 7.7 ИЗМЕНЕНИЕ РАЗМЕРА ПРОЦЕССА
- 6. Маленький побеждает большого (или «размер имеет значение»)
- Размер имеет значение?!
- Кеш базы данных
- 11. Лекция: Пакет java.awt
- Глава 3 Массивы, процедуры, функции
- Унарные операции