Kon Polzovatelskie-istorii-Gibkaya-razrabotka-programmnogo-obespecheniya RuLit Me 670377

Пользовательские
истории
ГИБКАЯ РАЗРАБОТКА
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Майк Кон
Предисловие Кента Бека
Пользовательские
истории
Гибкая разработка программного
ОБЕСПЕЧЕНИЯ
User Stories Applied
For Agile Software Development
Mike Cohn
▲
▼▼
ADDISON-WESLEY
Boston • San Francisco • New York • Toronto • Montreal
London • Munich • Paris • Madrid
Cape Town • Sydney • Tokyo • Singapore • Mexico City
Пользовательские
истории
Гибкая разработка программного
ОБЕСПЕЧЕНИЯ
Майк Кон
Москва • Санкт-Петербург • Киев
2012
ББК 32.973.26-018.2.75
К64
УДК 681.3.07
Издательский дом “Вильямс”
Главный редактор С. Н. Тригуб
Зав. редакцией В. Р. Гинзбург
Перевод с английского и редакция канд. хим. наук А. Г. Гузикевича
По общим вопросам обращайтесь в Издательский дом “Вильямс” по адресу:
[email protected], http://www.williamspublishing.com
Кон, Майк.
К64
Пользовательские истории: гибкая разработка программного обеспечения. :
Пер. с англ. — М.: ООО “И.Д. Вильямс”, 2012. — 256 с.: ил. — Парад, тит. англ.
ISBN 978-5-8459-1795-9 (рус.)
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответ­
ствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то ни
было форме и какими бы то ни было средствами, будь то электронные или механические, включая фото­
копирование и запись на магнитный носитель, если на это нет письменного разрешения издательства
Addison-Wfesley Publishing Company, Inc.
Authorized translation from the English language edition published by Addison-Wesley, Copyright © 2004.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the publisher.
Russian language edition is published by Williams Publishing House according to the Agreement with R&I
Enterprises International, Copyright © 2012.
Научно-популярное издание
Майк Кон
Пользовательские истории: гибкая разработка
программного обеспечения
Литературный редактор
Верстка
Художественный редактор
Корректор
Е.Д. Давидян
М.А. Удалов
В. Г. Павлютин
Л. А. Гордиенко
Подписано в печать 04.05.2012. Формат 70x100/16.
Гарнитура limes. Печать офсетная
Усл. печ. л. 21,93. Уч.-изд. л. 15,4
Тираж 1500 экз. Заказ № 3146
Первая Академическая типография “Наука”
199034, Санкт-Петербург, 9-я линия, 12/28
ООО “И. Д. Вильямс”, 127055, г. Москва, ул. Лесная, д. 43, стр. 1
ISBN 978-5-8459-1795-9 (рус.)
ISBN 978-0-321-20568-1 (англ.)
© Издательский дом “Вильямс”, 2012
© Pearson Education, Inc., 2004
Оглавление
Введение
Часть I. Приступаем к работе
Глава 1. Общий обзор
Глава 2. Написание историй
Глава 3. Моделирование пользовательских ролей
Глава 4.
Глава 5.
Глава 6.
Глава 7.
Сбор историй
Работа с представителями пользователей
Приемочное тестирование пользовательских историй
Советы по написанию хороших историй
Часть II. Оценка и планирование
Глава 8. Оценка пользовательских историй
Глава 9. Планирование выпусков
Глава 10. Планирование итераций
Глава 11. Измерение и мониторинг производительности
Часть III. Часто обсуждаемые вопросы
Глава 12. Чем не являются истории
Глава
Глава
Глава
Глава
13. Зачем нужны пользовательские истории
14. Каталог запахов историй
15. Использование историй в методологии Scrum
16. Дополнительные вопросы
Часть IV. Пример
Глава 17. Пользовательские роли
Глава 18. Истории
Глава 19. Оценка историй
Глава 20. План выпуска
Глава 21. Приемочные тесты
Часть V. Приложения
Приложение А. Обзор экстремального программирования
Приложение Б. Ответы на контрольные вопросы
Список литературы
Предметный указатель
15
19
21
35
47
57
69
81
89
97
99
107
117
123
135
137
149
159
165
177
187
189
197
205
215
219
227
229
239
251
255
Содержание
Предисловие
Благодарности
Введение
Часть I. Приступаем к работе
Глава 1. Общий обзор
Что такое пользовательская история
Где описывать детали
“На скольких страницах я должен это написать?”
Команда заказчика
Что будет собой представлять сам процесс
Планирование выпусков и итераций
Что такое приемочные тесты
Зачем что-то менять
Резюме
Контрольные вопросы
Гпава 2. Написание историй
Независимость
Обсуждаемость
Ценность для покупателей или пользователей
Оцениваемость
Компактность
Разбиение историй
Объединение историй
Тестируемость
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Гпава 3. Моделирование пользовательских ролей
Пользовательские роли
Этапы моделирования ролей
Определение начального набора ролей методом “мозгового штурма
Организация начального набора ролей
Объединение ролей
Уточнение ролей
Две дополнительные методики
Личности
Экстремальные персонажи
Содержание
Если есть местные пользователи
Резюме
Обязанности разработчиков
Обязанности заказчика
Контрольные вопросы
Глава 4. Сбор историй
Откажитесь от выявления и фиксации требований
Сколько нужно написать историй
Методы
Интервьюирование пользователей
Открытые и контекстно-независимые вопросы
Анкетирование
Наблюдение
Собрания по написанию историй
Резюме
Обязанности разработчиков
Обязанности заказчика
Контрольные вопросы
Гпава 5. Работа с представителями пользователей
Менеджер пользователей
Менеджер разработчиков
Продавцы
Специалисты в предметной области
Маркетинговая группа
Прежние пользователи
Заказчики
Обучающий персонал и группа технической поддержки
Системные аналитики и бизнес-аналитики
Как организовать работу с представителями пользователей
Если пользователи есть, но доступ к ним ограничен
Если доступ к пользователям полностью исключен
Можете ли вы сделать все сами
Принципы формирования команды заказчика
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Глава 6. Приемочное тестирование пользовательских историй
Сначала пишутся тесты, а затем — код
Тесты определяет заказчик
Тестирование — это часть процесса разработки
Сколько нужно тестов
Инфраструктура для интеграционного тестирования
Содержание
Типы тестирования
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Глава 7. Советы по написанию хороших историй
Начинайте с целевых историй
Разрежьте пирог
Пишите законченные истории
Используйте карточки ограничений
Растяните историю до масштабов горизонта
Не беритесь за пользовательский интерфейс как можно дольше
Не все должно описываться историями
Включайте пользовательские роли в истории
Формулируйте историю для пользователя в единственном числе
Используйте действительный залог в предложениях
Истории пишет заказчик
Не нумеруйте карточки историй
Не упускайте из виду цель
Резюме
Контрольные вопросы
Часть II. Оценка и планирование
85
86
86
87
87
89
89
89
90
91
92
93
93
94
94
95
95
95
95
95
96
Глава 8. Оценка пользовательских историй
Баллы историй
Выполняйте оценку всей командой
Процесс оценки
Триангуляция
Использование баллов историй
А что если программисты работают в паре
Полезные напоминания
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
97
99
99
100
100
102
102
104
105
105
105
106
106
Глава 9. Планирование выпусков
На какую дату планировать выпуск
Что должно войти в выпуск
Назначение приоритетов историям
Смешанные приоритеты
Истории, сопряженные с рисками
Приоритеты инфраструктурных потребностей
Выбор длительности итерации
От баллов историй к ожидаемой длительности
107
107
108
108
110
110
111
112
113
Содержание
Начальная скорость
Выдвижение предположений относительно скорости разработки
Составление плана выпуска
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Гпава 10. Планирование итераций
Общая схема процесса планирования итераций
Обсуждение историй
Разбиение историй на задачи
Рекомендации
Ответственность за выполнение
Оценка и подтверждение
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Гпава 11. Измерение и мониторинг производительности
Измерение производительности
Плановая и фактическая скорость
Итерационный график объема невыполненных работ
График объема оставшихся работ для одной итерации
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Часть III. Часто обсуждаемые вопросы
▼
113
114
114
115
116
116
116
117
117
117
118
119
120
121
122
122
122
122
123
123
125
126
128
131
132
132
132
135
Ггава 12. Чем не являются истории
Пользовательские истории не подчиняются стандарту IEEE 830
Пользовательские истории — это не варианты использования
Пользовательские истории не являются сценариями
Резюме
Контрольные вопросы
137
137
140
144
146
147
Гпава 13. Зачем нужны пользовательские истории
Устное общение
Пользовательские истории понятны
Размер пользовательских историй делает их удобными
для планирования
Пользовательские истории пригодны для итеративной разработки
Истории стимулируют откладывать разработку деталей на более
поздние этапы
149
149
151
152
153
154
Содержание
Истории поддерживают спонтанную разработку
Пользовательские истории стимулируют совместное проектирование
Работа с историями способствует обмену опытом
Когда истории могут быть неэффективными
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
154
155
156
156
157
158
158
158
Глава 14. Каталог запахов историй
Заниженный размер историй
Взаимозависимые истории
Украшательство
Чрезмерное количество деталей
Преждевременное включение деталей пользовательского интерфейса
Опережение событий
Разбиение слишком большого количества историй
Заказчик испытывает проблемы с назначением приоритетов историй
Отказ заказчика от написания и ранжирования историй
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
159
159
Глава 15. Использование историй в методологии Scrum
Итеративная и инкрементная природа Scrum
Основы Scrum
Команда Scrum
Журнал запросов на выполнение работ
Собрания по планированию спринтов
Собрания по обзору результатов спринта
Ежедневные собрания Scrum
Добавление историй в Scrum
Истории и журнал запросов на выполнение работ
Использование историй на собраниях по планированию спринтов
Использование историй на собраниях по обзору результатов спринта
Истории и ежедневные Serum-собрания
Конкретный пример
Резюме
Контрольные вопросы
Гиава 16. Дополнительные вопросы
Обработка нефункциональных требований
Бумага или программное обеспечение?
Истории и пользовательский интерфейс
Хранение историй
159
160
161
161
161
162
162
163
163
164
164
164
165
165
166
166
167
168
170
170
172
172
173
173
173
173
175
175
177
177
178
181
183
Содержание
Истории для устранения ошибок
Резюме
Обязанности разработчика
Обязанности заказчика
Контрольные вопросы
Часть IV. Пример
184
185
185
186
186
187
Глава 17. Пользовательские роли
Проект
Определение заказчика
Определение начальных ролей
Объединение и сужение ролей
Моделирование ролей
Добавление личностей
189
189
189
190
191
192
194
Глава 18. Истории
Истории для Терезы
Истории для капитана Рона
Истории для новичка
Истории для покупающего в подарок
Истории для читателя отчетов
Административные истории
Подведение итогов
197
197
200
201
201
202
203
204
Глава 19. Оцеилса историй
Первая история
Расширенный поиск
Рейтинги и отзывы
Учетные записи
Завершение процесса оценивания историй
Полная сводка оценок историй
205
206
208
209
210
210
211
Глава 20. План выпуска
Оценка производительности команды
Установление приоритетов историй
Окончательный план выпуска
215
215
215
217
Глава 21. Приемочные тесты
Тестирование поиска
Тестирование покупательской корзины
Покупка книг
Учетные записи пользователей
Администрирование
Тестирование ограничений
Завершающая история
219
219
220
221
222
223
224
224
Содержание
Часть V. Приложения
227
Приложение А. Обзор экстремального программирования
Роли
Двенадцать основных приемов ХР
Частые выпуски версий
Игра в планирование
Рефакторинг
Разработка через тестирование
Парное программирование
Оптимальный рабочий ритм
Совместное владение кодом
Стандарты кодирования
Простота дизайна
Метафора системы
Непрерывная интеграция
Присутствие заказчика в команде
Ценности ХР
Принципы ХР
Резюме
229
229
230
230
231
232
232
233
233
234
234
235
235
235
236
236
237
237
Приложение Б. Ответы на контрольные вопросы
Глава 1. “Общий обзор”
Глава 2. “Написание историй”
Глава 3. “Моделирование пользовательских ролей”
Глава 4. “Сбор историй”
Глава 5. “Работа с представителями пользователей”
Глава 6. “Приемочное тестирование пользовательских историй”
Глава 7. “Советы по написанию хороших историй”
Глава 8. “Оценка пользовательских историй”
Глава 9. “Планирование выпусков”
Глава 10. “Планирование итераций”
Глава 11. “Измерение и мониторинг производительности”
Глава 12. “Чем не являются истории”
Глава 13. “Зачем нужны пользовательские истории”
Глава 14. “Каталог запахов историй”
Глава 15. “Использование историй в методологии Scrum”
1лава 16. “Дополнительные вопросы”
239
239
240
241
242
243
243
243
245
245
246
246
247
248
249
249
250
Список литературы
251
Предметный указатель
255
Предисловие
Как принять решение о том, что собой должна представлять программная система? А как
добиться того, чтобы принятое решение отражало интересы самых разных людей, непосред­
ственно или косвенно связанных с проектом? Рассмотрению этой сложнейшей проблемы
и посвящена данная книга. Основные трудности обусловлены необходимостью согласова­
ния множества различных целей и потребностей всех участников проекта. Менеджер про­
екта стремится контролировать ход выполнения работ. Программисты хотят реализовать си­
стему. Менеджер по продукту требует гибкости программного обеспечения. Тестировщикам
нужны модули, обладающие измеримыми характеристиками. Пользователи заинтересованы
в получении работоспособного и эффективного приложения. Возникновение конфлик­
та между столь разными ожиданиями от проекта, поиск единого коллективного решения,
одобренного всеми сторонами, и сохранение достигнутого баланса интересов на протя­
жении месяцев или даже лет — все вместе это представляет серьезную проблему.
Подход, предлагаемый Майком Коном в данной книге, внешне мало чем отличает­
ся от уже известных решений — спецификаций требований, вариантов использования
и сценариев. Казалось бы, что тут сложного? Вы просто записываете, что надо сделать,
а потом делаете это. Однако при любой попытке передачи решений между участниками
проекта сразу же выясняется, что проблема не так проста, как кажется. Все зависит от
того, что именно записывать и когда именно это делать.
Рассматриваемая в книге технология процесса проектирования начинается с со­
ставления пользовательских историй, содержащих следующую информацию: описание
пользовательских целей, достижение которых должна обеспечить реализуемая система,
и примерная оценка связанных с этим трудозатрат. Такая история умещается буквально
в нескольких коротких предложениях и предоставляет информацию, которая не обеспе­
чивается при других подходах. Действуя по принципу “последний момент решающий”,
команда откладывает детализацию функциональных возможностей до того времени,
когда это становится действительно необходимым для их реализации.
Такой простой перенос планирования части работ на более поздние этапы разра­
ботки приводит к двум важным последствиям. Во-первых, команде не составляет тру­
да начать реализацию наиболее “лакомых” функциональных возможностей на ранних
этапах, когда о других возможностях достаточно иметь лишь самые общие представле­
ния. Автоматизированные тесты, документирующие детали отдельных функциональных
возможностей, гарантируют сохранение работоспособности продукта и его соответствие
ожиданиям заказчика на протяжении всего цикла разработки, начиная с самых ранних
ее стадий. Во-вторых, раннее определение стоимости разработки каждой функциональ­
ной возможности заставляет устанавливать приоритеты историй уже с самого начала,
что исключает лихорадочный пересмотр проекта на завершающем этпапе, когда коман­
да лезет из кожи вон, лишь бы уложиться в срок.
Благодаря большому опыту работы Майка с пользовательскими историями книга
насыщена множеством практических рекомендаций, которые позволят вашей команде
разработчиков получить максимальную отдачу от применения пользовательских исто­
рий в своих проектах.
Кент Бек
Three Rivers Institute
Благодарности
Работая над книгой я учитывал замечания множества рецензентов. В частности, хочу
поблагодарить Марко Абиса, Дейва Астелза, Стива Баннермана, Стива Берчука, Лин
Бейн, Дэна Брауна, Лору Кон, Рона Крокера, Уорда Каннингема, Рейчел Дейвис, Ро­
берта Эллсуорта, Дорис Форд, Джона Гилмана, Свена Гортса, Дебору Хартманн, Криса
Лесли, Цзинь Кьюн Лина, Кита Рэя, Мишель Слигер, Джеффа Тейтельмана, Анко Теймана, Тронда Вингорда, Джейсона Ипа и многих других анонимных рецензентов.
Выражаю искреннюю признательность официальным рецензентам: Рону Джеффрису,
Тому Поппендику и Биллу Уэйку. Рон помогал мне оставаться честным и гибким. Том
открыл для меня многие идеи, которые я раньше не замечал. Билл не давал мне сбиться
с курса и поделился со мной своим акронимом INVEST. Советы этих прекрасных лю­
дей, сотрудничеством с которыми я горжусь, помогли значительно улучшить мою книгу.
Я также благодарен Лайзе Криспин, автору книги Testing Extreme Programming, ко­
торая вдохновила меня на написание книги своими рассказами о приятном опыте со­
трудничества с издательством Addison-Wesley. Без ее поддержки я никогда не взялся бы
за этот проект.
Большую часть того, что знаю, я обсуждал с Тодом Голдингом на протяжении по­
следних девяти лет. Чаще всего мы сходились с Томом во мнении, что оба в достаточной
степени владеем предметом, но я всегда черпал в наших беседах что-то новое для себя.
Я благодарен Тому за все, чему он научил меня за многие годы. Содержание моих бесед
с ним во многом обогатило эту книгу.
Я благодарю Алекса Виджио и всех коллег из ХР Denver, с которыми я имел воз­
можность поделиться многими идеями, вошедшими в книгу. Говорю спасибо Марку
Мошолдеру и Дж. Б. Рейнсбергеру, которые рассказали мне о том, как они используй
ют программное обеспечение вместо бумажных карточек. Я благодарен Кенни Рубину,
написавшему в соавторстве с Адель Гольдберг книгу Succeeding With Objects. Его бли­
стательное мастерство, которым наполнена эта книга, побудило меня вернуться к писа­
тельской деятельности после нескольких лет перерыва.
Сердечная благодарность Марку и Дэну Гутрич, основателям компании Fast401k, ко­
торые всей душой восприняли идеи пользовательских историй и Scrum. Наряду с ними
хочу поблагодарить также всех моих коллег в Fast401k, где мы успели далеко продви­
нуться на пути к нашей заветной цели — стать одной из лучших команд в Колорадо.
Никакими словами не передать, насколько я благодарен своей семье за то, что она
дали мне возможность работать над книгой в течение длительного времени, ни на что не
отвлекаясь. Спасибо вам, мои очаровательные дочки и принцессы Саванна и Дилейни.
Особая благодарность моей прекрасной и очаровательной жене Лоре за то многое, что
она сделала для меня, тогда как я для нее сделал так мало.
Я в большом долгу перед коллективом Addison-Wesley. Пол Петралия сделал весь
процесс подготовки книги к печати приятным от начала до конца. Микеле Винченти за­
ставлял меня не стоять на месте. Лайза Ярковски оказала мне неоценимую помощь при
работе с программой FrameMaker. Гейл Кокер придала моим иллюстрациям приличный
вид, а Ник Радхубер свел напоследок все воедино.
И наконец, не могу не поблагодарить Кента Бека за его глубокомысленные советы,
за проведенное в обществе с ним время и за включение моей книги в его серию Signature
Series.
Введение
Примерно с середины 90-х годов прошлого столетия я начал испытывать чувство вины.
Я работал на компанию, которая ежегодно покупала другие компании, и каждый раз
меня назначали руководить вновь приобретенной группой разработки программного
обеспечения. Каждая группа приносила с собой великолепно оформленные, объемные,
тщательно документированные требования. Я постоянно чувствовал себя виноватым,
потому что в моих собственных группах никогда не готовились настолько замечатель­
ные спецификации требований. И тем не менее в производстве программного обеспече­
ния мои группы всегда были более успешными, чем те, которые приобретались.
Я понимал: то, что мы делаем, работает. Но я никак не мог избавиться от мысли,
что если бы мы научились выкраивать время для подготовки развернутых, обширных
спецификаций, то смогли бы стать еще более успешными. В конце концов, именно об
этом писали во всех книгах и статьях, которые я тогда читал. Если все успешные ко­
манды разработчиков не жалели времени для написания великолепно подготовленных
документальных требований, то, казалось бы, точно так же должны поступать и мы. Но
на это нам никогда не хватало времени. Наши проекты всегда были слишком важными,
а их разработка всегда была срочной, поэтому любые задержки перед началом проекта
были просто непозволительны.
'
Из-за вечной нехватки времени для написания прилично документированных тре­
бований мы остановились на способе их установления, который предполагал простые
беседы с пользователями. Вместо того чтобы все записывать, каждый раз просматри­
вать сделанные записи и вести переговоры, постоянно прислушиваясь к неумолимо­
му тиканью часов, мы разговаривали. Мы рисовали эскизы экранов на бумаге, иногда
создавали прототипы, часто писали немного кода, а затем показывали предполагаемым
пользователям, что у нас получилось. Не реже одного раза в месяц мы собирали пред­
ставительную группу пользователей и показывали им все, что к тому времени было по­
лучено в виде работоспособного кода. Сохраняя постоянный контакт с пользователями
и демонстрируя им достигнутые результаты небольшими порциями, мы нашли способ
быть успешными, обходясь без формального документирования требований.
И все же я испытывал вину за то, что мы поступаем не так, как должны были бы.
В 1999 году вышла небольшая книга Кента Бека под названием Extreme Programming
Explained: Embrace Change, которая перевернула мои взгляды. Хватило всего одной
ночи, чтобы мое чувство вины улетучилось. Наконец-то появился тот, кто сказал, что
беседы разработчиков с заказчиками, вместо писанины, переговоров и повторной писа­
нины, — это совершенно нормальная вещь. Кент многое разъяснил для меня и открыл
передо мной множество путей. Но что самое главное, он дал разумное обоснование того,
чему я научился на собственном опыте.
Основательная работа по сбору и документированию требований еще до начала ка­
ких бы то ни было работ во многих отношениях способна погубить проект на корню.
Одна из наиболее распространенных опасностей состоит в том, что документирование
требований становится самоцелью. Документальное оформление требований необходи­
мо применять лишь в тех случаях, когда оно способствует достижению реальной цели
поставки программного обеспечения.
Введение
Вторая опасность, которая может подстерегать каждого при работе с документиро­
ванными требованиями, связана с ограниченными возможностями передачи мыслей
средствами письма. Помню, как много лет назад мне рассказали одну историю о ребен­
ке, которого собирались купать в ванне. Отец наполнил ванну и начал помогать ребенку
войти в воду. Девочка, двух-трех лет от роду, едва окунув ногу в воду, быстро вытянула ее
обратно и попросила отца “сделать воду теплее”. Отец попробовал рукой воду и очень
удивился, поскольку она оказалась не слишком холодной, как он подумал, а даже те­
плее, чем обычно.
Задумавшись над просьбой дочери, отец пришел к выводу, что причина недопони­
мания крылась в том, что в одни и те же слова они вкладывали разный смысл. Просьба
дочери “сделать воду теплее” для отца означала “увеличить температуру воды”. Для де­
вочки же “сделать теплее” означало “сделать температуру воды ближе к привычному
ощущению тепла”.
Слова, особенно когда их видишь на письме, представляют собой слишком тонкий
носитель, чтобы его можно было использовать для передачи столь сложных требований
к программному обеспечению. Учитывая риск неправильного истолкования написанно­
го, мы должны заменить письменные формулировки частыми обсуждениями, в которых
участвуют разработчики, заказчики и пользователи. Пользовательские истории не толь­
ко позволяют записывать лишь то, о чем мы не должны забыть и что сможем оценить
и использовать при составлении планов, но и стимулируют устные обсуждения. К тому
моменту, когда вы закончите чтение части I, вы уже будете подготовлены к тому, чтобы
полностью отказаться от строгой фиксации всех без исключения требований вплоть до
мельчайших деталей. После прочтения всей книги вы будете знать все необходимое для
того, чтобы реализовать процесс, управляемый историями, в своей среде.
Книга разбита на пять частей: в частях I—ГУ содержится основной материал, а в ча­
сти V — два приложения.
• Часть I. “Приступаем к работе”. Содержит все необходимое для того, чтобы вы
могли приступить к написанию историй уже сегодня. Одна из целей написания
пользовательских историй — заставить людей разговаривать друг с другом, а не
обмениваться письменной документацией. Цель части I — стимулировать вас
к тому, чтобы вы приступили к таким обсуждениям как можно раньше. Глава 1 со­
держит обзор, из которого вы узнаете, что такое пользовательские истории и для
чего они предназначены. В следующих главах подробно рассказывается о том, как
писать пользовательские истории, как осуществлять их сбор посредством модели­
рования ролей, как писать истории в отсутствие контакта с конечными пользова­
телями и как тестировать такие истории. Завершает эту часть глава, содержащая
рекомендации по улучшению пользовательских историй.
• Часть II. “Оценка и планирование”. После того как у вас наберется достаточное
количество пользовательских историй, вам в большинстве случаев потребуется
хотя бы приблизительно оценить, сколько времени займет разработка. В этой
части объясняется, как оценить трудоемкость историй в баллах, как планировать
выпуски на периоды времени от трех до шести месяцев, как планировать предсто­
ящую итерацию с учетом большего количества деталей и, наконец, как измерить
количественные характеристики хода выполнения работ и оценить, продвигается
ли разработка проекта с должной скоростью.
• Часть III. “Часто обсуждаемые вопросы”. Эта часть начинается с описания того,
чем пользовательские истории отличаются от других возможных видов требова-
Введение
ний, таких как варианты использования, спецификации требований и сценарии
проектирования взаимодействия. В следующих главах будет рассказано об уни­
кальных преимуществах пользовательских историй, а также о томпак опреде­
лить, что что-то пошло не так, и как видоизменить процесс Зсгигп для примене­
ния пользовательских историй. В заключительной главе данной части рассматри­
вается ряд второстепенных тем, например, вопрос о том, что лучше — записывать
истории на бумажных карточках или сохранять их в электронном виде с помощью
каких-либо программ, а также вопрос о том, как обрабатывать нефункциональ­
ные требования.
• Часть IV. “Пример”. В этой части представлен расширенный пример, иллюстри­
рующий практическое применение всего изложенного материала. Если утверж­
дается, что пользовательские истории помогают разработчикам лучше понять
потребности пользователей, было вполне логично завершить данную книгу рас­
смотрением обширной истории, позволяющей проиллюстрировать все аспекты
пользовательских историй, собранные в одном примере.
• Часть V. “Приложения”. Пользовательские истории берут свое начало в экстре­
мальном программировании. Чтобы читать эту книгу, вы не обязаны быть зна­
током экстремального программирования. Тем не менее краткое введение в эту
дисциплину дано в приложении А. В приложении Б содержатся ответы на конт­
рольные вопросы, которыми завершаются главы.
Введение
Ждем ваших отзывов
Вы, читатель этой книги, и есть главный ее критик. Мы ценим ваше мнение и хотим
знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы
хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания,
которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать нам бумаж­
ное или электронное письмо либо просто посетить наш Web-сервер и оставить свои за­
мечания там. Одним словом, любым удобным для вас способом дайте нам знать, нра­
вится ли вам эта книга, а также выскажите свое мнение о том, как сделать наши книги
более интересными для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а
также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обяза­
тельно учтем его при отборе и подготовке к изданию последующих книг. Наши коорди­
наты:
E-mail:
info@williamspublishing. com
WWW
http://www.williamspublishing.com
Адреса для писем из:
России:
127055, г. Москва, ул. Лесная, д. 43, стр. 1
Украины: 03150, Киев, а/я 152
ЧАСТЬ I
Приступаем
к работе
Эта часть начинается с краткого ознакомительного тура, из которого вы узнаете, что та­
кое пользовательские истории и для чего они нужны. Далее подробно рассматривает­
ся, как писать пользовательские истории, как моделировать пользовательские роли, как
взаимодействовать с людьми, представляющими интересы пользователей в тех случаях,
когда непосредственный контакт с самими пользователями затруднен, и как писать те­
сты, позволяющие установить, успешно ли реализована история в виде программного
кода. Завершает эту часть сводка рекомендаций по написанию качественных историй.
После изучения материала этой части книги ваших знаний будет вполне достаточно
для того, чтобы приступить к написанию и тестированию собственных историй. Далее
можно будет переходить к вопросам оценки и планирования объемов работ на основе
пользовательских историй, что является предметом рассмотрения части И.
Глава 1
Общий обзор
Определение требований к программному обеспечению (ПО) — это задача коммуни­
кативного характера. Те, кто хочет получить новое программное обеспечение (для ис­
пользования или продажи), должны обмениваться информацией с теми, кто будет его
создавать. Чтобы проект был успешным, он должен создаваться на основе информации,
поступающей от самых разных людей. С одной стороны — это заказчики и пользова­
тели, иногда аналитики, специалисты в предметной области и те, кто оценивает про­
граммное обеспечение с точки зрения деловой или организационной перспективы,
а с другой — техническая команда.
Доминирование одной из сторон в процессе общения наносит вред проекту. Если
доминирует бизнес-сторона, она диктует функциональность и сроки, мало интересуясь
тем, смогут ли разработчики удовлетворить оба требования и правильно ли они понима­
ют, чего именно от них хотят. Если же доминируют разработчики, то деловой язык вы­
тесняется техническим жаргоном и разработчики теряют благоприятную возможность
глубже вникнуть в суть дела, выслушивая другую сторону.
Необходим такой способ организации совместной работы, при котором никто ни­
кому не навязывает своего мнения, а вопросы распределения ресурсов, обсуждение
которых не обходится без накала страстей и тактического противоборства сторон, ре­
шаются сообща. Проекты, в которых распределением ресурсов занимается лишь одна
сторона, обречены на неудачу. Если эта проблема взваливается на плечи разработчиков
(обычно в форме “Нас не интересует, как вы это сделаете, но проект должен быть сдан
к июню!”), то дополнительные функциональные возможности могут разрабатывать­
ся в ущерб качеству, некоторые функции могут оказаться реализованы лишь частично,
а решения, при утверждении которых следовало бы выслушать пользователей и заказчи­
ков, могут приниматься в одностороннем порядке. Если же груз ответственности за рас­
пределение ресурсов возлагается на заказчика, то работа, как правило, начинается лишь
после длительных предварительных переговоров, в ходе которых из проекта постепенно
выбрасываются те или иные функциональные возможности. А когда, наконец, завер­
шенный программный продукт поставляется заказчику, то оказывается, что он даже ме­
нее функционален, чем это предусматривалось сокращенным набором требований.
Сейчас мы уже знаем, что заранее спрогнозировать все аспекты будущего программ­
ного продукта с абсолютной точностью невозможно. По мере ознакомления пользовате­
лей с ранними версиями приложений у них могут появляться новые идеи, изменяющие
их первоначальное видение продукта. Вследствие нематериальной природы программ­
ного обеспечения оценка временных характеристик проекта для большинства разработ­
чиков затруднительна. В силу этого, а также ряда других факторов невозможно заранее
составить идеальную диаграмму PERT (Program Evaluation and Review Technique — тех­
ника оценки и анализа программ), точно отражающую все без исключения связи между
работами и событиями проекта.
Каков же выход из этого положения?
V
Часть I. Приступаем к работе
Мы принимаем решения на основании информации, которой располагаем в данный
момент, причем делаем это довольно часто. Вместо принятия единого всеобъемлющего
набора решений в самом начале проекта решения принимаются непрерывно на протя­
жении всего процесса разработки. Для этого мы должны организовать рабочий процесс,
гарантирующий своевременное и как можно более частое получение соответствующей
информации. Вот здесь на помощь и приходят пользовательские истории.
Что такое пользовательская история
Пользовательская история (user story) содержит описание функциональности, кото­
рая будет представлять ценность для пользователя или покупателя программного про­
дукта. Концепция пользовательской истории охватывает три аспекта:
• текстовое описание истории, которое используется при планировании проекта
и служит напоминанием о том, что именно предстоит сделать;
• устные обсуждения истории, конкретизирующие ее детали;
• тесты, которые отражают и документируют детали истории и могут применяться
для подтверждения того факта, что ее разработка завершена.
С учетом того, что пользовательские истории обычно пишутся от руки на бумажных
карточках, Рон Джеффрис предложил для указанной триады аспектов превосходную ал­
литерацию ЗС: Card (карточка), Conversation (обсуждение), Confirmation (подтверждение)
[35]. Будучи наиболее наглядным воплощением пользовательской истории, карточка
отнюдь не является самым важным ее компонентом. Как сказала Рейчел Дейвис [25],
карточки лишь “представляют требования заказчика, но не документируют их”. Суть
концепции можно сформулировать так: бумажная карточка содержит лишь краткое
описание пользовательской истории, тогда как детали самой истории выясняются в ходе
обсуждения и фиксируются в подтверждении.
В качестве примера рассмотрим карточку истории 1.1 для гипотетического веб-сайта
BigMoneyJobs, предоставляющего пользователям услуги по публикации резюме и поиску
вакансий.
Пользователь может поместить свое резюме из вебсайте
■ Карточка истории 1.1. Исходная пользовательская история, записанная на карточке
Ради согласованности многие из используемых в книге примеров будут относиться
именно к сайту BigMoneyJobs. Вот пример других возможных историй для этого сайта.
• Пользователь может осуществить поиск вакансий.
• Компания может опубликовать вакансию.
• Пользователь может ограничить доступ к просмотру своего резюме.
Поскольку пользовательские истории отражают функциональность, представляю­
щую ценность с точки зрения потребителя, следующие две истории неприемлемы для
данной системы.
Глава 1. Общий обзор
• Программа будет написана на C++.
• Программа подключается к базе данных через пул соединений.
Первая из указанных историй не может считаться хорошей для сайта BigMoneyJobs,
поскольку его пользователям безразлично, на каком языке написано программное обе­
спечение. Но если бы речь шла о программном интерфейсе (API), то пользователь такой
системы (будучи, естественно, программистом) вполне мог бы записать в карточку, что
“программа должна быть написана на C++”.
Вторая пользовательская история неудачна потому, что в данном случае технические
детали процесса подключения к базе данных не представляют для пользователей систе­
мы никакого интереса.
Возможно, прочитав эти истории, вы воскликнете: “Постойте-ка, но ведь исполь­
зование пула соединений как раз и является одним из требований для моей системы!”
Даже если это действительно так, не волнуйтесь. Ключевой момент — пользовательские
истории должны писаться так, чтобы их ценность была ясна для заказчика. Для выраже­
ния историй наподобие этой существуют такие способы, которые не дают заказчику по­
вода сомневаться в их ценности. Примеры того, как это делается, приведены в главе 2.
Где описывать детали
Одно дело — сказать: “Пользователь может осуществить поиск вакансий”, и совер­
шенно иное — написать, а затем протестировать код, основываясь только на этой ис­
ходной информации. Где же содержатся детали? И как бьггь со следующими вопросами,
на которые неизбежно придется искать ответ?
• Какие критерии поиска должны быть доступны пользователю: область, город,
должность, ключевые слова?
• Должен ли пользователь регистрироваться на сайте?
• Могут ли сохраняться параметры поиска?
• Какая информация должна отображаться при выводе списка вакансий?
Многие из этих деталей можно выразить в виде дополнительных пользовательских
историй. Фактически всегда вместо одной крупной пользовательской истории лучше
иметь несколько отдельных историй. Например, можно попытаться дать полное описа­
ние сайта BigMoneyJobs с помощью всего лишь двух историй.
• Пользователь может осуществить поиск вакансий.
• Компания может опубликовать вакансию.
Совершенно очевидно, что проку от таких историй будет не очень много, поскольку
они сформулированы в чересчур обобщенном виде. Выбор размера историй обсуждается
в главе 2, но в первом приближении можно исходить из того, что на написание и тести­
рование кода истории силами одного-двух программистов должно уходить от половины
рабочего дня до двух недель. Обе вышеприведенные истории допускают вольную интер­
претацию в весьма широких пределах и охватывают большую часть функциональности
сайта BigMoneyJobs, поэтому над каждой из них большинству программистов наверняка
придется потрудиться достаточно долго.
V
Часть I. Приступаем к работе
Истории столь большого размера иногда называют эпическими (epic). Такие истории
могут быть разбиты на несколько меньших историй. Например, историю “Пользователь
может осуществить поиск вакансий” можно разбить на три меньшие истории следую­
щим образом.
• Пользователь может осуществить поиск вакансий по таким атрибутам, как место­
нахождение, диапазон зарплаты, должность, название компании и дата опубли­
кования вакансии.
• Пользователь может просмотреть информацию о каждой вакансии, соответствую­
щей критериям поиска.
• Пользователь может просмотреть подробную информацию о компании, опубли­
ковавшей объявление о вакансии.
В то же время в процессе такого разбиения не следует стремиться получить истории,
описывающие каждую конкретную деталь. Например, история “Пользователь может про­
смотреть информацию о каждой вакансии, соответствующей критериям поиска” весьма
разумна и реалистична. Дальнейшее ее разбиение, как показано ниже, нецелесообразно.
• Пользователь может просмотреть описание вакансии.
• Пользователь может просмотреть диапазон зарплаты для данной вакансии.
• Пользователь может просмотреть информацию о местонахождении вакансии.
Точно так же не следует детализировать содержание пользовательской истории путем
включения в нее подпунктов в стиле традиционных спецификаций требований.
4.6. Пользователь может просмотреть информацию о каждой вакансии, соответ­
ствующей критериям поиска.
4.6.1. Пользователь может просмотреть описание вакансии.
4.6.2. Пользователь может просмотреть диапазон зарплаты для данной ва­
кансии.
4.6.3. Пользователь может просмотреть информацию о местонахождении ва­
кансии.
Такого рода детали лучше не записывать в виде историй, а оставлять разработчикам
и заказчику для обсуждения. Иными словами, организуйте обсуждение деталей, когда
это становится действительно необходимым. Вы ничего не нарушите, если по резуль­
татам обсуждения сделаете в карточке несколько записей в виде примечаний, как по­
казано на примере карточки 1.2. Однако ключевой момент здесь — само обсуждение,
а не примечания в карточках. Ни разработчики, ни заказчик не могут апеллировать к за­
писям в карточке три месяца спустя со словами: “Смотрите, ведь здесь же записано то,
о чем я сейчас говорю!” Карточка — не обязательство по контракту. Как будет показано
далее, все достигнутые договоренности документируются тестами, подтверждающими,
что история разработана корректно.
“На скольких страницах я должен это написать?”
Всякий раз, когда нам в школе задавали писать сочинение, я спрашивал учителя:
“На скольких страницах я должен это написать?” Такой вопрос очень не нравился учи­
телям, но я по-прежнему считаю его вполне законным, поскольку ответ на него давал
Глава 1. Общий обзор
Пользователи мотут просматривать информацию о каждой вакансии,
соответствующей критериям поиска.
Марко предложил отображать описание, зарплату и местонахождение
для вакансии.
■ Карточка истории 1.2. Карточка истории с примечанием
мне понять, чего от меня ожидают. Точно так же важно, чтобы вы понимали, чего от вас
ожидают пользователи проекта. Эти ожидания (expectations) лучше всего фиксировать
в виде приемочных тестов (acceptance tests).
Если вы используете бумажную карточку, можете записать ожидания пользователей
на ее оборотной стороне. Ожидания представляют собой напоминания о том, каким об­
разом должна тестироваться история, как показано на примере карточки 1.3. Если для
работы с историями применяется какая-либо программа, то, вероятнее всего, в ней так­
же будет предусмотрена возможность сохранять напоминания о приемочных тестах.
'Тестировать с пустым описанием вакансии.
'Тестировать с достаточно полным описанием вакансии.
"Тестировать без информации о зарплате.
"Тестировать с использованием шестиразрядных чисел для указания
размера зарплаты.
■ Карточка истории 1.3. Оборотная сторона карточки с напоминаниями о том, какие тесты
должна пройти история
Описания тестов должны быть краткими. В любое время можно добавить, удалить
или изменить любой тест. Смысл в том, чтобы предоставить разработчикам дополни­
тельную информацию об истории, позволяющую определить тот момент, когда работа
над историей может считаться завершенной. Понимание ожиданий заказчика дает раз­
работчикам возможность фиксировать момент завершения работ, точно так же как по­
нимание требований учителя подсказывало мне, где можно с чистой совестью поставить
точку в сочинении.
Команда заказчика
Для проекта было бы идеально, если бы нашелся такой человек, который смог бы
в одиночку устанавливать приоритеты задач для разработчиков, квалифицированно
Часть I. Приступаем к работе
отвечать на все их вопросы, апробировать программное обеспечение, когда оно разра­
ботано, и писать все пользовательские истории. Почти всегда это остается неосуществи­
мой мечтой, и потому обычно создается команда заказчика (customer team). В нее входят
люди, отвечающие за то, чтобы программный продукт удовлетворял требованиям пред­
полагаемых пользователей. Это означает, что в ее состав могут включаться тестировщи­
ки, менеджер по продукту, конечные пользователи и проектировщики взаимодействия.
Что будет собой представлять сам процесс
Проект, разрабатываемый на основе историй, будет восприниматься по-другому
и иметь иную ритмичность продвижения, чем в подходах, к которым вы, возможно,
привыкли. В традиционной модели водопада (waterfall model), также называемой каскад­
ной моделью, процесс разработки программного обеспечения сводится к последователь­
ному прохождению этапов документирования всех требований, анализа требований,
проектирования решения, написания программного кода и его финального тестирова­
ния. В процессах такого типа заказчики и пользователи нередко привлекаются к уча­
стию лишь на начальном и конечном этапах, когда готовятся требования и принимается
готовый продукт, тогда как на промежуточных этапах их участие почти полностью ис­
ключается. Теперь мы знаем, что такая схема не работает.
При изучении проекта, управляемого историями (story-driven project), в первую оче­
редь бросается в глаза то, что заказчики и пользователи участвуют в нем на протяже­
нии всего процесса разработки. Ослабление этого участия по ходу проекта не только не
приветствуется, но и не допускается. Сказанное остается справедливым независимо от
того, какая методология разработки программного обеспечения применяется командой:
экстремальное программирование (Extreme Programming; приложение А), agile-версия
унифицированного процесса, agile-процесс наподобие Scrum (глава 15) или специали­
зированный agile-процесс на основе пользовательских историй.
Заказчики и предполагаемые пользователи нового программного обеспечения долж­
ны быть настроены на самое активное участие в написании пользовательских историй,
особенно если речь идет об экстремальном программировании (ХР). Процесс подго­
товки к написанию историй лучше всего начинать с рассмотрения типов пользователей
(user types) разрабатываемой системы. Например, в случае создания туристического веб­
сайта такими типами могут быть Постоянный клиент, Клиент, собирающийся в отпуск
и т.п. В команду заказчика должны включаться представители как можно большего ко­
личества типов пользователей. Если по каким-то причинам этого не удается добиться,
можно прибегнуть к моделированию ролей (глава 3).
▼------------------------------------------------------------------------------------ ▼
Почему пользовательские истории должен писать заказчик
Существуют две основные причины, по которым пользовательские истории должны
писаться командой заказчика, а не командой разработчиков. Во-первых, каждая исто­
рия должна быть изложена на деловом языке, а не на техническом жаргоне, чтобы ко­
манда заказчика могла правильно назначить приоритеты историям при включении их
в итерации и выпуски. Во-вторых, поскольку участники команды заказчика представ­
ляют интересы тех, для кого создается продукт, именно они могут наиболее адекватно
описать его поведение.
Глава 1. Общий
обзор
V
Для написания первоначальных историй проекта созывается специально посвящен­
ное этому вопросу совещание, или собрание по написанию историй (story writing workshop),
но впоследствии истории пишутся на протяжении всего времени работы над проектом.
Собрание проводится в формате “мозгового штурма”, участники которого стремятся
предложить как можно больше идей пользовательских историй. Вооружившись началь­
ным набором историй, разработчики оценивают размер (трудоемкость) каждой из них.
Действуя сообща, команды заказчика и разработчиков выбирают длительность ите­
рации, которая может составлять от одной до четырех недель. Будучи один раз опреде­
ленной, длительность итерации должна оставаться неизменной на протяжении всего
проекта. Результатом выполнения каждой итерации должен быть полностью работо­
способный код, реализующий некоторую ограниченную функциональность системы.
На протяжении всей итерации команда заказчика активно участвует в работе, обсуждая
с разработчиками пользовательские истории, включенные в данную итерацию. Также
она определяет тесты и совместно с разработчиками участвует в их автоматизации и вы­
полнении. Кроме того, команда заказчика контролирует непрерывность продвижения
проекта в направлении поставки готового продукта.
Как только определена длительность итерации, разработчики оценивают, какой объем
работ они смогут выполнить за одну итерацию. Мы называем это скоростью разработ­
ки (velocity). Первоначальная оценка почти всегда будет ошибочной, поскольку невоз­
можно определить истинную производительность команды, когда работы еще не нача­
ты. Однако благодаря даже такой оценке мы можем набросать черновой план выпуска
(release plan), который позволит примерно представить, какие работы будут выполнены
на каждой итерации и сколько всего итераций потребуется.
При планировании выпуска все истории сортируются так, чтобы любая отдельная их
группа представляла одну итерацию. В каждой из таких групп содержится определенное
количество историй, суммарная трудоемкость которых не превышает оценочной величи­
ны. В первую группу включаются истории с наивысшим приоритетом. После заполнения
первой группы формируется вторая (представляющая вторую итерацию), которая включает
в себя истории с более низким приоритетом. Этот процесс прекращается лишь тогда, когда
дальнейшее увеличение количества групп историй будет приводить к превышению сроков
выполнения проекта или когда имеющихся групп окажется достаточно для представле­
ния очередного выпуска продукта. (Более подробно об этом говорится в главах 9 и 10.)
Перед началом каждой итерации команда заказчика может вносить в план оператив­
ные коррективы. В процессе выполнения итераций выясняется фактическая производи­
тельность команды разработчиков, что позволит далее опираться на уточненные оценки,
а не на первоначально полученные. Это может потребовать перегруппировки историй
путем их удаления или добавления в соответствующие группы. Кроме того, может ока­
заться, что выполнение некоторых историй займет меньше времени, чем предполагалось
изначально, и команда разработчиков захочет, чтобы в данную итерацию были дополни­
тельно включены другие истории. Возможно и прямо противоположное, когда некоторые
истории окажутся более трудоемкими, чем предполагалось, и тогда возникнет необходи­
мость перенести их на более поздние итерации или вообще исключить из выпуска.
Планирование выпусков и итераций
Выпуск состоит из одной или нескольких итераций. Планирование выпуска заклю­
чается в нахождении оптимального баланса между запланированным временным гра-
¥
Часть I. Приступаем
к работе
фиком выполнения работ и требуемым набором обеспечиваемой функциональности.
Планирование итераций заключается в выборе историй, подлежащих включению в ту
или иную итерацию. В планировании выпуска и итераций принимают участие и коман­
да заказчика, и разработчики.
Команда заказчика начинает планирование выпуска с назначения приоритетов исто­
риям. При определении приоритетов учитываются следующие факторы.
• Степень заинтересованности широкого круга пользователей или заказчиков в ре­
ализуемых данной историей функциональных возможностях.
• Степень заинтересованности ограниченного круга наиболее важных пользователей
или заказчиков в реализуемых данной историей функциональных возможностях.
• Сродство (cohesiveness) данной истории с другими историями. Например, вполне
вероятно, что сама по себе история “Уменьшить масштаб” не является высоко­
приоритетной, но может считаться таковой в случае, если она дополняет собой
историю “Увеличить масштаб”, имеющую высокий приоритет.
У разработчиков может быть свое мнение относительно приоритета многих историй.
Например, они могут предложить изменить приоритет истории, исходя из связанных
с ней технических рисков или на основании того, что она дополняет другую историю.
Команда заказчика выслушивает это мнение, а затем присваивает историям приорите­
ты, обеспечивающие достижение максимальной ценности продукта для организации.
Расстановка приоритетов историй невозможна без учета их оценочной стоимости,
т.е. трудозатрат. Приоритетным местом проведения летнего отпуска в прошлом году для
меня было Таити, но только до тех пор, пока я не оценил соответствующие расходы.
При определении приоритетов историй должна обязательно приниматься в расчет их
стоимость, которая оценивается разработчиками. Количественно такая оценка выража­
ется в баллах историй (story points), или просто — баллах, которые служат мерой величи­
ны и сложности истории относительно других историй. Соответственно предполагает­
ся, что размер истории, получившей оценку четыре балла, в два раза превышает размер
истории, оцененной в два балла.
План выпуска составляется путем распределения историй по итерациям. Разработ­
чики заявляют о желательной для них скорости разработки, выражаемой количеством
баллов на одну итерацию. После этого заказчик включает истории в итерации, следя за
тем, чтобы суммарная оценка историй, включенных в каждую итерацию, не превышала
предполагаемой скорости разработки.
В табл. 1.1 приведен пример, в котором все истории проекта отсортированы в по­
рядке убывания приоритета. Принятая командой скорость разработки (производитель­
ность) составляет тринадцать баллов на одну итерацию. Истории распределяются по
итерациям, как показано в табл. 1.2.
Поскольку ожидаемая скорость разработки составляет тринадцать баллов, суммар­
ная оценка любой итерации не должна превышать этой величины. Поэтому для второй
и третьей итераций запланированы истории, суммарно оцененные в двенадцать баллов.
Пусть вас это не смущает — точность оценок редко бывает такой, чтобы столь незначи­
тельные различия могли иметь существенное значение. Если разработка продвигается
быстрее, чем планировалось, то разработчики могут обратиться к заказчику с просьбой,
чтобы тот дополнительно включил в данную итерацию одну-две небольшие истории.
Заметьте, что при включении историй в третью итерацию команда заказчика отдала
предпочтение истории J, а не истории I, хотя последняя имеет более высокий приори-
Глава 1. Общий обзор
тет. Это было сделано по той причине, что история I со своими пятью баллами слишком
велика, для включения в данную итерацию.
Таблица 1.1. Истории
и соответствующие оценки
Таблица 1.2. План выпуска для историй,
приведенных в табл. 1.1
История
Итерация
Истории
Оценка
Оценка
История А
3
Итерация 1
А, В, С
13
История В
5
Итерация 2
D, Е, F
12
История С
5
Итерация 3
G, H,J
12
История D
3
Итерация 4
I
5
История Е
1
История F
8
История G
5
История Н
5
История I
5
История J
2
Альтернативой включению в итерацию нескольких меньших историй вместо одной
большой может служить разбиение большой истории на меньшие. Предположим, что
историю I, оцененную в пять баллов, можно разделить на две: историю У (три балла)
и историю Z (два балла). История Y содержит наиболее важные компоненты преж­
ней истории I, и ее размер позволяет включить ее в третью итерацию, как показано
в табл. 1.3. Рекомендации относительно того, как и в каких случаях следует расчленять
истории на несколько частей, приведены в главах 2 и 7.
Таблица 1.3. Разбиение истории на части для улучшения плана выпуска
Итерация
Истории
Оценка
Итерация 1
А, В, С
13
Итерация 2
D, Е, F
12
Итерация 3
G, Н,У
13
Итерация 4
J, Z
4
Что такое приемочные тесты
Приемочное тестирование (acceptance testing) — это процесс подтверждения того, что
истории реализованы в полном соответствии с ожиданиями и потребностями команды
заказчика. В самом начале итерации разработчики приступают к написанию исходного
кода, а команда заказчика — к определению тестов. В зависимости от степени техниче­
ской подготовки членов команды заказчика, процесс может принимать разные формы,
от записи тестов на оборотной стороне карточки истории до их ввода в средство авто­
матизированного тестирования. Для решения всех сугубо технических вопросов, воз-
Часть I. Приступаем к работе
никающих при решении подобного рода задач, в состав команды заказчика включают
опытного тестировщика, обладающего соответствующими навыками.
Приступать к написанию тестов для каждой итерации следует на самых ранних ее
стадиях (или даже заблаговременно, если можно выдвинуть хоть какие-то разумные
предположения относительно того, что будет делаться на протяжении предстоящей ите­
рации). Своевременное написание тестов играет чрезвычайно важную роль, так как при
этом разработчики уже с самого начала получают больше информации об ожиданиях
команды заказчика. Предположим, например, что вы пишете историю “Включенный
в покупательскую корзину пользователя товар может быть оплачен с помощью кредит­
ной карты”. В данном случае на оборотной стороне карточки истории можно записать
следующие тесты.
• Тестировать с картами Visa, MasterCard и American Express (проходит).
• Тестировать с картами Diner’s Club (не проходит).
• Тестировать с дебетовыми картами Visa (проходит).
• Тестировать с правильным, неправильным и отсутствующим подтверждающим
кодом (указывается на обратной стороне карты).
• Тестировать с просроченными платежными картами.
• Тестировать с различными суммами покупки (в том числе с превышением лимита
карты).
Тесты фиксируют тот факт, что с помощью данной системы предполагается прини­
мать карты Visa, MasterCard и American Express и что совершение покупки по другим
картам не допускается. Раннее определение тестов позволяет команде заказчика не толь­
ко сформулировать свои ожидания для программистов, но и, возможно, напомнить им
о каких-либо моментах, о которых те могут забыть. Например, программист может упу­
стить из виду необходимость отдельного рассмотрения случая, когда срок действия кар­
ты истек. Увидев напоминание об этом в качестве теста на оборотной стороне карточки
истории перед тем, как приступить к работе, программист сэкономит время. Более под­
робно о написании приемочных тестов для историй будет говориться в главе 6.
Зачем что-то менять
Читая главу, вы, наверное, уже не раз задавали себе вопрос: к чему все это? Зачем
писать карточки историй и проводить какие-то обсуждения? Почему бы не ограничить­
ся простым определением требований (requirements) или вариантов использования (use
cases)? Пользовательские истории обладают рядом преимуществ по сравнению с други­
ми возможными подходами. Более подробно об этом говорится в главе 13, но некоторые
из причин предпочтительности историй можно назвать уже сейчас.
• Пользовательские истории подчеркивают роль обычного, устного общения между
людьми по сравнению с обменом формальной документацией.
• Пользовательские истории понятны как заказчикам, так и разработчикам.
• Пользовательские истории, благодаря их размеру, легко использовать для плани­
рования работ.
• Пользовательские истории хорошо сочетаются с итеративными методами разра­
ботки.
Глава 1. Общий обзор
• Пользовательские истории побуждают к отсрочке обсуждения деталей до тех пор,
пока вы сами до конца не осознаете, что именно требуется создать.
Поскольку пользовательские истории смещают акценты от формальной документа­
ции к устному обсуждению, важные решения не фиксируются в документах, которые
вряд ли кто-либо будет читать. Вместо этого самые главные аспекты разработки, вклю­
ченные в истории, фиксируются в автоматизированных приемочных тестах и часто про­
веряются. Кроме того, мы избавляем себя от необходимости работать с документами,
содержащими нечеткие формулировки наподобие следующей:
“В системе должны сохраняться адрес и номер рабочего телефона или но­
мер мобильного телефона”.
Что означает эта фраза? Ведь она не позволяет однозначно определить, какой имен­
но из двух приведенных ниже вариантов имеется в виду:
“... (адрес и номер рабочего телефона) или номер мобильного телефона”
или
“...адрес и (номер рабочего телефона или номер мобильного телефона)”.
Так как в пользовательских историях отсутствует технический жаргон (вы ведь не за­
были, что они пишутся командой заказчика!), их смысл понятен как разработчикам, так
и заказчику.
Каждая пользовательская история представляет отдельную часть функциональности,
обеспечивающую выполнение какой-либо одной полезной для пользователя функции.
Это делает пользовательские истории удобным инструментом планирования. Результат
перемещения историй между выпусками поддается оценке гораздо легче, чем послед­
ствия исключения или вставки предложений типа “Система должна...” в случае форма­
лизованных требований.
Итеративными называют процессы, которые развиваются через ряд последователь­
ных стадий улучшения. Сначала команда разработчиков создает первичный, черновой,
вариант системы, отдавая себе отчет в том, что он несовершенен или слаб в некоторых
(возможно, многих) отношениях. Далее система последовательно улучшается, пока не
будет получен удовлетворительный продукт. С каждой итерацией программное обе­
спечение усовершенствуется путем все более углубленной разработки функциональных
возможностей. Пользовательские истории хорошо встраиваются в итеративный про­
цесс разработки, поскольку они также допускают итерирование. Для функциональных
возможностей, которые требуются в начальном продукте, но на данном этапе особого
значения не имеют, сначала можно написать эпическую историю. Когда вы уже будете
готовы к тому, чтобы добавить историю в систему, ее можно детализировать, заменив
рядом меньших историй, с которыми легче работать.
Именно возможность применения итеративного подхода к набору историй и по­
зволяет разработчикам откладывать рассмотрение деталей на более поздние эта­
пы. Благодаря тому что в самом начале можно ограничиться эпической историейзаполнителем, появляется возможность отложить составление историй, описывающих
отдельные детали системы, до тех пор, пока не возникнет реальная необходимость
в разработке этих деталей. Откладывание разработки деталей на более поздние этапы
играет важную роль, так как позволяет не тратить время на тщательное продумывание
возможных новшеств, пока не возникнет твердая уверенность в том, что они необходимы.
Часть I. Приступаем к работе
Истории удерживают нас от соблазна притворяться, будто мы в состоянии заранее все
предвидеть и описать. Вместо этого они стимулируют использование такого процесса
разработки, при котором программное обеспечение итеративно улучшается на основе
обсуждений с участием команды заказчика и разработчиков.
Резюме
• Карточка истории содержит краткое описание функциональности, представ­
ляющей ценность с точки зрения пользователя или заказчика.
• Карточка — это лишь наглядно воспринимаемый элемент истории, в то время
как важнейшим элементом историй является их обсуждение между заказчиком
и разработчиками.
• В состав команды заказчика включаются те, кто может обеспечить контроль соот­
ветствия программного обеспечения потребностям предполагаемых пользовате­
лей. Ее участниками могут быть тестировщики, менеджер по продукту, конечные
пользователи и проектировщики взаимодействия.
• Карточки историй пишет команда заказчика, поскольку именно ее участники мо­
гут лучше всего сформулировать суть требуемых функциональных возможностей
и впоследствии именно они будут обсуждать детали совместно с разработчиками
и устанавливать приоритеты историй.
• При назначении приоритетов историям руководствуются тем, насколько полезны
эти истории для заказчика.
• Выпуски и итерации планируются путем включения историй в итерации.
• Скорость разработки — это объем работ, который разработчики могут выполнить
за одну итерацию.
• Сумма оценок историй, включенных в итерацию, не может превышать скорость
разработки, прогнозируемую разработчиками для данной итерации.
• Если история не укладывается в одну итерацию, ее можно разбить на несколько
меньших историй.
• Приемочные тесты позволяют удостовериться в том, что разработанная история
обеспечивает именно ту функциональность, которая подразумевалась командой
заказчика при написании данной истории.
• Пользовательские истории следует использовать, поскольку их важным элемен­
том является устная форма общения, они понятны как заказчику, так и разработ­
чикам, могут использоваться для планирования итераций, хорошо сочетаются
с итеративным процессом разработки и стимулируют откладывание разработки
деталей на более поздние этапы.
Контрольные вопросы
1.1. Назовите три составляющие пользовательской истории.
1.2. Кто входит в состав команды заказчика?
Глава 1. Общий обзор
1.3. Какие из приведенных ниже историй не могут считаться хорошими? Почему?
A. Пользователь может запустить систему в Windows ХР и Linux.
Б. Построение всех графиков и диаграмм будет выполняться с помощью сто­
ронней библиотеки.
B. Пользователь может отменить результаты выполнения вплоть до 50 преды­
дущих команд.
Г. Программное обеспечение будет выпущено к 30 июня.
Д. Программное обеспечение будет написано на языке Java.
Е. Пользователь может выбрать страну из раскрывающегося списка.
Ж. Для записи всех сообщений об ошибках в файл система будет использо­
вать библиотеку Log4J.
3. Каждые 15 минут пользователю будет предлагаться сохранить результаты
работы, если этого не было сделано ранее.
И. Пользователю предоставляется возможность выбрать вариант “Экспорт
bXML”.
К. Пользователю предоставляется возможность экспортировать данные
в формат XML.
1.4. Каковы преимущества устного обсуждения требований по сравнению с их опре­
делением в виде формальной документации?
1.5. Почему следует записывать тесты на оборотной стороне карточек?
Глава 2
Написание историй
В этой главе рассматривается процесс написания пользовательских историй. Приступая
к нему, мы должны сконцентрировать внимание на следующих шести атрибутах, харак­
теризующих качественно написанную историю:
• независимость (Independent);
• обсуждаемость (Negotiable);
• ценность для пользователей или заказчиков (Valuable);
• оцениваемость (Estimatable);
• компактность (Small);
• тестируемость (Testable).
Для перечисленных свойств Билл Уэйк, автор книг Extreme Programming Explored
и Refactoring Workbook, предложил использовать акроним INVEST [54].
Независимость
По мере возможностей старайтесь избегать создания зависимостей между история­
ми. Такие зависимости порождают проблемы при установлении приоритетов историй
и планировании. Например, может оказаться так, что в качестве высокоприоритетной
заказчик выберет историю, которая зависит от истории с более низким приоритетом.
Кроме того, зависимости между историями могут необоснованно усложнить их оцен­
ку. Предположим, что мы работаем над проектом веб-сайта BigMoneyJobs и необходимо
подготовить истории, описывающие, каким образом компании могут оплачивать публи­
кацию на нашем сайте объявлений об открывающихся вакансиях. Мы могли бы напи­
сать следующие истории.
1. Компания может оплатить публикацию вакансии с помощью кредитной карты Visa.
2. Компания может оплатить публикацию вакансии с помощью кредитной карты
MasterCard.
3. Компания может оплатить публикацию вакансии с помощью кредитной карты
American Express.
Предположим, разработчики решили, что для написания кода поддержки любой
карты (независимо от ее типа), выбранной в качестве первой, им потребуется три дня,
а для организации поддержки остальных двух типов карт — по одному дню на каждый
тип. В случае историй со столь сильной взаимной зависимостью, как приведенные
выше, трудно принять решение об их оценке, т.е. определить, разработку какой именно
истории следует оценить в три дня.
▼
Часть I. Приступаем к работе
В ситуациях с подобным типом зависимости можно пойти двумя путями:
• объединить две зависимые истории в одну большую, но независимую;
• найти другой способ разбиения историй.
Объединение историй, относящихся к кредитным картам различного типа, в одну
большую историю (“Компания может оплатить публикацию вакансии с помощью кре­
дитной карты”) в данном случае работает хорошо, поскольку длительность разработки
объединенной истории составляет всего пять дней. При значительно более длительных
сроках разработки объединенной истории лучше подыскать какой-нибудь другой при­
знак, по которому следует осуществлять разбиение историй. Если бы оценки продол­
жительности этих историй были большими, то был бы возможен следующий вариант их
разбиения.
1. Компания может оплатить публикацию вакансии с помощью кредитных карт одного
типа.
2. Компания может оплатить публикацию вакансии с помощью двух дополнительных
типов кредитных карт.
Если же вы не хотите объединять истории и вам не удается подыскать подходящий
способ их разбиения, в вашем распоряжении всегда имеется простой выход — проста­
вить на карточке истории две оценки: одну для случая, когда данная история разраба­
тывается до начала разработки остальных историй, и вторую, более низкую, для случая,
когда разработка истории начинается после завершения разработки другой истории.
Обсуждаемость
Уже написанные истории впоследствии можно обсуждать и вносить в них измене­
ния. Истории не являются формальными контрактными обязательствами или требова­
ниями, которые программное обеспечение должно реализовать. Карточки историй —
это краткие описания функциональности, детали которых должны уточняться в ходе
устных обсуждений между командами заказчика и разработчиков. Поскольку карточки
историй призваны лишь напоминать нам о том, что еще подлежит дальнейшему обсуж­
дению, и вовсе не обязаны содержать подробное изложение требований, их не следует
излишне перегружать деталями. Но если в ходе составления истории вам стали извест­
ны какие-то важные подробности, их можно включить в карточку истории в виде при­
мечаний, как показано на примере карточки 2.1. Вся трудность состоит в том, чтобы
научиться ограничивать себя лишь минимально необходимым уровнем детализации.
Карточка истории 2.1 является вполне подходящей, поскольку она предоставляет
достаточный объем информации для разработчика и заказчика, которые будут обсуж­
дать эту историю. Когда разработчик приступит к написанию исходного кода для этой
истории, он увидит напоминание о том, что ранее было принято решение относительно
поддержки трех основных видов платежных карт, и это заставит его поинтересоваться
у заказчика, принято ли также дополнительное решение относительно карт Discover.
Примечания на карточке истории помогают разработчику и заказчику возобновлять не­
законченные обсуждения. В идеальном случае это не должно вызывать затруднений, не­
зависимо от того, продолжают обсуждение те же самые представители команд разработ­
чика и заказчика или другие люди. Руководствуйтесь этим, когда решаете, включать или
не включать описание деталей в историю.
Глава 2. Написание
историй
Кампания может оплатить публикацию вакансии с помощью кредитной
карты.
Примечание: принимаются карты Visa, MasterCard и American Express.
Под вопросом карты discover
■ Карточка истории 2.1. Карточка истории с примечаниями относительно дополнительных
деталей
С другой стороны, рассмотрим историю, содержащую избыточное количество при­
мечаний, как показано на примере карточки истории 2.2. В этой истории содержится
слишком много детальных сведений (“Проверять дату, когда истекает срок действия
платежной карты”), а кроме того, в нее включено то, что, вероятно, можно было бы вы­
делить в отдельную историю (“Система может определить тип карты по первым двум
цифрам ее номера и сохранить номер для будущего использования”).
Компания может оплатить публикацию вакансии с помощью кредитной
карты.
Примечание: принимаются карты Visa, MasterCard и American Express.
Под вопросом карты discover При совершении покупок на сумму свыше
100$ запросить подтверждающий код с обратной стороны карты.
Система может определить тип карты по первым двум цифрам ее номера
и сохранить номер для будущего использования. Проверять дату, когда
истекает срок действия платежной карты.
■ Карточка истории 2.2. Карточка истории с избыточным количеством деталей
Работать с подобными историями очень трудно. Большинство людей, которые будут
читать эту историю, ошибочно воспримут наличие избыточных деталей как исчерпываю­
щую точность описания. Однако во многих случаях преждевременное указание деталей
просто задает больше работы. Например, если два разработчика обсуждают и оценива­
ют историю, в которой лишь сказано, что “компания может оплатить публикацию ва­
кансии с помощью кредитной карты”, то они не забудут о том, что тема их обсужде­
ния сформулирована довольно абстрактно. Для того чтобы разработчики могли считать
тему своего обсуждения полностью определенной, а свои оценки — точными, не хватает
слишком многих деталей. Но если в историю включено избыточное количество деталь­
ных описаний, как в карточке 2.2, то ее обсуждение может восприниматься как кон­
кретное и максимально исчерпывающее. Это может создать ошибочное впечатление,
Глава 2. Написание историй
Ценность для покупателей или пользователей
Существует соблазн сказать нечто вроде “Каждая история должна представлять
определенную ценность с точки зрения пользователей”. Но такое утверждение было
бы неверным. Многие проекты включают истории, не представляющие для пользовате­
лей никакого интереса. Помня о различиях между пользователями и покупателями про­
граммного обеспечения, проанализируем случай, когда команда разработчиков создает
программное обеспечение, которое будет развертываться на широкой пользовательской
базе, например на 5000 компьютеров в пределах одной компании. Покупатель продукта
хочет, чтобы на каждом компьютере использовалась одна и та же конфигурация про­
граммного обеспечения. Это может привести к истории наподобие “Вся конфигураци­
онная информация считывается из централизованного источника”. Пользователям без­
различно, где хранится конфигурационная информация, но для покупателя это может
иметь значение.
Аналогичным образом истории наподобие следующей также могли бы представлять
ценность для покупателей, намеревающихся приобрести продукт, но не для фактиче­
ских пользователей.
• На протяжении всего процесса команда разработчиков готовит документацию,
удовлетворяющую требованиям стандарта ISO 9001.
• Команда разработчиков создает программное обеспечение в соответствии с мо­
делью СММ Level 3.
Чего следует избегать, так это историй, которые имеют ценность только в глазах раз­
работчиков. Примеры подобных историй приводятся ниже.
• Все подключения к базе данных осуществляются через пул соединений.
• Обработка и протоколирование ошибок осуществляются набором общих классов.
В том виде, как они записаны, эти истории сфокусированы на вопросах технологии
и удобства для программистов. Вполне вероятно, что в этих историях содержатся не­
плохие идеи, но их следует переписать так, чтобы стали очевидными выгоды, предостав­
ляемые ими для заказчиков или пользователей. Благодаря этому заказчик сможет на­
значить разумные приоритеты историям при составлении плана разработки. В качестве
улучшенных вариантов этих историй можно использовать, например, следующие.
• Благодаря пяти клиентским лицензиям на доступ к базе данных с приложением
могут работать до пятидесяти пользователей.
• Все ошибки протоколируются, а сообщения о них направляются пользователям
унифицированным способом.
Точно так же старайтесь не включать в истории предположения, относящиеся
к пользовательскому интерфейсу и вопросам технологии. Например, из приведенных
выше переписанных вариантов истории исключены упоминания о предполагаемом ис­
пользовании пула соединений и наборе классов для обработки ошибок.
Лучший способ добиться того, чтобы каждая история представляла ценность для
заказчика или пользователей, — поручить написание историй заказчику. При этом на
первых порах заказчики часто чувствуют себя довольно неуютно — возможно, потому,
что опыт общения с разработчиками приучил их к мысли, будто все написанное ими
впоследствии может быть обращено против них. (“Видите ли, в требованиях ничего не
Часть I. Приступаем
к работе
сказано о том, что...”) Однако большинство заказчиков начинают самостоятельно пи­
сать истории, как только приходят к пониманию того, что карточки историй — это всего
лишь основание для дальнейших обсуждений, а не формальные контрактные обязатель­
ства или описание конкретной функциональности.
Оцениваемость
Важно, чтобы разработчики были в состоянии оценить (или, по крайней мере, обо­
снованно спрогнозировать) размер истории, т.е. количество времени, которое понадо­
бится для того, чтобы превратить историю в работающий код. Существуют три основ­
ные причины, по которым трудоемкость истории может не поддаваться количественной
оценке.
1. Разработчикам недостает знаний в данной предметной области.
2. Разработчикам недостает технического опыта.
3. История слишком велика по размеру.
Во-первых, разработчикам может не хватать знаний в данной предметной области.
Если история в том виде, как она написана, непонятна разработчикам, им следует обсу­
дить ее с заказчиком, который ее написал. Опять-таки, вовсе не обязательно понимать
все детали, связанные с историей, но в целом она должна быть понятна разработчикам.
Во-вторых, трудности с оценкой истории могут возникнуть из-за того, что разработ­
чики не владеют необходимой технологией. Допустим, при разработке Java-проекта вас
попросили предусмотреть в системе интерфейс CORBA. Ранее никто из членов коман­
ды этим не занимался, в связи с чем оценка трудоемкости такой задачи вызовет затруд­
нения. Выход состоит в том, чтобы поручить одному или нескольким разработчикам
выполнение кратковременного исследования, целью которого является ознакомление
с предметной областью приложения. В методологии экстремального программирования
такая исследовательская история называется спайком (spike). Полученных в процессе
выполнения спайка дополнительных сведений разработчикам должно быть достаточно
для того, чтобы суметь оценить трудоемкость предстоящей задачи. Эксперимент всегда
ограничивается фиксированными временными рамками, что позволяет присвоить ему ко­
личественную оценку. С учетом всего вышесказанного не поддающаяся оценке история
преобразуется в две: историю, описывающую проведение быстрого исследования для
сбора информации, и историю, соответствующую реальной работе.
Наконец, разработчики могут оказаться не в состоянии оценить историю, так как
она слишком велика. Таковой, например, была бы история “Соискатель может осуще­
ствить поиск вакансий” для веб-сайта BigMoneyJob. Чтобы оценить ее, разработчикам
потребуется разбить ее на несколько меньших историй.
▼------------------------------------------------------------------------------------ ▼
Отсутствие знаний о предметной области
В качестве примера проекта, потребовавшего ознакомления с предметной об­
ластью, могу привести веб-сайт, который мы разрабатывали для обеспечения долго­
срочного медицинского обслуживания хронических больных. Заказчик (высококвали­
фицированная медсестра) подготовил историю следующего содержания: “Новые поль­
зователи проходят обследование на диабет”. Разработчики не были уверены в том,
что они все поняли правильно, поскольку такая фраза может означать что угодно — от
Глава 2. Написание историй
создания простой веб-анкеты до выезда с оборудованием на дом к новому пользова­
телю с целью его физического обследования, как это было предусмотрено в программ­
ном продукте данной компании, предназначенном для обслуживания астматиков.
Разработчики переговорили с заказчиком и выяснили, что в данном случае имелась
в виду простая веб-анкета, содержащая ряд вопросов, на которые должен был ответить
пациент.
▲------------------------------------------------------------------------------------ ▲
Хотя они и слишком велики, чтобы их можно было надежно оценить, все же ино­
гда полезно использовать эпические истории наподобие “Соискатель может осуществить
поиск вакансий”, поскольку они выступают в качестве заполнителей, напоминающих
о крупных компонентах системы, которые еще предстоит обсудить. Если вы сознательно
принимаете решение о том, чтобы отложить на время рассмотрение крупных частей си­
стемы, подумайте о том, чтобы написать одну-две масштабные истории, охватывающие
эти части. Эпической истории можно присвоить высокую оценку, взяв ее “с потолка”.
Компактность
Словно в сюжете сказки о Златовласке, пытавшейся найти кроватку подходящего
размера, одни истории могут оказаться слишком большими, другие — слишком малень­
кими, а третьи — в самый раз. От размера истории зависит очень многое, поскольку
слишком большие или слишком маленькие истории сложно оценивать при планиро­
вании. С эпическими историями трудно работать, так как они часто содержат в себе
несколько историй. Например, в случае системы для турбюро история “Пользователь
может составить маршрут путешествия на время отпуска” является эпической.
Планирование маршрута представляет собой важную функциональную часть системы
турбюро, но подразумевает решение целого ряда задач. Эпические истории следует раз­
бивать на истории меньшего размера. Окончательное решение относительно того, имеет
ли история подходящий размер, зависит от команды, ее возможностей и используемых
технологий.
Разбиение историй
Обычно эпические истории можно отнести к одной из двух категорий:
• составные истории;
• сложные истории.
Эпическую историю называют составной, если она заключает в себе несколько не­
больших историй. Например, рассмотрим историю “Пользователь может поместить на
сайте свое резюме”. Для начальной стадии планирования системы эта история вполне
подойдет. Но когда разработчики приступят к обсуждению проекта с заказчиком, то вы­
яснится, что “поместить на сайте свое резюме” фактически означает следующее:
• резюме может включать данные об образовании, трудовом стаже, зарплате, пу­
бликациях, волонтерской деятельности и желаемой должности;
• пользователи могут помечать резюме как неактивные;
• пользователи могут иметь несколько резюме;
V
Часть I. Приступаем к работе
• пользователи могут изменять резюме;
• пользователи могут удалять резюме.
В зависимости от того, сколько времени займет разработка, каждый из этих пунктов
можно было бы сделать самостоятельной историей. Но если пойти по такому пути, глав­
ное — не увлечься и не превратить эпическую историю в множество слишком мелких
историй. Так, в зависимости от используемых технологий, а также численности и ква­
лификации команды, приведенные ниже истории в большинстве случаев можно считать
чрезмерно детализированными.
• Соискатель может ввести в резюме даты начала и окончания для каждого из пе­
риодов волонтерской деятельности.
• Соискатель может изменить в резюме даты начала и окончания для каждого из
периодов волонтерской деятельности.
• Соискатель может ввести в резюме сроки пребывания на каждой из предыдущих
должностей.
• Соискатель может изменить в резюме сроки пребывания на каждой из предыду­
щих должностей, указанных в резюме.
Вообще говоря, рекомендуется группировать небольшие истории, как показано
ниже.
• Пользователь может создать резюме, включающее данные об образовании, трудо­
вом стаже, зарплате, публикациях, волонтерской деятельности и желаемой долж­
ности.
• Пользователь может изменить резюме.
• Пользователь может удалить резюме.
• Пользователь может иметь несколько резюме.
• Пользователь может активизировать резюме или сделать его неактивным.
Как правило, составную историю можно разбить на ряд историй меньшего разме­
ра несколькими способами. В приведенном выше примере разбиение истории на более
мелкие было выполнено в соответствии с обычно используемыми операциями создания,
изменения и удаления элементов. Такой подход работает хорошо, если история, соот­
ветствующая созданию элемента, достаточно невелика, чтобы ее можно было оставить
в качестве неделимой истории. Другой возможный подход основывается на разбиении
историй в соответствии с используемыми типами данных. Для этого следует представить
себе, что каждый элемент резюме добавляется и изменяется по отдельности. Такой спо­
соб рассуждений приводит к совершенно иной схеме разбиения.
• Пользователь может добавить или изменить данные об образовании.
• Пользователь может добавить или изменить данные о трудовом стаже.
• Пользователь может добавить или изменить данные о заработной плате.
• Пользователь может добавить или изменить данные о публикациях.
• Пользователь может добавить или изменить данные о волонтерской деятельности.
• Пользователь может добавить или изменить название желаемой должности и т.д.
Глава 2. Написание историй
Сложными, в отличие от составных, называют истории, большой размер которых об­
условлен самой их сутью и которые нелегко расчленить на ряд составляющих историй.
Если история является сложной в силу каких-либо связанных с ней неопределенных об­
стоятельств, попытайтесь разбить ее на две истории: исследовательскую и относящую­
ся непосредственно к разработке новой функциональности. Например, предположим,
что разработчикам передали историю “Компания может оплатить публикацию вакансии
с помощью кредитной карты”, но никто из разработчиков до этого никогда не сталки­
вался с обработкой платежных карт. Тогда они могут разбить первоначальную историю
на следующие две.
• Изучить способы работы с платежными картами в Интернете.
• Пользователь может произвести оплату с помощью кредитной карты.
В данном случае первая история потребует выполнения экспериментальной разра­
ботки (спайка) силами одного или нескольких разработчиков. Если используется такой
способ разбивки, всегда устанавливайте для исследовательской истории строго фикси­
рованные временные рамки. Даже если эту историю не удается оценить с разумной точ­
ностью, всегда есть возможность определить максимальный промежуток времени, кото­
рое должно быть отведено для соответствующего изучения.
Сложные истории часто встречаются при разработке новых или расширении извест­
ных алгоритмов. В одной биотехнологической компании группе разработчиков при­
шлось столкнуться с пользовательской историей, связанной с модернизацией стандарт­
ного статистического подхода, называемого ЕМ-алгоритмом (expectation maximization
algorithm). Он используется для нахождения оценок максимального правдоподобия па­
раметров вероятностных моделей, зависящих от скрытых переменных. Сложная история
была переписана в виде двух историй: одной — для проведения исследования и вынесе­
ния заключения относительно возможности осуществления запланированного новше­
ства и второй — для добавления соответствующей функциональности в продукт. В си­
туациях, подобных этой, трудно оценить, сколько времени уйдет на исследовательскую
историю.
▼----------------------------------------------------------------------------- ▼
Подумайте о включении спайка в другую итерацию
При малейшей возможности старайтесь поместить исследовательскую историю
в одну итерацию, а остальные истории — в одну или несколько последующих итераций.
Обычно оценить удается только исследовательскую историю. Включение остальных, не
поддающихся оценке историй в одну итерацию с исследовательской будет означать, что
степень неопределенности того, какой объем работ может быть выполнен за данную
итерацию, будет выше, чем обычно.
▲----------------------------------------------------------------------------- ▲
Ключевое преимущество разбиения историй, оценка которых затруднена, состо­
ит в том, что это позволяет заказчику установить для исследований и создания новой
функциональности отдельные приоритеты. Назначая приоритет сложной истории (“До­
бавить новые расширения в ЕМ-алгоритм”) и зная только суммарную оценку ее тру­
доемкости, заказчик будет неявно предполагать, что новая функциональность заведомо
сможет быть реализована в отведенные сроки, хотя это предположение может оказаться
ошибочным. Если же вместо этого заказчику предоставят исследовательскую историю —
спайк (“изучить возможность расширения ЕМ-алгоритма и сделать соответствующее
Часть I. Приступаем к работе
заключение”) и функциональную историю (“расширить ЕМ-алгоритм”), то он сможет
выбирать, как следует поступить — включить ли в данную итерацию исследовательскую
историю, которая не добавляет никакой новой функциональности, или, возможно,
какую-то другую историю, привносящую новую функциональность.
Объединение историй
Иногда истории оказываются слишком мелкими. Как правило, разработчики не хо­
тят записывать или оценивать такие истории, поскольку на это уйдет больше времени,
чем на внесение самих изменений в продукт. Типичными примерами историй, часто
имеющих небольшой размер, являются истории, в которых содержатся описания из­
менений в пользовательском интерфейсе и способов генерации отчетов об ошибках.
Обычной практикой команд, использующих методологию экстремального программи­
рования, является объединение совсем небольших историй в более крупные, на которые
уйдет от половины рабочего дня до нескольких рабочих дней. Объединенная история
получает имя, включается в план и обрабатывается точно так же, как и любая другая
история.
Пусть имеется проект, в котором обнаружено пять ошибок и для которого запрошены
изменения в цветовой гамме экрана поиска. Разработчики оценивают общую трудоем­
кость связанных с этим работ, и вся совокупность изменений обрабатывается как одна
история. В случае использования бумажных карточек это технически обеспечивается пу­
тем прикрепления карточек всех небольших историй к карточке-обложке степлером.
Тестируемость
Истории должны писаться так, чтобы их можно было тестировать. Подтверждением
того, что история разработана успешно, служит удачное прохождение ею тестов. Если
историю нельзя протестировать, каким образом разработчики смогут узнать, что созда­
ние исходного кода завершено?
Нетестируемые истории обычно появляются в случае нефункциональных требова­
ний, т.е. таких, которые относятся к самому программному обеспечению, а не непосред­
ственно к его функциональным возможностям. Рассмотрим, например, следующие не­
функциональные истории.
• Пользователь должен считать программное обеспечение удобным в использовании.
• Пользователь никогда не должен долго ждать появления какого-либо экрана.
В том виде, в котором они написаны, эти истории не являются тестируемыми. По
возможности следует автоматизировать все тесты, т.е. стремиться к 99% автоматиза­
ции, а не к 10%. Почти всегда можно автоматизировать больше, чем кажется на первый
взгляд. Если продукт разрабатывается инкрементно, то все изменяется очень быстро
и код, прекрасно работавший вчера, сегодня может перестать работать. Вам нужны та­
кие тесты, которые смогут обнаружить это на как можно более ранних стадиях.
Существует лишь небольшое подмножество тестов, которые не поддаются реали­
стичной автоматизации. Например, пользовательская история, в которой записано:
“Пользователь-новичок в состоянии выполнять типичные операции без специального
обучения”, может быть протестирована, но не автоматизирована. Вероятно, для тестиро­
вания этой истории потребуется привлечь специалиста по учету человеческого фактора,
Глава 2. Написание историй
чтобы тот спроектировал тест, включающий в себя наблюдение за репрезентативной
выборкой пользователей-новичков. Тест такого рода может оказаться дорогостоящим
и затратным по времени, но зато история станет тестируемой и вполне подойдет для не­
которых продуктов.
История “Пользователь никогда не должен долго ждать появления какого-либо экра­
на” не относится к тестируемым, поскольку в ней фигурирует обстоятельство “никогда”
и не определено, что означает “долго ждать”. Продемонстрировать, что нечто никогда не
случится, невозможно. Гораздо легче и рациональнее стремиться продемонстрировать,
что это “нечто” может происходить очень редко. Данная история может быть перепи­
сана в виде “В 95% случаев для отображения нового экрана потребуется не более двух
секунд”. А еще лучше — написать автоматизированный тест, с помощью которого это
можно было бы проверить.
Резюме
• В идеальном случае истории не должны зависеть друг от друга. Это не всегда по­
лучается, но в той степени, в какой это возможно, истории следует писать так,
чтобы их можно было разрабатывать в любой очередности.
• Детали истории отрабатываются в ходе обсуждения между пользователем и раз­
работчиками.
• Истории следует писать таким образом, чтобы их ценность для пользователей или
заказчиков была очевидной. Наилучший способ достижения этой цели состоит
в том, чтобы поручить написание истории заказчику.
• Истории могут снабжаться примечаниями с описанием деталей, но чрезмерное
обилие деталей мешает пониманию сути истории и может создавать ложное впе­
чатление, будто никакого обсуждения деталей между разработчиками и заказчи­
ком уже не потребуется.
• Одним из наилучших способов комментирования историй является написание
вариантов тестирования для каждой истории.
• Слишком большие, составные или сложные истории лучше разбивать на несколь­
ко небольших историй.
• Если имеется множество мелких историй, имеет смысл объединить их в одну
историю большего размера.
• Истории должны быть тестируемыми.
Обязанности разработчика
• Вы обязаны помогать заказчику в написании историй, которые не были бы под­
робными спецификациями, а отражали намерение провести дальнейшее обсужде­
ние, представляли ценность для пользователей или заказчика, а также были неза­
висимыми, тестируемыми и имели адекватный размер.
• Вы обязаны следить за тем, чтобы в историях описывались не особенности ис­
пользования той или иной технологии или части инфраструктуры, а потребность
Часть I. Приступаем к работе
в них с точки зрения ценности, которую они представляют для пользователей или
заказчика.
Обязанности заказчика
• Вы ответственны за то, чтобы написанные истории были не подробными специ­
фикациями, а служили своего рода протоколом о намерениях провести дальней­
шее обсуждение, представляли ценность для пользователей или для вас, а также
были независимыми, тестируемыми и имели подходящий размер.
Контрольные вопросы
2.1. Укажите для каждой из приведенных ниже историй, может ли она считаться хо­
рошей. Если нет, то почему?
A. Пользователь может быстро освоить систему.
Б. Пользователь может изменить адрес, указанный в резюме.
B. Пользователь может добавить, изменить и удалить несколько резюме.
Г. Система может аппроксимировать распределения квадратичных форм
в нормальных координатах методом седловой точки.
Д. Все ошибки времени выполнения заносятся в журнал унифицированным
способом.
2.2. Разбейте эпическую историю “Пользователь может создавать и изменять авто­
матизированные агенты поиска вакансий” на составляющие истории подходя­
щего размера.
Глава 3
Моделирование
пользовательских ролей
Во многих проектах истории пишутся так, как если бы существовал всего один пользо­
вательский тип, и именно он неявно подразумевается во всех историях. Такое упроще­
ние является ошибочным и создает риск того, что команда потеряет истории, которые
пригодились бы пользователям, не укладывающимся в жесткие общие рамки основно­
го пользовательского типа системы. На преимуществах предварительного определения
пользовательских ролей и личностей до написания историй делается акцент в моделях
проектирования, ориентированных на практичность конечного продукта (usage-centered
design) [21], и в моделях проектирования взаимодействий (interaction design) [23]. В этой
главе будут рассмотрены такие вопросы, как пользовательские роли, моделирование
ролей, карты пользовательских ролей, а также продемонстрировано, почему использо­
вание ролей на начальных этапах разработки приводит к улучшению пользовательских
историй и программного обеспечения.
Пользовательские роли1
Предположим, мы создаем сайт BigMoneyJobs, предназначенный для предоставления
услуг по поиску работы и подбору персонала и позволяющий публиковать резюме и объ­
явления о вакансиях. Сайт такого типа будет пользоваться популярностью у различных
пользователей. А какого пользователя мы подразумеваем, когда говорим о пользователь­
ских историях? Алекса, который имеет работу, но не прочь подыскать что-то получше?
А может быть, мы имеем в виду Лору, только что закончившую колледж и впервые стол­
кнувшуюся с проблемой поиска работы? Или Аллана, решившего устроиться на любую
работу, лишь бы это позволило ему перебраться на Мауи и каждый вечер после работы
посвящать виндсерфингу? Или же Скотта, вполне довольного своей работой, но жажду­
щего перемен? Возможно, мы имеем в виду Кристину, которая вот уже полгода времен­
но не работает, стараясь подыскать для себя хорошее местечко, но теперь готова согла­
ситься на что угодно, лишь бы это было на северо-востоке США?
А ведь мы должны подумать также о пользователях, которые работают в компаниях,
публикующих объявления о вакансиях. Кого мы при этом должны себе представлять?
Марио, работающего в отделе кадров и отвечающего за публикацию объявлений? А мо­
жет быть, Делани, которая также работает в отделе кадров, но отвечает за просмотр ре­
зюме? Или, возможно, пользователь — это Сьюзан, которая работает в кадровом агент­
стве и по роду деятельности занимается поиском не только подходящих рабочих мест,
но и подходящих специалистов?
1 Большая часть обсуждения пользовательских ролей в данной главе базируется на работе
Ларри Константайна и Люси Локвуд. Более полную информацию относительно моделирования
пользовательских ролей можно получить на их веб-сайте (www. foruse. com) или в книге [21].
1
Часть I. Приступаем к работе
Совершенно ясно, что никакая история, написанная исходя из какой-то одной точки
зрения, не в состоянии охватить все возможные варианты сочетания таких факторов, как
опыт, уровень образования и мотивация пользователей. Бухгалтер Алекс может загляды­
вать на сайт лишь раз в месяц только для того, чтобы иметь в запасе другие варианты
работы. Официант Аллан, возможно, захочет создать фильтр, чтобы получать уведомле­
ния о публикации объявлений, касающихся любых вакансий на Мауи, но он не сможет
этого сделать, пока мы не упростим выполнение подобных операций. Кристина может
ежедневно часами искать подходящую работу, расширяя свой поиск с течением времени.
Если Марио и Делани работают в крупной компании с регулярно возникающими вакан­
сиями, то на данном сайте они могут проводить ежедневно по несколько часов.
Несмотря на то что с вашим программным обеспечением могут работать пользова­
тели, имеющие различные уровни подготовки и различные цели, все-таки существует
возможность объединять пользователей по каким-либо признакам и рассматривать их
в рамках ролей. Пользовательская роль (user role) — это собрание описательных атрибу­
тов, характеризующих некоторую совокупность пользователей и предполагаемые типы
их взаимодействия с системой. Если говорить о пользователях из предыдущего примера,
то мы могли бы сгруппировать их по ролям так, как показано в табл. 3.1.
Таблица 3.1. Один из возможных вариантов состава ролей для проекта BigMoneyJobs
Роль
Пользователь
Соискатель (Job Seeker)
Скотт
Новичок (First Timer)
Лора
Жертва увольнения (Layoff Victim)
Кристина
Региональный соискатель (Geographic Searcher)
Аллан
Наблюдатель (Monitor)
Алекс
Публикатор вакансий (Job Poster)
Марио, Сьюзан
Читатель резюме (Resume Reader)
Делани, Сьюзан
Естественно, различные пользовательские роли могут в определенной степени пере­
секаться. Роли Соискатель, Новичок, Жертва увольнения, Региональный соискатель
и Наблюдатель будут использовать предоставляемые сайтом возможности поиска ва­
кансий. Они могут делать это разными способами и с разной частотой, но многое в ха­
рактере использования ими системы будет совпадать. Точно так же, вероятно, будут
пересекаться и роли Публикатор вакансий и Читатель резюме, поскольку обе пресле­
дуют одну и ту же цель — поиск подходящих кандидатов на текущую вакансию.
Представленный в табл. 3.1 способ группирования пользователей сайта BigMoneyJob
по ролям не является единственным. Например, в случае необходимости можно было
бы ввести такие роли, как Совместитель (Part-Timer), Штатный сотрудник (Full-Timer)
и Контрактник (Contractor). Далее будет показано, как составить список ролей и улуч­
шить его, чтобы сделать его более полезным.
Этапы моделирования ролей
Для идентификации и выбора полезного набора пользовательских ролей будем ис­
пользовать следующие этапы:
Глава 3. Моделирование пользовательских ролей
• определение начального набора ролей методом “мозгового штурма”;
• организация начального набора;
• объединение ролей;
• уточнение ролей.
Определение начального набора ролей методом “мозгового штурма”
Чтобы определить пользовательские роли, заказчик и как можно больше разработчи­
ков собираются в одной комнате, где в их распоряжении будет большой стол или стены,
на которые можно наклеивать или прикалывать кнопками карточки историй. Будет иде­
ально, если в процессе моделирования пользовательских ролей в начале проекта при­
нимает участие вся команда, однако это необязательно. Коль скоро наряду с заказчи­
ком собралось достаточно представительное количество разработчиков, собрание может
пройти успешно.
Каждый участник “мозгового штурма” берет несколько пустых карточек, заранее
разложенных на столе в достаточном количестве. (Даже если планируется, что пользо­
вательские роли будут сохраняться в электронном виде, начинать следует с карточек.)
Затем участники записывают на карточках названия ролей и выкладывают их на стол
или прикалывают (приклеивают) к стене.
Когда карточка новой роли занимает свое место, ее автор лишь оглашает название
роли и ничего больше. Поскольку это “мозговой штурм”, никакого обсуждения карто­
чек или оценки ролей не происходит. Но при этом каждый присутствующий записывает
столько ролей, сколько он в состоянии придумать. Никто не стоит ни в какой очереди
и не ходит вокруг стола, опрашивая участников. Каждый лишь записывает в карточку
новую роль, как только она приходит ему в голову.
В процессе “мозгового штурма” все будут заняты заполнением карточек, и лишь
время от времени тишину будет нарушать голос того, кто размещает новую карточку на
столе или стене и зачитывает вслух название новой роли. Этот процесс будет продол­
жаться до тех пор, пока сам собой не замедлится, ибо придумывать новые роли станет
все труднее. Возможно, к этому времени еще не все роли будут определены, но вы буде­
те достаточно близки к этому. За исключением редких случаев, на все про все уйдет не
более пятнадцати минут.
▼-------------------------------------------------------------------------------------▼
Одна роль — один пользователь
При проведении “мозгового штурма” с целью генерации набора ролей для проекта
придерживайтесь того, чтобы определяемая роль представляла одного пользователя.
Например, в случае проекта BigMoneyJobs может появиться соблазн написать историю
наподобие “Компания может опубликовать вакансию”. Однако поскольку программ­
ное обеспечение используется не компанией в целом, а конкретными людьми, история
улучшится, если будет ссылаться на роль, представляющую физическое лицо.
▲-------------------------------------------------------------------------------------▲
Организация начального набора ролей
Как только группа закончит определять роли, их надо будет каким-то образом упо­
рядочить. Для этого карточки располагают на столе или стене таким образом, чтобы их
Часть I. Приступаем к работе
позиции отражали связи между ролями. Пересекающиеся роли располагаются так, что­
бы их карточки перекрывались. При незначительном пересечении ролей должны соот­
ветственно (незначительно) перекрываться и сами карточки. В случае полного пересече­
ния ролей должны полностью перекрываться и их карточки. Соответствующий пример
приводится на рис. 3.1.
■ Рис. 3.1. Порядок расположения карточек ролей на столе
Как видно на рис. 3.1, карточки ролей Выпускник (Colledge Grad) и Новичок, пред­
ложенные разными авторами, значительно перекрываются. Аналогичное, хотя и мень­
шее перекрытие мы видим и для других карточек, представляющих разных людей, ко­
торые будут использовать сайт для поиска работы. Карточка роли Наблюдатель лишь
незначительно перекрывает другие карточки, поскольку данная роль относится к соис­
кателю, которого нынешняя работа в целом устраивает, и он просто хочет всегда иметь
в запасе другие возможные варианты.
Справа от ролей тех, кто ищет работу, на рис. 3.1 отображены карточки ролей Пуб­
ликатора вакансий, Рекрутингового агента (Recruiter) и Читателя резюме. Рисунок
отражает тот факт, что роль Рекрутингового агента пересекается как с ролью Публи­
катора вакансий, так и с ролью Читателя резюме, поскольку сотрудникам кадровых
агентств приходится как публиковать объявления с предложениями работы, так и чи­
тать резюме тех, кто ищет работу. На рисунке также отображена карточка роли Адми­
нистратор (Administrator). Эта роль представляет системных пользователей, обслужи­
вающих сайт BigMoneyJobs.
▼------------------------------------------------------------------------------------ ▼
Системные роли
Стремитесь к тому, чтобы пользовательские роли определяли людей, а не какиелибо другие системы. Если же вы считаете, что без этого не обойтись, то в исключи­
тельных случаях можно ввести роль, не связанную с людьми. Однако в целом пользо­
вательские роли вводятся для того, чтобы мы никогда не забывали о людях и делали
все возможное для того, чтобы новая система удовлетворяла их потребности “на все
сто процентов”. Нет нужды вводить пользовательские роли для каждого мыслимого
пользователя системы, но их надо определять для тех людей, мнение которых о проек­
те как успешном или неудачном является решающим. Поскольку другие системы лишь
Глава 3. Моделирование пользовательских ролей
в редчайших случаях могут быть каким-либо образом уподоблены покупателям нашей
системы, то столь же редко приходится учитывать их возможное влияние на успешность
проекта. Разумеется, из этого правила возможны исключения, и если вы считаете, что
введение роли, не связанной с человеком, поможет вам лучше продумать свою систе­
му, добавьте эту роль.
▲------------------------------------------------------------------------------------ А
Объединение ролей
После того как роли сгруппированы, попробуйте объединить некоторые из них или
исключить ненужные. Начните с карточек, которые полностью перекрываются. Авторы
этих карточек должны подробно рассказать, что именно они подразумевают под назва­
ниями ролей. После краткого обсуждения группа принимает решение о том, эквива­
лентны ли эти роли. Если роли эквивалентны, то можно либо объединить их в одну роль
(возможно, оставив для нее название одной из первоначальных ролей), либо просто по­
рвать одну карточку.
Представленные на рис. 3.1 роли Выпускник и Новичок почти полностью пересека­
ются. Группа решает порвать карточку Выпускник, поскольку любые истории для этой
пользовательской роли, скорее всего, будут совпадать с таковыми для роли Новичок.
Несмотря на значительное пересечение ролей Новичок, Жертва увольнения, Регио­
нальный соискатель и Соискатель, группа приходит к заключению, что каждая из них
представляет свой круг пользователей, интересы которых должны быть обязательно удо­
влетворены, и все они, несмотря на незначительность различий, представляют отдель­
ные направления использования веб-сайта BigMoneyJobs.
Относительно карточек, находящихся справа на рис. 3.1, группа принимает решение,
что роли Публикатор вакансий и Читатель резюме ничем существенным друг от друга
не отличаются и что их назначение адекватно роли Рекрутинговый агент, поэтому обе
карточки рвутся. В то же время группа приходит к выводу, что роли Внутренний рекру­
тинговый агент (Internal Agent — агент, работающий на конкретную компанию) и Внеш­
ний рекрутинговый агент (External Agent — независимый агент, подбирающий кандида­
тов для любой компании) различаются между собой. Создаются две новые карточки для
ролей Внутренний рекрутинговый агент и Внешний рекрутинговый агент, которые рас­
сматриваются в качестве специализированных версий роли Рекрутинговый агент.
Кроме случаев слияния ролей, должны рваться также карточки любых других ролей,
которые не являются существенными для обеспечения успешности системы. Например,
карточка роли Наблюдатель представляет пользователя, который всего лишь хо­
чет “на всякий случай” постоянно иметь свежую информацию о наличии вакансий.
Наблюдатель может не поменять работу и через несколько лет. Вероятно, для сайта
BigMoneyJobs будет целесообразнее вообще игнорировать такие пользовательские роли.
Поэтому группа решает, что лучше сосредоточить внимание на тех ролях, которые будут
важны для успешности компании, в частности Соискатель и Рекрутинговый агент.
Когда команда завершит процесс объединения ролей, карточки следует располо­
жить на столе или стене так, чтобы они отображали связи между ролями. Одна из мно­
гих возможных схем расположения ролевых карточек для сайта BigMoneyJobs показана
на рис. 3.2. В этой схеме обобщенные роли, такие как Соискатель или Рекрутинговый
агент, располагаются над своими специализированными версиями. Также возможно ис­
пользование других подходов, при которых карточки располагаются стопками или лю­
бым другим способом, который группа решит использовать для того, чтобы отобразить
важные с ее точки зрения отношения между ролями.
V
Часть I. Приступаем к работе
■ Рис. 3.2. Карточки после объединения ролей
Уточнение ролей
Консолидировав роли и в целом достигнув понимания того, как они соотносятся
друг с другом, можно приступить к моделированию ролей путем определения атрибутов
для каждой из них. Атрибут роли (role attribute) — это какой-нибудь факт или полезная
информация о пользователях, которые действуют в данной роли. В качестве атрибута
роли может использоваться любая информация, отличающая одну роль от другой. Ниже
приведены некоторые атрибуты, которые стоит рассматривать при подготовке любой
ролевой модели.
• Частота (периодичность), с которой пользователь будет использовать данную
программу.
• Уровень подготовки пользователя в данной предметной области.
• Общий уровень пользователя в работе с компьютерами и программным обеспе­
чением.
• Чего в целом ожидает пользователь от данного программного обеспечения. Для
одних пользователей важно удобство в работе, для других — расширение своего
профессионального опыта и т.п.
Кроме этих стандартных атрибутов, вы должны обратить внимание на создаваемое
программное обеспечение и посмотреть, существуют ли еще какие-либо атрибуты, кото­
рые могли бы пригодиться при описании пользователей. Например, в случае веб-сайта
BigMoneyJobs можно проанализировать, будет ли данная пользовательская роль осу­
ществлять поиск вакансий штатного работника или совместителя.
При определении атрибутов, представляющих для роли интерес, записывайте приме­
чания на карточке роли. Когда закончите, можете вывесить карточки ролей там, где они
будут доступны для обозрения всей команде и смогут служить напоминаниями. Пример
карточки пользовательской роли приведен на рис. 3.3.
Глава 3. Моделирование пользовательских ролей
Пользовательская роль: внутренний рекрутинговый агент
Не особый знаток компьютеров, но умеет довольно хорошо работать
в Интернете. Будет использовать данноеПО нечасто, зато интенсивно,
Будет читать объявления, публикуемые другими компаниями, чтобы
понять, как наилучшим образом готовить объявления. Простотз
использования продукта для него важна, но гораздо важнее, чтобы
и месяцы спустя он мог легко вспомнить то, чему научился.
■ Рис. 3.3. Пример карточки пользовательской роли
Две дополнительные методики
При желании на этом можно было бы остановиться. К этому времени участники ко­
манды, вероятно, проработали уже час (скорее всего, не более), и теперь они, наверное,
будут посвящать размышлениям о пользователях своего продукта больше времени, чем
99% всех остальных команд разработчиков вместе взятых. В данный момент большин­
ство команд разработчиков действительно остановились бы. Однако существуют еще
две методики, на которые стоит обратить ваше внимание, поскольку они могут вам при­
годиться при анализе возможных способов общения пользователей с системой в неко­
торых проектах. Использовать их следует только в том случае, если это, по вашему мне­
нию, принесет проекту ощутимую пользу.
Личности
Определение ролей пользователей представляет собой огромный шаг вперед, но для
некоторых особо важных пользовательских ролей может оказаться целесообразным
пойти еще дальше и создать для роли личность (persona). Личность — это воображаемое
представление пользовательской роли. Ранее нам уже встречался Марио, в обязанности
которого входила публикация объявлений о вакансиях, открывшихся в его компании.
Создание личности требует не просто присвоения названия пользовательской роли.
Личность должна быть описана достаточно полно, чтобы у каждого члена команды воз­
никало ощущение, будто он лично знает этого человека. Например, описание Марио
могло бы быть таким.
Марио работает рекрутинговым агентом в отделе кадров компании Speedy
Networks, производящей высококачественные сетевые компоненты. В ком­
пании он уже шесть лет. У Марио гибкий рабочий график, и по пятницам
он работает на дому. Марио силен в компьютерах и считает себя опытным
пользователем почти всех используемых им программных продуктов. Жена
Марио, Ким, заканчивает работу над докторской диссертацией по химии
в Стэнфордском университете. Поскольку компания SpeedyNetworks непре­
рывно развивается, Марио постоянно ищет талантливых инженеров.
V
Часть I. Приступаем к работе
Если вы решите создать личности для своего проекта, позаботьтесь о проведении до­
статочно глубокого маркетингового и демографического исследования, позволяющего
убедиться в том, что выбранные личности представляют целевую аудиторию продукта
в истинном свете.
Приведенное выше описание личности дает нам хорошее представление о Марио.
Однако зрительные образы говорят громче слов, поэтому постарайтесь подыскать изо­
бражение для Марио и присовокупите его к описанию личности. Для этого можно вос­
пользоваться фотографиями из Интернета или какого-нибудь журнала. Хорошо под­
готовленное описание личности в сочетании с фотографией позволит каждому члену
команды получить о данной личности достаточно полное представление.
В большинстве случаев описания личностей окажутся слишком длинными и не смо­
гут уместиться на бумажной карточке, поэтому рекомендую записывать их на отдельных
листах бумаги и вывешивать в доступном для всеобщего обозрения месте. Вы не обяза­
ны описывать личности для каждой пользовательской роли. Однако подумать о написа­
нии таких определений для одной-двух основных пользовательских ролей имеет смысл.
Если для создаваемой вами системы абсолютно необходимо, чтобы продукт удовлетво­
рял потребности одной-двух ролей, то эти пользовательские роли являются первыми
кандидатами для перевода в категорию личностей.
Истории становятся гораздо более выразительными, когда излагаются в терминах
пользовательских ролей и личностей. Определив пользовательские роли и, возможно,
одну или две личности, вы сможете вести обсуждение в этих терминах, а не с использо­
ванием более общего термина “пользователь”. Вместо того чтобы писать историю на­
подобие “Пользователь может ограничить поиск вакансий определенным регионом”,
можно сформулировать ее в виде “Региональный соискатель может ограничить поиск
вакансий определенным регионом”. Есть надежда, что написание истории в таком виде
напомнит команде об Аллане, которого устроит любая работа на Мауи. Из того, что
история написана с упоминанием в ней названий пользовательских ролей или лич­
ностей, вовсе не следует, что она неприменима к другим ролям. Это лишь означает, что
если при обсуждении истории или в процессе написания исходного кода для нее вы бу­
дете представлять себе некоторую пользовательскую роль или личность, то это может
принести определенный положительный эффект.
Экстремальные персонажи
Джаядининграт с соавторами [26] предложил еще одну дополнительную методи­
ку, о которой вам следует знать, — использование экстремальных персонажей (extreme
characters) при рассмотрении проекта новой системы. В качестве примера они исполь­
зуют проектирование PDA — персонального цифрового помощника (Personal Digital
Assistant), или карманного компьютера. Вместо того чтобы проектировать программный
продукт, ориентируясь исключительно на типичного шикарно одетого консультанта по
менеджменту, разъезжающего на собственном BMW, они предлагают проектировщикам
системы подумать также о пользователях с неординарными личностными качествами.
В частности, предлагается рассмотреть проектирование PDA для торговца наркотиками,
папы римского и двадцатилетней девицы, меняющей своих многочисленных бойфрен­
дов, как перчатки.
Вполне вероятно, что рассмотрение экстремальных персонажей приведет вас к исто­
риям, которые иначе вы могли бы легко упустить из виду. Например, нетрудно себе
представить, что торговец наркотиками и девица с многочисленными бойфрендами
Глава 3. Моделирование пользовательских ролей
захотят иметь в календаре несколько отдельных расписаний на тот случай, если PDA
попадет в руки полиции или ревнивого приятеля. Вероятно, у Папы нет столь острой
необходимости соблюдать строгую секретность, но зато ему может потребоваться более
крупный шрифт.
Несмотря на то что рассмотрение экстремальных персонажей в качестве пользова­
телей может привести вас к новым историям, трудно сказать, окажутся ли они теми,
которые следует включать в продукт. Тратить на это много времени, пожалуй, не стоит,
но поэкспериментировать с экстремальными персонажами можно. По крайней мере,
вам самому будет забавно поразмышлять несколько минут над тем, каким образом папа
римский сможет использовать ваше программное обеспечение, и в процессе этого вас
даже может озарить какая-нибудь необыкновенная идея.
Если есть местные пользователи
Методики моделирования пользовательских ролей, описанные в этой главе, будут
полезны даже тогда, когда рядом с вами находятся реальные пользователи, работающих
в одном с вами офисе. Сотрудничество с реальными пользователями значительно уве­
личит вероятность того, что вы поставите именно то программное обеспечение, кото­
рое будет востребовано. Однако и в этом случае нельзя гарантировать, что такая группа
пользователей окажется достаточно представительной для того, чтобы отражать интере­
сы всех возможных пользователей вашей системы.
Чтобы свести вероятность неудач в удовлетворении потребностей важных пользова­
телей к минимуму, используйте простое ролевое моделирование в проекте, даже если вы
тесно контактируете с местными пользователями.
Резюме
• Большинство команд, работающих над проектами, учитывают только один тип
пользователей. В результате этого получаем программное обеспечение, в котором
игнорируются потребности по меньшей мере некоторых пользовательских типов.
• Во избежание написания всех историй с точки зрения только одного типа поль­
зователей определите пользовательские роли, которые будут взаимодействовать
с программным обеспечением.
• Определяя соответствующие атрибуты для каждой пользовательской роли, вы
сможете лучше понять различия между ролями.
• Некоторые пользовательские роли выигрывают от описания их в терминах лич­
ностей. Пользовательская личность — это некое воображаемое представление
пользовательской роли. Для личности придумываются имя, визуальный образ
и другие характеристики, создающие впечатление ее реальности в глазах участ­
ников проекта.
• Для некоторых приложений целесообразно вводить экстремальных персонажей,
использование которых может облегчить поиск историй, которые иначе могли
быть пропущены.
Часть I. Приступаем к работе
Обязанности разработчиков
• Вы обязаны участвовать в определении пользовательских ролей и личностей.
• Вы обязаны понимать суть каждой пользовательской роли или личности и раз­
личий между ними.
• В процессе разработки программного обеспечения вы обязаны продумывать, ка­
кое поведение системы может быть предпочтительным для различных пользова­
тельских ролей.
• Вы отвечаете за то, чтобы пользовательские роли определялись и описывались
исключительно для достижения целей проекта и ни для чего более.
Обязанности заказчика
• Вы отвечаете за проведение широкого анализа возможного круга пользователей
и определение соответствующих пользовательских ролей.
• Вы обязаны участвовать в определении пользовательских ролей и личностей.
• Вы обязаны следить за тем, чтобы приложение не оказалось неоправданно ориен­
тированным только на интересы какого-то одного подмножества пользователей.
• При написании историй вы обязаны следить за тем, чтобы каждую историю мож­
но было связать по крайней мере с одной пользовательской ролью или личностью.
• В процессе разработки программного обеспечения вы обязаны продумывать, ка­
кое поведение системы может быть предпочтительным для различных пользова­
тельских ролей.
• Вы отвечаете за то, чтобы пользовательские роли определялись и описывались
исключительно для достижения целей проекта и ни для чего более.
Контрольные вопросы
3.1. Загляните на сайт eBay.com. Какие пользовательские роли вы могли бы опреде­
лить для него?
3.2. Объедините роли, список которых вы определили при ответе на предыдущий
вопрос, и покажите, каким образом вы расположили бы их карточки. Поясните
свой ответ.
3.3. Составьте описание личности для одной из наиболее важных пользовательских
ролей.
Глава 4
Сбор историй
Как собирать истории? Этому вопросу посвящена данная глава, в которой приводится
ряд рекомендаций по организации совместной работы с пользователями для определе­
ния историй. Описание различных подходов сопровождается сравнительным анализом
их преимуществ и недостатков. В частности, рассказывается о том, как правильно подо­
бранные вопросы способны превратить диалог с пользователями в эффективный метод
извлечения информации об их реальных потребностях.
Откажитесь от выявления и фиксации требований
Даже в некоторых лучших книгах, посвященных требованиям, при описании мето­
дов их определения используются такие понятия, как выявление (elicitation) [38], [40],
[57] и фиксация (capture) [34]. Подобные термины подразумевают, что сами по себе тре­
бования объективно существуют, но находятся вне нашего поля зрения. Все, что тре­
буется сделать, — это попросить, чтобы нам их разъяснили, после чего останется лишь
зафиксировать их. Однако требования не витают где-то в пространстве проекта в ожи­
дании появления того, кому они нужны, а рассчитывать на то, что все требования уже
известны пользователям и нам остается лишь выявить их, также не приходится.
Для описания процесса сбора требований Сьюзан и Джеймс Робертсон [47] вводят
термин траление (trawling), или вылавливание. Выражение “вылавливание требований”
призывает нас мысленно уподоблять процесс сбора требований ловле рыбы сетью, ко­
торую тянет за собой судно. Эта метафора работает на самых разных уровнях описания.
Во-первых, она согласуется с той идеей, что для “вылавливания” требований раз­
личного размера можно использовать “сети” с ячейками различной величины. Во время
первого захода в “море требований” можно забросить сети с крупными ячейками, чтобы
отловить требования большого размера. Это позволит получить первое представление
о том, каким должно быть программное обеспечение, после чего можно будет сделать
еще один заход, используя сети с меньшими ячейками для вылавливания требований
среднего размера и оставляя мелкие требования на потом. Метафора работает одина­
ково хорошо, независимо от того, что именно понимается под “размером” требований:
бизнес-ценность, значимость для программного обеспечения или что-либо другое.
Во-вторых, выражение “вылавливание требований” наталкивает на проведение дру­
гой аналогии между рыбами и требованиями, а именно: требования, как и рыбы, могут
“стариться” и, возможно, “умирать”. Если моя “сеть” упустила какое-либо требование
сегодня, то это значит, что сейчас оно не актуально для системы. Но по мере того как
в результате обратной связи на разных итерациях процесса разработки система будет раз­
виваться в направлении, которое нелегко точно предсказать заранее, значимость неко­
торых требований может возрасти. Точно так же значимость требований, которые ранее
считались важными, может снизиться до такой степени, что они фактически “умрут”.
Часть I. Приступаем к работе
В-третьих, подобно тому, как невозможно выловить тралом всю рыбу в море, нельзя
“выловить” и все требования. Однако, как и в случае траления рыбных косяков, вместе
с полезными требованиями вы выловите и кучу ненужного хлама, приводящего к нео­
правданно раздутым требованиям.
Наконец, метафора “вылавливания требований” отражает ту важную реалию, что
при поиске нужных требований многое зависит от мастерства. Умелый “ловец” тре­
бований знает, где их искать, тогда как неумелый лишь потратит время зря, используя
неэффективные методы или действуя в неверном направлении. Эта глава научит вас
методикам, которые повысят вашу результативность при определении требований для
пользовательских историй.
Сколько нужно написать историй
Один из простейших способов определить, относится ли данный процесс разработки
к традиционным процессам предписательного типа, — посмотреть, какой подход к тре­
бованиям в нем применяется. Характерным признаком предписательных процессов
служит то, что особое значение в них придается заблаговременной подготовке и доку­
ментальному оформлению всех требований в законченном виде еще на ранних стадиях
проекта. В то же время в agile-проектах признается тот факт, что, говоря образным язы­
ком, невозможно подобрать сеть с ячейками столь малого размера, чтобы с ее помощью
можно было “выловить” все требования за один заход. В agile-процессах также призна­
ется, что при работе с историями должны учитываться временные факторы: релевант­
ность изменений, вносимых в историю с течением времени, а также то, какие истории
были добавлены в продукт на предыдущих итерациях.
Вместе с тем, даже признавая невозможность априорного написания всех историй
для проекта, все же имеет смысл попытаться заранее написать некоторые истории,
хотя при этом многие из них будут относиться к очень высокому уровню. Одним из
преимуществ работы с историями является та необычайная простота, с которой мож­
но писать истории на разных уровнях детализации. Мы можем записать историю в виде
“Пользователь может осуществить поиск вакансий” либо с целью использовать ее в ка­
честве заполнителя, либо потому, что в настоящее время мы больше ничего не можем
об этом сказать. Впоследствии у нас еще будет возможность развернуть данную исто­
рию в ряд меньших, более полезных историй. В силу этого не составит труда написать
истории для значительной части приложения, затратив на такую работу меньше рабоче­
го времени, чем при использовании других методик, основанных на документировании
требований.
Вышесказанное не следует рассматривать как совет начинать новый проект, засев
за написание пользовательских историй месяца на три. Скорее, это означает, что вы
должны заглянуть в будущее на глубину примерно одного выпуска (на создание кото­
рого, вероятно, уйдет от одного до трех месяцев) и впоследствии писать истории, ко­
торые будут становиться все более детальными по мере расширения временного гори­
зонта. Например, если заказчик или пользователи говорят, что они “пожалуй, хотели
бы получить возможность выводить отчеты уже в этом выпуске”, то в карточке следует
сделать всего лишь такую запись: “Пользователь может выводить отчеты”. Но на этом
вы и должны остановиться: не пытайтесь определить, следует ли предоставить пользова­
телям возможность самостоятельно конфигурировать отчеты, должны ли отчеты выво­
диться в формате HTML и следует ли предусмотреть возможность их сохранения.
Глава 4. Сбор историй
Точно так же перед началом проекта важно знать хотя бы приблизительный размер
приложения. Во многих случаях, еще до того как будет начато финансирование проекта
и дана команда приступать к работе, вы должны иметь по крайней мере общее пред­
ставление о стоимости проекта и приносимых им выгодах. Чтобы получить ответы на
подобные вопросы, следует предварительно обдумать истории, которые будут входить
в проект.
Методы
Поскольку на протяжении всего проекта истории появляются, развиваются и исче­
зают, нам необходим такой набор методов их сбора, который допускал бы итеративный
подход. Методы, которые мы собираемся использовать, должны быть простыми и не­
обременительными, чтобы их можно было применять более или менее непрерывно.
Одними из наиболее полезных методов сбора историй являются следующие:
• интервьюирование пользователей;
• анкетирование;
• наблюдение;
• собрания по написанию историй.
Многие из перечисленных методов входят в инструментарий традиционных бизнесаналитиков. Если существует такая возможность, включите бизнес-аналитика в проект,
поскольку его вклад в сбор историй может быть значительным.
Интервьюирование пользователей
Устный опрос пользователей — это стандартный подход, применяемый командами
для сбора историй, и вам, вероятно, также следует его задействовать. Одним из ключе­
вых факторов успешного интервьюирования является правильный отбор опрашиваемых
лиц. Как обсуждается в главе 5, существует много типов представителей пользовате­
лей, но совершенно очевидно, что по возможности следует опрашивать прежде всего
реальных пользователей. Кроме того, круг опрашиваемых пользователей должен быть
достаточно широк для того, чтобы охватить как можно больше различных пользова­
тельских ролей.
Недостаточно спросить пользователя: “А что вам надо?” Большинство пользователей
не очень-то понимают, да и не могут сформулировать, в чем состоят их истинные по­
требности. Я это очень хорошо понял, когда однажды ко мне в офис пришел пользова­
тель и признался: “Вы сделали в точности то, о чем я просил, но это не то, чего я хочу”.
Я работал с командой, разрабатывавшей программное обеспечение для проведения
опросов. Предусматривалось, что опросы будут проводиться по телефону, а также с по­
мощью электронной почты и системы предварительно записанных голосовых сообще­
ний (Interactive Voice Response, IVR). Предполагалось, что для различных типов поль­
зователей будут использоваться различные типы опросов. Вопросники имели сложную
структуру: ответы на какой-то один набор вопросов определяли, какой вопрос будет за­
дан следующим. Пользователи нуждались в удобном способе ввода вопросов, и с этой
целью разработчикам были предоставлены примеры сложного мини-языка, используе-
Часть I. Приступаем к работе
мото для конструирования соответствующих формулировок. Одному из разработчиков
такой подход, основанный на текстовом представлении информации, показался не­
оправданно сложным. Он продемонстрировал пользователям, что гораздо удобнее ис­
пользовать визуальный метод построения вопросников, который базируется на перета­
скивании значков, представляющих вопросы различного типа. Пользователи отказались
от своей идеи мини-языка и вместе с разработчиками включились в работу по созданию
визуального инструмента для разработки опросов. Отсюда мораль: даже если проблему
формулируют пользователи, не им одним принадлежит исключительное право предла­
гать пути ее решения.
Открытые и контекстно-независимые вопросы
Вы лучше всего сможете разобраться в том, что действительно необходимо пользо­
вателю, если начнете задавать ему вопросы. Я работал с одной проектной командой,
которая никак не могла решить, на каком варианте приложения следует остановиться:
создать его на основе браузера или в виде более привычной платформенно-зависимой
программы. Простоте развертывания и более низкой стоимости обучения работе с бра­
узерной версией противостояли более мощные возможности клиента, зависящего от
платформы. Предполагаемые пользователи, несомненно, приветствовали бы преимуще­
ства браузерной версии, но они также по достоинству оценили бы и большие удобства
использования продукта, обеспечиваемые клиентом второго типа.
Поступило предложение выяснить предпочтения целевых пользователей продукта
путем их опроса. Поскольку продукт должен был представлять собой новое поколение
традиционного продукта, код которого следовало переписать заново, маркетинговая
группа согласилась поработать с представительной выборкой текущих пользователей.
Опрашиваемым пользователям задавался один и тот же вопрос: “Хотели бы вы, чтобы
новое приложение работало в браузере?”
Ситуация выглядела так, как если бы вы пошли в свой любимый ресторан и офи­
циант спросил вас, хотите ли вы, чтобы вас обслужили бесплатно. Ну кто же откажет­
ся от столь щедрого предложения? Поэтому не было ничего удивительного и в реакции
пользователей, которые все как один отвечали, что, конечно же, они очень хотят, чтобы
новая версия программы работала в браузере.
Ошибка маркетинговой группы состояла в том, что вопрос был сформулирован
в замкнутой форме и не содержал абсолютно никаких дополнительных деталей, которые
помогли бы правильно на него ответить. Вопрос предполагал, что каждый, кому он за­
давался, хорошо осведомлен о тех компромиссах, которые следует учитывать, выбирая
между браузером и какими-то нечетко определенными альтернативами. Гораздо лучше
было бы использовать следующую формулировку:
“Хотели бы вы, чтобы новое приложение работало в браузере, а не выпол­
нялось в виде обычного Windows-приложения, даже если это будет означать
снижение его производительности, ухудшение общего удобства использова­
ния и меньшие интерактивные возможности?”
Этот вопрос по-прежнему проблематичен, поскольку сохранилась его замкнутая
форма. Он лишает респондента какой-либо свободы выбора и вынуждает его отвечать
лишь простым “да” или “нет”. Гораздо лучше задавать открытые вопросы, позволяю­
щие респондентам более развернуто выражать свое мнение. Например, вопрос может
быть таким: “Чем бы вы были готовы пожертвовать ради того, чтобы наш следующий
Глава 4. Сбор историй
продукт нового поколения выполнялся в браузере?” Отвечая на этот вопрос, пользова­
тель может думать в разных направлениях. Анализ того, куда направлены (или не на­
правлены) его мысли, сделает его ответ более содержательным для вас.
В равной степени немаловажно, чтобы задаваемые вопросы были контекстно­
независимыми, а не наводящими, т.е. не включали в себя неявно предполагаемый от­
вет или предпочтения. Например, не стоит задавать таких вопросов, как “Вам ведь не
хотелось бы пожертвовать производительностью и большими удобствами использо­
вания приложения ради того, чтобы оно могло выполняться в браузере, не так ли?”
Совершенно очевидно, какого рода ответ даст вам большинство людей на таким обра­
зом поставленный вопрос.
Точно так же, вместо того чтобы спрашивать: “Как быстро должен осуществляться
поиск?”, сформулируйте вопрос иначе: “Какая требуется производительность?” или
“Является ли производительность главенствующим фактором для некоторых частей
приложения?” Первый из этих вопросов не является контекстно-независимым, по­
скольку в нем подразумевается, что к производительности процедуры поиска должны
выдвигаться какие-то требования. На самом деле требования такого рода могут отсут­
ствовать, но в ответе на подобного рода вопрос вы вряд ли услышите это от пользовате­
ля. Скорее всего, он начнет выдвигать относительно этого некоторые предположения.
В какой-то момент вам все равно придется перейти от контекстно-независимых
вопросов к весьма конкретным. Тем не менее, когда вы начинаете интервью именно
с контекстно-независимых вопросов, вы получаете возможность услышать от пользо­
вателей более разноплановые ответы. Это приведет вас к историям, которые могли бы
просто остаться незамеченными, если бы вы сразу начали задавать пользователям во­
просы с ограниченным множеством возможных ответов.
Анкетирование
Эффективным инструментом сбора информации об уже имеющихся пользователь­
ских историях могут служить анкеты, или вопросники. Если у вас есть доступ к широко­
му кругу пользователей, то анкетирование — это замечательный способ получения ин­
формации о том, какие приоритеты следует назначить историям. Точно так же анкеты
полезны в тех случаях, когда необходимо получить ответы на конкретные вопросы от
большого количества пользователей.
В то же время анкеты, как правило, не могут служить главным инструментом для
сбора новых историй. Они не предназначены для гибкого формирования структуры до­
полнительных вопросов. Кроме того, в отличие от устного обсуждения, они не дают воз­
можности глубже развивать интересные идеи, которые могут возникать у пользователей.
В качестве примера можно привести использование анкетирования для того, чтобы
выяснить, как часто текущие пользователи используют возможности программного обе­
спечения в настоящее время и чем их не устраивают какие-либо из имеющихся возмож­
ностей. Такой опрос может показать, что для некоторых историй, касающихся удобства
использования (usability) программного обеспечения, следует установить более высокие
приоритеты, чем те, которые были назначены им ранее. Еще один пример. От вопроса
“Какие новые возможности вы хотели бы получить?” будет мало пользы. Если вы пре­
доставите пользователю фиксированный список вариантов ответа, то рискуете не узнать
о существовании еще нескольких критически важных для пользователя возможностей,
о которых вы даже не догадываетесь. С другой стороны, если пользователю предостав-
V
Часть I. Приступаем к работе
лено право письменно изложить свое мнение в свободной форме, то такие ответы будет
трудно табулировать.
Учитывая одностороннюю коммуникативную природу анкетирования и связанные
с этим временные задержки, я не рекомендую применять этот метод для сбора историй.
Если вы хотите подключить к сбору информации широкую базу существующих пользо­
вателей и можете позволить себе выждать одну или несколько итераций, прежде чем эта
информация будет задействована в проекте, то анкеты можно использовать лишь для
этой цели, но никак не в качестве основного средства для сбора историй.
Наблюдение
Наблюдение за поведением пользователей в процессе взаимодействия с вашим про­
граммным обеспечением — прекрасная возможность глубже вникнуть в суть вещей.
Всякий раз, когда мне представлялся случай понаблюдать, как люди используют раз­
работанное мною программное обеспечение, меня осеняли новые идеи относительно
того, как сделать общение с программой более комфортным для пользователя, повысить
продуктивность его труда или обеспечить и то, и другое. К сожалению, возможности для
такого наблюдения предоставляются крайне редко, если только заказчик не находится
рядом с вами. При разработке многих коммерческих продуктов исходят из того, что по­
желания заказчика можно предвидеть. Если вам выпадает возможность понаблюдать за
пользователями в процессе эксплуатации вашего программного продукта, обязательно
воспользуйтесь этим. Быстрая обратная связь с пользователями значительно ускоряет
выпуск очередных версий, что сокращает сроки поставки программного обеспечения,
обладающего нужной заказчику функциональностью.
В одной компании в качестве пользователей выступали медсестры, работавшие
в колл-центре. В их обязанности входило отвечать на поступающие звонки, касающи­
еся медицинского обслуживания. Медсестры подсказали, что неплохо было бы иметь
большое текстовое поле, позволяющее документировать результаты звонков по их за­
вершении. Именно такое текстовое поле было предусмотрено в первоначальной версии
ПО на экране, предназначенном для ввода резюме звонка. Однако после выпуска этой
версии каждый член команды разработчиков посвятил один день наблюдениям за дей­
ствиями пользователей. В частности, было обнаружено, что указанное текстовое поле
использовалось для ввода информации, которую легко могла бы отслеживать сама си­
стема. Результаты наблюдения позволили разработчикам сделать вывод, что реальной
потребностью пользователей была система, способная отслеживать решения, принимае­
мые ими в процессе работы с ПО. Большое текстовое поле было заменено средством,
обеспечивающим занесение в журнал всех операций поиска и выбираемых медсестрами
рекомендаций. Реальная потребность — отслеживание всех инструкций, предлагаемых
абоненту, — совершенно не просматривалась за попытками медсестер дать ее описание
и была выявлена лишь благодаря наблюдению за тем, как используется система.
Собрания по написанию историй
Собрания по написанию историй (story-writing workshops) — это семинары, в которых
принимают участие разработчики, пользователи, заказчик продукта и другие стороны,
способные внести свой вклад в составление историй. В ходе такого собрания его участ-
Глава 4. Сбор историй
ники записывают как можно больше пользовательских историй. На этой стадии исто­
риям не назначаются никакие приоритеты: у заказчика еще будет возможность сделать
это позднее. По моему мнению, такие собрания — самый эффективный способ сбора
историй. Я рекомендую проводить их перед началом каждого запланированного выпу­
ска. У вас всегда есть возможность созвать собрание и в процессе работы над выпуском,
но необходимости в этом обычно не возникает.
При условии правильной организации работы такое собрание — это замечательный
способ быстрого написания множества историй. Исходя из собственного опыта могу
сказать, что собрания по написанию историй сочетают в себе лучшие черты “мозгового
штурма” и чернового прототипирования (low-fidelity prototyping). Черновые прототипы
создаются на листах бумаги, бумажных (картонных) карточках или на белой доске (доска
для временных записей) и используются для отображения высокоуровневых взаимодей­
ствий в планируемом ПО. Прототип создается итеративным путем во время собрания,
когда его участники генерируют методом “мозгового штурма” идеи относительно того,
какими могут быть намерения пользователя в тот или иной момент в процессе исполь­
зования приложения. Цель всего этого состоит не в том, чтобы определить фактически
необходимые экраны или поля, как это делается при построении прототипов традици­
онными методами или в сеансах JAD (Joint Application Design — совместное проекти­
рование приложений). Вместо этого определяются концептуальные последовательности
выполняемых действий (workflows). Начало процесса чернового прототипирования для
веб-сайта BigMoneyJobs иллюстрирует рис. 4.1.
■ Рис. 4.1. Черновой прототип для сайта BigMoneyJobs
V
Часть I. Приступаем к работе
Каждый прямоугольник представляет новый компонент веб-сайта. Названия ком­
понентов выделены. Под каждым названием размещается краткий список того, какие
действия выполняет компонент или что он содержит. Стрелки, соединяющие прямоу­
гольники, отражают связи между компонентами. В случае веб-сайта компонентами
могут быть либо новая страница, либо часть пространства на текущей странице. Таким
образом, связь указывает либо на появление новой страницы, либо на то, что информа­
ция отображается на той же веб-странице. Например, компонентом Search Jobs (Поиск
работы) может служить либо сама страница, либо часть домашней страницы. Это раз­
личие несущественно, поскольку у заказчика и разработчиков впоследствии будет масса
времени для обсуждения подобных деталей.
Прежде чем приступить к построению чернового прототипа, решите, с какой поль­
зовательской роли или личности системы вы хотите начать. Вы будете повторять про­
цесс для каждой роли или личности, поэтому выбор их очередности значения не имеет.
После этого начертите пустой прямоугольник, объясните участникам, что это основной
экран данного программного обеспечения, и спросите, какие, по их мнению, действия
здесь могут потребоваться пользователю. Неважно, что пока еще не выяснено, что собой
представляет основной экран и какие на нем имеются активные элементы. Участники
собрания начнут генерировать идеи относительно того, какие действия данная роль или
личность могут предпринять. Для каждого предполагаемого действия проведите линию,
ведущую к новому прямоугольнику, а затем впишите в него имя компонента и напиши­
те соответствующую историю.
В результате обсуждения, которое привело к созданию прототипа, изображенного на
рис. 4.1, будут сгенерированы следующие истории.
• Соискатель может поместить свое резюме на веб-сайте.
• Работодатель может публиковать вакансии.
• Работодатель может просмотреть представленные резюме.
• Соискатель может осуществить поиск вакансий.
• Соискатель может просмотреть информацию о вакансиях, удовлетворяющих кри­
териям поиска.
• Соискатель может просмотреть подробное описание отдельной вакансии.
Ни одна из этих историй не требует знания того, какие экраны будут спроектирова­
ны. В то же время при таком способе перебора всех возможных действий пользователя
в конкретных ситуациях каждый участник сможет предложить намного больше историй.
Я пришел к выводу, что эффективнее всего выполнять обход полученной системы пря­
моугольников по принципу сначала вглубь, суть которого в следующем. Запишите для
первого компонента наиболее важные детали, а затем перейдите к одному из связанных
с ним компонентов и проделайте с ним то же самое. Далее, вместо того чтобы вернуться
к первому компоненту и итеративно применить описанную процедуру ко всем остав­
шимся компонентам, которые с ним связаны, продолжите продвижение “вглубь”, т.е.
перейдите к одному из компонентов, связанных с только что описанным и т.д. При об­
ходе прямоугольников по принципу сначала вширь вам будет труднее ориентироваться
в логике прохождения каждого возможного пути на схеме до конца.
В процессе обхода прототипа задавайтесь вопросами, подобными приведенным
ниже, которые помогут вам установить отсутствующие истории.
Глава 4. Сбор историй
▼----------------------------------------------------------------------------- ▼
Не храните черновые прототипы
Обязательно выбрасывайте или уничтожайте черновой прототип спустя несколько
дней после того, как создали его. Прототипы не относятся к долгосрочным артефактам
процесса разработки, и вам не стоит их хранить, чтобы не создавать путаницы. Если вы
покидаете собрание по написанию историй с чувством, будто что-то не было доведено
до конца, сохраните прототип еще на несколько дней, пересмотрите его, постарайтесь
дописать отсутствующие истории, но впоследствии все равно избавьтесь от него.
• Каким, вероятнее всего, будет следующее действие пользователя?
• Какие ошибки может совершить пользователь в данный момент?
• Что может сбить пользователя с толку в данный момент?
• В какой дополнительной информации может нуждаться пользователь?
Задаваясь этими вопросами, не забывайте о пользовательских ролях и личностях.
Ответы на многие вопросы могут зависеть от того, какая пользовательская роль рассма­
тривается.
Выделите место для размещения списка проблем, к которым еще надо будет вернуть­
ся. Например, в процессе обсуждения проекта BigMoneyJobs кто-то мог спросить, будет
ли система поддерживать контрактных работников наряду с теми, кто работает на пол­
ную ставку. Если до собрания никто об этом не задумывался, сделайте соответствующую
запись и поместите ее на видном месте, чтобы рассмотреть позднее — либо в конце со­
брания, либо по завершении некоторой дополнительной работы после собрания.
В ходе собрания, посвященного написанию историй, вашей целью должно быть
их количество, а не качество. Даже если истории, в конечном счете, будут храниться
в электронном виде, на собрании следует использовать карточки. Просто дожидайтесь
появления идей и записывайте их. История, которая вначале выглядит не очень удач­
ной, через несколько часов может быть признана великолепной или послужить источ­
ником вдохновения для написания другой истории. Кроме того, вы сами не захотите
увязнуть в затяжных дебатах вокруг каждой истории. Если история явно ничего не дает
или впоследствии может быть заменена лучшей, выбросьте ее, не колеблясь ни минуты.
Точно так же, когда заказчик будет устанавливать приоритеты историй для выпуска, он
сможет назначить историям низкого качества низкий приоритет.
Иногда для некоторых участников собрания по написанию историй может выдаться
неудачный день, когда они либо никак не могут раскачаться, либо надолго застревают
на одном месте. В этом случае полезно обратиться к рассмотрению аналогов или конку­
рирующих продуктов.
Следите за тем, чтобы все участники собрания проявляли активность. Временами не­
которые участники могут не проронить ни слова на протяжении всего собрания. В таком
случае поговорите с участником во время одного из перерывов и постарайтесь добиться
того, чтобы он раскрепостился. Некоторые участники могут смущаться в присутствии
коллег или начальства, и именно поэтому важно, чтобы никакие оценки историям на
собраниях не ставились. Как только участники свыкнутся с мыслью, что их идеи просто
записываются, а не обсуждаются, их активность заметно повысится.
Наконец, позвольте мне повториться и еще раз напомнить, что на собраниях по на­
писанию пользовательских историй обсуждению подвергаются лишь самые верхние
Часть I. Приступаем к работе
уровни. Целью является написание как можно большего количества историй за как
можно более короткое время. Проектировать экраны и разрешать проблемы — не цель
подобных собраний.
Резюме
• Идея выявления и простой фиксации требований является ошибочной. За ней
скрывается двойной обман, заключающийся в том, что в соответствии с этой
идеей пользователям все требования уже известны и нам остается лишь зафикси­
ровать их и применять далее в неизменном виде.
• Метафора “вылавливания” требований гораздо более полезна, и в ней находит
свое отражение тот факт, что требования могут быть измеримыми, могут изме­
няться со временем и для их определения необходимы определенные навыки.
• Несмотря на то что для agile-процессов характерна поддержка требований, возни­
кающих на более поздних стадиях процесса, вы должны уже с самого начала мыс­
ленно проанализировать почти весь планируемый выпуск и записать все пользо­
вательские истории, которые сможете легко усмотреть.
• При подготовке пользовательских историй могут применяться такие методы,
как интервьюирование пользователей, наблюдение за их действиями при работе
с программой, анкетирование и собрания по написанию историй.
• Наилучших результатов можно добиться, если применять сочетание различных
методов и не полагаться чрезмерно на какой-то один из них.
• Наиболее полезными являются ответы на открытые, контекстно-независимые
вопросы, такие, например, как “Скажите, а по каким признакам вы хотели бы
искать работу?”, в отличие от “Хотели бы вы искать работу по названию долж­
ности?”.
Обязанности разработчиков
• Вы обязаны понимать и уметь применять на практике различные методики для
сбора пользовательских историй.
• Вы обязаны знать, как наилучшим образом использовать открытые, контекстно­
независимые вопросы.
Обязанности заказчика
• Вы обязаны понимать и уметь применять на практике различные методики для
сбора пользовательских историй.
• Вы обязаны написать как можно большее количество пользовательских историй.
• Как главный представитель пользователей программного обеспечения и вырази­
тель их интересов, вы обязаны знать и использовать в процессе общения с ними
все доступные вам возможности сбора требований.
Глава 4. Сбор историй
• Вы обязаны знать, как наилучшим образом использовать открытые, контекстно­
независимые вопросы.
• Если вы должны или хотите оказать помощь в написании историй, то обязаны
запланировать и провести одно или несколько собраний по написанию историй.
• Вы обязаны убедиться в том, что в процессе сбора историй надлежащим образом
учтены все пользовательские роли.
Контрольные вопросы
4.1. Возникновения проблем какого рода следует ожидать, если для сбора требова­
ний команда использовала только анкеты?
4.2. Переформулируйте приведенные ниже вопросы таким образом, чтобы придать
им открытость и контекстную независимость: “Считаете ли вы, что пользова­
тель должен вводить пароль?”, “Должна ли система автоматически сохранять
результаты работы пользователя каждые 15 минут?”, “Должен ли пользователь
иметь возможность просматривать записи в базе данных, сделанные другим
пользователем?”.
4.3. Почему наиболее эффективными являются открытые, контекстно-независимые
вопросы?
Глава 5
Работа с представителями
пользователей
Для проекта жизненно важно, чтобы в состав команды заказчика входил хотя бы один
реальный пользователь. В то время как другие люди могут лишь догадываться о том, ка­
кое поведение программного обеспечения было бы желательным для пользователя, до­
стоверно об этом знает только он сам. К сожалению, нередко бывает трудно добиться
контакта с пользователями, которые нам нужны. Например, мы разрабатываем продукт,
пользователи которого разбросаны по всей стране, но не можем обеспечить приезда
к нам хотя бы одного из них для участия в написании историй. Или же мы разрабатыва­
ем ПО, предназначенное для использования в нашей же компании, но руководство по
той или иной причине запрещается общаться с пользователями. В тех случаях, когда ор­
ганизовать обсуждение продукта с нужными пользователями не удается, мы вынуждены
привлекать уполномоченных представителей пользователей (user proxies), которые, сами
не являясь пользователями, все же могут представлять их интересы в проекте.
Выбор подходящих представителей пользователей может иметь ключевое значение
для успешности проекта. При этом должны обязательно учитываться уровень подготов­
ки и мотивация возможных представителей пользователей. Подход к историям маркето­
лога как представителя пользователя будет отличаться от подхода представителя, являю­
щегося специалистом в предметной области. Важно знать об этих отличиях. В данной
главе рассмотрен ряд типов представителей пользователей, которые иногда привлекают­
ся вместо реальных пользователей.
Менеджер пользователей
Если проект разрабатывается для внутреннего применения, организация может очень
неохотно предоставлять вам полный и неограниченный доступ к одному или нескольким
сотрудникам, но не будет возражать против вашего общения с менеджером пользовате­
лей. Вы должны относиться к этому скептически, если только менеджер сам не является
пользователем вашего программного обеспечения. Но даже в последнем случае можно
почти с полной уверенностью утверждать, что взгляды менеджера на характер исполь­
зования данного программного обеспечения будут отличаться от взглядов типичного
пользователя. Например, одной команде, разрабатывавшей приложение для управле­
ния работой колл-центра, предоставили возможность общаться с начальниками смен.
Начальники смен сами были пользователями соответствующего программного обеспече­
ния, однако многие новые возможности, которые они хотели увидеть в новой версии, ка­
сались в основном управления очередностью звонков и перераспределения звонков меж­
ду операторами. Для операторов, работу которых контролировали начальники смен и для
которых новые программы в основном и предназначались, эти возможности были далеко
Часть I. Приступаем к работе
не самыми важными. Если бы разработчики не добились разрешения на непосредствен­
ное общение с типичными пользователями, то менее часто используемым функциональ­
ным возможностям продукта было бы уделено неоправданно много внимания.
Иногда менеджеры пользователей идут на уступки и добровольно играют роль поль­
зователя в проекте, однако при этом ими движут амбиции. Менеджер может признавать,
что его нельзя считать типичным пользователем, но будет настаивать, что в работе сво­
их подчиненных он разбирается гораздо лучше, чем они сами. Разумеется, в подобных
ситуациях вы должны действовать деликатно, чтобы не ущемить его самолюбия. Тем не
менее, руководствуясь интересами проекта, вы должны найти тактичный способ отго­
ворить его от этой идеи и постараться обеспечить хотя бы частичное участие реальных
пользователей в проекте. Некоторые соображения по этому поводу приводятся в разделе
“Как организовать работу с представителями пользователей”.
▼----------------------------------------------------------------------------- ▼
Пять минут — не одна минута
В одном внутреннем проекте, о котором сейчас пойдет речь, “пользователем” был
вице-президент компании, который ни разу не использовал данное программное обе­
спечение и был отделен от конечных пользователей слоем менеджеров. Во время
расстановки приоритетов для очередной итерации он выразил желание, чтобы раз­
работчики сконцентрировали внимание на повышении скорости обработки запросов
к базе данных. Команда записала соответствующую историю и присвоила ей высокий
приоритет, испытывая при этом некоторое недоумение. Дело в том, что о критической
роли производительности приложения им было хорошо известно и они встроили в про­
граммное обеспечение механизм мониторинга: каждый раз, когда выполнялся запрос
к базе данных, его параметры, время исполнения и имя пользователя сохранялись
в базе данных. Эта информация проверялась по крайней мере раз в день, и на воз­
никновение каких-либо проблем с производительностью ничто не указывало. Однако
их “пользователь” заявил, что на некоторые запросы у него уходило “целых пять минут”.
После совещания с вице-президентом команда заглянула в журнал регистрации
запросов, и вот что выяснилось. Действительно, пару раз для выполнения запроса по­
требовалось около минуты. Конечно, эти запросы обслуживались дольше, чем хотелось
бы, но с учетом характера объектов поиска, размера базы данных и относительной
редкости выполнения поисковых запросов данного типа производительность системы
оставалась в ожидаемых пределах. Тем не менее пользователи проинформировали
своего менеджера об этих двух одноминутных запросах. После этого менеджер проин­
формировал о проблеме вице-президента, а для пущей уверенности в том, что тот о ней
не забудет, сказал, что запросы выполнялись по две минуты каждый. В изложении же
сути дела разработчикам вице-президент, руководствуясь теми же соображениями, что
и менеджер, довел время выполнения проблемных запросов до “целых пяти минут”.
Менеджеры пользователей могут сеять дезинформацию. При любой удобной воз­
можности ищите подтверждения их словам в разговоре с реальными пользователями.
Менеджер разработчиков
Если только вы не создаете программное обеспечение для менеджеров разработчи­
ков, то они — наихудший вариант кандидата на роль представителя пользователей. Даже
если менеджер разработчиков обладает самыми благими намерениями, слишком велика
Глава 5. Работа с представителями пользователей
вероятность того, что некоторые из его целей будут конфликтными. Например, устанав­
ливая приоритеты историй, менеджер будет руководствоваться собственными сообра­
жениями, а не занимать позицию реального разработчика, поскольку это позволит ему
быстрее внедрить захватывающую новую технологию. Кроме того, у него могут быть
несовпадающие корпоративные цели: возможно, его ежегодный бонус привязан к дате
сдачи проекта, что будет побуждать его назвать проект завершенным раньше, чем так
счел бы реальный пользователь.
Наконец, большинство менеджеров разработчиков просто не имеют опыта работы
с создаваемым программным обеспечением и не являются специалистами в предметной
области. Если же ваш кандидат на роль пользователя в проекте — менеджер, который
действительно обладает знаниями в соответствующей области, подумайте над тем, что­
бы использовать его в качестве специалиста, и прочитайте раздел “Специалисты в пред­
метной области”, прежде чем полагать, будто вы нашли подходящего представителя
пользователей.
Продавцы
Опасность привлечения в проект торгового агента в качестве представителя поль­
зователей состоит в том, что это ничего не дает в плане получения всестороннего пред­
ставления о создаваемом продукте. Самой важной для продавца будет та история, из-за
отсутствия которой у него сорвалась последняя сделка. Если сделка не состоялась по
той причине, что в продукте не было предусмотрено средство отмены, то можете не со­
мневаться, что карточка истории, описывающая отмену, тут же появится на самом верху
стопки. В зависимости от суммы сорвавшейся сделки, может потребоваться написать
одну-две новые истории. Однако компания-разработчик, придающая слишком большое
значение анализу причин срыва каждой несостоявшейся сделки, рискует упустить из
виду стратегическое видение продукта в долгосрочной перспективе.
Вместе с тем, через продавцов вы получаете замечательную возможность общения
с пользователями, и именно в таком плане вы и должны их рассматривать. Попросите
их, чтобы они представили вас заказчикам по телефону или во время встречи на пере­
говорах. Но будет еще лучше, если вы придете на выставку-продажу и поработаете в ка­
честве продавца в павильоне своей компании.
▼------------------------------------------------------------------------------------ ▼
Поговорите с пользователями вашего продукта
В 1995 году перед одной командой была поставлена задача создания информаци­
онного веб-сайта по общим вопросам здравоохранения. В то время это был один из
первых сайтов такого рода, конкуренты отсутствовали, и подсмотреть идеи пользова­
тельских историй у кого-то другого было невозможно. Роль представителя пользовате­
лей в проекте играл директор, прошлая деятельность которого была связана с марке­
тингом. В силу этого он очень хорошо понимал, насколько важно знать мнение людей
о том, каким должен быть медицинский информационный сайт. Однако, движимый же­
ланием запустить сайт как можно быстрее, директор очень торопился и при создании
сайта руководствовался лишь своим внутренним чутьем.
Как нетрудно догадаться, проект не удовлетворял потребностям своих пользовате­
лей. Спустя месяц после запуска сайта я зашел в офис директора по маркетингу. Он по­
казал на монитор и воскликнул: “Нет, вы только взгляните на это!” На экране красовал-
Часть I. Приступаем к работе
ся порносайт. Немного придя в себя, я спросил у него, почему мы должны любоваться
этим. Но похоже, он вообще не замечал порно. Его взгляд был прикован к счетчику по­
сещений, и он произнес: “Представляете, у них за день набежало 100 000 посещений,
а у нас — всего 200”.
Мораль сей басни такова: если хотите, чтобы ваше программное обеспечение ис­
пользовалось, разговаривайте с теми, кто будет пользоваться им.
▲------------------------------------------------------------------------------------ ▲
Специалисты в предметной области
Эксперты в конкретных областях, так называемые специалисты в предметной области
(domain experts), составляют важнейшую часть ваших ресурсов, ибо от того, насколько
хорошо они разбираются в данной области, зависит, насколько хорошо ваше программ­
ное обеспечение будет ориентировано на целевую аудиторию. Вполне естественно, что
одни области более трудны для понимания, чем другие. В прошлом мне довелось пи­
сать множество программ для адвокатов и помощников юристов, и хотя при этом ино­
гда возникали определенные сложности, обычно мне всегда удавалось понимать, чего от
меня хотят. Уже гораздо позже я участвовал в написании программного обеспечения для
статистической обработки генетических данных. Я столкнулся с массой таких терминов,
как фенотип, сантиморган, гаплотип. Все эти слова были для меня незнакомы, и поэто­
му разбираться в том, что они означают, было очень нелегко. Это заставляло меня, как
и остальных разработчиков, в значительно большей степени полагаться на мнение экс­
перта, который помогал нам понять, что именно мы должны разработать.
Несмотря на то что специалисты в предметной области представляют собой замеча­
тельный источник дополнительных сведений, приносимая ими реальная польза зави­
сит от того, пользовались ли они программным обеспечением разрабатываемого вами
типа ранее или начнут использовать его только сейчас. Например, создавая автомати­
зированную систему учета заработной платы, вы, несомненно, захотите получить в свое
распоряжение дипломированного бухгалтера в качестве консультанта. Но поскольку
пользователями этой системы будут, вероятнее всего, не бухгалтеры, а простые кассиры,
то можно ожидать, что именно они смогут больше помочь вам при написании пользо­
вательских историй. Специалисты в предметных областях окажутся вашими идеальны­
ми помощниками при моделировании той или иной сферы деятельности и определении
бизнес-правил, но значительно больше сведений, касающихся особенностей производ­
ственного процесса и специфики использования ПО, вы сможете получить от общения
с фактическими пользователями продукта.
Сотрудничество со специалистом в предметной области в качестве представителя
пользователей чревато еще одной возможной проблемой, состоящей в том, что в резуль­
тате вы получите программное обеспечение, ориентированное лишь на пользователей
с аналогичным уровнем экспертных знаний. Специалисты склонны направлять проект
в русло решений, которые удобны для них, но слишком сложны или совершенно невер­
ны для целевой пользовательской аудитории.
Маркетинговая группа
Ларри Константайн и Люси Локвуд [21] подчеркивают, что специалисты по марке­
тингу хорошо знакомы с потребностями рынка, но не с потребностями пользователей.
Глава 5. Работа с представителями пользователей
Как следствие, маркетинговая группа или профессиональный маркетолог будут сосре­
доточиваться в основном на количестве возможностей продукта, а не на их качестве.
Во многих случаях от маркетинговой группы можно получить ценные рекомендации,
касающиеся относительных приоритетов высокоуровневых задач, но члены этой груп­
пы часто недопонимают суть проблем предметной области и не в состоянии привнести
в истории какие-либо конкретные детали.
Прежние пользователи
Прежний пользователь программного обеспечения может замечательным образом
представлять интересы пользователей, но только в том случае, если его опыт достаточ­
но свеж. В то же время, как и в случае других типов представителей пользователей, вы
должны тщательно проанализировать, совпадают ли цели и мотивация пользователя,
имеющего предыдущий опыт работы, с таковыми для реальных пользователей.
Заказчики
Заказчики (customers) — это те, кто принимает решение приобрести продукт. Они не
обязательно являются пользователями программного обеспечения. От учета пожеланий
заказчика зависит очень многое, поскольку именно он, а не пользователи, выписывает
чек на покупку ПО. (Разумеется, если только в роли пользователей и заказчиков не вы­
ступают одни и те же люди.)
В качестве превосходного примера, иллюстрирующего различия между заказчиком
и пользователем, можно привести программное обеспечение, повышающее эффектив­
ность корпоративного документооборота. Решение о том, каким текстовым процес­
сором будут пользоваться все сотрудники компании, может принимать ИТ-персонал.
В данном случае ИТ-персонал является заказчиком, а все сотрудники — пользователя­
ми (в том числе и ИТ-персонал, являющийся одновременно и заказчиком, и пользо­
вателем). Возможностей подобного продукта должно быть достаточно для того, чтобы
пользователи не выражали своего недовольства слишком громко, но эти возможности
должны соответствовать и пожеланиям заказчика, принимающего решение о покупке.
Например, средства обеспечения безопасности, как правило, не имеют особого зна­
чения для большинства пользователей программ, предназначенных для обработки до­
кументов. Однако безопасность ПО крайне важна для ИТ-персонала (заказчиков), при­
нимающего решение о приобретении продукта.
▼----------------------------------------------------------------------------- ▼
Поговорите с пользователями прежней версии продукта
В одной компании в роли представителя заказчика нового продукта, который дол­
жен был заменить собой используемый на то время продукт, основанный на бумажной
технологии, выступала группа маркетинга. Компания функционировала весьма успеш­
но, торгуя печатной продукцией в виде справочников, содержащих сводку действующих
правил, установленных по согласованию между больницами и страховыми компания­
ми. Например, операция по удалению аппендицита признавалась обязательной лишь
в том случае, если (наряду с другими факторами) содержание лейкоцитов у пациента
превышало определенное пороговое значение.
Часть I. Приступаем к работе
Маркетинговая группа не проявила никакой инициативы, чтобы встретиться с поль­
зователями прежней печатной продукции и выяснить у них, какие, по их мнению, воз­
можности должно предоставлять программное обеспечение. Члены группы посчитали,
будто они в точности знают, чего хотят их пользователи, и что разработка продукта
может происходить полностью под их руководством. Маркетинговая группа выбрала
для ПО метафору книги. Вместо того чтобы воспользоваться преимуществами свой­
ственной программному обеспечению гибкости, они остановились на варианте “авто­
матизированной книги”. Пользователей программное обеспечение разочаровало, что
и неудивительно. У компании была возможность избежать такого исхода, если бы в ка­
честве представителей пользователей выступила не маркетинговая группа, а реаль­
ные пользователи.
▲------------------------------------------------------------------------------------ ▲
Как-то я работал в составе команды, которая спроектировала приложение, требую­
щее интенсивного обмена информацией с базой данных. Информация должна была
загружаться из других систем, которыми заказчик уже располагал. Разработчикам тре­
бовалось выбрать формат файлов для обмена соответствующими записями. В данном
случае в роли заказчика выступал главный ИТ-менеджер организации, а в роли поль­
зователей — ИТ-персонал его же организации, который должен был написать програм­
му, позволяющую извлекать данные из существующих систем и переводить их в формат,
назначенный для новой системы. Когда заказчика (главного ИТ-менеджера) спросили,
какой файловый формат он предпочитает, тот решил, что идеальной технологией будет
XML, поскольку на то время эта технология была сравнительно новой и, несомненно,
казалась ему более привлекательной, чем нестандартизированные CSV-файлы с запяты­
ми в качестве разделителей. Когда программное обеспечение было поставлено заказ­
чику, оказалось, что мнение пользователей (ИТ-персонала) по поводу формата файлов
было совершенно иным — вместо XML-файлов они предпочли бы иметь дело с CSVфайлами, генерировать которые гораздо проще. Если бы команда разработчиков полу­
чила истории непосредственно от пользователей, то она знала бы об этом заранее и не
тратила времени на внедрение XML-формата.
Обучающий персонал и группа технической поддержки
Казалось бы, логично предположить, что обучающий персонал (trainers) и специали­
сты службы технической поддержки (technical support) вполне могут выступать в качестве
представителей пользователей. Дни напролет они проводят в непрерывном общении
с пользователями и поэтому, несомненно, должны знать, чего те хотят. К сожалению,
используя в качестве представителя пользователей инструктора, вы получите систему,
основным достоинством которой будет простота освоения. Точно так же, если вы ис­
пользуете в этой роли кого-то из группы технической поддержки, то основным лейт­
мотивом разработки системы станет легкость ее сопровождения. Например, специалист
из группы технической поддержки может присвоить низкий приоритет расширенным
функциональным средствам, поддержка которых, как он считает, доставит ему много
хлопот. И хотя легкость обучения пользователей работе с системой и простота ее под­
держки — достойные цели, реальные пользователи, вероятнее всего, признали бы прио­
ритетными другие свойства системы.
Глава 5. Работа с
представителями пользователей
Системные аналитики и бизнес-аналитики
Многие системные аналитики и бизнес-аналитики могут быть хорошими кандидата­
ми на роль представителей пользователей, поскольку они знакомы как с миром компью­
терных технологий, так и с предметной областью. Аналитик, способный балансировать
между этими двумя мирами и находить время для общения с реальными пользователя­
ми, может отлично представлять их интересы.
Однако на этом пути иногда могут возникать определенные трудности, поскольку
часть аналитиков предпочитает размышлять о проблеме, а не решать ее. Слишком уж
много попадалось мне аналитиков, которые считали, что они способны удобно устро­
иться в своих офисных креслах и интуитивно предугадать, чего хотят пользователи, даже
не потрудившись пообщаться с ними. Обязательно проконтролируйте, чтобы аналитик
разговаривал с пользователями и прислушивался к их мнению, а не принимал решения
по собственному усмотрению.
Еще одна проблема, с которой время от времени приходится сталкиваться при ра­
боте с аналитиками, состоит в том, что они склонны уделять слишком много времени
предпроектной деятельности. В тех случаях, когда для выяснения всех деталей, касаю­
щихся плана выпуска на четыре месяца, вполне хватило бы потратить всего два часа на
ролевое моделирование и провести совещание по написанию историй, некоторые ана­
литики растянут подготовительную деятельность недели на три.
Как организовать работу с представителями пользователей
Хотя это и не идеальный выход, все же можно создать замечательное программ­
ное обеспечение, работая не с реальными пользователями, а с их представителями.
Существует ряд приемов, к которым вполне можно прибегнуть, чтобы повысить свои
шансы на успех в подобных случаях.
Если пользователи есть, но доступ к ним ограничен
Если доступ к пользователям затруднен и вместо этого команде предлагается рабо­
тать через представителя пользователей, который будет принимать все решения по про­
екту, то с этим придется смириться, но в таком случае целесообразно установить связь
с реально работающими пользователями. Лучше всего это сделать, запросив разреше­
ние на создание специальной пользовательской группы (user task force). В эту группу может
входить произвольное число реальных пользователей — от небольшого их количества до
двух десятков человек. Любые идеи отрабатываются на этой группе, но окончательное
решение остается за представителем пользователей. В большинстве случаев представи­
тель пользователей пойдет на такой вариант развития событий, в частности, из-за того,
что такая группа создаст для него своего рода “подушку безопасности”, защищающую
его от принятия неверных решений.
Как только специальная пользовательская группа будет создана и укомплектована
реальными пользователями, ее, как правило, можно использовать для корректировки
все большего и большего количества ежедневно принимаемых решений по проекту. Это
можно сделать, проведя серию совещаний для обсуждения отдельных частей приложе­
ния и поручив специальной пользовательской группе определение, написание историй
и назначение им приоритетов.
Часть I. Приступаем к работе
Одна проектная команда, участником которой я был и которая разрабатывала систе­
му для внутренних пользователей, добилась большого успеха, получая рекомендации,
касающиеся верхнего уровня разработки, от представителя пользователей, создавая про­
тотипы для демонстрации специальной пользовательской группе, а затем действуя на
основании обратной связи с этой группой в ходе совещаний. Проект разрабатывался
с использованием итераций длительностью в один месяц. Первые пять—семь дней каж­
дой итерации уходили на создание прототипов и проведение совещаний со специальной
пользовательской группой. Благодаря этому представитель пользователей имел возмож­
ность контролировать стратегическое направление развития проекта, а управление дета­
лями реализации делегировалось специальной пользовательской группе.
Если доступ к пользователям полностью исключен
Если пользователи вообще недоступны и вы должны полагаться только на их пред­
ставителя, вам может пригодиться один ценный прием, суть которого заключается
в том, чтобы использовать нескольких представителей пользователей. Это снизит ве­
роятность построения системы, удовлетворяющей потребности только какой-то одной
определенной стороны. В подобных случаях обязательно используйте представителей
пользователей различного типа. Например, вместо того чтобы взять для этой цели двух
специалистов в предметной области, возьмите только одного и подключите к нему когонибудь из группы маркетинга. Можно работать либо с двумя специально назначенными
для этой цели представителями пользователей, либо с одним, которому разрешено при­
влекать к работе других, неформальных представителей пользователей.
В случае разработки программного обеспечения, которое будет конкурировать
с другими коммерческими продуктами, можете использовать эти продукты в качестве
образца для написания некоторых историй. О каких функциональных возможностях
конкурирующих продуктов упоминается в обзорах? Какие возможности обсуждаются
на форумах? Обсуждаются ли некоторые из возможностей с той точки зрения, что они
чрезмерно сложны в использовании?
Помню состоявшийся несколько лет тому назад спор с одним приверженцем вариан­
тов использования (use case) относительно того, какого типа документ лучше всего выра­
жает требования системы. Оппонент был ярым сторонником хорошо продуманной мо­
дели вариантов использования. Я же защищал руководства пользователей (user’s guide).
Я не видел ни одного проекта, который завершался бы идеально точной и отвечающей
текущему состоянию дел моделью вариантов использования, хотя некоторые и пытались
этого добиться. Но я видел множество проектов, которые завершались точным и соот­
ветствующим текущему состоянию продукта руководством пользователя.
Еще один прием, к которому можно прибегнуть, если приходится работать не с ре­
альными пользователями, а с их представителями, состоит в том, чтобы выпустить про­
дукт как можно скорее. Даже если выпуск будет назван предварительным или ранней
бета-версией, его быстрая передача в руки пользователей поможет выявить расхожде­
ния во взглядах на продукт между вашими реальными пользователями и теми, кто пред­
ставлял их интересы. Более того, как только программное обеспечение окажется в руках
одного или нескольких первопроходцев, это немедленно откроет коммуникационный
канал, соединяющий вас с пользователями, который вы сможете использовать для об­
суждения с ними будущих возможностей продукта.
Глава 5. Работа с представителями пользователей
Можете ли вы сделать все сами
Если вам не удается найти реального пользователя или получить доступ к нему, не
попадитесь в западню, полагая, будто мысли пользователей по поводу продукта вам
хорошо известны и поэтому в сотрудничестве с их представителями вы не нуждаетесь
в мнении пользователей или можете игнорировать его. Конечно, всем представителям
пользователей свойственно немного искажать потребности реальных пользователей, но
применительно к разработчикам эти искажения окажутся еще большими. В целом, раз­
работчики не имеют достаточных знаний в области маркетинга, которые позволили бы
им профессионально судить об относительной ценности возможностей продукта, они не
имеют столь тесного контакта с клиентами, как продавцы, они не являются специали­
стами в предметной области и т.п.
Принципы формирования команды заказчика
Прежде всего, никогда не забывайте о том, что ранг реального пользователя для вас
всегда выше ранга того, кто лишь представляет его интересы. Используйте любую воз­
можность включения реальных пользователей в команду заказчика. Но если сформи­
ровать необходимый состав команды вам не удается, дополните ее одним или несколь­
кими представителями пользователей. Команду заказчиков следует формировать таким
образом, чтобы сила одного из ее участников уравновешивала слабость другого. Процесс
создания команды заказчика разбивается на три этапа.
Во-первых, введите в команду заказчика реальных пользователей. Если для про­
граммного обеспечения предвидится несколько типов пользователей, постарайтесь, что­
бы каждый из них был представлен в команде. Так, пользователями одного из наших
приложений медицинской направленности были медсестры. В нашу команду заказчика
вошли квалифицированные медсестры, специалисты-онкологи, специалисты по лече­
нию диабета и т.д.
Во-вторых, определите в команде заказчика единоличного лидера проекта, или
“первого среди равных”. В компаниях, выпускающих коммерческое программное обе­
спечение, им очень часто бывает менеджер продукта, но на его месте может оказаться
и кто-то другой. На лидера проекта возлагается ответственность за координацию сотруд­
ничества внутри команды заказчика. В той мере, в какой это достижимо, все участники
команды несут ответственность за выработку единой позиции, и от команды должно ис­
ходить только одно согласованное мнение.
В-третьих, определите ключевые факторы успешности проекта. Они могут быть раз­
ными от проекта к проекту. Например, если целью проекта является создание нового
поколения существующего продукта, то ключевым фактором успеха будет то, насколько
легко существующим пользователям перейти на новую систему. Дополните команду за­
казчика представителями пользователей, обладающими соответствующими знаниями,
умением и опытом, чтобы обеспечить ключевые факторы успешности проекта. В на­
шем примере с переходом существующих пользователей на новую систему это могло бы
означать включение инструктора в команду заказчика.
Часть I. Приступаем к работе
Резюме
• В этой главе вы познакомились с различными типами представителей пользова­
телей и узнали, почему ни один из них не может полностью заменить собой ис­
тинного пользователя в том, что касается написания пользовательских историй.
• Менеджер пользователей не совсем подходит на роль представителя пользовате­
лей, если только он сам не является пользователем.
• Менеджеры разработчиков могут казаться хорошими кандидатами на роль пред­
ставителей пользователей, поскольку они уже вовлечены в ежедневное обсужде­
ние деталей проекта. Однако редко бывает так, чтобы менеджеры пользователей
входили в число предполагаемых пользователей разрабатываемого программного
обеспечения, и потому они плохо подходят для этой роли.
• В производственных компаниях заказчиком часто выступает один из сотрудников
группы маркетинга. Часто такого человека можно вполне успешно использовать
в качестве представителя пользователей, но для этого он должен преодолеть свой­
ственное людям этой профессии стремление обращать внимание не на качество,
а на количество.
• Продавцы могут быть хорошими представителями заказчиков, если они контак­
тируют с широким кругом клиентов, которые одновременно являются пользова­
телями. Продавцы должны удерживать себя от соблазна отдавать предпочтение
той истории, которая могла бы спасти последнюю сорвавшуюся сделку. В целом,
продавцы — это великолепный канал получения информации об ожиданиях
пользователей.
• Специалисты в предметной области могут быть отличными представителями
пользователей, но должны избегать искушения писать истории для продукта,
с которым сможет эффективно работать лишь пользователь с аналогичным уров­
нем знаний.
• Заказчики, принимающие решение о покупке, хорошо подходят на роль предста­
вителей пользователей, если они находятся в тесном контакте с теми пользовате­
лями, для которых закупается программное обеспечение. Если же заказчик одно­
временно является и пользователем, то можете считать, что вам фантастически
повезло.
• Чтобы выступать в качестве представителей пользователей, обучающий персонал
и сотрудники службы технической поддержки должны постараться шире взгля­
нуть на продукт, с которым они сталкиваются каждый день.
• В данной главе также были кратко рассмотрены методы работы с представителя­
ми пользователей, в частности, специальные пользовательские группы, назначе­
ние нескольких представителей пользователей, анализ конкурирующих продуктов
и ранний выпуск релизов, позволяющий быстрее начать получать обратную связь
от пользователей.
Глава 5. Работа с представителями пользователей
Обязанности разработчика
• Вы обязаны оказывать своей организации помощь в выборе подходящих заказчи­
ков для проекта.
• Вы обязаны понимать, как различные представители пользователей будут отно­
ситься к разрабатываемой системе и каким образом их уровень подготовки может
влиять на ваше взаимодействие с ними.
Обязанности заказчика
• Если вы не будете пользователем данного программного обеспечения, то обязаны
знать, какие типы представителей пользователей могут описывать ваше поведение.
• Вы обязаны понимать, в чем именно можете неправильно оценивать проект,
и пытаться устранить связанные с этим возможные риски, полагаясь для этого на
мнение других людей или используя какие-то другие способы.
Контрольные вопросы
5.1. Какие проблемы могут возникать в случае выбора менеджера пользователей
в качестве их представителя?
5.2. Какие проблемы могут возникать в случае выбора специалиста в предметной об­
ласти в качестве представителя пользователей?
Глава 6
Приемочное тестирование
пользовательских историй
Одна из причин для написания приемочных тестов (acceptance tests) заключается в том,
чтобы выразить в концентрированном виде множество деталей, выясненных в резуль­
тате обсуждений между заказчиками и разработчиками. Вместо того чтобы составлять
длинные списки “Система должна...” в стиле формализованных требований к проекту,
для наполнения пользовательских историй деталями используются тесты.
Тестирование лучше всего представлять в виде двухэтапного процесса. На первом
этапе на оборотной стороне карточек историй записываются примечания относительно
будущих тестов. Это можно делать в любое время, как только кому-то в голову придет
мысль о новом тесте. На втором этапе примечания о тестах превращаются в полноцен­
ные тесты, которые демонстрируют, что история написана корректно и полностью пере­
ведена в исходный код.
В качестве примера напоминаний о тестах рассмотрим историю: “Компания может
оплатить публикацию вакансии с помощью кредитной карты”, оборотная сторона кар­
точки которой может содержать следующие записи.
• Тестировать с картами Visa, MasterCard и American Express (проходит).
• Тестировать с картами Diner’s Club (не проходит).
• Тестировать с правильным, неправильным и отсутствующим подтверждающим
кодом (указывается на обратной стороне карты).
• Тестировать с просроченными платежными картами.
• Тестировать с различными суммами покупки (в том числе с превышением лимита
карты).
В этих примечаниях о тестах фиксируются предложения заказчика. Предположим,
в примере с сайтом BigMoneyJobs заказчик написал историю: “Соискатель может про­
смотреть подробное описание отдельных вакансий”. Заказчик и разработчик обсужда­
ют историю и определяют набор фактов, касающихся вакансии, которые должны будут
отображаться: название, описание, местонахождение, диапазон заработных плат, способ
подачи заявки и т.п. Однако заказчик знает, что не все компании предоставляют эту ин­
формацию в полном объеме, и рассчитывает на то, что сайт автоматически обработает
отсутствующие данные. Например, заказчик может захотеть, чтобы в тех случаях, когда
информация о зарплате не предоставляется, графа “Диапазон зарплат” вообще не ото­
бражалась на экране. Это должно найти свое отражение в соответствующем тесте, иначе
программист может предположить, что контроль за включением в каждое объявление
информации о зарплате возложен на ту часть системы, которая отвечает за публикацию
вакансий.
Часть I. Приступаем к работе
Приемочные тесты также предоставляют базовые критерии, по которым можно су­
дить, реализована ли история полностью. Наличие критериев, которые однозначно го­
ворят нам о том, что такая-то часть работы выполнена, — это наилучший способ избе­
жать нерациональных затрат времени и усилий. Например, когда моя жена печет пирог,
она втыкает в него зубочистку — это ее приемочный тест: если зубочистка выходит су­
хой, значит, пирог готов. Мой же приемочный тест — просто добраться пальцем до пи­
рога, проткнув корочку, а затем облизнуть палец.
Сначала пишутся тесты, а затем — код
Приемочные тесты предоставляют большой объем информации, которую програм­
мисты могут использовать еще до написания исходного кода истории. Рассмотрим, на­
пример, следующее напоминание о тесте: “Тестировать с различными суммами покупки
(в том числе с превышением лимита карты)”. Если записать тест еще до того, как про­
граммист приступит к написанию кода истории, то он напомнит о необходимости об­
работать ситуации, когда покупка отклоняется из-за нехватки денег на счете. Не увидев
этот тест, некоторые программисты могли бы забыть о поддержке таких ситуаций.
Разумеется, чтобы помогать программистам в этом смысле, приемочные тесты долж­
ны быть уже записаны к тому моменту, когда программист приступит к написанию кода
истории. Обычно тесты пишутся:
• всякий раз, когда заказчик и разработчики обсуждают историю и хотят зафикси­
ровать подробно выясненные детали;
• в виде отдельного задания в начале итерации, но до того, как начнется процесс
программирования;
• всякий раз, когда в процессе или по завершении написания кода истории обнару­
живаются новые тесты.
В идеальном случае в ходе обсуждения истории заказчиком и разработчиками они
отражают ее детали в виде тестов. Однако в начале итерации заказчик должен про­
смотреть все истории и записать любые дополнительные тесты, относительно которых
у него могли возникнуть идеи к тому времени. При этом неплохо заглянуть в каждую
историю и задаться примерно следующими вопросами.
• Что еще должны программисты знать об этой истории?
• Каковы мои предположения относительно того, каким образом будет реализовы­
ваться история?
• Существуют ли обстоятельства, при которых эта история может вести себя как-то
иначе?
• Что может пойти не так в этой истории?
Карточка истории 6.1 иллюстрирует пример из реального проекта, в котором созда­
валось программное обеспечение для системы сканирования документов. Автор этой
истории четко описал свои ожидания относительно того, что должно происходить (от­
сканированные страницы направляются в новый документ, даже если текущий документ
в это время открыт в программе). В данном случае ожидание описано как часть истории
на лицевой стороне карточки. Точно так же его можно было бы записать в виде теста на
Глава 6. Приемочное тестирование пользовательских историй
оборотной стороне. Самое главное, чтобы оно было отражено где-нибудь на карточке
до того, как программист начнет работать с историей. Если этого не сделать, то не ис­
ключено, что программист может написать код, соответствующий другому поведению
системы, например, такой, при котором отсканированные страницы направляются в те­
кущий документ.
Пользователь может сканировать страницы и вставлять их в новый
документ. Если документ уже открыт, приложение должно вывести
подсказку и закрыть текущий документ.
■ Карточка истории 6.1. Информация
для
программиста об ожиданиях пользователя
Тесты определяет заказчик
Поскольку программное обеспечение пишется для создания продукта, соответству­
ющего видению заказчика, приемочные тесты должны определяться заказчиком. Для
фактического создания тестов заказчик может работать с программистом или тести­
ровщиком, но, как минимум, заказчик должен определить такие тесты, которые можно
будет использовать для того, чтобы установить момент, когда история может считаться
корректно разработанной. Кроме того, команда разработчиков (особенно если в ее со­
став входят опытные тестировщики) обычно дополняет некоторые истории собственны­
ми тестами.
Тестирование — это часть процесса разработки
Недавно я работал в одной компании, в которой суждения тестировщика о про­
граммном обеспечении основывались на его общении с программистами. Обычно дело
происходило таким образом. Программисты кодировали новую функциональность,
объясняли ее тестировщику, и тот проверял, работает ли программа так, как должна ра­
ботать в соответствии с описанием. Довольно часто программа проходила тест, но как
только пользователи начинали с ней работать, оказывалось, что в ней полно ошибок.
Проблема, разумеется, заключалась в том, что тестировщик проверял лишь, сделал ли
программист то, о чем он отрапортовал. Никто так и не тестировал, делает ли программ­
ное обеспечение именно то, чего хотят заказчики или пользователи, которых к тестиро­
ванию вообще не привлекали.
В случае пользовательских историй очень важно, чтобы тестирование рассматрива­
лось как часть процесса разработки, а не как изолированный акт, который осуществля­
ется “после того, как код написан”. За определение тестов часто совместно отвечают
менеджер продукта и тестировщик. Менеджер продукта привносит свое знание органи­
зационных целей, движущих проект, а вкладом тестировщика является его скептицизм.
В начале каждой итерации они собираются вместе и определяют столько первоначаль­
ных тестов, сколько в состоянии придумать. Но этим дело не ограничивается, равно
Часть I. Приступаем к работе
как не ограничивается оно и их еженедельными встречами. По мере разработки деталей
истории определяются дополнительные тесты.
Сколько нужно тестов
Заказчик должен продолжать писать тесты до тех пор, пока они привносят в историю
ясность и дополнительные ценности. Пожалуй, нет нужды писать тест, позволяющий
удостовериться в том, что расчет по просроченной карте Visa не будет производиться,
если такой тест уже написан для просроченных карт MasterCard.
Кроме того, имейте в виду, что у хорошей команды программистов всегда будут под
рукой подходящие модульные тесты (unit tests) для многих низкоуровневых ситуаций.
Например, программисты должны иметь заранее заготовленные модульные тесты, ко­
торые корректно идентифицируют 30 февраля или 31 июня как недействительные даты.
Заказчик не несет ответственности за определение всех мыслимых тестов. Он должен
сосредоточить свои усилия на написании тестов, которые разъясняют изложенные
в истории намерения разработчикам.
Инфраструктура для интеграционного тестирования
Приемочные тесты должны демонстрировать, что приложение приемлемо для заказ­
чика, который несет ответственность за осуществление общего руководства разработкой
системы. Это означает, что заказчик и должен быть тем человеком, который выполня­
ет приемочное тестирование. Как минимум, приемочные тесты должны выполняться
в конце каждой итерации. Поскольку работоспособность кода, прошедшего тестирова­
ние на какой-то итерации, может нарушиться в процессе разработки на следующей ите­
рации, очень важно выполнять приемочные тесты всех предыдущих итераций. По воз­
можности, команда разработчиков должна искать пути автоматизации некоторых или
даже всех приемочных тестов.
Прекрасным инструментом автоматизации приемочных тестов является разработан­
ная Уордом Каннингемом инфраструктура для интеграционного тестирования (Frame­
work for Integrated Test, Fit)1. При использовании Fit тесты записываются в привычном
формате электронной таблицы. Под руководством Роберта Мартина было разработано
средство FitNesse2 — расширение Fit, которое еще больше упрощает написание тестов.
Средство FitNesse (которое использует Fit) очень быстро завоевывает популярность
в качестве инструмента для написания приемочных тестов в agile-проектах. Тесты пред­
ставляются в виде электронных таблиц на веб-страницах, что значительно облегчает
заказчикам задачу определения и записи тестов. В табл. 6.1 приведен пример таблицы,
которая может обрабатываться указанным средством. Каждая строка представляет один
набор данных. В данном случае первая строка определяет платежную карту Visa, срок
действия которой истекает в мае 2005 года и которая имеет идентификационный номер
4123456789011. В последнем столбце указано, должна ли такая карта быть признана при­
ложением как действительная3.
1 Инфраструктура FIT доступна на сайте fit.c2.com.
2 Средство FitNess доступно на сайте fitnesse. org.
3 Более подробную информацию о проверке действительности кредитных карт можно найти
на сайте http://www.beachnet.сот/~hstiles/сагdtype.html.
Глава 6. Приемочное тестирование пользовательских историй
Таблица 6.1. Тестирование действительности кредитных карт с помощью
таблицы, которая может использоваться средствами Fit и FitNesse
Тип карты
Срок действия
Номер
valid()
Visa
05/05
4123456789011
true
Visa
05/23
4123456789012349
false
MasterCard
12/04
5123456789012343
true
MasterCard
12/98
5123456789012345
false
MasterCard
12/05
42
false
American Express
4/05
341234567890127
true
Чтобы выполнить тесты, описанные в табл. 6.1, программист команды должен на­
писать код, отвечающий на простые команды Fit. Он напишет код, который будет вы­
зывать в тестируемом приложении другой код, определяющий действительность кредит­
ной карты. В то же время для написания приемочных тестов от заказчика потребуется
лишь создать простую таблицу наподобие приведенной выше, которая отображает зна­
чения данных и ожидаемые результаты.
При выполнении тестов из табл. 6.1 результаты (последний столбец в данном приме­
ре) выделяются либо зеленым (для прошедших тест), либо красным (для не прошедших
тест) цветом. Средства Fit и FitNesse значительно упрощают задачу выполнения прие­
мочных тестов для заказчика и разработчика.
Ъшы тестирования
Существует множество типов тестирования, и заказчик с командой разработчиков
должны совместно позаботиться о выборе тестов подходящего типа. Для большинства
систем тестирование историй — это, в основном, функциональное тестирование, в ходе
которого убеждаются, что приложение функционирует в соответствии с ожиданиями.
Однако существуют и другие типы тестов, возможность применения которых вы долж­
ны обязательно рассматривать. В частности, среди них можно назвать следующие.
• Тестирование интерфейса пользователя (user interface testing), в ходе которого
убеждаются, что поведение всех компонентов пользовательского интерфейса со­
ответствует ожиданиям.
• Тестирование удобства использования (usability testing), которое выполняется для
проверки того, что использование приложения не связано с какими-либо неудоб­
ствами или сложностями для пользователя.
• Тестирование производительности (performance testing), которое выполняется для
количественной оценки того, насколько эффективно приложение работает при
различных нагрузках.
• Стресс-тестирование (stress testing), при котором приложение подвергается воз­
действию пиковых нагрузок, вызываемых действиями пользователей, транзак­
циями и любыми другими факторами, приводящими к нагрузкам, значительно
превышающим ожидаемые на стадии сопровождения.
Часть I. Приступаем к работе
▼----------------------------------------------------------------------------- ▼
Цель тестирования — обнаружение ошибок, а не покрытие кода
В agile-проектах, разрабатываемых на основе историй, тестирование не превраща­
ется в партизанщину, как во многих других проектах. Здесь никто никого не ловит на
ошибках и никто никого не обвиняет в том, что ошибка смогла проникнуть незамечен­
ной в конечный продукт. Высокий дух сотрудничества, лозунг “один за всех и все за
одного’ — вот что служит тому залогом.
В agile-проектах мы выполняем тесты с целью обнаружения и устранения ошибок.
Нашей целью не должно быть 100% покрытие кода (code coverage) или тестирование
всех граничных условий. В своих усилиях по тестированию продукта мы должны руко­
водствоваться нашей интуицией, знаниями и прошлым опытом.
Тестирование должен выполнять тот, кто к этому лучше всего подготовлен. Заказчик
должен определить приемочные тесты, но делать это он должен при содействии раз­
работчиков и специально выделенных для этого тестировщиков и на основании по­
лучаемой от них информации. Например, рассмотрим тесты в табл. 6.1. Единственной
просроченной платежной картой из всех тестируемых является MasterCard. Если бы мы
стремились к полному покрытию кода, то нам, конечно же, следовало бы тестировать
и карты других типов. Но когда заказчик поговорил с разработчиками, то узнал, что
(в данном случае) все карты обрабатываются одинаковым образом и тестирования
карточки только одного типа будет вполне достаточно. Со временем, благодаря часто­
му общению и видя, какие платежные карты не проходят тест, каждый участник проекта
начинает понимать, на чем должно фокусироваться тестирование.
▲----------------------------------------------------------------------------- ▲
Резюме
• Приемочные тесты используются для выражения деталей историй, которые вы­
ясняются в процессе обсуждений, проводимых между заказчиком и разработчи­
ками.
• Приемочные тесты документируют предложения заказчика относительно исто­
рий, которые он не успел обсудить с разработчиками.
• Приемочные тесты обеспечивают базовые критерии, которые можно использо­
вать для установления того факта, что история полностью завершена.
• Приемочные тесты должны писать заказчики, а не разработчики.
• Процесс написания тестов следует прекращать лишь тогда, когда очередные те­
сты уже не в состоянии дать ничего нового в отношении дальнейшего проясне­
ния деталей или назначения истории.
• Великолепными инструментами для написания приемочных тестов в привычном
формате электронных или обычных таблиц являются средства Fit и FitNesse.
Обязанности разработчика
• Вы можете брать на себя ответственность за автоматизацию выполнения прие­
мочных тестов, если команда согласна на это.
Глава 6. Приемочное тестирование пользовательских историй
• Вы обязаны продумывать дополнительные приемочные тесты, когда начинается
разработка новой истории.
• Вы ответственны за модульное тестирование вашего кода, чтобы исключить не­
обходимость в написании приемочных тестов для мельчайших деталей истории.
Обязанности заказчика
• Вы ответственны за написание приемочных тестов.
• Вы ответственны за выполнение приемочных тестов.
Контрольные вопросы
6.1. Кто определяет тесты? Кто ему в этом помогает?
6.2. Почему необходимо определять тесты еще до написания кода истории?
Глава 7
Советы по написанию хороших
историй
Сейчас, когда у вас уже имеется достаточно хорошее начальное представление о том, что
такое пользовательские истории, как их собирать и писать, как определять ключевые
пользовательские роли и какова роль приемочного тестирования, мы обратимся к рас­
смотрению некоторых дополнительных рекомендаций по написанию хороших пользо­
вательских историй.
Начинайте с целевых историй
В больших проектах, особенно тех, в которых имеется много пользовательских ро­
лей, иногда даже трудно решить, с чего начать определение историй. Я пришел к вы­
воду, что лучше всего рассмотреть каждую роль и определить цели, которые преследу­
ет пользователь, взаимодействуя с программным обеспечением. Обратимся, например,
к роли Соискатель в проекте BigMoneyJobs. Фактически главная цель у соискателя
одна — найти работу. Но в своем рассмотрении мы можем исходить из того, что эта цель
включает в себя ряд подчиненных целей:
• осуществлять поиск работы, представляющей интерес для соискателя (критериями
поиска служат квалификация, уровень зарплаты, местонахождение работы и т.д.);
• автоматизировать процесс поиска таким образом, чтобы соискатель не осущест­
влял поиск каждый раз вручную;
• сделать резюме соискателя доступным, чтобы компании могли осуществлять его
поиск;
• обеспечить простой способ подачи соискателем заявки относительно заинтересо­
вавшей его вакансии.
Эти цели, которые в действительности уже сами по себе являются высокоуровневы­
ми историями, впоследствии можно использовать для создания дополнительных исто­
рий по мере необходимости.
Разрежьте пирог
Если история получается слишком большой, обычно существует много способов раз­
бить ее на меньшие части. Первое, что приходит на ум многим разработчикам, — это
выполнить такое разбиение, исходя из соображений технического характера. Например,
предположим, что команда рассмотрела историю “Соискатель может поместить резюме
Часть I. Приступаем к работе
на веб-сайте” и пришла к выводу, что эта история слишком велика, чтобы ее можно
было поместить в текущую итерацию. Разработчики решили разбить ее на две меньшие,
ориентируясь на техническую специфику результирующих историй, как показано ниже.
• Соискатель может ввести данные в форму резюме.
• Информация из формы резюме записывается в базу данных.
В этом случае одна история будет реализовываться в текущей итерации, тогда как другая
будет отложена до (предположительно) следующей итерации. Проблема в том, что пользо­
вателям обе эти истории мало что дают. В первой из них говорится о том, что соискатели
могут заполнять форму, но данные не сохраняются. Такая операция не только бесполезна
для пользователя, но и приведет к напрасным тратам его времени. Вторая история гласит,
что данные, извлекаемые из формы, будут записываться в базу данных. Без истории, опи­
сывающей предоставление формы пользователям, от второй истории нет никакого проку.
Взамен этого гораздо лучше написать другие истории, каждая из которых обеспечи­
вает определенный уровень сквозной функциональности. Билл Уэйк [54] называет это
разрезанием пирога (“slicing the cake”). Любая история должна содержать хоть немного
от каждого уровня. Например, историю “Соискатель может поместить резюме на веб­
сайте” можно было бы разбить следующим образом.
• Соискатель может отправить резюме, содержащее лишь основную информацию,
например имя, адрес, сведения об образовании.
• Соискатель может отправить резюме, содержащее всю информацию, которая мо­
жет заинтересовать работодателя.
Предпочтение следует отдавать тем историям, которые представляют собой “целый
кусок пирога”. На то есть две причины. Во-первых, использование всех уровней архи­
тектуры приложения снижает риск того, что в самый последний момент с одним из них
возникнут проблемы. Во-вторых, приложение, хотя оно еще далеко не идеально, может
быть сразу же сдано в эксплуатацию, пусть даже с частично реализованной функцио­
нальностью, коль скоро функциональность, включенная в выпуск, пронизывает (“раз­
резает”) всю систему.
Пишите законченные истории
В своем собрании методов подготовки требований Сорен Лауэсен [40] вводит поня­
тие замыкания задач (closure for tasks). Его идеи в равной степени могут быть применены
к пользовательским историям. Законченная история (closed story) — это та, окончание ко­
торой знаменуется достижением какой-нибудь содержательной цели и которая дает поль­
зователю возможность почувствовать, что он получает некий законченный результат.
Например, предположим, что проект веб-сайта BigMoneyJobs включает в себя исто­
рию “Рекрутер может управлять объявлениями, которые он опубликовал”. Эта исто­
рия не является законченной. Управление объявлениями вообще нельзя рассматривать
как нечто, что может быть полностью выполнено. Оно представляет собой непрерывно
продолжающийся вид деятельности. Данную историю лучше переписать, представив ее
в виде набора законченных историй, например, как показано ниже.
• Рекрутер может просмотреть резюме заявителей, ответивших на одно из его
объявлений.
Глава 7. Советы
по написанию хороших историй
• Рекрутер может изменить срок действия объявления.
• Рекрутер может удалить заявку, не соответствующую вакансии и т.д.
Каждая из этих законченных историй — это часть первоначальной истории, кото­
рая сама была незаконченной. После выполнения одной из этих законченных историй
пользователь, несомненно, почувствует, что достиг определенной цели. Не забывайте
также о том, что истории должны быть достаточно небольшими, чтобы их можно было,
с одной стороны, оценить, а с другой — заключить в одну итерацию. В то же время раз­
мер историй должен быть достаточно большим, чтобы избежать преждевременной фик­
сации связанных с ними деталей.
Используйте карточки ограничений
Ньюкерк и Мартин [42] рекомендуют один прием, который я считаю полезным. Они
рекомендуют использовать карточки историй с пометкой “Ограничение” (“Constraint”)
в тех случаях, когда требуется не непосредственная реализация истории, а соблюдение
описанных в ней условий. В качестве примера рассмотрим карточку истории 7.1.
■ Карточка истории 7.1. Пример карточки истории с ограничением
В качестве других примеров ограничений можно привести следующие.
• Не препятствовать возможной локализации программы, что может потребоваться
в дальнейшем.
• Новая система должна использовать существующую базу данных заказов.
• Программное обеспечение должно выполняться во всех версиях Windows.
• Показатель времени безотказной работы системы должен достигнуть значения 99,999 %.
• Программа должна быть простой в использовании.
Несмотря на то что карточки ограничений не оцениваются и не включаются в пла­
нирование итераций, как обычные карточки, они приносят пользу. Самое первое, что
можно сделать с такой карточкой, — это прикрепить ее к стене клейкой лентой, чтобы
она служила для всех напоминанием. Еще лучше — написать приемочные тесты, позво­
ляющие быть уверенным в том, что указанные в карточке ограничений условия выдер­
живаются. Например, нетрудно написать тест для карточки истории 7.1. Будет идеально,
если команда напишет этот тест во время одной из первых итераций, когда шансы того,
что это условие не будет соблюдено, невелики. После этого команда должна продолжать
выполнять данный тест в качестве составной части каждой последующей итерации. При
любой удобной возможности (а они, как правило, всегда существуют) пишите автомати­
зированные тесты, подтверждающие соблюдение ограничений.
V
Часть I. Приступаем к работе
Более подробно по поводу ограничений как способа спецификации нефункциональ­
ных требований говорится в главе 16.
Растяните историю до масштабов горизонта
Вы должны концентрироваться на тех областях, где это необходимо. Обычно это
означает, что больше внимания следует уделять тому, что ожидается в ближайшем буду­
щем, а не тому, что может произойти намного позже. В случае пользовательских исто­
рий вы реализуете это путем написания историй, относящихся к различным уровням
проекта, ориентируясь на горизонты реализации историй. Это, например, может озна­
чать, что размер историй для нескольких следующих итераций должен быть таким, что­
бы их можно было запланировать для этих итераций, тогда как истории, относящиеся
к более удаленным промежуткам времени, должны быть намного больше по размеру
и менее точными. Предположим, что на самом верхнем уровне мы определили, что веб­
сайт BigMoneyJobs должен включать следующие четыре истории.
• Соискатель может поместить свое резюме на веб-сайте.
• Соискатель может осуществить поиск вакансий.
• Рекрутер может опубликовать вакансию.
• Рекрутер может осуществить поиск резюме.
Заказчик решил, что на первых итерациях надо сосредоточиться на том, чтобы дать
пользователям возможность размещать на сайте свои резюме. Лишь только после того,
как будет добавлена достаточно большая часть функциональности, реализующей раз­
мещение резюме, можно будет переключиться на задачи поиска вакансий, публика­
ции объявлений об открывшихся вакансиях и поиска резюме. Это означает, что пред­
метом первого диалога между командой разработчиков и заказчиком будет история
“Соискатель может поместить резюме на веб-сайте”. Эта история будет расширяться по
мере выявления деталей в обсуждениях; остальные три высокоуровневые истории оста­
ются пока нетронутыми. Ниже приведен возможный результирующий список историй.
• Соискатель может добавить на сайт новое резюме.
• Соискатель может изменить резюме, уже помещенное на веб-сайте.
• Соискатель может удалить свое резюме с сайта.
• Соискатель может пометить свое резюме как неактуальное.
• Соискатель может пометить свое резюме как подлежащее сокрытию от опреде­
ленных работодателей.
• Соискатель может выяснить, сколько раз просматривалось его резюме.
• ...и далее все, что относится к размещению резюме...
• Соискатель может осуществить поиск вакансий.
• Рекрутер может опубликовать вакансию.
• Рекрутер может осуществить поиск резюме.
При написании историй пользуйтесь преимуществами гибкости историй, позволяю­
щей им приносить пользу на разных уровнях.
Глава 7. Советы
по написанию хороших историй
Не беритесь за пользовательский
интерфейс как можно дольше
Практически все подходы, применяемые при разработке требований к программно­
му обеспечению, имеют одну и ту же проблему — смешивание требований со специфи­
кациями решений. Здесь имеется в виду, что сама формулировка требования может яв­
ным или неявным образом навязывать и характер соответствующего решения. Особенно
это касается интерфейса пользователя. Старайтесь откладывать рассмотрение пользова­
тельского интерфейса в настолько долгий ящик, насколько это возможно. Обратимся,
например, к карточке истории 7.2, представляющей историю из реальной системы. Если
эта история подлежит разработке на самых ранних стадиях жизненного цикла проек­
та, то в ней содержится слишком много деталей, касающихся интерфейса пользовате­
ля. Читателям этой истории рассказывают о диалоговом окне вывода на печать, списках
принтеров и по крайней мере о четырех способах осуществления поиска.
Диалоговое окно вывода иа печать позволяет пользователю изменить
список принтеров.Пользователь может добавить или удалить принтеры
из списка.Пользователь может добавить принтер средствами
автопоиска или вручную путем указания ero DNS-имени или IP-адреса.
Средства расширенного поиска дополнительно позволяют
пользователю ограничить поиск указанным диапазоном IP-адресов и
подсетей.
■ Карточка истории 7.2. Карточка, содержащая излишне детализированное описание интер­
фейса пользователя
В конечном счете, описание деталей пользовательского интерфейса все равно про­
никнет в истории. Это будет происходить, когда программное обеспечение будет все
больше приближаться к завершающей стадии и описания историй, ранее целиком от­
носящиеся к новой функциональности, будут смещаться в сторону модификаций или
расширений существующей функциональности.
Рассмотрим, например, историю “Пользователь может выбрать дату из виджета ка­
лендаря, который отображается на экране поиска”. Данная история может представлять
трехдневный рабочий цикл, независимо от того, выполняется она в начале или конце
проекта. Однако это не та история, которую следовало бы ожидать в начале проекта,
когда к рассмотрению интерфейса пользователя еще даже не приступали.
Не все должно описываться историями
В то время как пользовательские истории обеспечивают очень гибкий формат, который
хорошо приспособлен для описания значительной части функциональности многих систем,
они не обладают универсальной применимостью. Если у вас возникает необходимость вы-
V
Часть I. Приступаем к работе
разить некоторые требования в другой форме, смело делайте это. Например, рекомендации
по созданию интерфейса пользователя часто описываются в документах, содержащих мно­
жество экранных снимков. Точно так же, независимо от наличия каких бы то ни было исто­
рий, может оказаться целесообразным задокументировать и согласовать интерфейс между
важными системами, особенно если одна из них разрабатывается внешним поставщиком.
Если вы приходите к выводу, что некоторые аспекты системы только выиграют от их
представления в другом формате, обязательно используйте эту возможность.
Включайте пользовательские роли в истории
Если команда, разрабатывающая проект, определила пользовательские роли, то их сле­
дует использовать при написании историй. Поэтому, например, история “Пользователь
может поместить свое резюме на веб-сайте” должна быть записана в виде “Соискатель
может поместить свое резюме на веб-сайте”. Различие незначительно, но написание исто­
рий в таком стиле выдвинет пользователя на первый план в представлении разработчика.
Вместо того чтобы держать в голове образ ничем не выделяющихся, безликих, равноцен­
ных пользователей, разработчик подумает о реальном, осязаемом пользователе, потребно­
сти которого в необходимом программном обеспечении он должен удовлетворить.
Компания Connextra, один из первых последователей методологии экстремально­
го программирования, внедряла роли в свои истории с помощью короткого шаблона.
Каждая история писалась в следующем формате.
“Мне как (роль) требуется средство (функция), которое (бизнес-ценность)”
Можете поэкспериментировать с этим или другим шаблоном, созданным по своему
усмотрению. Шаблоны наподобие этого помогут вам отделить зерна от плевел — отли­
чить важные истории от второстепенных.
Формулируйте историю для пользователя
в единственном числе
Как правило, история легче читается, если в ней фигурирует один пользователь.
Для многих историй несущественно, в каком числе упоминаются в них пользователи —
единственном или множественном. Но возможны истории, в которых это различие об­
ретает смысл. Например, рассмотрим историю “Соискатели могут удалять резюме с сай­
та”. Это может быть истолковано так, будто любой Соискатель может удалять не только
собственные резюме, но и, возможно, резюме других пользователей.
Обычно проблемы такого типа исчезают сами собой, как только вы начинаете ду­
мать об истории, подразумевая единственного пользователя. Например, приведенную
выше историю можно было бы переписать в виде “Соискатель может удалить резюме”.
Однако в такой форме проблема удаления соискателем резюме других соискателей ста­
новится еще более очевидной, и поэтому данную историю можно улучшить, записав ее
как “Соискатель может удалить собственные резюме”.
Глава 7. Советы по написанию хороших историй
Используйте действительный залог в предложениях
Пользовательские истории гораздо легче читать и воспринимать, если они написа­
ны с использованием действительного залога. Например, вместо того чтобы сказать:
“Резюме может быть помещено на веб-сайте соискателем”, употребите следующую фор­
мулировку: “Соискатель может поместить резюме на веб-сайте”.
Истории пишет заказчик
В идеальном случае истории должен писать заказчик. Во многих проектах разработ­
чики выручают заказчика, записывая вместо него начальные истории во время проведе­
ния первого совещания или предлагая ему новые истории. Но ответственность за напи­
сание историй лежит на заказчике и не может переноситься на разработчиков.
Кроме того, поскольку ответственным за установление приоритетов историй, пере­
даваемых в каждую итерацию, является заказчик, очень важно, чтобы он понимал суть
каждой истории. Наилучший способ добиться этого — браться самому за их написание.
Не нумеруйте карточки историй
Когда мы впервые начинаем пользоваться карточками историй, у многих из нас воз­
никает желание проставить на них номера. Обычно это объясняется тем, что это облегчает
отслеживание отдельных карточек или позволяет ввести некий дополнительный уровень
трассировки историй. Например, если выясняется, что история на карточке 13 слишком
велика, мы разрываем карточку 13 и заменяем ее карточками 13.1, 13.2 и 13.3. Однако ну­
мерация историй неоправданно перегружает процесс лишними действиями и заставляет
нас обсуждать некоторые абстрактные сущности, а не вполне осязаемые вещи. Я бы, на­
пример, предпочел говорить об “истории для добавления групп пользователей”, нежели
об “истории 13”. А о перспективе обсуждения “истории 13.1” я лучше вообще промолчу.
Если уж вам так хочется пронумеровать карточки, попробуйте вместо этого снабдить
карточки коротким названием и используйте его в качестве ярлыка для остальной части
текста.
Не упускайте из виду цель
Помните о том, что основное назначение карточки истории — служить напоминани­
ем о необходимости обсудить какую-то функциональность. Такие напоминания должны
быть короткими. Добавляйте детали, необходимые для того, чтобы впоследствии вспом­
нить, с чего должна бьггь возобновлена дискуссия, но не заменяйте обсуждение включе­
нием большего количества деталей в карточку истории.
Резюме
• Приступая к написанию историй, начинайте с рассмотрения целей каждой поль­
зовательской роли в использовании системы?
Часть I. Приступаем к работе
• Разбивая историю, постарайтесь сделать это так, чтобы результирующие истории
пронизывали все уровни приложения.
• Пишите истории такого размера, чтобы по завершении истории пользователь мог
с чувством полного удовлетворения устроить себе небольшой перерыв и выпить
чашечку кофе.
• Дополняйте истории другими методами сбора или документирования требований
в соответствии с нуждами предметной области и среды проекта.
• Создавайте карточки с ограничениями и либо закрепляйте их на стене для обще­
го обозрения, либо пишите тесты, гарантирующие соблюдение этих ограничений.
• Пишите небольшие истории для функциональности, которую команда сможет
быстро реализовать в короткое время, и более широкоплановые, высокоуровне­
вые истории для функциональности, которая должна быть дополнительно реали­
зована в будущем.
• Не касайтесь пользовательского интерфейса в историях как можно дольше.
• Если это практически целесообразно, включайте пользовательскую роль в историю.
• Формулируйте предложения в историях с использованием действительного зало­
га. Например, вместо “Резюме может быть помещено соискателем на веб-сайте”
запишите “Соискатель может поместить резюме на веб-сайте”.
• Пишите истории, ссылаясь на пользователя в единственном числе. Например,
вместо “Соискатели могут удалять резюме” запишите “Соискатель может удалить
собственные резюме”.
• Пусть заказчик, а не разработчик пишет историю.
• Не нумеруйте карточки историй.
Контрольные вопросы
7.1. Предположим, что история “Соискатель может осуществить поиск вакансий”
слишком велика, чтобы ее можно было поместить в одну итерацию. Как бы вы
разбили ее?
7.2. Какая из приведенных ниже историй имеет подходящий размер и может счи­
таться законченной?
A. Пользователь может сохранить предпочтительный набор конфигурацион­
ных параметров.
Б. Пользователь может изменить данные кредитной карты, используемой по
умолчанию для оплаты покупок.
B. Пользователь может регистрироваться в системе.
7.3. Внесением каких небольших изменений можно улучшить историю
“Пользователи могут размещать свои резюме на сайте”?
7.4. Как бы вы тестировали ограничение “Программа должна быть проста в исполь­
зовании”?
ЧАСТЬ II
Оценка
и планирование
Теперь, когда вы уже хорошо знаете, что такое пользовательские истории, пора позна­
комиться с тем, как их используют при оценке и планировании проектов. Почти во всех
случаях, то ли мы хотим этого сами, то ли нас просят об этом, требуется каким-то об­
разом оценить, сколько времени займет работа над проектом. От этого зависит, когда
начинать маркетинговую компанию, приступать к подготовке пользователей, закупать
необходимое оборудование и т.п. Каждый из этих видов деятельности привязывается
к планам проекта.
В части II будет показано, как оценивать пользовательские истории и как плани­
ровать выпуски высокоприоритетных историй. Далее вы увидите, как уточнять планы
выпусков, дополняя их деталями в начале каждой итерации, и поймете, почему выпол­
нение работ, относящихся к данной итерации, нуждается в дополнительном планирова­
нии. Наконец, будут продемонстрированы способы измерения и контроля хода выпол­
нения запланированных работ, что позволяет постоянно корректировать план с учетом
опыта, приобретаемого с каждой очередной итерацией.
Глава 8
Оценка пользовательских
историй
Стоит только приступить к работе над проектом, как вас уже начинают спрашивать:
“Когда вы закончите?” Наилучшим подходом к оценке трудоемкости историй может
считаться тот, который:
• позволяет изменять первоначальные намерения всякий раз, когда появляется но­
вая информация об истории;
• применим как к эпическим, так и к небольшим историям;
• не требует больших затрат времени;
• предоставляет полезную информацию о достигнутом прогрессе и объеме работ,
которые еще предстоит выполнить;
• применим даже с учетом того, что получаемые оценки могут быть неточными;
• может применяться для планирования выпусков.
Баллы историй
Всем перечисленным выше критериям отвечает подход, основанный на использова­
нии баллов историй (story points) в качестве меры оценки сложности историй. Удиви­
тельным свойством этой условной единицы является то, что каждая команда определяет
ее произвольно в соответствии со своим видением. Одни могут понимать под баллом
истории идеальный рабочий день (т.е. рабочий день, на протяжении которого разработчи­
ка ничто не отвлекает — никаких собраний, электронной почты, телефонных звонков
и т.п.). Другие могут определить этот балл как идеальную рабочую неделю. Некоторые
предпочитают рассматривать эти баллы как меру сложности истории. Учитывая широ­
кое разнообразие смыслов, приписываемых баллам историй, Джошуа Кериевски пред­
ложил считать их плавающими единицами времени (Nebulous Units of lime, NUT)1.
Я приверженец того, чтобы соотносить баллы историй с идеальными рабочими дня­
ми. В реальной жизни такие дни, когда все рабочее время уходит на выполнение основ­
ной работы, выпадают очень редко, но оценка трудозатрат в терминах идеальных дней
обладает двумя преимуществами. Во-первых, это проще, чем пытаться оценивать факти­
ческую продолжительность работ (elapsed time). Оценка общих затрат времени вынуждает
нас учитывать все факторы, которые могут на это влиять, например не забыть об общем
собрании коллектива компании во вторник, сходить к стоматологу в среду, отвести
несколько часов в день на работу с электронной почтой и т.п. Во-вторых, выражение
1 http://tech.groups.yahoo.com/group/extremeprogramming/message/77121.
Часть II. Оценка и планирование
баллов историй в единицах идеального времени делает наши оценки более обоснован­
ными, чем в случае использования NUT. Но поскольку одна из основных целей оцен­
ки — дать возможность прогнозировать общие затраты времени в процессе выполнения
проекта, в конечном счете мы должны преобразовать наши оценки в единицы реального
времени. С использованием единиц идеального времени выполнить такое преобразование
гораздо проще, чем с использованием совершенно неопределенных плавающих единиц.
Выполняйте оценку всей командой
Оценки историй принадлежат всей команде. Позже, в главе 10, будет показано, что
каждая история состоит из задач и что оценка отдельной задачи принадлежит тому че­
ловеку, который будет ее выполнять. Оценки историй должны принадлежать команде
в целом по двум причинам. Во-первых, поскольку заранее не известно, кто именно из
коллектива разработчиков будет работать с данной историей, то можно считать, что она
принадлежит всей команде. Во-вторых, оценки, даваемые командой, а не отдельным че­
ловеком, окажутся, вероятнее всего, более полезными.
Поскольку оценки историй принадлежат коллективу в целом, важно, чтобы в са­
мом процессе оценки участвовала значительная часть команды. Если команда довольно
многочисленна (возможно, семь или более человек), то в этом могут принимать участие
не все разработчики, но обычно чем больше разработчиков вовлечено в этот процесс,
тем лучше. Заказчик присутствует при обсуждении программистами оценок, но не имеет
права лично оценивать истории или корректировать оценки, с которыми он не согласен.
Процесс оценки
Я предпочитаю подход, который основывается на методике Wideband Delphi, пред­
ложенной Бемом [9]. Точно так же, как экстремальное программирование — это итера­
тивный подход к разработке программного обеспечения, используемый нами процесс —
это итеративный подход к получению оценок. Вот как он работает.
Прежде всего, организуйте встречу заказчика с разработчиками, участвующи­
ми в создании оценок. Возьмите с собой карточки историй и стопку пустых карточек.
(Запаситесь пустыми бумажными карточками, даже если описания историй хранятся
в электронном виде.) Раздайте каждому участнику по нескольку пустых карточек. Разра­
ботчики задают заказчику любые необходимые с их точки зрения вопросы, а заказчик
дает на них ответы в пределах своей компетенции. В случае затруднений с ответом за­
казчик может выдвинуть некоторые предположения или попросить команду отложить
оценку данной истории.
▼------------------------------------------------------------------------------▼
Любое дело занимает четыре часа
Героями одного моего любимого телевизионного шоу была молодая семейная пара
из Нью-Йорка. В одном из эпизодов жена пытается уговорить мужа выбраться в ма­
газин для покупки дивана. Она уговаривает его, что на это у них уйдет не более часа,
на что муж отвечает ей: “В этом мире на любое дело уходит четыре часа. Надо куда-то
пойти, что-то сделать, перекусить, поговорить о том, о сем, вернуться домой — четыре
часа, как минимум!"
Глава 8. Оценка пользовательских историй
Когда программисты оценивают историю, они должны принять во внимание аб­
солютно все, что им может потребоваться для ее полной разработки. Должны учи­
тываться такие вещи, как тестирование кода, переговоры с заказчиком, вероятное
оказание помощи заказчику в планировании или автоматизации приемочных тестов
и т.п. Игнорирование этих факторов равносильно надеждам на то, что покупка дивана
займет не более часа.
▲----------------------------------------------------------------------------- ▲
Когда все вопросы, касающиеся пользовательской истории, исчерпаны, каждый раз­
работчик записывает свою оценку на карточке, никому пока не показывая ее. Если ко­
манда договорилась считать баллом истории идеальный рабочий день, то разработчики
присваивают оценку исходя из того, сколько идеальных рабочих дней, по их мнению,
потребуется для реализации данной истории. Если же команда договорилась считать
баллы мерой сложности историй, то оценка должна отражать восприятие степени слож­
ности истории программистами.
Когда все участники запишут свои оценки, карточки переворачиваются или дер­
жатся так, чтобы оценки были видны каждому. Весьма вероятно, что оценки, данные
разными участниками на этой стадии, будут значительно различаться между собой. На
самом деле это будет хорошей новостью. В подобных ситуациях участники, давшие ми­
нимальную и максимальную оценку, объясняют свое решение. Очень важно, что это не
связано ни с какими упреками. Скорее, это диктуется желанием узнать, какими сооб­
ражениями они руководствовались в своем выборе.
Тот разработчик, который дал высокую оценку истории, мог, например, сказать:
“Видите ли, для тестирования истории нам надо будет создать объект фиктивной базы
данных, на что может уйти один день. Кроме того, я не уверен, что наш стандартный ал­
горитм сжатия будет хорошо работать, и нам, возможно, придется написать другой алго­
ритм с более эффективным использованием памяти”. Разработчик же, давший низкую
оценку, мог аргументировать свое решение таким образом: “Я полагаю, что нам лучше
сохранять эти данные в XML-файле — это значительно проще, чем использовать базу
данных. Кроме того, я не учитывал, что объем данных может оказаться большим, чем
мы предполагаем. Не исключено, что впоследствии нам придется решать эту проблему”.
Группа должна потратить несколько минут на обсуждение сложившейся ситуации.
Несомненно, у других участников может быть свое мнение относительно того, почему
предыдущие два участника дали столь разные оценки. Заказчик выясняет все неясности
по ходу обсуждения. На карточке истории может быть записано одно-два примечания.
Не исключено также, что появится пара новых историй.
После того как группа завершит обсуждение истории, разработчики вновь записыва­
ют свои оценки на карточках. Пересмотренные оценки опять выставляются для всеоб­
щего обозрения. Во многих случаях после второго круга оценки сблизятся. Если этого
не произойдет, процесс повторяется, и те, кто дал крайние оценки, дают свои поясне­
ния, как и на первом круге. Любопытно отметить, что мне встречались случаи, когда
те, кто давали самую низкую и самую высокую оценки, меняли свое мнение на прямо
противоположное, узнав в ходе обсуждения нечто новое для себя.
Цель состоит в том, чтобы все сошлись на единой оценке, которую можно будет ис­
пользовать по отношению к данной истории. В подавляющем большинстве случаев для
этого потребуется не более трех кругов обсуждения, но процесс следует повторять, пока
оценки продолжают изменяться, приближаясь друг к другу. Для окончания процесса во­
все не требуется, чтобы все записанные на карточках оценки совпадали между собой.
Если я приглашен участвовать в процессе и после второго круга вижу, что четыре оцен-
Часть II. Оценка и планирование
щика дали такие результаты: 4, 4, 4 и 3 балла, то я спрошу четвертого оценщика, со­
гласится ли он с тем, что историю следует оценить в 4 балла. Всем правит разум, а не
стремление к абсолютной точности. Да, возможно, потратив на обсуждение еще некото­
рое время, разработчики пришли бы к тому, что у каждого на карточке красовалась одна
и та же цифра, но вряд ли на это стоило бы тратить дополнительное время.
Триангуляция
После того как сделана оценка нескольких первых историй, можно (и нужно) три­
ангулировать оценки. Триангуляцией оценок называют процесс получения оценки исто­
рии путем соотнесения ее с одной или несколькими другими историями. Предположим,
одна история оценена в четыре балла, а другая — в два балла. Когда обе истории рассма­
триваются вместе, программисты должны сойтись на том, что размер четырехбалльной
истории в два раза превышает размер двухбалльной. Если затем некоторая история оце­
нивается в три балла, то программисты должны согласиться, что она несколько больше
двухбалльной истории, но все же меньше четырехбалльной.
Ни одна из этих оценок не является точной, но триангуляция служит эффектив­
ным средством проверки, помогающим команде убедиться во взаимной согласованно­
сти оценок различных историй. Триангуляцию удобно выполнять, приколов карточки
историй к стене в определенном порядке в соответствии с размерами историй. Для этого
проведите на стене вертикальные линии, проставьте в заголовках образовавшихся столб­
цов таблицы количество баллов историй и приколите карточки в соответствующих ме­
стах, как показано на рис. 8.1. Как только история получает оценку, приколите ее в со­
ответствующем месте. Уже на самых ранних стадиях этого процесса сравнивайте вновь
оцененные истории с другими историями в данном столбце, чтобы проверить, являются
ли их оценки “примерно одинаковыми”.
■ Рис. 8.1. Чтобы облегчить процесс триангуляции, приколите карточки историй к стене
Использование баллов историй
В конце каждой итерации команда подсчитывает, какой объем работ в баллах она
выполнила. Полученные данные используются для того, чтобы спрогнозировать объем
Глава 8. Оценка пользовательских историй
работ, который можно будет выполнить на протяжении предстоящей итерации той же
длительности. Пусть, например, в течение двухнедельной итерации команда выполнила
объем работ на 32 балла. Разумнее всего предположить, что объем работ, который ко­
манда сможет выполнить в течение следующей итерации, также будет соответствовать
32 баллам. Количество баллов, характеризующих объем работ, который команда выпол­
няет (или рассчитывает выполнить) на протяжении одной итерации и который позволяет
судить о производительности команды, называется скоростью или темпом разработки.
Давайте посмотрим, как скорость и баллы историй работают вместе и почему точ­
ность их определения особого значения для нас не имеет. Предположим, команда при­
ступает к новому проекту. Участники оценивают все истории, входящие в проект, и по­
лучают для них суммарную оценку 300 баллов. Прежде чем начать первую итерацию,
команда примерно просчитывает, что в течение недели их коллектив сможет выполнить
объем работ, эквивалентный тридцати баллам, откуда следует, что на весь проект им по­
требуется десять итераций (недель).
В конце первой итерации команда складывает баллы историй, реализованных в те­
чение первой итерации. Выясняется, что вместо ожидаемых 30 баллов они выполнили
работ на 50 баллов. Если команда будет выдерживать такой же темп для каждой после­
дующей итерации, то проект можно будет выполнить всего за шесть итераций. Должны
ли участники проекта планировать сохранение скорости равной 50 баллам? Да, должны,
но при соблюдении трех условий.
Во-первых, на производительность данной итерации не должны были повлиять
какие-то особые факторы (например, переработка по времени, подключение допол­
нительного программиста или что-нибудь еще в этом роде). Влияние таких факторов
на скорость разработки совершенно очевидно. Если высокая скорость итерации была
обусловлена тем, что рабочая неделя каждого разработчика составила шестьдесят четыре
часа, то она значительно снизится, если на следующей итерации все вернутся к 40-часо­
вой рабочей неделе.
Во-вторых, подход к оценке всех историй должен быть однотипным. Данный фактор
имеет большое значение в силу того, что это сглаживает флуктуации скорости при перехо­
де от одной итерации к другой. Предположим, что какая-то итерация сплошь состоит из
историй, которые оценивались участником с явной склонностью к переоценке. Скорость
работы команды на этой итерации окажется искусственно завышенной, если оценщик
историй, включенных в следующую итерацию, обладал прямо противоположными на­
клонностями. Лучший способ добиться того, чтобы все оценки назначались согласован­
ным образом, — это оценивать истории всей командой, о чем уже говорилось ранее.
Наконец, истории, выбранные для первой итерации, должны быть независимыми.
Это условие будет соблюдаться, если истории пишутся так, как рекомендовалось в гла­
ве 2. Рассмотрим итерацию, полностью состоящую из неудачных историй, написанных
так, что на протяжении всей итерации разрабатывался пользовательский интерфейс.
Скорость данной итерации не стоит экстраполировать на оставшиеся итерации.
▼------------------------------------------------------------------------------▼
Почему это работает
Согласно центральной предельной теореме теории вероятностей, сумма достаточ­
но большого количества независимых, одинаково распределенных случайных величин
приблизительно описывается законом нормального распределения.
Часть II. Оценка и планирование
В нашей ситуации это означает, что оценки историй в баллах, данные командой, мо­
гут быть смещены в сторону недооценки, переоценки или вообще распределены какимто другим образом. Но когда мы будем выбирать из любого этого распределения исто­
рии для заполнения итерации, они окажутся распределенными по нормальному закону.
Это означает, что скорость, измеренную для одной итерации, можно использовать для
предсказания значений скорости на будущих итерациях.
Разумеется, скорость одной итерации не может служить идеальным прогностиче­
ским показателем. Например, использовать для прогнозов итерацию, содержащую
одну историю с оценкой в 20 баллов, менее надежно, чем итерацию, состоящую из
двадцати историй, каждая из которых оценена в один балл. Точно так же скорость мо­
жет измениться вследствие того, что команда изучает новую технологию, знакомится
с новой предметной областью или просто привыкает к новым участникам команды или
новым методам работы.
▲------------------------------------------------------------------------------------ А
А что если программисты работают в паре
Оценка историй в баллах работает независимо от того, прибегает ли команда к пар­
ному программированию (pair programming) или нет. Предположим, что команда из двух
разработчиков оценивает истории в баллах, основанных на идеальных рабочих днях.
Они программируют не в паре. Запланирована итерация недельной длительности, вклю­
чающая в себя две истории, каждая из которых оценена в три балла. В течение этой ите­
рации программисты завершают разработку обеих историй и получают для своей коман­
ды значение скорости, равное шести.
А теперь рассмотрим другой случай, когда используется парное программирование,
а истории оцениваются в идеальных парных рабочих днях. Программисты оценивают
истории и решают, что на разработку каждой уйдет два идеальных парных рабочих дня.
В конце итерации они завершают разработку обеих историй и получают значение ско­
рости, равное четырем.
Несмотря на различия в числовом выражении, скорость разработки в обоих случаях
одна и та же. Обе команды продвигаются с одним и тем же темпом, поскольку за одну
итерацию они выполнили один и тот же объем работ. Отсюда следует, что команда может
свободно выбирать способ интерпретации баллов историй — трактовать их как идеальные
дни работы в паре или идеальные рабочие дни одного программиста, а различие между
этими способами будет проявляться лишь в виде разных числовых значений скорости.
▼-------------------------------------------------------------------------------------▼
С увеличением размера историй точность оценок снижается
С оценкой историй в баллах связана одна проблема, суть которой в том, что для не­
которых оценок иногда трудно найти какие-либо веские обоснования. Предположим, на­
пример, что одну и ту же историю один программист оценил в два балла, а другой — в три.
Такое различие в оценках заслуживает обсуждения, поскольку вторая из них представ­
ляет на 50% больший объем работ, чем первая. Весьма вероятно, что оба разработчика
решат обсудить историю более подробно и выработают какое-то общее мнение.
А теперь представьте, что разработчики решают, оценить ли историю в семь или
восемь баллов. В большинстве случаев различие в один балл между столь большими
значениями вряд ли стоит обсуждать, поскольку при таком обсуждении мы пытались бы
достичь большей точности, чем та, которая нам доступна.
Глава 8. Оценка пользовательских историй
Чтобы избежать подобных ситуаций и упростить весь процесс, команда может до­
говориться, что возможные оценки могут иметь лишь предопределенный ряд значений,
например:
1/2,1, 2, 3, 5,8,13, 20,40,80.
Эта идея привлекательна, поскольку отражает ту истину, что чем выше значение
оценки, тем меньше мы можем сказать что-либо для ее обоснования. Если имеется
эпическая история и команда должна решить, какую оценку ей присвоить — 40 или 80,
то это легче сделать, чем выбрать между значениями 79 и 80.
▲------------------------------------------------------------------------------------ ▲
Полезные напоминания
Работа с баллами историй иногда может сбивать с толку. Обычно это происходит,
когда люди слишком интенсивно над ними раздумывают или пытаются придать им бо­
лее глубокий смысл, чем тот, который в них заложен. Чтобы уверенно работать с балла­
ми историй, не забывайте о следующих моментах.
• Баллы историй, используемые одной командой, не эквивалентны баллам историй
другой команды. История, которую ваша команда оценивает в три балла, моя ко­
манда может оценить в пять баллов.
• Если история (возможно, эпическая) разбивается на составляющие истории, то
сумма оценок отдельных историй не обязательно должна совпадать с оценкой на­
чальной истории.
• Аналогичным образом историю можно разбить на составляющие ее задачи. Сум­
ма оценок задач не обязательно должна совпадать с оценкой начальной истории.
Резюме
• Оценивайте истории в условных единицах, называемых баллами историй и игра­
ющих роль относительной меры сложности, трудоемкости или длительности
истории.
• Оценивать истории должна команда, и сами оценки принадлежат команде, а не
отдельным людям.
• Триангулируйте оценки путем сравнения их с другими оценками.
• Оценки, выражаемые баллами историй, никоим образом не зависят от того, ис­
пользует ли команда парное программирование. Программирование в паре ска­
зывается лишь на скорости работы команды, но не на оценках историй.
Обязанности разработчика
• Вы обязаны пользоваться баллами историй, вкладывая в них тот смысл, который
признается командой и практичен в применении. Вы обязаны последовательно
придерживаться единого стандарта оценок, принятого в команде.
Часть II. Оценка и планирование
• Вы обязаны давать добросовестные оценки. Вы должны избегать искушения за­
нижать оценки, будь то по собственной воле или под давлением.
• Вы обязаны давать оценки как член единой команды.
• Вы обязаны давать оценки, согласующиеся с другими оценками. Например, все
истории, оцененные в два балла, должны быть аналогичны друг другу.
Обязанности заказчика
• Вы обязаны принимать участие в работе команды по оценке историй, но ваша
роль сводится к ответам на задаваемые вам вопросы и разъяснению историй. Вы
не даете историям самостоятельные оценки.
Контрольные вопросы
8.1. На собрании по оценке историй три программиста оценивают историю. Их
оценки составили, соответственно, два, четыре и пять баллов. Какую оценку
следует использовать?
8.2. В каких целях используется триангуляция оценок?
8.3. Дайте определение скорости разработки.
8.4. На протяжении последней двухнедельной итерации команда А выполнила объем
работ на 43 балла. Команда В работает над отдельным проектом и насчитывает
в два раза больше разработчиков. За время своей двухнедельной итерации они
также выполнили объем работ на 43 балла. Как такое может быть?
Глава 9
Планирование выпусков
Большинство программных проектов обретает наибольшую эффективность, если каж­
дые два—шесть месяцев заказчику поставляется новая версия продукта. В некоторых
проектах по созданию веб-сайтов новые версии могут выходить еще чаще, но и в этом
случае имеет смысл выпускать версии, регулярно включающие в себя какую-нибудь
группу родственных новых возможностей по мере их появления. Во многих случаях пла­
нирование выпуска целесообразно начинать с составления дорожной карты разработки
продукта (product development roadmap), отображающей новые области концентрации
усилий для нескольких следующих выпусков. Несомненно, эта карта будет меняться, но
мы и хотим этого, поскольку такие изменения будут результатом более глубокого пони­
мания нами нашего продукта, особенностей соответствующего рынка и нашей способ­
ности разработать данный продукт.
Дорожная карта разработки продукта не обязательно должна быть сложной. Она мо­
жет представлять собой простой список основных областей, или тем (themes), как на­
зывает их Кент Бек, на которых сосредоточивается внимание в каждом из нескольких
следующих выпусков. Например, для очередного выпуска веб-сайта BigBucksJob.com мы
могли бы составить такой список тем:
• средства фильтрации и просмотра резюме для компаний;
• автоматизированные поисковые агенты для соискателей;
• высокопроизводительный механизм обработки запросов.
Имея в своем распоряжении лишь грубый исходный вариант дорожной карты разра­
ботки продукта, мы начинаем планирование выпуска с ответа на следующие два вопроса.
• К какому сроку мы хотим подготовить выпуск?
• Каковы приоритеты каждой истории?
Как только ответы на эти вопросы будут найдены, мы приступаем к планированию
выпуска путем оценки объема работ, который команда сможет выполнить за одну итера­
цию. Имея на руках эту оценку, мы сможем составить разумный прогноз относительно
того, сколько итераций потребуется для создания выпуска, который соответствовал бы
ожиданиям заказчика.
На какую дату планировать выпуск
В идеальном случае разработчики и заказчик намечают не конкретную дату выпуска
очередной версии продукта, а интервал дат: “Хотелось бы, чтобы это произошло в мае,
но даже если выпуск будет где-то в июле, то это нормально”. Итеративный процесс раз­
работки, управляемый историями, упрощает назначение фиксированной даты, но при
этом очень трудно зафиксировать, что именно будет включено в выпуск к заданной дате.
Часть II. Оценка и планирование
Если команда приступает к планированию, основываясь на некотором допустимом ин­
тервале возможных дат, то это дает ей достаточную гибкость в составлении расписания
выпусков. Например, в плане могут содержаться пункты наподобие следующего: “После
шести-семи итераций мы получим продукт с минимальным набором функциональных
возможностей, а для реализации всех возможностей, запланированных для включения
в версию 1.0, нам понадобится от десяти до двенадцати итераций”.
Иногда дата выпуска очередной версии действительно фиксируется. Как правило,
это происходит, когда выпуск готовится к демонстрации на торговой выставке, является
ключевым выпуском для заказчика или знаменует собой достижение какой-то другой,
вполне определенной вехи в разработке. Если это так, то планирование выпуска факти­
чески немного облегчается, поскольку анализировать следует меньшее количество пере­
менных факторов. В то же время решения относительно того, какие истории должны
быть включены в выпуск, обычно даются труднее.
Что должно войти в выпуск
Чтобы можно было приступить к планированию выпуска, заказчик должен назна­
чить историям приоритеты. Приоритетность историй с привычной всем градацией
приоритетов (высокий, средний, низкий) полезна, но может привести к утомительным
спорам относительно того, что должно быть положено в основу различения среднего
и высокого приоритетов историй. К счастью, мы можем позаимствовать соответству­
ющую методику из другой разновидности agile-процессов — DSDM (Dynamic System
Development Method — метод разработки динамических систем)’.
В DSDM применяется метод расстановки приоритетов, который называется MoSCoW.
Это акроним, образованный из следующих заглавных букв:
• М (Must have) — обязательно;
• S (Should have) — желательно;
• С (Could have) — возможно;
• W (Won’t have this time) — необязательно.
Функциональные возможности категории М — это те, которые имеют для системы
фундаментальное значение. Возможности категории S важны, но вместо них можно
временно использовать некие обходные пути. Если проект не ограничен во времени, то
возможности этой категории обычно рассматриваются как обязательные для реализа­
ции. Возможности С — это те, которые можно не включать в выпуск, если подгоняет
время. Возможности с приоритетом W желательны, но нужда в них возникнет только
в более поздних выпусках.
Назначение приоритетов историям
Существует множество признаков, по которым можно сортировать истории при рас­
становке приоритетов. Из технических признаков для этой цели можно использовать
следующие:
1 Более подробную информацию о DSDM можно найти в Википедии: http: //ru. wikipedia.
org/wiki/DSDM. — Примеч.ред.
Глава 9. Планирование выпусков
• риск того, что история не может быть завершена так, как планировалось (напри­
мер, с требуемыми показателями производительности или с использованием но­
вейшего алгоритма);
• влияние, которое задержка с реализацией истории окажет на другие истории
(ведь не хотим же мы узнать лишь на последней итерации, что приложение долж­
но быть многопоточным и иметь трехуровневую архитектуру).
Кроме того, заказчик и пользователь могут располагать собственным набором при­
знаков, которые они могут использовать для сортировки историй, включая следующие:
• желательность истории для широкого круга пользователей и заказчиков;
• желательность истории для ограниченного круга важных пользователей и заказ­
чиков;
• сродство данной истории с другими историями (например, история “уменьшить
масштаб изображения” сама по себе может не быть высокоприоритетной, но мо­
жет рассматриваться как таковая, поскольку дополняет историю “увеличить мас­
штаб изображения”, имеющую высокий приоритет).
Точки зрения коллектива разработчиков и заказчика на очередность, в которой
должны реализовываться истории, могут расходиться. При наличии любых разногласий
по этому вопросу мнение заказчика всегда является решающим.
В то же время заказчик не может установить приоритеты, не получив предварительно
информацию от разработчиков. Он должен иметь хотя бы приблизительное представле­
ние о том, сколько времени уйдет на разработку каждой истории. Прежде чем историям
можно будет назначить приоритеты, они должны быть оценены, а оценки — записаны
на карточках, как показано на примере карточки истории 9.1.
Сайт всегда должен сообщать пользователю о последних 3 (?)
просмотренных позициях каталога товаров и предоставлять ссылки на
них. Это средство работает даже при переключениях между
сеансами.)
Оценка: 3 дня
■ Карточка истории 9.1. Предоставление ссылок, ведущих к ранее просмотренным позици­
ям товарного каталога
На данной стадии заказчик не пытается получать какие-либо суммарные оценки со­
ртируемых историй или принимать решения о том, какие из них следует включить в вы­
пуск, а какие — нет. Руководствуясь оценками историй, назначенными разработчиками,
а также собственным видением относительной ценности историй для него, заказчик
лишь сортирует истории, раскладывая их в том порядке, в котором он хотел бы, что­
бы они были реализованы, тем самым обеспечивая максимальную потребительскую
Часть II. Оценка и
планирование
ценность продукта для его организации. Иногда заказчик может отойти от этого прави­
ла. Например, некоторые истории могут быть очень ценными, но на их разработку уйдет
целый месяц, тогда как иная история может иметь в два раза меньшую ценность, но для
ее разработки потребуется всего лишь день.
▼------------------------------------------------------------------------------------ ▼
Стоимость историй влияет на их приоритет
Несколько лет назад моя команда создавала пользовательский интерфейс для за­
казчика, который переносил на платформу Windows крупное приложение, разработан­
ное для DOS. В системе DOS клавиша <Enter> использовалась для перехода от одно­
го поля к другому. Заказчик хотел, чтобы мы сохранили такое же поведение системы
и в Windows. С точки зрения заказчика было все равно, использовать для этой цели
клавишу <ТаЬ> или клавишу <Enter>, ибо согласно его логике разработка любого из этих
вариантов заняла бы одинаковое количество времени. Однако мы оценили, что исполь­
зование клавиши <Enter> потребует привлечения дополнительного человека, который
будет заниматься этим неделю. Выслушав наш вердикт, заказчик быстро согласился по­
низить приоритет этой истории. Пока он думал, что на нее уйдет несколько часов, она
была для него высокоприоритетной, но когда оказалось, что часы растянулись до недели,
он решил, что есть достаточно много более важных вещей, и он отдал предпочтение им.
--------------------------------------------------------------------------------------- ▲
Смешанные приоритеты
Если у заказчика возникают проблемы с определением приоритета истории, ее мож­
но разбить на несколько меньших историй. Такое разбиение позволяет назначить от­
дельным историям разные приоритеты. Как-то мне пришлось иметь дело с описанием,
представленным на карточке истории 9.2. Заказчик настаивал на присвоении высокого
приоритета этой истории, поскольку возможность поиска по автору и названию была
для него очень важна, тогда как другие поля, будучи сами по себе полезными, суще­
ственного значения для него не имели. В результате обсуждения эта история была
разбита на три отдельные истории, соответствующие поиску по автору или названию
статьи, поиску по названию или дате выхода издания и поиску с использованием ком­
бинации перечисленных критериев.
Пользователи могут осуществлять поиск журнальных статей по имени
автора, названию публикации, названию издания, дате публикации или
по любой комбинации этих критериев.
■ Карточка истории 9.2. Критерии поиска
Истории, сопряженные с рисками
Если вспомнить ранние подходы к разработке программного обеспечения, то станет
ясно, что идет постоянный спор относительно того, на реализацию чего в первую оче-
Глава 9. Планирование выпусков
редь должен быть нацелен проект, — частей проекта, с которыми связан наибольший
риск, или частей, представляющих наибольшую потребительскую ценность. Самым ак­
тивным сторонником разработки на основе минимизации рисков (risk-driven development)
являлся, пожалуй, Барри Бем, предложивший спиральную модель разработки, в которой
во главе угла ставится раннее устранение рисков [8]. Сторонником противоположного
подхода был Том Гилб, который считал, что в первую очередь следует заниматься “лако­
мыми кусочками” (“juicy bits”) [29].
Можно с полной уверенностью утверждать, что резиденция agile-подходов находится
в лагере любителей “лакомых кусочков”. Это позволяет agile-проектам избежать пре­
ждевременного разрешения проблем, связанных с возможными рисками, и отложить на
более поздние стадии создание инфраструктурного кода, если к тому времени это во­
обще понадобится. Кроме того, смещение предпочтений в пользу “лакомых кусочков”
обеспечивает возможность выпуска ранних версий продукта, в которых присутствует
функциональность, обладающая наибольшей ценностью.
Но даже и в этом случае мы все равно должны учитывать риски в процессе назначе­
ния приоритетов историям. Многие разработчики склонны браться сначала за истории,
с которыми связаны наибольшие риски. Иногда такой подход оправдан, но окончатель­
ное решение в любом случае должно оставаться за заказчиком. В то же время при рас­
становке приоритетов историй заказчик руководствуется информацией, поступающей
к нему от разработчиков.
В одном недавнем проекте из области биотехнологий некоторые истории требовали
реализации новых идей в рамках стандартного статистического подхода, называемого
ЕМ-алгоритмом. Поскольку предстоящая работа была поистине новаторской, команда
не была уверена в том, сможет ли она вообще ее выполнить, и не знала, сколько време­
ни это займет. Даже без включения этих историй продукт был пригодным для продажи,
и поэтому заказчик установил для них приоритет, близкий к среднему. Однако после
того, как заказчику сообщили о чрезвычайно высоком риске, связанном с этими исто­
риями, приоритет достаточно большого количества таких историй был несколько по­
вышен, чтобы можно было своевременно определить, с какими трудностями придется
столкнуться разработчикам при реализации новых алгоритмов.
Приоритеты инфраструктурных потребностей
Истории, с которыми сопряжены риски, часто связаны с инфраструктурными или
нефункциональными потребностями, например с производительностью. Я участвовал
в проекте по разработке веб-приложения, которое должно было отображать диаграммы
биржевых цен акций. Одна из наших историй отражена на карточке 9.3. Обеспечение
требуемой производительности на заданном оборудовании базового сервера могло при­
вести к заметным проблемам. Трудности с удовлетворением требований в отношении
производительности оказали бы значительное влияние на наши архитектурные решения.
Обеспечить возможность генерации 50 биржевых диаграмм в секунду.
■ Карточка истории 9.3. Генерация 50 изображений в секунду
▼
Часть II. Оценка и
планирование
Ранее нами уже было принято решение относительно использования языка Java на
стороне сервера, но сумеем ли мы добиться вывода 50 изображений в секунду с помо­
щью Java? Не стоит ли нам использовать для генерации изображений языки С или C++?
А может быть, мы добьемся нужной производительности за счет алгоритма интенсивно­
го кеширования, при необходимости обеспечивающего извлечение из кеш-памяти изо­
бражений, сохраненных во время недавних запросов?
В данном случае история 9.3 была написана для нас заказчиком. Однако он присво­
ил ей довольно низкий приоритет. Несколько наших первых итераций были ориенти­
рованы на реализацию возможностей, которые можно было бы отобразить в рекламных
проспектах и использовать для запуска начальных продаж и вызова интереса к продукту.
Наш заказчик рассуждал, что масштабируемость можно обеспечить позднее. В некото­
рых случаях выполнить рефакторинг системы для улучшения масштабируемости не со­
ставляет труда. В других же случаях этот тип рефакторинга может вызвать затруднения.
И именно разработчики обязаны помочь заказчику в идентификации историй, разра­
ботку которых можно отложить, но ценой того, что их реализация на более поздних эта­
пах обойдется значительно дороже. В то же время разработчики не должны злоупотре­
блять подобными ситуациями для того, чтобы склонить заказчика в сторону разработки
привлекающих их технических возможностей.
В другом проекте заказчик выразил отчетливое желание, чтобы программу можно
было развертывать в виде трехуровневого приложения с сервером базы данных и кли­
ентской машиной, маршрутизация запросов и данных между которыми осуществляет­
ся сервером приложений. Заказчик говорил об этом команде на различных собраниях,
а маркетинговая литература, которую он готовил, описывала систему как трехуровне­
вую. Тем не менее не было написано ни одной истории, предусматривающей добавление
сервера приложений.
Это начинало тревожить техническую команду. Они не имели ничего против того,
чтобы начать разработку с простой двухуровневой системы (сервер базы данных и кли­
ентская машина), но после нескольких итераций они уже были обеспокоены тем, что
сервер приложений все еще не добавлен в проект. Они знали, что пока это можно легко
сделать, но с каждой новой итерацией сделать это будет немного труднее. Кроме того,
поскольку пользовательские истории писались так, что они были полностью ориенти­
рованы на функциональность, необходимую конечному пользователю, оставалось неяс­
ным, когда будет добавлено описание инфраструктурных потребностей.
Решение состояло в том, чтобы написать такую историю, которая сделала бы обе­
спечение трехуровневой архитектуры высокоприоритетной задачей в глазах заказчика,
устанавливающего приоритеты для работы команды. В данном случае мы добавили сле­
дующую историю: “Во время установки программного обеспечения пользователь может
выбрать вариант локальной установки всех компонентов на своем ПК или выполнить
раздельную установку клиента, сервера приложений и сервера базы данных”.
Выбор длительности итерации
Коллективным решением разработчики и заказчик выбирают устраивающую обе
стороны длительность одной итерации. Типичная длительность итерации составляет
от одной до четырех недель. Короткие итерации позволяют чаще вносить коррективы
в проект, а контроль продвижения проекта становится более наглядным, однако с каж­
дой итерацией связаны небольшие накладные расходы. Отдавайте предпочтение ите-
Глава 9. Планирование выпусков
рациям, которые кажутся немного более короткими, чем следовало, а не тем, которые
кажутся слишком длинными.
По мере возможностей сохраняйте постоянную длительность итераций на протяже­
нии всего времени работы над проектом. При условии такого постоянства проекты до­
стигают своего естественного ритма, что благотворно сказывается на скорости работы
команды. Разумеется, возможны периоды, когда вам потребуется изменить длительность
итерации. Например, команду, которая использует итерации длительностью три неде­
ли, просят подготовить очередную версию для очень важной выставки, которая состо­
ится через восемь недель. Вместо того чтобы сделать остановку в работе по прошествии
двух итераций длительностью три недели каждая, оставляя себе две свободные недели
до выставки, команда может выполнить две первые трехнедельные итерации в обычном
режиме, после чего перейти к выполнению сокращенной итерации двухнедельной дли­
тельности. Это вполне нормально. Чего надо стремиться избегать, так это беспорядоч­
ного изменения длительности итераций.
От баллов историй к ожидаемой длительности
Предположим, заказчик установил приоритеты для всех историй. Команда суммиру­
ет оценки, проставленные на каждой карточке, и получает результат, равный 100 баллам.
Использование баллов историй облегчает оценку самих историй, но теперь мы должны
решить, каким образом перейти от баллов к ожидаемой длительности проекта.
Разумеется, ответ состоит в использовании понятия производительности, или скоро­
сти разработки. Как вам уже известно из главы 8, под скоростью разработки понима­
ется объем работ, выполняемый за одну итерацию. Если нам известна скорость работы
команды, мы можем использовать ее для пересчета идеальных рабочих дней в кален­
дарные. Например, если наш проект оценивается в 100 идеальных дней, а скорость со­
ставляет 25, то мы легко находим, что для выполнения всего проекта нам понадобится
100/25 = 4 итерации.
Начальная скорость
Для нахождения начальной скорости разработки проекта можно использовать один
из следующих способов.
1. Применить для определения значения скорости ранее накопленный опыт.
2. Выполнить начальную итерацию и принять достигнутое на ней значение скорости
в качестве начального.
3. Сделать разумное предположение относительно возможного значения скорости.
Первый способ наилучший, но его удается использовать лишь в том случае, если
уже существует команда, работающая над аналогичным проектом, и если при переходе
к новому проекту никто не покинет эту команду или в нее не войдут другие участники.
К сожалению, очень редко бывает так, чтобы следующий проект, которым займется ко­
манда, был аналогичен предыдущему.
Выполнение начальной итерации — это замечательный способ определения старто­
вой скорости. Однако существует масса обстоятельств, препятствующих его использо­
ванию. Представьте, что ваш начальник пришел к вам со своей идеей нового продукта.
V
Часть II. Оценка и планирование
Он написал пользовательские истории, которые, как он считает, должны войти в пер­
вую версию. Эти истории он использовал для проведения маркетингового исследования
и полагает, что уже в течение первого года продукт принесет $500 000 дохода. Если раз­
работка продукта будет стоить достаточно дешево, то компания пойдет на это. В про­
тивном случае компания откажется от проекта. Когда ваш босс спрашивает, во сколько
обойдется разработка, вы не можете просто сказать ему: “Дайте мне две недели на проб­
ную итерацию, и тогда я вам отвечу”. В подобных случаях необходимо иметь в своем
распоряжении способ, позволяющий сделать разумные предположения относительно
возможной скорости разработки.
Выдвижение предположений относительно скорости разработки
Если требуется выдвинуть какие-то предположения относительно возможной скоро­
сти разработки, то они должны быть осмысленными, чтобы можно было объяснить их
другим людям. К счастью, для этого существуют разумные способы, если только вы сле­
довали рекомендациям главы 8 и в качестве определения балла истории приняли, что он
эквивалентен одному идеальному рабочему дню.
Если балл истории — это один идеальный рабочий день, то для получения оценки
начальной скорости мы должны оценить, какое количество фактических рабочих дней
составит один полный идеальный рабочий день. Совершенно очевидно, что на всем
протяжении итерации работа команды будет прерываться из-за множества факторов,
в результате чего ни один рабочий день команды не будет идеальным. Реальные рабо­
чие дни отличаются от идеальных, поскольку часть рабочего времени тратится на ра­
боту с электронной почтой, телефонные звонки, общие собрания компании, собрания
отдела, обучение, подготовку или просмотр презентаций, мытье машины босса, беседы
с новыми кандидатами, а есть еще и болезни, отпуска и прочее. С учетом всех этих фак­
торов обычно начинают со значения ожидаемой скорости, которое составляет от одной
трети до половины суммарного количества человеко-дней в итерации. Например, для
команды из шести разработчиков, использующей итерации длительностью две недели
каждая (десять рабочих дней), одной итерации соответствует шестьдесят человеко-дней.
В качестве начальной оценки скорости команда может принять 20—30 баллов историй за
одну итерацию, в зависимости от того, насколько рабочие дни команды, по мнению ее
членов, будут отличаться от идеальных.
Конечно, по мере продвижения проекта и после преодоления первых нескольких
итераций команда будет гораздо лучше чувствовать, сколько времени может занять раз­
работка всего проекта. Уже одной-двух итераций им будет достаточно для того, чтобы
определить, насколько они ошиблись при выборе начального значения скорости, и они
смогут уточнить эту оценку, что позволит с большей уверенностью осуществлять плани­
рование.
Составление плана выпуска
Итак, если проект оценен в 100 баллов, а наша оценка скорости составляет 20 баллов
за одну итерацию, то можно ожидать, что длительность проекта составит пять итераций.
Завершающий шаг при планировании выпуска — это распределение историй по итера­
циям. Совместно вырабатывая решения, заказчик и разработчики выбирают истории
с наивысшим приоритетом так, чтобы их суммарная оценка составляла двадцать баллов,
Глава 9. Планирование выпусков
и включают их в первую итерацию. Следующий набор историй, оцененных в двадцать
баллов, идет во вторую итерацию и так далее, пока истории не заполнят все итерации.
В зависимости от того, располагается ли команда в разных офисах или в одном
(включая всех участников проекта, например менеджеров верхнего звена) и есть ли не­
обходимость в соблюдении возможных формальных требований, принятых в организа­
ции, существует множество способов доведения плана выпуска до ведома участников.
Лично я, например, использовал в своей практике каждый из перечисленных ниже спо­
собов.
• Если все члены команды располагаются в одном офисе, я прикалываю карточки
историй к стене, располагая их столбцами, которые соответствуют итерациям.
• Если истории хранятся в виде электронной таблицы, я сортирую их по итераци­
ям, а затем обозначаю границы между итерациями широкими полужирными ли­
ниями.
• Для удаленных участников проекта я готовлю фотокопии карточек историй (раз­
мещая три такие карточки на странице или шесть в уменьшенном масштабе).
Я отмечаю начало каждой итерации и заключаю весь материал в красивую об­
ложку.
• Для удаленных участников проекта, к которым требуется особый подход, подго­
тавливаются диаграммы Ганта. Я создаю записи наподобие “Итерация 1” и под­
чиненные им записи с именами историй, входящих в данную итерацию.
▼------------------------------------------------------------------------------▼
Предупреждение
Будьте осмотрительны и не слишком доверяйте плану выпуска. Описанные в этой
главе методики помогут вам оценить приблизительную продолжительность разработки
проекта и позволят делать такие заключения, как “Проект будет готов к выпуску при­
близительно через 5-7 итераций”. В то же время для заявлений наподобие “Мы закон­
чим 3 июня” обеспечиваемой описанными методами точности недостаточно.
Используйте план выпуска для того, чтобы зафиксировать первоначальные ожида­
ния, но по мере последующего получения новой информации подвергайте свои ожи­
дания постоянному пересмотру. Ведите наблюдение за скоростью каждой итерации
и заново оценивайте истории, когда вы узнаете нечто новое, что может повлиять на
эти оценки.
▲----------------------------------------------------------------------------- ▲
Резюме
• Перед планированием выпуска необходимо хотя бы приблизительно знать, к ка­
кому сроку заказчик хочет получить выпуск и каковы приоритеты историй.
• Приоритеты историй должны располагать их в определенном порядке (первая,
вторая, третья и т.д.), а не разделять на группы (максимальный приоритет, высо­
кий, средний и т.д.).
• Приоритеты историй устанавливает заказчик, однако при этом он использует ин­
формацию, получаемую от разработчиков.
Часть II. Оценка и
планирование
• Оценки трудоемкости историй, выраженные в идеальных днях, пересчитываются
в календарные дни с использованием значения скорости.
• Во многих случаях требуется оценивать начальную скорость работы команды.
Обязанности разработчика
• Вы обязаны предоставлять заказчику информацию (включая собственные обо­
снованные допущения и возможные альтернативы), которая поможет ему назна­
чить приоритеты историям.
• Вы обязаны противостоять желанию устанавливать для инфраструктурных и ар­
хитектурных потребностей более высокие приоритеты, чем следовало бы.
• Вы ответственны за создание плана выпуска, построенного на реалистичных
оценках, но при этом учитывающего возможность их корректировки в определен­
ных пределах в ходе выполнения проекта.
Обязанности заказчика
• Вы обязаны расставлять приоритеты пользовательских историй в точности в том
порядке, в каком они представляют для вас ценность. Недостаточно сортировать
истории в группы, имеющие, например, высокий, средний и низкий приоритеты.
• Вы обязаны быть откровенным при назначении крайних сроков поставки выпу­
ска. Если выпуск нужен вам к 15 июля, не старайтесь перестраховаться, говоря
разработчикам, что выпуск нужен вам к 15 июня.
• Вы обязаны понимать, в чем состоит различие между идеальным и календарным
временем.
• Вы обязаны осуществлять разбиение историй, содержащих компоненты, которым
вы хотели бы назначить разные приоритеты.
• Вы обязаны понимать, почему программиста, личный показатель скорости ко­
торого равен 0,6, нельзя укорять и подвергать критике лишь за то, что величина
этого показателя меньше 1,0.
Контрольные вопросы
9.1. Назовите три способа оценки начальной скорости работы команды.
9.2. Предполагая, что длительность итерации составляет одну неделю, а команда со­
стоит из четырех разработчиков, ответьте, сколько времени понадобится этой
команде для завершения проекта, оцененного в 27 баллов, если скорость работы
команды равна 4?
Глава 10
Планирование итераций
Планирование выпусков обеспечивает грубое распределение историй по итерациям,
составляющим выпуск. Такой уровень планирования — не столь много деталей, чтобы
внушить нам ложное чувство, будто определенные нами цифры точны, но все достаточ­
но продумано, чтобы на этой основе строить свои действия, — идеально подходит для
планирования выпусков. Однако в начале каждой итерации очень важно продвинуться
в планировании еще на один шаг.
Общая схема процесса планирования итераций
Для планирования итерации проводится специальное собрание команды. Наряду
с членами команды (программистами, тестировщиками и др.) в работе собрания при­
нимает участие заказчик. Поскольку члены команды будут рассматривать истории очень
подробно, у них, несомненно, возникнет ряд вопросов. Для ответа на эти вопросы
и требуется присутствие заказчика.
Общая последовательность действий на собрании по планированию итерации такова.
1. Обсуждается история.
2. История разбивается на составляющие задачи.
3. Для каждой задачи назначается ответственный исполнитель из числа разработчиков.
4. После обсуждения всех историй и распределения задач каждый разработчик оцени­
вает принятую им к исполнению задачу, убеждаясь в том, что он сможет выполнить
взятые на себя обязательства.
Описанию каждого из этих действий посвящен отдельный раздел.
Обсуждение историй
К началу собрания по планированию итераций (iteration planning meeting) команда
располагает набором историй с установленными приоритетами. Аналогично тому, как
программисты могут менять свое мнение относительно трудности программирования
историй, заказчик может изменить свое мнение в отношении назначенных приорите­
тов. Собрание предоставляет заказчику великолепную возможность сообщить команде
об изменившихся приоритетах.
Собрание по планированию итераций начинается с того, что заказчик зачитывает
разработчикам историю, имеющую наивысший приоритет. После этого разработчи­
ки задают вопросы заказчику, пока история не будет понята ими достаточно полно для
того, чтобы разбить ее на составляющие задачи. На данном этапе не следует стремиться
к полному пониманию всех деталей истории. Их углубленное исследование лишь затянет
Часть II. Оценка и планирование
собрание и сделает его неэффективным, тем более что знание этих деталей требуется не
каждому из присутствующих. У разработчиков еще будет возможность подробно погово­
рить о деталях с заказчиком после окончания собрания.
▼------------------------------------------------------------------------------------ ▼
Изменение приоритетов
Как правило, заказчику лучше всего воздержаться от искушения изменять приори­
теты в течение итерации. Частые изменения заказчиком своего мнения могут легко
разбалансировать работу команды. Так, в одном проекте заказчик встретился с про­
граммистом, и они договорились о том, как должен выполняться поиск в базе данных.
Спустя пять дней после начала десятидневной итерации (когда около двух третей кода
для средства поиска было уже написано) заказчик появился вновь, на этот раз с ре­
шением, которое казалось ему лучшим, но полностью отличалось от первоначального
решения, код которого был уже частично написан. В тот момент заказчик сравнивал
решения так, как будто разработка обоих решений еще не была начата, и вполне есте­
ственно, что он отдавал предпочтение тому из них, которое он считал лучшим. Заказчик
настаивал на том, чтобы команда отказалась от прежнего подхода и использовала
новый. Мы вежливо попросили его дождаться окончания итерации, и он согласился.
Во время нашей следующей встречи заказчик имел возможность сравнить полностью
работающее решение, которое обеспечивало большую часть того, чего ему хотелось от
средства поиска, и другую версию, которая была, несомненно, лучше, но потребовала
бы 10 дней разработки.
Несмотря на то что заказчик и часть членов команды разработчиков считали но­
вое средство поиска лучшим, было признано, что его не стоит вводить в проект на тот
момент, когда на руках имеется вполне адекватное работающее решение. Для поль­
зователей лучше, если разработчики, не теряя времени, будут затрачивать усилия на
разработку совершенно новых средств.
▲------------------------------------------------------------------------------------ А
Разбиение историй на задачи
В сущности, разбиение историй на задачи не требует особого мастерства. Многие
разработчики постоянно занимаются этим на протяжении большей части своей трудо­
вой деятельности. Поскольку истории уже сами по себе имеют сравнительно неболь­
шой размер (в типичных случаях на них уйдет от одного до трех идеальных рабочих дней
среднего программиста), необходимость в таком разбиении возникает не так уж часто.
А действительно, зачем вообще дробить истории? Почему бы не рассматривать лю­
бую историю как единый объект разработки?
Даже если истории достаточно малы для того, чтобы их можно было оставить в каче­
стве отдельных объектов разработки, их дальнейшее разбиение на задачи обычно облег­
чает сопровождение проекта. Во-первых, во многих командах ни одна история не реа­
лизуется силами только одного разработчика (или пары разработчиков). История может
распределяться между разработчиками либо потому, что каждый разработчик специали­
зируется в определенной технологии, либо потому, что распределение работы — это са­
мый быстрый способ завершения разработки истории.
Во-вторых, истории — это описания функциональности, представляющей цен­
ность для пользователей или заказчика, а не списки “что сделать” для разработчиков.
Преобразование истории в совокупность составляющих ее задач часто бывает полезным,
Глава 10. Планирование итераций
поскольку позволяет заострить внимание на тех моментах, которые иначе могли быть
забыты. Поскольку разбиение историй на задачи происходит в групповой среде, то за­
действованными оказываются все силы команды. Если один разработчик еще может за­
быть о том, что обновление программы установки является частью истории, то малове­
роятно, что об этом забудет вся группа.
Одним из поводов для критики agile-процессов служит отсутствие в них отдельной
стадии предварительного проектирования (upfront design), которая, например, обязатель­
на в каскадной модели (waterfall model). И хотя в agile-процессах фаза предварительного
проектирования действительно отсутствует, проектирование в них выполняется факти­
чески непрерывно на протяжении частых коротких промежутков времени. Разбиение
историй на отдельные задачи — а это невозможно сделать, не занимаясь проектиро­
ванием хотя бы в минимальном объеме — является одним из примеров таких незапла­
нированных коротких периодов оперативного проектирования, заменяющих отдельную
фазу предварительного проектирования каскадной модели.
По мере того как члены команды предлагают, на какие задачи разбить историю, ктото должен на чем-то записывать эти задачи. Я предпочитаю использовать для этих целей
доску для временных записей (white board), вывешенную в комнате, где проводятся общие
собрания команды.
В качестве примера рассмотрим историю “Пользователь может осуществить поиск
гостиниц по различным полям”. Эту историю можно представить в виде набора следую­
щих задач:
• написать код экрана обычного поиска;
• написать код экрана расширенного поиска;
• написать код экрана для вывода результатов;
• написать и отладить SQL-запросы для обычного поиска;
• написать и отладить SQL-запросы для расширенного поиска;
• документировать новую функциональность в справочной системе и руководстве
пользователя.
Кстати, обратите внимание на то, что в этот список включена задача, касающаяся
обновления руководства пользователя и справочной системы. Хотя в самой истории об
этой документации не сказано ни слова, из предыдущих историй команде уже было из­
вестно о существовании таких документов, и включение подобной задачи будет напоми­
нать команде о необходимости их обновления в конце каждой итерации. Если по этому
поводу возникают какие-либо вопросы, их можно задать заказчику.
Рекомендации
Поскольку истории уже сами по себе имеют довольно небольшой размер, вряд ли
стоит давать какие-либо уточняющие рекомендации относительно предпочтительного
размера задач. В процессе разбивки историй на задачи достаточно руководствоваться
следующими простыми советами.
• Если одна из задач истории с трудом поддается оценке (например, список под­
держиваемых форматов данных требует утверждения вице-президентом компа­
нии, который находится в другом городе и никогда не спешит с ответом), отдели­
те ее от остальной части истории.
Часть И. Оценка и
планирование
• Если задачи могут быть легко выполнены отдельными разработчиками, разбей­
те их на отдельные подзадачи. Например, в описанном выше случае написание
кода экранов простого и расширенного поиска было разделено на две задачи.
Возможно, целесообразно поручить выполнение обеих задач одному программи­
сту или двум программистам, работающим в паре, но это вовсе не обязательно.
Разбиение задач подобным способом полезно, поскольку позволяет нескольким
программистам работать над одной и той же историей. В этом часто возникает
необходимость в конце итерации, когда начинает ощущаться нехватка времени.
Точно так же задачу “Написать код экрана обычного поиска” можно разбить на
две: “Спроектировать компоновку экрана обычного поиска” и “Написать код
экрана обычного поиска”, если в состав команды входят дизайнер или дизайнер­
ская группа, занимающиеся проектированием интерфейсов пользователя.
• Если знание того факта, что какая-то часть истории завершена, может оказать
определенное положительное влияние на весь процесс разработки, выделите ее
в отдельную задачу. В приведенном выше примере кодирование экранов обычно­
го и расширенного поиска было выделено в отдельные задачи. Это позволит раз­
работчику, пишущему код доступа к базе данных, подключить свои SQL-запросы
поочередно к каждому экрану поиска, как только они становятся доступными.
Сказанное означает, что задержка с завершением разработки экрана расширенно­
го поиска не приведет к задержке завершения двух задач, относящихся к экрану
обычного поиска.
Ответственность за выполнение
Как только для истории будут определены все задачи, для каждой из них должен
быть найден член команды, который добровольно возьмется за ее выполнение. Если за­
дачи были записаны на “белой доске”, разработчики просто пишут свои имена напро­
тив задач, за разработку которых они берутся.
Даже если в команде будет использоваться парное программирование, лучше, как
правило, связывать с каждой задачей единственного человека, который возьмет на себя
ответственность за ее выполнение. Если ему нужна дополнительная информация от за­
казчика, именно он получает ее. Если он решает программировать в паре, эту пару фор­
мирует тоже он. В конце концов, именно он отвечает за то, что к концу итерации задача
будет выполнена.
Фактически каждый член команды обязан прилагать все усилия к тому, чтобы за­
дача была решена. В команде должен господствовать дух товарищества “один за всех
и все за одного”. И если с приближением конца итерации один разработчик не успевает
справиться со всеми задачами, которые он на себя принял, то он может рассчитывать на
посильную помощь остальных членов команды.
Несмотря на то что за каждой задачей стоит один человек, который отвечает за ее
выполнение, должна признаваться возможность смещения этой ответственности на
протяжении итерации. По мере того как команда в ходе выполнения итерации узнает
больше о задачах и выясняется, что некоторые задачи оказались более трудными или
легкими, чем планировалось, обязательства должны пересматриваться. В конце итера­
ции никто не может сказать: “Я закончил свою работу, а у Тома еще осталось несколько
задач”.
Глава 10. Планирование итераций
Оценка и подтверждение
Если команда работает со скоростью сорок баллов за итерацию, то предыдущие ста­
дии — обсуждение истории, разбиение ее на задачи и возложение ответственности за их
выполнение — повторяются до тех пор, пока не будут обсуждены истории с наивысшим
приоритетом, в сумме набирающие 40 баллов. На данном этапе каждый разработчик
обязан оценить объем работ, за выполнение которых он отвечает. Для такой оценки попрежнему лучше всего использовать единицы идеального времени.
К данному моменту размер задач должен быть достаточно небольшим, чтобы их мож­
но было надежно оценить. Если это условие не выполняется, не огорчайтесь. Сделайте
разумное предположение относительно длительности разработки задачи и двигайтесь
вперед. Если, как это рекомендовалось ранее, задачи и имена ответственных исполни­
телей были записаны на доске, то каждый разработчик может вписать туда свои оценки.
Примерный вид того, что у вас должно получиться, показан в табл. 10.1.
Таблица 10.1. Запись данных на доске позволяет легко отслеживать задачи
с их ответственными исполнителями и оценками
Задача
Исполнитель
Написать код экрана обычного поиска
Сьюзан
6
Написать код экрана расширенного поиска
Сьюзан
8
Написать код экрана для вывода результатов
Джей
6
Написать и отладить SQL-запросы для обычного поиска
Сьюзан
4
Написать и отладить SQL-запросы для расширенного поиска
Сьюзан
8
Документировать новую функциональность в справочной системе Шэннон
и руководстве пользователя
Оценка
2
Оценив каждую из своих задач, разработчик должен сложить их оценки и сделать
реалистичные предположения относительно возможности их выполнения за одну ите­
рацию. Предположим, начинается итерация длительностью в две недели и я оценил,
что на выполнение взятых на себя задач мне потребуется 53 часа фактического рабочего
времени. С учетом того, что у меня есть еще и другие дела, маловероятно, чтобы я мог
посвятить этим задачам все свое рабочее время. Для выхода из создавшейся ситуации
я могу воспользоваться одной из следующих возможностей:
• оставить за собой все задачи, рассчитывая на то, что мне удастся с ними справиться;
• попросить кого-то из членов команды взять на себя часть моих задач;
• поговорить с заказчиком относительно исключения истории из итерации (или
разбиения истории и исключения некоторой ее части).
Если один из разработчиков оценил доставшийся ему объем работ и видит, что мо­
жет подключиться к моим задачам, ответственность за их выполнение переходит на
него. Если же никто не может взять на себя дополнительные задачи, то команда должна
обратиться к заказчику с просьбой об исключении некоторых задач из итерации. Беря
на себя ответственность за выполнение определенного объема работ, разработчик не
должен испытывать беспокойства. А поскольку команда действует по принципу “один
за всех и все за одного”, то никто не будет бояться ответственности, ибо в трудную ми­
нуту его поддержит вся команда.
Часть II. Оценка и планирование
Резюме
• Планирование итерации продвигает план выпуска на один шаг вперед в пределах
объема работ запускаемой итерации.
• Планируя итерацию, команда обсуждает каждую историю и разбивает ее на со­
ставляющие задачи.
• В отношении размеров задач не существует каких-либо жестких рекомендаций
(нельзя, например, говорить, что на разработку задачи должно уходить от 3 до 6
часов). Истории разбиваются на задачи либо для того, чтобы облегчить процесс
их оценки, либо для того, чтобы над отдельными частями истории работали одно­
временно несколько человек.
• Ответственность за выполнение каждой задачи берет на себя один разработчик.
• Разработчики выясняют, не переоценили ли они свои силы, путем самостоятель­
ной оценки каждой из взятых на себя задач.
Обязанности разработчика
• Вы обязаны участвовать в работе собраний по планированию итераций.
• Вы обязаны оказывать помощь в разбиении всех историй на задачи, а не только
тех, над которыми вам, вероятнее всего, придется работать.
• Вы обязаны принимать на себя ответственность за выполнение тех задач, над ко­
торыми будете работать.
• Вы отвечаете за то, чтобы брать на себя посильный объем работы.
• На протяжении итерации вы обязаны следить за тем, какой объем еще осталось сде­
лать вам, а также вашим товарищам по команде. Если вы видите, что успеваете за­
кончить свою работу в срок, то обязаны взять на себя часть работы ваших товарищей.
Обязанности заказчика
• Вы обязаны назначать приоритеты историям, которые будут включаться в итерации.
• Вы отвечаете за то, чтобы бизнес-ценность создаваемого разработчиками про­
дукта к моменту поставки была максимальной. Это означает, что, если с момента
первоначального утверждения выпуска выявились более ценные истории, вы обя­
заны скорректировать приоритеты таким образом, дабы это обеспечило макси­
мально возможную бизнес-ценность поставляемого продукта.
• Вы обязаны участвовать в работе собраний по планированию итераций.
Контрольные вопросы
10.1. Разбейте на составляющие задачи следующую историю: “Пользователь может
просмотреть подробную информацию о гостинице”.
Глава 11
Измерение и мониторинг
производительности
Как вы, возможно, помните, в главе 9 говорилось о том, что план выпуска создается пу­
тем разбиения проекта на ряд итераций, где каждая итерация включает в себя объем ра­
бот, оцениваемый определенным количеством баллов. Количество баллов выполненных
на протяжении итерации историй, называемое скоростью разработки проекта или про­
сто скоростью, характеризует производительность команды разработчиков. При плани­
ровании проекта мы либо используем известное значение скорости (если оно известно,
например, из опыта разработки аналогичных предыдущих проектов), либо определяем
его сами. Скорость разработки может служить полезным инструментом управления, по­
этому важно контролировать ее значение как в конце каждой итерации, так и на про­
тяжении всех итераций.
Измерение производительности
Поскольку скорость может играть роль важной меры, необходимо хорошо проду­
мать, как ее измерять. Большинство историй легко поддается учету: коль скоро команда
выполнила их за время итерации, следует учесть в расчетах их полную оценку. Допус­
тим, команда выполнила истории, представленные в табл. 11.1, на протяжении итера­
ции. Как видно из этой таблицы, значение скорости составляет 23, что является сум­
мой баллов историй, выполненных за итерацию. Если в плане выпуска была принята
скорость, значительно отличающаяся от 23, то может потребоваться пересмотр плана
проекта. Однако не спешите преждевременно корректировать план. Начальная скорость
может не только быть неверно определена, но и претерпевать заметные изменения на
протяжении ранних итераций. Поэтому имеет смысл выждать две или три итерации,
чтобы получить долгосрочную картину изменения скорости.
А что делать с историями, которые выполнены командой лишь частично? Должны
ли они учитываться при расчете скорости?
Таблица 11.1. Истории, выполненные на протяжении итерации
История
Баллы историй
Пользователь может...
4
Пользователь может...
3
Пользователь может...
5
Пользователь может...
3
Часть И. Оценка и
планирование
Окончание табл. 11.1
История
Баллы историй
Пользователь может...
2
Пользователь может...
4
Пользователь может...
2
Скорость
23
Нет, рассчитывая скорость, вы не должны учитывать частично выполненные исто­
рии. Причин тому несколько. Во-первых, существуют объективные трудности вычисле­
ния того, какая доля истории выполнена. Во-вторых, мы не хотим иметь дело с ложной
точностью определения скорости, записывая ее значения с указанием дробной части,
например 43,8. В-третьих, незавершенные истории не представляют никакой ценно­
сти для заказчика или пользователя. Поэтому такие истории, даже с частично написан­
ным кодом, часто не включаются в официальные сборки по окончании итерации, если
программное обеспечение поставляется пользователям на всем протяжении проекта.
В-четвертых, если размер историй таков, что включение лишь частично выполненной
истории приводит к изменению значения скорости, скажем, с 41 на 50, то это означа­
ет, что данная история имеет слишком большой размер. Наконец, нам ведь очень не
хочется попадать в ситуации, когда многие истории выполнены на 90% и лишь неко­
торые — на 100%. За этими 10% может скрываться масса сложностей, поэтому очень
важно полностью завершить историю, прежде чем ее учитывать.
Если у вас все-таки возникает соблазн включить частично выполненную историю
в расчеты, оцените средний размер историй и подумайте о разбиении данной исто­
рии на несколько меньших. В конце итерации, когда вы будете определять скорость,
гораздо легче пожертвовать половиной истории, оцененной в один балл, чем историей
в двадцать баллов. Кроме того, если вы замечаете, что в конце итераций у вас часто на­
капливается много частично выполненных историй (даже если они оцениваются в один
балл), то это может указывать на то, что в вашей команде отсутствует дух коллективиз­
ма. Работая по принципу “все за одного”, команда очень быстро придет к выводу, что
лучше совместными усилиями завершить реализацию пусть даже не всех историй, чем
выполнить все истории, но частично.
Скорость разработки не связана с фактическими рабочими часами
Обратите внимание на то, что расчеты скорости выполняются с использованием
оценок, присвоенных историям до начала итерации. Не изменяйте оценки историй по
окончании итерации исходя из фактических трудозатрат, которые к этому времени вам
станут уже известны. Предположим, история была оценена в четыре балла, но оказа­
лась значительно более трудозатратной. Команда выяснила постфактум, что историю
следовало бы оценить в семь баллов. Тем не менее при расчете скорости разработки
вклад этой истории должен оцениваться в четыре, а не семь баллов.
Вообще говоря, команды должны привыкать к тому, что скорость, планируемая для
следующей итерации, не должна превышать скорость на предыдущей итерации. Однако
если команда твердо убеждена, что оценка истории явно занижена и они в состоянии
выполнить больший объем работ на следующей итерации, то допускается незначитель­
ное увеличение запланированного значения скорости.
Глава 11. Измерение и мониторинг производительности
Несмотря на то что команда не должна изменять баллы выполненных историй “за­
дним числом”, эту информацию всегда следует использовать для коррекции оценок
историй, которые еще предстоит разработать.
Плановая и фактическая скорость
Чтобы проконтролировать, не отличается ли фактическая скорость разработки от за­
планированного значения и, что более важно, не следует ли предпринять в связи с этим
какие-либо действия, имеет смысл откладывать на графике запланированное и фактиче­
ское значения скорости для каждой итерации. Пример этого приведен на рис. 11.1, где
показано, как плановая скорость, начальное значение которой оказалось ниже фактиче­
ского, сначала возрастает, а затем стабилизируется к третьей итерации.
Итерации
■ Рис. 11.1. Плановое и фактическое значения скорости после первых трех итераций
Фактическая скорость, график которой проведен до третьей итерации, превышает
плановую для первой итерации. В то же время фактическое увеличение скорости оказа­
лось меньше запланированного для второй и третьей итераций, что привело к несколько
меньшим значениям фактической скорости по сравнению с запланированными.
Команда, разрабатывающая проект, данные которого отображены на рис. 11.1, по­
ступила бы неправильно, если бы по завершении первой итерации информировала за­
казчика о том, что скорость разработки превышает плановую и поэтому проект может
быть завершен досрочно. Что будет происходить после третьей итерации? Может ли
команда сказать, что они должны скорректировать ожидания заказчика относительно
плана выпуска? Чтобы дать ответы на эти вопросы, нужно, кроме графика, приведен­
ного на рис. 11.1, иметь еще и накопительный график объема выполненных работ в баллах
историй (рис. 11.2).
Этот график представляет общий объем работ в баллах, выполненный к концу каж­
дой итерации. Как видно из рис. 11.2, к концу второй итерации команда выработала
больше баллов историй, чем планировалось, хотя скорость разработки на второй итера­
ции была намного меньше плановой. Однако к концу третьей итерации преимущества
удачного старта команды на первой итерации были нивелированы более медленным
продвижением на второй и третьей итерациях.
Часть II. Оценка и планирование
■ Рис. 11.2. Накопительный график планового и фактического объемов выполненных работ
в баллах историй
Судя по результатам, достигнутым к концу третьей итерации, можно с большой до­
лей вероятности заключить, что команда не успеет реализовать тот объем функциональ­
ности, который планировался. Если эти данные не стали известны заказчику из его
ежедневного общения с командой, то надо обязательно разъяснить ему сложившуюся
ситуацию.
Итерационный график объема невыполненных работ
Еще один полезный способ контроля выполнения работ заключается в использова­
нии итерационных графиков объема оставшихся работ (iteration bumdown chart). Эти гра­
фики отображают выраженный в баллах историй объем работ, который еще остается вы­
полнить для завершения проекта, по состоянию на момент окончания каждой итерации.
Пример такого графика приведен на рис. 11.3.
■ Рис. 11.3. Итерационный график объема оставшихся работ
Глава 11. Измерение и мониторинг производительности
Интересным свойством этих графиков является то, что они учитывают не только
объем выполненных работ, исчисляемый в баллах, но также изменения в количестве
баллов историй, запланированных для оставшейся части выпуска. Пусть, например, ко­
манда выполнила работы объемом 20 баллов на протяжении итерации, но заказчик ввел
в проект новые истории объемом 15 баллов. В результате этого чистый итоговый резуль­
тат составляет всего 5 баллов. Если разработчики работают в оптимальном режиме, то
заказчику, пожалуй, стоило бы помедлить с добавлением новой работы, если он видит,
что проект будет быстро завершен.
График на рис. 11.3 свидетельствует о том, что прогресс команды на первой итера­
ции был фактически отрицательным. Они начали первую итерацию с оставшимися для
выполнения историями, суммарно оцениваемыми в 115 баллов, а закончили ее со 120
баллами. Менеджеры и заказчики должны внимательнее изучать графики оставшихся
объемов работ наподобие того, который приведен на рис. 11.3, и не напускаться зря на
команду, не разобравшись в сути дела. О чем мы не можем судить, глядя на такие гра­
фики, так это о том, насколько быстро продвигается команда. Возможно, команда, раз­
рабатывающая проект, проиллюстрированный на рис. 11.3, выполнила работы объемом
90 баллов, но заказчик мог добавить дополнительную работу, оцениваемую в 95 баллов.
Чтобы определить, сколько баллов историй отработано командой, следует посмотреть
на график скорости (см. рис. 11.1) или на накопительный график объема выполненных
работ (см. рис. 11.2).
Графики объемов оставшихся работ полезны, поскольку позволяют лучше предста­
вить общую картину хода выполнения работ, хотя и не отражают скорость разработки,
обеспечиваемую командой. Сила гибкой методологии разработки заключается в том,
что к разработке проекта можно приступать, не теряя времени на длительную предва­
рительную подготовку полной спецификации требований к проекту. Командами, при­
меняющими гибкую методологию, признается тот факт, что заказчик не может знать все
заранее. Поэтому agile-разработчики сначала просят заказчика рассказать им как можно
больше о своем видении предполагаемого программного обеспечения, а затем позво­
ляют ему изменять или уточнять свое мнение по мере того, как продвигаются работы
по проекту и создаваемое программное обеспечение постепенно обретает свой облик.
Это означает, что проект может пополняться новыми историями или лишаться преж­
них, а размер текущих историй, равно как и их значимость, может меняться. Обратимся
к примеру, представленному в табл. 11.2.
Таблица 11.2. Ход выполнения работ и вносимые изменения для четырех итераций
Итерация 1 Итерация 2 Итерация 3 Итерация 4
Количество баллов в начале итерации
130
113
78
31
Выполнено за итерацию (в баллах)
45
47
48
31
Изменение оценки (в баллах)
10
4
Количество баллов новых историй
18
8
-3
4
Количество баллов в конце итерации
113
78
31
0
Команда посчитала, что объем работ, который они смогут выполнить за одну ите­
рацию, составляет 45 баллов. Они начали проект со 130 баллами и планировали закон­
чить разработку за три итерации. За первую итерацию команда выполнила объем работ
на 45 баллов. Однако после этого разработчики решили, что размер нескольких остав­
шихся историй больше, чем вначале предполагалось, и увеличили суммарную оценку
Часть И. Оценка и
планирование
историй, разработка которых еще не была начата, на 10 баллов. Кроме того, заказчик
написал шесть новых историй, каждая из которых была оценена в три балла. Это озна­
чает, что чистый итоговый результат команды, выполнившей работу, оцениваемую в 45
баллов, составил 45 - 10 - 18 = 17 (баллов историй). Отсюда следует, что в конце первой
итерации объем оставшихся работ, который еще предстояло выполнить, составлял 113
баллов. На этой стадии команда уже увидела, что для выполнения всего проекта трех
запланированных итераций недостаточно. Даже если бы в проекте не появились новые
истории, объем работ, оставшихся невыполненными после первой итерации, превышал
90 баллов, т.е. для его выполнения (при скорости, равной 45) потребовалось бы более
двух итераций. Во время встречи заказчика с командой обсуждался вопрос о прекраще­
нии работ после третьей итерации и исключении некоторой части функциональности из
программного обеспечения, но вместо этого была достигнута договоренность о продле­
нии проекта еще на одну итерацию.
Вторая итерация следовала тому же тренду, что и первая, причем объем выполнен­
ных работ составил 47 баллов, а суммарная оценка неначатых и добавленных историй
увеличилась на 4 балла. Заказчик снизил темп внесения изменений, но все-таки добавил
в итерацию новые истории с суммарной оценкой 8 баллов. Чистый итоговый результат
второй итерации составил 47 - 4 - 8 = 35 (баллов историй).
Третью итерацию команда начала с оставшимися для выполнения историями, сум­
марно оцениваемыми в 78 баллов. Все шло хорошо, и команда завершила разработку
историй общим объемом 48 баллов. Суммарная оценка историй, которые еще предстоя­
ло разработать, уменьшилась на три балла. (Вспомните, что на предыдущих итерациях
суммарные оценки оставшихся работ увеличивались.) Заказчик добавил пару историй,
суммарно оцениваемых в четыре балла. Чистый итоговый результат третьей итерации
составил 48 + 3 - 4 = 47 (баллов историй). Для разработки на четвертой итерации оста­
лись истории с общим объемом работ в тридцать один балл, что команда выполнила без
внесения каких-либо дополнительных изменений.
Итерационный график объема оставшихся работ для этого проекта представлен на
рис. 11.4. Если посмотреть на наклон линии графика после первой итерации, то станет
очевидно, что после выполнения трех итераций проект не будет завершен.
График объема оставшихся работ для одной итерации
Графики объема оставшихся работ полезны не только для отслеживания хода разра­
ботки проекта по результатам итераций, но и могут служить замечательным средством
управления в течение итерации. Применительно к отдельно взятой итерации ежеднев­
ный график объема оставшихся работ (daily burndown chart) отображает оцененное ко­
личество часов, оставшихся до завершения данной итерации. Пример такого графика
приведен на рис. 11.5.
Для сбора информации относительно объема работ, которые еще предстоит выпол­
нить, я прошу, чтобы каждый член команды скорректировал свои данные, отображен­
ные на общей доске. По окончании планирования итерации все записи остаются на до­
ске. В частности, там находится список историй, каждая из которых представлена в виде
одной или нескольких задач. Напротив каждой задачи вписывается имя программиста,
берущегося за ее разработку. Примерно раз в день я складываю числа, указанные на до­
ске, и добавляю их в график объема оставшихся работ для данной итерации. В начале
итерации данные выглядят примерно так, как показано на рис. 11.6.
Глава 11. Измерение и мониторинг производительности
■ Рис. 11.4. Итерационный график объема оставшихся работ для проекта из табл. 11.2
Дни
■ Рис. 11.5. Ежедневный график объема оставшихся работ
Из рис. 11.6 следует, что разработка задачи “Создать HTML-страницу” завершена,
поскольку число оставшихся часов разработки исправлено с 2 на 0. Однако Мэри увели­
чила свою оценку для задачи “Создать улучшенный набор выборочных данных”. Впол­
не может быть, что Мэри даже не бралась за эту задачу и просто изменила ее оценку
или уже затратила на нее два (три, четыре...) часа, но считает, что ей надо еще четыре
часа, — все это не имеет ровным счетом никакого значения. Важно лишь то, что послед­
няя запись на доске отражает ее последнее мнение относительно остающегося объема
предстоящих работ.
Часть II. Оценка и
планирование
Создать HTML-страницу
Тед
2- 0
Прочитать значения поисковых
полей из HTML-формы
Тед
2
Создать улучшенный набор
выборочных данных
Мэри
2- 4
Написать сервлет для
выполнения поиска
Мэри
4
Сгенерировать страницу
результатов
Тед
2
■ Рис. 11.6. Пример оперативной записи оценок и их частой корректировки на доске
Каждый член команды знает, что он обязан постоянно обновлять свою информацию,
чтобы она всегда была сравнительно свежей. Обычно лучше всего это делать всякий раз,
когда завершается разработка задачи, или в конце рабочего дня. Благодаря этому данная
информация всегда отражает текущее состояние дел. Каждый член команды должен ста­
раться оценивать оставшийся объем работ как можно точнее. При необходимости про­
граммисты могут без какого-либо стеснения как увеличивать свои оценки оставшегося
до конца разработки времени, так и уменьшать.
▼----------------------------------------------------------------------------- ▼
Подсчитываются остающиеся часы, а не затраченные
Обратите внимание на то, что ежедневные графики объема оставшихся работ отра­
жают количество времени, остающегося до окончания разработки истории или задачи,
а не уже затраченного. Также не исключено, что может понадобиться отслеживать и за­
траченные часы (например, для сравнения запланированных и фактических трудоза­
трат с целью развития оценочных навыков или для мониторинга еженедельного коли­
чества продуктивных часов). Однако нежелание фиксировать количество затраченных
часов (то ли вследствие приблизительности оценок, то ли из-за того, что программисты
не хотят чувствовать себя “под колпаком" или заниматься лишней работой) обычно бе­
рет верх.
Кроме того, гораздо важнее знать не то, сколько труда было затрачено до сих пор,
а то, сколько труда еще предстоит вложить в проект.
▲----------------------------------------------------------------------------- ▲
Естественно, могут добавляться и новые задачи. Однако новую задачу следует добав­
лять только в тех случаях, когда кто-то вдруг понял, что о задаче забыли, а она необ­
ходима для завершения истории, уже включенной в текущую итерацию. Новые задачи
не должны добавляться чьим-то самовольным решением. Любое изменение такого рода
должно включаться в итерацию лишь после того, как на очередном совещании по пла­
нированию заказчик определит его приоритет.
Глава 11. Измерение и мониторинг производительности
▼------------------------------------------------------------------------------------ ▼
Используйте яркие графики большого размера
Любой из приведенных в этой главе типов графиков принесет максимальную пользу,
если сделать его достаточно большим и броским, чтобы он приковывал к себе взгляд.
Если в вашей организации есть графопостроитель, вычертите с его помощью графики
и вывесьте их на стене в комнате для совещаний или в коридоре, по которому все обыч­
но ходят. Если графопостроителя у вас нет, повесьте несколько настенных досок или
плакатных листов на рейках и вычертите графики на них.
Во время работы над одним проектом мы повесили в общем помещении три боль­
шие доски размером метр на полтора каждая. В ближайшем магазине канцтоваров
я приобрел небольшую черную ленту и использовал ее для обозначения осей на доске.
Таким образом, у нас получилась постоянная заготовка для осей, которая не стиралась
при смене графиков. Каждую неделю мы добавляли в каждый из трех графиков новую
точку. Время от времени, когда свободное место заканчивалось, мы стирали график
и начинали новый.
Резюме
• При определении скорости принимайте в расчет лишь законченные истории, т.е.
истории, прошедшие приемочные тесты.
• Неплохим способом контроля различий между фактическим и запланированным
значениями скорости является построение графиков как для запланированного
объема работ, выраженного в баллах историй, так и для фактически выполненно­
го объема для каждой итерации.
• Не пытайтесь предсказывать тренды в изменении скорости, базируясь лишь на
результатах одной-двух итераций.
• Количество часов, фактически затраченных на выполнение задачи или истории,
не имеет никакого отношения к скорости.
• Вывешивайте большие, хорошо различимые графики в местах сбора членов ко­
манды, где каждый сможет их увидеть.
• Накопительные графики (см. рис. 11.2) полезны тем, что они отображают общий
объем работы в баллах историй, выполненный к концу каждой итерации.
• Итерационные графики объема невыполненных работ (см. рис. 11.3) отобра­
жают как достигнутый прогресс в виде объема выполненных историй в баллах,
так и изменения в количестве баллов историй, запланированных на оставшуюся
часть выпуска.
• В течение итерации полезно использовать ежедневные графики объема невыпол­
ненных работ, отражающие количество оставшихся часов разработки по состоя­
нию на каждый день итерации.
• Отслеживание потерь времени команды из-за ошибок в разработке в пересчете на
один балл истории и построение соответствующих графиков помогает выяснить, не
происходит ли увеличение скорости за счет историй, разработанных с дефектами.
Часть II. Оценка и планирование
Обязанности разработчика
• В той мере, насколько это возможно, вы обязаны полностью завершить одну
историю, прежде чем переходить к следующей. Лучше иметь меньшее количество
завершенных историй, чем немного большее количество историй, ни одна из ко­
торых не завершена.
• Вы обязаны понимать, какое влияние может оказать любое ваше решение на ско­
рость разработки проекта.
• Вы обязаны знать, как читать и интерпретировать каждый график, представлен­
ный в этой главе.
• Если вы менеджер или, возможно, играете роль Контролера (Tracker) в ХР-проекте, то обязаны знать, как и когда создавать диаграммы, представленные в этой
главе.
Обязанности заказчика
• Вы обязаны знать, как читать и интерпретировать каждый график, представлен­
ный в этой главе.
• Вы обязаны знать скорость работы команды.
• Вы обязаны знать, как соотносятся между собой запланированная и фактическая
скорости, и уметь определять, требуется ли корректировка плана.
• Вы обязаны добавлять или удалять истории из выпуска, чтобы обеспечить дости­
жение целей проекта в той мере, в какой это возможно с учетом существующих
ограничений.
Контрольные вопросы
11.1. Для завершения истории, оцененной в один балл, фактически потребовалось
два дня. Какой вклад эта история внесет в скорость разработки, рассчитываемую
в конце итерации?
11.2. О чем можно узнать из ежедневного графика объема невыполненных работ, чего
нельзя увидеть на итерационном графике невыполненных работ?
11.3. Какие выводы можно сделать из рис. 11.7? Какой исход для завершения проекта
наиболее вероятен: раньше срока, позже срока или точно по плану?
11.4. Какова скорость работы команды, которая завершила итерацию с результатами,
представленными в табл. 11.3?
11.5. Какие обстоятельства могут бьггь причиной того, что итерационный график объе­
ма невыполненных работ будет отображать восходящий тренд?
11.6. Заполните до конца табл. 11.4, вписав в нее недостающие значения.
Глава 11. Измерение и мониторинг производительности
Итерации
■ Рис. 11.7. Закончится ли этот проект раньше срока, позже срока или по плану?
Таблица 11.3. Истории, выполненные на протяжении итерации
История
Баллы историй
Статус
История 1
4
Закончена
История 2
3
Закончена
История 3
5
Закончена
История 4
3
Закончена наполовину
История 5
2
Закончена
История 6
4
Не начата
История 7
2
Закончена
Скорость
23
Таблица 11.4. Впишите недостающие значения
Итерация 2
Итерация 3
35
40
36
0
Итерация 1
Количество баллов в начале итерации
100
Выполнено за итерацию (в баллах)
Изменение оценки (в баллах)
5
-5
Количество баллов новых историй
6
3
Количество баллов в конце итерации
76
О
ЧАСТЬ III
Часто
обсуждаемые
вопросы
К данному моменту вы уже знаете, что такое пользовательские истории, для чего они
служат и как применяются в процессах оценивания и планирования работ. В начале
этой части мы изучим различия между историями и другими подходами к определе­
нию требований, такими как документирование спецификаций требований, варианты
использования и сценарии. Затем будет показано, в чем именно состоят преимущества
пользовательских историй по сравнению с другими подходами.
Однако при любом подходе что-то иногда может пойти не так, как ожидалось, в свя­
зи с чем мы далее обратимся к рассмотрению списка так называемых запахов (smells),
или индикаторов того, что кое-что не было нами учтено. Колыбелью пользовательских
историй является экстремальное программирование, и с ним они теснее всего связа­
ны. Поэтому в данной части демонстрируется, как ввести пользовательские истории
в Scrum — другую методологию гибкой разработки. Завершается эта часть рассмотрени­
ем некоторых второстепенных, однако часто обсуждаемых вопросов, к примеру, какой
способ обработки историй эффективнее — бумажный или электронный, следует ли пи­
сать истории для обработки ошибок и т.п.
Глава 12
Чем не являются истории
Чтобы лучше понять, что представляют собой пользовательские истории, важно разо­
браться, чем они не являются. В этой главе объясняется, чем пользовательские истории
отличаются от трех других подходов к определению требований: вариантов использо­
вания, спецификаций требований к программному обеспечению (стандарт IEEE 830)
и сценариев проектирования взаимодействий.
Пользовательские истории не подчиняются
стандарту IEEE 830
Компьютерное общество Института инженеров по электротехнике и радиоэлектро­
нике (Institute of Electrical and Electronics Engineers, IEEE) опубликовало набор реко­
мендаций по написанию спецификаций требований к программному обеспечению [32].
Последняя редакция этого документа, известного под названием стандарта IEEE 830,
датируется 1998 годом. Рекомендации IEEE охватывают такие вопросы, как структура
документа для спецификации требований, роль прототипирования и характеристики
качественно подготовленных требований. Отличительной чертой спецификации требо­
ваний в стиле IEEE 830 является наличие фразы “Система должна...”, которую IEEE ре­
комендует использовать при написании функциональных требований. Типичный фраг­
мент спецификации, удовлетворяющей стандарту IEEE 830, выглядит примерно так.
4.6. Система должна предоставлять компании возможность оплачивать публика­
цию объявлений о вакансиях с помощью кредитной карты.
4.6.1. Система должна принимать карты Visa, MasterCard и AmericanExpress.
4.6.2. Система должна снимать деньги с карты до того, как объявление о ва­
кансии будет опубликовано на сайте.
4.6.3. Система должна предоставить пользователю уникальный подтверждаю­
щий код.
Документирование требований к системе на таком уровне трудоемко, чревато ошиб­
ками и занимает очень много времени. Кроме того, документ, написанный в таком сти­
ле, откровенно говоря, скучно читать. Но даже если документ скучно читать, это еще
не повод для того, чтобы отказываться от самой методики. Впрочем, когда имеешь дело
с 300 страницами требований наподобие приведенных выше, можно ожидать, что да­
леко не каждый, кому следовало бы их прочитать, сделает это добросовестно. Читатели
будут лишь бегло просматривать требования, а то и вовсе пропускать целые разделы.
Кроме того, подготовленный таким образом документ часто не дает читателю возмож­
ности получить целостное представление о будущей системе.
Часть III. Часто обсуждаемые вопросы
Возможные опасности
Если в процессе подготовки спецификаций требований участвуют одновременно
несколько различных групп, например маркетинговая группа, группа управления про­
дуктом и разработчики, то это может свидетельствовать о потенциальной опасности
возникновения расхождений между реализацией проекта и спецификацией требова­
ний к нему. Обычно все начинается с того, что группа по управлению продуктом (или
другая аналогичная группа) пишет спецификацию требований, которая передается
разработчикам. После этого разработчики переписывают документ так, чтобы он отра­
жал их интерпретацию требований, первоначально составленных группой управления.
Разработчики не преминут присвоить документу совершенное другое имя (назвав его,
например, функциональной спецификацией), дабы затушевать тот факт, что это тот же
самый первоначальный документ, который всего лишь переписан с точки зрения дру­
гой группы.
Обе группы отлично знают, что спецификацию требований для любого скольконибудь серьезного проекта очень трудно прочесть и полностью понять, не говоря уже
о том, что в ней невозможно описать все с необходимой точностью. Поэтому та группа,
которая пишет окончательный вариант требований, обычно и заявляет о своем исклю­
чительном праве трактовки назначения документа. Если по завершении проекта воз­
никают какие-либо претензии и начинается поиск виноватых, то эта группа укажет на
какой-нибудь раздел документа и заявит, что отсутствующие возможности предусма­
тривались данным разделом. Или же, наоборот, они заявят, что ожидаемая функцио­
нальность выходит за рамки требований, и доказать обратное будет очень трудно, по­
скольку нужные положения скрываются где-то в дебрях документа.
В большинстве случаев, когда я вижу, что две группы пишут две разные версии, по
сути дела, одного и того же документа, то заранее могу сказать, что они обрекают себя
на выяснение отношений между собой по завершении проекта и яростные споры за
право окончательной трактовки документации. В случае пользовательских историй та­
кой глупости вы просто не встретите. Вместе со смещением акцентов от письменной
документации к устному обсуждению приходит свобода действий, рожденная осозна­
нием того факта, что ничто не может быть истиной в последней инстанции. Документы,
подготовленные в виде контрактов, воспринимаются как нечто незыблемое. Иное дело
обсуждения. Если сегодня мы все обговорили, а месяц спустя узнали нечто новое, мы
возобновляем обсуждение.
Идея о том, что сначала следует трижды продумать все, что связано с системой, а за­
тем сесть и записать окончательный набор абсолютно всех необходимых требований
в виде “Система должна...”, кажется необычайно привлекательной. Ведь это звучит на­
много лучше, чем утверждения наподобие “если окажется возможным, то система бу­
дет...” или “если у нас будет время, то мы попытаемся...”, что точнее характеризует реа­
лии большинства проектов.
К сожалению, описать все требования к системе таким способом практически невоз­
можно. Стоит только пользователям увидеть программное обеспечение, которое для них
создается, как моментально образуется очень мощная и важная обратная связь. При зна­
комстве с программой у пользователей возникают новые идеи, а отношение к прежним
идеям меняется. Запросы на изменение программного обеспечения, описанного в спе­
цификации требований, мы привыкли называть “изменением границ проекта”. Такой
тип мышления нельзя считать правильным по следующим двум причинам. Во-первых,
Глава 12. Чем не являются
истории
он предполагает, что в какой-то момент времени о программе известно достаточно мно­
го, чтобы ее область применения можно было считать вполне определенной. Но сейчасто мы уже знаем, что как бы тщательно ни продумывались заранее требования, мнение
пользователей о программе, когда они увидят ее, будет другим (причем более содержа­
тельным). Во-вторых, этот тип мышления укрепляет веру в то, что разработка програм­
мы завершена, если она соответствует списку требований, а не ожиданиям пользовате­
лей, для которых она предназначена. В случае изменения потребностей пользователей
мы еще, пожалуй, могли бы говорить об “изменении области применения”, но этот тер­
мин обычно используют даже в тех случаях, когда изменения касаются лишь деталей
конкретного программного решения.
Многие проекты, разрабатываемые в соответствии с требованиями в стиле IEEE 830,
развивались в противоречии с интересами пользователей, поскольку внимание в них
фокусировалось на списке требований, а не на тех целях, которые преследовали поль­
зователи. Список требований не дает их читателю того общего понимания продукта,
которое обеспечивают пользовательские истории. Очень трудно читать требования так,
чтобы в твоей голове не прокручивались автоматически возможные варианты решений
по мере чтения. Кэрролл (12] полагает, что “образ решения может создаваться в головах
проектировщиков уже по прочтении первых нескольких требований, которые им встре­
тились”. Обратимся, например, к следующим требованиям1.
3.4. Продукт должен иметь бензиновый двигатель.
3.5. Продукт должен иметь четыре колеса.
3.5.1. Продукт должен иметь резиновые шины на каждом из колес.
3.6. Продукт должен иметь руль.
3.7. Продукт должен иметь стальной корпус.
К этому моменту, я полагаю, в вашей голове уже витает образ автомобиля. Разумеет­
ся, такой автомобиль удовлетворяет всем перечисленным выше требованиям. Однако вы
могли представить себе ярко-красного красавца с откидным верхом, а я — синий пикап.
Остается лишь допустить, что различия между моим и вашим вариантами будут отрегу­
лированы дополнительными положениями требований.
А теперь представим, что вместо написания спецификации требований в стиле
IEEE 830 пользователь рассказал нам, чего он ожидает от продукта.
• Продукт облегчает и ускоряет стрижку газона на моей лужайке.
• Мне очень удобно пользоваться продуктом.
Знакомясь с тем, какие цели преследует пользователь, мы получаем совершенно
иное видение продукта и понимаем, что на самом деле пользователь имел в виду газо­
нокосилку с сиденьем для водителя, а вовсе не автомобиль. Описанные ожидания
пользователя — это не пользовательские истории, но там, где документы IEEE 830 со­
держат списки требований, истории содержат описания пользовательских ожиданий.
Концентрируя внимание на ожиданиях пользователя в отношении нового продукта, а не
на списке атрибутов продукта, мы можем спроектировать решение, намного лучше удо­
влетворяющее потребности пользователя.
И последнее, чем отличаются пользовательские истории от спецификаций требова­
ний в стиле IEEE 830, — это то, что о стоимости каждого требования можно сказать
Адаптация примера из [23].
Часть III. Часто обсуждаемые вопросы
что-то определенное лишь тогда, когда будут написаны они все. В типичных случаях
на написание документа с требованиями, который никогда не бывает коротким, уходит
два-три месяца (иногда больше) работы одного или нескольких аналитиков. Затем этот
документ вручается программистам, которые говорят аналитикам (а те передают это за­
казчику), что работа над проектом потребует двадцати четырех месяцев, а не шести, как
ожидалось. В данном случае три четверти документа, на разработку которых у команды
просто не хватает времени, были написаны впустую, а ведь будут еще и дополнительные
затраты времени, поскольку разработчики, аналитики и заказчик должны многократно
просмотреть требования, чтобы выяснить, какую часть функциональности можно раз­
работать в срок. В случае же работы с историями с каждой из них заблаговременно свя­
зывается оценка. Заказчик знает скорость работы команды и трудоемкость каждой исто­
рии в баллах. Написав достаточное количество историй, которых хватит для заполнения
всех итераций, он легко сможет оценить сроки.
Для объяснения этого различия Кент Бек проводит аналогию с процедурой брако­
сочетания2. Составляя сценарий мероприятия, вы не смотрите на стоимость каждой от­
дельной услуги, а просто заказываете все, что считаете нужным. Такой подход вполне
приемлем для бракосочетания, но не для разработки программного обеспечения. Когда
заказчик прилагает к проекту список своих пожеланий, он должен знать, во что ему это
обойдется.
▼------------- ---------------------------------------------------------------- ▼
Как и для чего будут использоваться возможности программы
Со списками требований связана еще одна проблема, заключающаяся в том, что
они описывают поведение программы, но не поведение пользователей и цели, кото­
рые они преследуют. Список требований редко дает ответ на вопрос: “А каким образом
и для каких целей будет использоваться данная возможность?"
Стив Берчук, ХР-разработчик и автор книги Software Configuration Management Pat­
terns, подчеркивает важность следующего момента: “Я даже не могу точно сказать,
сколько раз я избавлял себя от массы лишней работы благодаря тому, что брал список
возможностей и просил заказчика создать сценарии, в которых он собирается их ис­
пользовать. Часто заказчики осознают, что необходимости в данной функциональности
на самом деле нет и что вам лучше потратить свое время на создание того, что пред­
ставляет для них ценность”3.
Пользовательские истории —
это не варианты использования
Впервые предложенные Иваром Якобсоном [33], прецеденты, или варианты исполь­
зования (use cases), сегодня обычно ассоциируются с рациональным унифицированным про­
цессом (Rational Unified Process, RUP). Вариант использования — это обобщенное опи­
сание набора взаимодействий между системой и одним или несколькими персонажами
(actors), где персонаж — либо пользователь, либо другая система. Варианты использо­
вания могут быть написаны в виде неструктурированного текста или соответствовать
определенному шаблону. К числу наиболее часто используемых относятся шаблоны,
2 Частное сообщение, 7 ноября 2003 г.
3 http://tech.groups.yahoo.com/group/extremeprogramming/message/69923.
Глава 12. Чем не являются истории
предложенные Алистером Коберном [16]. Пример такого шаблона, приведенный на
рис. 12.1, эквивалентен пользовательской истории “Рекрутер может оплатить публика­
цию вакансии с помощью кредитной карты”.
Название варианта использования (Use Case Title): Плата за публикацию
объявления о вакансии.
Главный персонаж (Primary Actor): Рекрутер (Recruiter).
Уровень (Level): Цель персонажа (Actor goal).
Предварительное условие (Precondition): Информация о вакансии вводится, но
не предоставляется для просмотра.
Минимальные гарантии (Minimal Guarantees): Отсутствуют.
Гарантии успеха (Success Guarantees): Объявление о вакансии опубликовано;
деньги с кредитной карты рекрутера сняты.
Основной успешный сценарий (Main Success Scenario):
1. Рекрутер предоставляет номер кредитной карты, указывает срок ее действия
и вводит учетные данные.
2. Система проверяет кредитную карту.
3. Система снимает полную сумму с карты.
4. Объявление о вакансии становится доступным для просмотра Соискателям.
5. Рекрутер получает уникальный код подтверждения.
Расширения (Extensions):
2а. Карты данного типа не обслуживаются системой.
2а1. Система уведомляет пользователя о необходимости использования
другой карты.
2Ь. Истек срок действия карты.
2Ы. Система уведомляет пользователя о необходимости использования
другой карты.
2с. Неправильный номер карты.
2d. Система уведомляет пользователя о необходимости использования
другой карты.
За. На карте недостаточно средств, чтобы оплатить публикацию объявления.
3а1. С карты снимается вся доступная сумма.
За2. Пользователь получает сообщение о возникшей проблеме вместе с
просьбой ввести данные другой кредитной карты для завершения платежа.
Вариант использования продолжается с п. 2.
■ Рис. 12.1. Образец варианта использования для оплаты за публикацию вакансии
Поскольку варианты использования не являются предметом рассмотрения данной
книги, мы не будем подробно останавливаться на них и ограничимся лишь обсужде­
нием назначения разделов “Основной успешный сценарий” (Main Success Scenario)
и “Расширения” (Extensions). Раздел “Основной успешный сценарий” — это опи­
сание главного успешного пути развития варианта использования. В данном случае
успешный исход достигается за счет выполнения пяти представленных пунктов. Раздел
“Расширения” определяет альтернативные пути развития варианта использования.
V
Часть III. Часто обсуждаемые вопросы
Часто расширения используются для обработки ошибок, но они служат также для опи­
сания вспомогательных (вторичных) путей, как, например, расширение За на рис. 12.1.
Отдельный путь развития варианта использования называют сценарием (scenario).
Поэтому, точно так же как “Основной успешный сценарий” представляет последова­
тельность пронумерованных пунктов от первого до пятого, альтернативный сценарий
представляет последовательность пунктов 1, 2, 2а, 2а1, 2, 3, 4, 5.
Одно из наиболее очевидных различий между историями и вариантами использова­
ния — их границы применения. Размер и тех, и других обеспечивает создание бизнесценности, но границы применения историй, как правило, уже границ применения ва­
риантов использования, поскольку обычно мы накладываем на истории ограничения
(например, не более 10 дней разработки), чтобы их можно было использовать в целях
планирования. Варианты использования почти всегда масштабнее историй. Например,
если вы посмотрите на пользовательскую историю “Рекрутер может оплатить публика­
цию вакансии с помощью кредитной карты”, то увидите, что она эквивалентна основ­
ному успешному сценарию использования из рис. 12.1. Это наводит на мысль, что
пользовательская история аналогична одиночному сценарию использования. Вовсе не
обязательно, чтобы пользовательской истории соответствовал основной успешный сце­
нарий. Например, мы вполне могли бы написать историю “Если пользователь пытает­
ся использовать просроченную кредитную карту, система предлагает ему указать другую
кредитную карту”, что эквивалентно расширению 2Ь из рис. 12.1.
Пользовательские истории и сценарии использования отличаются еще и уровнем
полноты. Джеймс Греннинг заметил4, что взятые вместе текст на карточке истории
и приемочные тесты — это в основном то же самое, что и вариант использования. Под
этим Греннинг подразумевает, что пользовательская история соответствует основному
успешному сценарию, а тесты истории — расширениям варианта использования.
Например, в главе 6 вы увидели, какими могут быть подходящие приемочные тесты
для пользовательской истории “Рекрутер может оплатить публикацию вакансии с помо­
щью кредитной карты”, которые для удобства повторно приведены ниже.
• Тестировать с картами Visa, MasterCard и American Express (проходит).
• Тестировать с картами Diner’s Club (не проходит).
• Тестировать с правильным, неправильным и отсутствующим подтверждающим
кодом (указывается на обратной стороне карты).
• Тестировать с просроченными платежными картами.
• Тестировать с различными суммами покупки (в том числе с превышением лимита
карты).
Глядя на эти тесты, нетрудно заметить, что они коррелируют с расширениями, пред­
ставленными на рис. 12.1.
Еще одно важное различие между вариантами использования и пользовательскими
историями касается сроков их жизни. Варианты использования часто являются посто­
янными артефактами, которые продолжают существовать на протяжении всего време­
ни активной разработки и сопровождения продукта. С другой стороны, относительно
историй не предполагается, что они переживут итерацию, в которой были реализованы
в программном обеспечении. Несмотря на то что истории можно архивировать, во мно­
гих командах карточки историй просто рвутся, когда необходимость в них исчезает.
4 http://tech.groups.yahoo.com/group/extremeprogramming/message/70040.
Глава 12. Чем не являются истории
Кроме того, различие состоит еще и в том, что в вариантах использования более ча­
сты случаи включения деталей пользовательского интерфейса, несмотря на настоятель­
ные рекомендации избегать этого [1; 16]. Причин тому несколько. Во-первых, посколь­
ку другого удобного места, куда можно было бы включить требования к интерфейсу
пользователя, нет, они, в конечном счете, попадают в описания вариантов использова­
ния, объем документации которых и без этого велик. Во-вторых, авторы вариантов ис­
пользования всегда фокусируют внимание прежде всего на вопросах реализации про­
граммного обеспечения и лишь затем — на бизнес-целях.
Включение описания деталей пользовательского интерфейса приводит к определен­
ным проблемам, особенно на ранних стадиях нового проекта, когда не стоит затруднять
проектирование интерфейса пользователя, базируясь на еще не устоявшихся представ­
лениях о том, каким он должен быть. Недавно мне на глаза попался один вариант ис­
пользования, представленный на рис. 12.2, который описывает последовательность ша­
гов по созданию и отправке сообщения электронной почты.
Название варианта использования: Создание и отправка электронного
сообщения
Основной успешный сценарий:
1. Пользователь выбирает пункт меню "Создать новое сообщение".
2. Система предоставляет пользователю диалоговое окно "Создать сообщение".
3. Пользователь вводит основной текст сообщения, тему сообщения, а также имя
и адрес получателя.
4. Пользователь щелкает на кнопке "Отправить".
5. Система отправляет сообщение.
■ Рис. 12.2. Пример варианта использования для создания и отправки электронного со­
общения
Весь этот сценарий буквально напичкан допущениями относительно пользователь­
ского интерфейса. В нем предполагается, что существует пункт меню Создать новое
сообщение, имеется диалоговое окно для подготовки нового сообщения, в котором
предусмотрены поля для ввода темы и информации о получателе, и, наконец, имеет­
ся кнопка Отправить. Возможно, многие из этих допущений полезны и безопасны, но
они исключают разработку интерфейса, в котором для создания сообщения достаточно
щелкнуть на имени получателя. Кроме того, сценарий этого типа исключает использо­
вание систем распознавания речи в качестве интерфейса системы.
Можно полагать, что гораздо больше почтовых клиентов рассчитаны на работу с тек­
стовыми сообщениями, чем на распознавание речи, но все дело в том, что варианты
использования — не совсем подходящее место для спецификации пользовательских ин­
терфейсов, подобных этому. Лучше подумать о пользовательской истории, которая за­
менит сценарий из рис. 12.2, например “Пользователь может составлять и отправлять
сообщения электронной почты”. В этом утверждении не кроется никаких предположе­
ний относительно интерфейса пользователя. При работе с историями пользовательский
интерфейс станет предметом обсуждения с заказчиком.
Чтобы обойти проблему допущений относительно интерфейса в вариантах исполь­
зования, Константайн и Локвуд [21] выдвинули идею ключевых вариантов использования
V
Часть III. Часто обсуждаемые вопросы
(essential use cases). Ключевыми называют варианты использования, из которых изъяты
любые скрытые допущения относительно технологии и деталей реализации. Например,
в табл. 12.1 представлен вариант использования, соответствующий созданию и отправ­
ке сообщений электронной почты. Интересно отметить, что цели пользователя (user
intentions) в ключевых вариантах использования можно непосредственно интерпретиро­
вать как пользовательские истории.
Таблица 12.1. Ключевой вариант использования
Цель пользователя
Ответственность системы
Составить сообщение электронной почты
Указать получателя (получателей)
Принять содержимое сообщения и информацию
о получателе (получателях)
Отправить сообщение электронной почты
Отправить сообщение
Варианты использования отличаются от пользовательских историй еще и тем, что
цели их написания разные. Варианты использования пишутся в формате, приемлемом
как для заказчиков, так и для разработчиков, чтобы каждый из них мог прочитать их
и прийти относительно них к некоторой договоренности. Их назначение состоит в том,
чтобы документально оформить соглашение между заказчиком и командой разработчи­
ков. С другой стороны, истории пишутся для того, чтобы облегчить планирование выпу­
сков и итераций, а также служат в качестве заполнителей, скрывающих детали потреб­
ностей пользователей, которые будут выясняться в ходе устного обсуждения.
Не все варианты использования записываются путем заполнения формы, как пока­
зано на рис. 12.1. Некоторые из них записываются в виде неструктурированного текста.
Коберн называет их сокращенными вариантами использования (use case briefs), которые
отличаются от пользовательских историй в двух отношениях. Во-первых, посколь­
ку сокращенный вариант должен по-прежнему иметь те же границы применения, что
и обычный вариант использования, границы применения сокращенного варианта обыч­
но шире границ применения пользовательской истории. То есть в одном сокращенном
варианте использования обычно сказано больше, чем в одной истории. Во-вторых, со­
кращенные варианты использования существуют на протяжении всего жизненного цик­
ла продукта, тогда как пользовательские истории просто выбрасываются.
Наконец, варианты использования обычно являются результатом предварительно
проведенного анализа, тогда как пользовательские истории пишутся в виде примеча­
ний, которые можно использовать для аналитических обсуждений.
Пользовательские истории не являются сценариями
Термин сценарий обозначает не только одиночный путь развития событий в варианте
использования. Он применяется также проектировщиками взаимодействия. В данном
контексте сценарий — это подробное описание взаимодействия пользователя с компью­
тером. Сценарии из области проектирования взаимодействия не тождественны сцена­
риям вариантов использования. Первые обычно крупнее, т.е. включают в себя больше,
Глава 12. Чем не являются истории
чем даже вся совокупность сценариев соответствующего варианта использования. Рас­
смотрим, например, следующий сценарий.
Мария подумывает о смене работы. Еще со славных времен зарождения се­
тевого бизнеса и расцвета “доткомов” она работает тестировщиком в ком­
пании BigTechCo. В прошлом учительница математики в средней школе,
Мария решила, что будет более счастлива, если вернется к преподаванию.
Мария заходит на веб-сайт BigMoneyJobs.com. Она создает новую учетную
запись с именем пользователя и паролем и составляет свое резюме. Мария
хочет найти место преподавателя математики в Айдахо, но предпочтительно,
чтобы это было рядом с ее нынешним местом работы в Кер-д’Ален. Она на­
шла много предложений, удовлетворяющих заданным ею критериям поис­
ка. Больше всего ее заинтересовала вакансия в North Shore School — частной
средней школе в Бойсе. В этом городе у нее есть подруга Джессика, которая,
как она надеется, может быть знакома с кем-нибудь из преподавательско­
го состава школы. Мария вводит адрес электронной почты Джессики и от­
правляет ссылку на объявление вместе с просьбой ответить, не работают ли
в этой школе ее знакомые. На следующее утро Мария получает ответное
письмо от Д жессики, в котором та сообщает, что в этой школе у нее знако­
мых нет, но она знает, что у школы прекрасная репутация. Мария щелкает на
кнопке и отправляет свое резюме в North Shore School.
Кэрролл [12] пишет, что сценарии включают следующие характерные элементы:
• место действия;
• персонажи;
• цели или задачи;
• действия и события.
Место действия — это место, в котором разворачиваются события истории. В исто­
рии о Марии действие предположительно происходит за ее домашним компьютером, но
поскольку об этом ничего не сказано в явном виде, местом действия в равной степени
может быть ее офис на протяжении рабочего дня.
В каждом сценарии фигурирует по крайней мере один персонаж. В сценарии может
также быть несколько персонажей. Например, в нашем сценарии персонажами являют­
ся Мария и Джессика. Марию можно назвать главным персонажем (primary actor), так
как именно ее взаимодействие с системой описывает сценарий. Поскольку Джессика
получает электронную почту от системы, а затем использует веб-сайт для просмотра
объявлений о вакансии, она является вспомогательным персонажем (secondary actor).
В отличие от вариантов использования, персонажами в сценариях проектирования вза­
имодействий всегда являются люди, а не другие системы.
Каждый персонаж сценария преследует одну или несколько целей. Как и персонажи,
цели могут быть главными и второстепенными. Например, главная цель Марии состоит
в том, чтобы найти подходящую работу в желаемом месте. Однако в процессе такого
поиска у нее может возникнуть необходимость в параллельном решении других задач.
Например, ей может понадобиться просмотреть подробную информацию о гостинице
или обменяться электронными письмами с подругой.
Кэрролл называет действия и события сюжетом сценария. Это те шаги, которые пер­
сонаж предпринимает для достижения своей цели или для получения отклика от системы.
Часть III. Часто обсуждаемые вопросы
Действием, которое совершает Мария, является поиск работы в Айдахо. Откликом на
это действие является отображения системой списка предложений, удовлетворяющих
заданным критериям поиска.
Основные различия между историями и сценариями касаются их границ примене­
ния и степени детализации. Сценарии содержат намного больше деталей, а по масштабу
обычно охватывают несколько историй. Примером сценария, содержащего несколько
историй, может служить следующий:
• пользователь может отправить информацию о работе своему другу по электрон­
ной почте;
• пользователь может создать резюме;
• пользователь может отправить свое резюме на веб-сайт для получения подходя­
щей работы;
• пользователь может осуществлять поиск вакансий, относящихся к конкретному
региону.
Даже с учетом содержащихся в них дополнительных деталей, сценарии (как и исто­
рии) опускают некоторые детали для их дальнейшего устного обсуждения.
• Мария вошла на сайт с именем пользователя и паролем. Всем ли пользователям
необходимо выполнять процедуру входа на сайт? А может быть, регистрация
на сайте открывает доступ к некоторым возможностям, которые использовала
Мария (например, возможность отправки электронной почты)?
• Что именно содержится в полученном Джессикой сообщении электронной почты:
информация о работе или просто ссылка на страницу сайта с этой информацией?
Резюме
• Пользовательские истории отличаются от спецификаций требований к программ­
ному обеспечению IEEE 830, вариантов использования и сценариев проектирова­
ния взаимодействия.
• Как ни старайтесь, невозможно заранее продумать полную и совершенную во
всех отношениях спецификацию любой нетривиальной системы.
• Предоставление пользователям частого доступа к программному обеспечению
уже на ранних стадиях разработки создает мощную обратную связь с ними, кото­
рая благотворно сказывается на процессе определения требований к программно­
му продукту.
• Гораздо важнее думать о целях пользователей, чем о перечне атрибутов программ­
ного решения.
• Пользовательские истории аналогичны сценариям вариантов использования.
Вместе с тем, типичные варианты использования характеризуются большим, по
сравнению с отдельной историей, размером и могут содержать скрытые предпо­
ложения относительно пользовательского интерфейса.
• Дополнительные различия между пользовательскими историями и варианта­
ми использования касаются степени завершенности и долговечности. Варианты
Глава 12. Чем не являются истории
использования пишутся таким образом, чтобы разработчики и заказчики мог­
ли обсуждать их и приходить к некоторому соглашению относительно них.
Пользовательские же истории призваны облегчить планирование выпусков и слу­
жат напоминаниями о тех деталях требований к продукту, которые были опущены
и требуют уточнения в процессе устных обсуждений.
• В отличие от спецификаций IEEE 830 и вариантов использования, пользователь­
ские истории являются не артефактами предварительно проведенного анализа
требований, а, скорее, инструментом такого анализа.
• Сценарии проектирования взаимодействия имеют гораздо большую степень де­
тализации по сравнению с пользовательскими историями и отличаются от них
характером представленных деталей.
• Размер типичного сценария взаимодействия намного больше размера пользова­
тельской истории. Один сценарий может охватывать несколько вариантов ис­
пользования, которые, в свою очередь, могут включать в себя много пользова­
тельских историй.
Контрольные вопросы
12.1. В чем состоят ключевые различия между пользовательскими историями и вариан­
тами использования?
12.2. В чем состоят ключевые различия между пользовательскими историями и специ­
фикациями требований IEEE 830?
12.3. В чем состоят ключевые различия между пользовательскими историями и сцена­
риями проектирования взаимодействия?
12.4. Почему невозможно заранее определить абсолютно все требования для скольконибудь серьезного проекта?
12.5. Почему гораздо плодотворнее думать о целях, которые преследуют пользователи,
чем о списке атрибутов создаваемого программного обеспечения?
Глава 13
Зачем нужны пользовательские
истории
Учитывая многообразие доступных методов установления требований к программному
обеспечению, возникает естественный вопрос: почему мы должны выбирать именно
пользовательские истории? В этой главе анализируются следующие преимущества поль­
зовательских историй по сравнению с альтернативными подходами:
• пользовательские истории делают особый акцент на устном общении;
• пользовательские истории понятны каждому;
• пользовательские истории имеют подходящий размер для планирования;
• пользовательские истории пригодны для итеративной разработки;
• пользовательские истории стимулируют откладывать рассмотрение деталей на бо­
лее поздние этапы разработки;
• пользовательские истории поддерживают спонтанную разработку;
• пользовательские истории стимулируют совместное проектирование;
• пользовательские истории способствуют достижению взаимопонимания внутри
команды.
После того как будут рассмотрены преимущества пользовательских историй по срав­
нению с другими возможными подходами, будет также указан ряд потенциальных недо­
статков таких историй.
Устное общение
Замечательный человеческий опыт устных преданий насчитывает не одно тысячеле­
тие. Мифы и легенды передавались из уст в уста от одного поколения к другому. До тех
пор пока правитель Афин не начал записывать гомеровскую Илиаду, чтобы не допустить
ее забвения потомками, истории, подобные гомеровским, передавались в виде устных
преданий. Должно быть, раньше люди обладали гораздо лучшей памятью, но посте­
пенно утрачивали эту способность, поскольку уже в 70-х годах прошлого столетия нам
стоило большого труда запоминать даже такие короткие фразы, как “Система должна
предлагать пользователю ввести имя и пароль для входа”. Потому-то мы и были вынуж­
дены их записывать.
Именно тогда мы и сбились с пути истинного. Вместо того чтобы сосредоточиться
на достижении взаимопонимания с заказчиком, мы сместили фокус нашего внимания
в сторону обмена документацией.
Часть III. Часто обсуждаемые вопросы
Вполне естественно думать, что если все записано и согласовано, то не может быть
никаких разногласий, разработчики будут точно знать, что им делать, тестировщики бу­
дут точно знать, как им тестировать продукт, но что самое главное — заказчики получат
то, что хотели. Вот тут-то и зарыта собака: заказчики получат вовсе не то, что они хоте­
ли, а то, что было записано и проинтерпретировано разработчиками.
Со стороны может показаться, будто нет ничего особенно сложного в том, чтобы на­
писать объемистый список требований к программе и поручить команде разработчиков
создать в точности то, что вы хотите. Но если даже точность формулировки обеденного
меню иногда оборачивается проблемой для нас, то что уж говорить о написании тре­
бований к программному обеспечению. Одна из записей моего меню вполне могла бы
выглядеть следующим образом:
“Для начала суп или салат и хлеб”.
Вряд ли можно было ожидать, что с пониманием смысла этого предложения возник­
нут какие-либо трудности, но здесь как раз тот случай. Какой именно из следующих
вариантов выбора я имел в виду:
“...суп или (салат и хлеб)” или “...(суп или салат) и хлеб”?
Мы часто действуем так, словно написанные слова точно передают вкладываемый
в них смысл, но это далеко не так. Сравните, например, то, что записано в этом меню,
со словами обращающейся к вам официантки: “Что вы хотите заказать: суп или салат?”
Более того, официантка вообще устранит какую бы то ни было неоднозначность, поста­
вив на стол наполненную хлебницу перед тем, как принимать заказ.
Не меньшие неприятности доставляют слова, имеющие несколько значений. В каче­
стве утрированного примера рассмотрим следующие два предложения:
“Buffalo buffalo buffalo”.
“Buffalo buffalo Buffalo buffalo”.
Ничего себе! Что вообще означает эта абракадабра? Слово Buffalo может означать
либо крупное животное с густой шерстью (бизона), либо название города в штате НьюЙорк, либо глагол запугивать. Поэтому первое предложение означает, что один бизон за­
пугивает другого. Второе предложение означает, что один бизон запугивает другого бизона
из города Буффало.
Конечно, этот пример не совсем уместен, если только мы не пишем программу для
бизонов, но чем он хуже следующего типичного положения требований?
• Система должна выводить хорошо различимое предупреждение всякий раз, когда
пользователь вводит недопустимые данные.
Означает ли слово должна, что данным требованием при желании можно прене­
бречь? Я должен есть овощи три раза в день — а я не ем! Что означает хорошо различи­
мое? То, что является хорошо различимым для того, кто это написал, может быть совсем
незаметным для разработчика или тестировщика.
Приведу еще один пример. Недавно мне встретилось одно требование, относящееся
к возможности пользователя ввести имя папки в системе управления данными.
• Пользователь может ввести имя папки. Имя может содержать 127 символов.
Это утверждение оставляет невыясненным вопрос о том, должен ли пользователь
вводить имя папки, ибо оно допускает трактовку, что пользователь может и не вводить
имени папки, и в этом случае будет использовано имя по умолчанию. Второе предложе-
Глава 13. Зачем нужны пользовательские истории
ние вообще почти ничего не означает. Может ли имя папки бьггь другой длины или оно
всегда должно состоять из 127 символов?
В записывании формулировок есть свои преимущества: запись слов помогает прео­
долеть ограничения кратковременной памяти, нивелирует влияние отвлекающих и пре­
рывающих факторов. Но как же много источников двусмысленности — то ли из-за
недостаточной точности записанных слов, то ли из-за того, что многие слова имеют не­
сколько значений, — исчезают, как только мы смещаем центр внимания от написания
требований к их устному обсуждению.
Разумеется, некоторые проблемы естественного языка в равной степени свойствен­
ны как письменной, так и устной формам общения, но общий разговор заказчиков, раз­
работчиков и пользователей создает благоприятные условия для образования тесной об­
ратной связи между ними, которая ведет к взаимному обучению и взаимопониманию.
В живом разговоре отсутствует ложная видимость точности и непогрешимости, возни­
кающая при соприкосновении с чем-то, изложенным на письме. На разговоре никто не
поставит свою подпись и никогда не скажет: “Вот, смотри, три месяца назад, во втор­
ник, ты сказал, что пароль не может содержать цифр!”
При работе с пользовательскими историями наша цель состоит не в том, чтобы
описать требуемую возможность в мельчайших подробностях. Скорее, мы записыва­
ем несколько коротких предложений-заполнителей, которые напомнят разработчи­
кам и заказчикам, что именно им еще предстоит обсудить. Многие вещи я обсуждаю
по электронной почте, и без этого, вероятно, я просто не смог бы работать. Я получаю
и отправляю сотни писем ежедневно. Но если мне нужно обсудить с кем-то сложные
вещи, я неизменно берусь за телефонную трубку или иду к этому человеку в офис или
встречаюсь с ним на его рабочем месте.
Программа одной недавней конференции, посвященной традиционным методам
подготовки требований, предусматривала проведение в течение половины дня прак­
тического семинара по написанию “идеальных требований”, на котором нас обещали
научить владеть улучшенным стилем изложения, позволяющим определять идеальные
требования. Написание идеальных требований представляется этакой эфемерной и не­
достижимой целью.
Но даже если каждое предложение документированных требований идеально, оста­
ются еще две проблемы. Во-первых, по мере все большего ознакомления с разрабаты­
ваемым продуктом пользователи будут непрерывно уточнять свое мнение. Во-вторых,
простое объединение идеальных отдельных частей в одно целое еще не означает, что по­
лученное целое тоже будет идеальным. Том Поппендик напомнил мне пословицу о том,
что даже из 100 идеальных левых ботинок невозможно подобрать хотя бы одну идеаль­
ную пару. Вместо того чтобы стремиться создавать идеальные требования, лучше допол­
нить подходящие истории частыми обсуждениями.
Пользовательские истории понятны
Одним из преимуществ вариантов использования и сценариев по сравнению с тре­
бованиями к программному обеспечению, соответствующими стандарту IEEE 830, яв­
ляется то, что они понятны как пользователям, так и разработчикам. Документы в сти­
ле IEEE 830 часто пестрят техническим жаргоном, непонятным для пользователей, или
специфическими для данной предметной области терминами, непонятными для разра­
ботчиков.
V
Часть III. Часто обсуждаемые вопросы
Истории представляют собой еще один шаг вперед, являясь даже более понятными,
чем варианты использования или сценарии. Константайн и Локвуд [21] заметили, что
присущий сценариям акцент на реализме и деталях может мешать видению общей кар­
тины. При работе со сценариями это затрудняет понимание основной природы взаимо­
действий. Поскольку истории отличаются сжатостью изложения и всегда пишутся так,
чтобы была отчетливо видна их ценность для заказчика или пользователя, их без труда
понимают как представители бизнеса, так и разработчики.
К тому же проведенное в конце 70-х годов прошлого столетия исследование пока­
зало, что человеческий мозг лучше запоминает события, если они организованы в виде
повествовательных историй [10]. Более того, участники этого исследования лучше запо­
минали как четко установленные, так и предполагаемые действия. Таким образом, исто­
рии способствуют запоминанию не только обозначенных действий, но и тех, которые
подразумеваются. Пользовательские истории, которые мы пишем, могут быть еще более
краткими, чем традиционные спецификации требований или даже варианты использо­
вания, а поскольку они пишутся и обсуждаются так, словно это обычные истории, запо­
минаются они лучше.
Размер пользовательских историй делает
их удобными для планирования
Помимо всего прочего, у пользовательских историй именно тот размер, который ну­
жен для планирования, — и не слишком большой, и не слишком маленький, а в самый
раз. На определенном этапе своей карьеры большинству разработчиков приходится об­
ращаться к заказчику или пользователю с просьбой установить приоритеты для требова­
ний, подготовленных в соответствии со стандартом IEEE 830. Обычный результат — 90%
требований обязательны, 5% весьма желательны, но могут быть отложены на короткий
срок, а еще 5% — отложены на более длительный срок. Так происходит потому, что не­
легко осмыслить и проранжировать тысячи предложений, каждое из которых начинает­
ся словами “Система должна...”. Взгляните на приведенный ниже пример требований.
4.6. Система должна поддерживать бронирование гостиничного номера с по­
мощью кредитной карты.
4.6.1. Система должна принимать платежные карты Visa, MasterCard и Ame­
rican Express.
4.6.1.1. Система должна проверять, не просрочена ли платежная карта.
4.6.2. Система должна снимать деньги с платежной карты в соответствии
с указанными расценками, прежде чем будет подтверждено бронирова­
ние номера.
4.7. Система должна предоставлять пользователю уникальный подтверждаю­
щий код.
Уровни вложенности в спецификациях требований по стандарту IEEE 830 указыва­
ют на то, как соотносятся между собой отдельные положения требований. Нереально
думать, будто в данном примере заказчик сможет установить приоритет для п. 4.6.1.1 не­
зависимо от п. 4.6.1. Если некоторые пункты требований невозможно ранжировать или
разработать по отдельности, то, возможно, их не следует и записывать отдельно. Если
Глава 13. Зачем нужны пользовательские истории
же они записаны по отдельности лишь для того, чтобы их можно было тестировать по
одному, то не лучше ли написать непосредственно сами тесты?
Когда приходится рассматривать тысячи или десятки тысяч положений специфика­
ции требований к программному обеспечению (а также отношений между ними), при­
сущие им трудности процедуры присвоения приоритетов становятся очевидными.
Вариантам использования и сценариям взаимодействия свойствен другой недоста­
ток — большие размеры. Иногда ранжирование нескольких десятков вариантов исполь­
зования или сценариев дается сравнительно несложно, но результатами этого зачастую
нельзя воспользоваться, поскольку редко случается так, чтобы все пункты, обладающие
высшим приоритетом, были важнее всех пунктов с более низким приоритетом. Во мно­
гих проектах делались попытки исправления подобных ситуаций путем написания мно­
жества меньших по размеру вариантов использования, но ни к чему хорошему это не
приводило.
Истории же, благодаря своей компактности, могут эффективно использоваться при
планировании, а разработчикам удобно их программировать и тестировать.
Пользовательские истории пригодны
для итеративной разработки
Огромным преимуществом пользовательских историй является их совместимость
с итеративной разработкой. Не требуется предварительно составлять все истории, пре­
жде чем начать писать исходный код первой из них. Я могу написать несколько исто­
рий, закодировать их и протестировать, а затем повторить подобный процесс по мере
необходимости. При написании историй я могу придерживаться любого подходящего
уровня детализации. Истории хорошо прижились в итеративной разработке, поскольку
сами они легко поддаются итерированию.
Например, если я только приступаю к обдумыванию проекта, то могу написать эпи­
ческие истории наподобие “пользователь может подготовить и отправить сообщение
электронной почты”. Для ранней стадии планирования этого может оказаться вполне
достаточно. Позже я смогу разбить данную историю хоть на десяток других примерно
следующим образом.
• Пользователь может создать сообщение электронной почты.
• Пользователь может включать в электронные сообщения графику.
• Пользователь может отправлять сообщения электронной почты.
• Пользователь может составить расписание, по которому электронная почта будет
отправляться в определенное время.
Сценарии и документы IEEE 830 не допускают такой детализации в процессе разра­
ботки. Сам способ написания документов IEEE 830 подразумевает, что отсутствие поло­
жения, гласящего о некой возможности “Система должна...”, означает, что в системе эта
возможность не должна быть реализована. Поэтому мы не можем обоснованно судить,
отсутствует ли данное требование или оно попросту еще не написано.
Мощь сценариев кроется в обеспечиваемой ими детализации. Поэтому идея начать
сценарий, не углубляясь в детали, а затем дать возможность разработчику постепенно
вводить их по мере необходимости, не имеет смысла и полностью лишает сценарии
присущих им полезных свойств.
V
Часть III. Часто обсуждаемые вопросы
При написании вариантов использования можно применять различную степень де­
тализации, и Коберн [16] предложил для этого великолепные способы. Однако, вместо
того чтобы писать варианты использования в свободной форме, большинство организа­
ций определяет стандартный шаблон. Все варианты использования в данной организа­
ции обязаны следовать этому шаблону. Когда у множества людей возникает ощущение,
будто их вынуждают заполнять каждое пустующее поле в форме, это становится про­
блемой. На практике лишь немногие организации способны подготовить одни варианты
использования на уровне резюме, а другие — на детальном уровне. Пользовательские
истории воспринимаются всеми положительно, поскольку (по крайней мере, до сих
пор) никем пока еще не предложен шаблон с полями, которые должны были бы запол­
няться для каждой истории.
Истории стимулируют откладывать разработку
деталей на более поздние этапы
Преимуществом пользовательских историй является также то, что они стимулиру­
ют команду откладывать сбор деталей. Начальную историю-заполнитель на уровне цели
(“Рекрутер может опубликовать новую вакансию”) можно написать, а затем заменить
более детальными историями, как только детали станут важными.
Благодаря этому свойству пользовательские истории отлично подходят для проектов,
ограниченных во времени. Команда может очень быстро написать несколько десятков
историй, что позволит разработчикам в целом “почувствовать” систему. После этого они
смогут погрузиться в детали в нескольких историях и приступить к написанию кода го­
раздо быстрее, чем команда, которую заставляли заполнять спецификацию требований
в стиле IEEE 830.
Истории поддерживают спонтанную разработку
Всегда возникает соблазн верить в то, что можно сначала записать все требования
к системе, а затем продумать способ построения решения по принципу “сверху вниз”.
Примерно два десятилетия назад Парнас и Клементс [43] подчеркнули, что ни один
проект не может следовать этому пути по причинам, которые перечислены ниже.
• Как правило, сами пользователи и заказчики не понимают, чего они хотят.
• Даже если разработчикам программного обеспечения известны все требования,
многие детали, без знания которых невозможно разработать программный про­
дукт, проясняются лишь по мере разработки системы.
• Даже если бы все детали были заранее известны, человек не в состоянии осмыс­
лить их в таком количестве одновременно.
• Даже если бы мы могли разобраться во всех деталях, продукт и проект претерпе­
вают изменения.
• Людям свойственно ошибаться.
Если построение программного обеспечения в строгом соответствии с принципом
“сверху вниз” невозможно, то как мы его создаем? Гуиндон [30] провел исследование,
Глава 13. Зачем нужны пользовательские истории
в котором выяснял, какой подход используют разработчики программного обеспечения
для решения стоящих перед ними задач. В исследовании принимала участие небольшая
группа разработчиков, которые должны были спроектировать систему управления лиф­
том. Разработчики находились под постоянным наблюдением, а весь процесс снимался
на видео. Было установлено, что разработчики вообще не придерживались принципа
разработки “сверху вниз”, а следовали спонтанному подходу, при котором свободно пе­
реходили от рассмотрения требований к продумыванию и обсуждению сценариев ис­
пользования и далее к проектированию на различных уровнях абстракции. Как только
у разработчиков появлялась возможность обменяться мнениями, они незамедлительно
ею пользовались.
Истории позволяют преодолеть проблемы, указанные Парнасом и Клементсом. По­
скольку истории предполагают последующее интенсивное обсуждение и их легко писать
и переписывать на различных уровнях детализации, они обеспечивают решение, обла­
дающее следующими особенностями.
• Оно не основано на той предпосылке, будто пользователи способны в полной
мере осознать свои потребности и точно их описать.
• Оно не основано на той предпосылке, будто разработчики способны полностью
разобраться в широком разнообразии деталей.
• Оно допускает внесение изменений на любой стадии.
В этом смысле само существование историй подтверждает тот факт, что в основе раз­
работки программного обеспечения должен лежать принцип гибкости. Поскольку ни
один процесс не может развиваться строго прямолинейно от высокоуровневых требова­
ний до написания кода, пользовательские истории дают команде возможность без труда
переходить от размышлений над различными уровнями разработки к обсуждению тре­
бований и наоборот.
Пользовательские истории стимулируют
совместное проектирование
Истории, как и сценарии, обладают притягательной силой. Смещая фокус внимания
от разговоров относительно атрибутов системы к историям о целях, которые преследуют
пользователи в процессе использования продукта, они приводят к более интересному
обсуждению системы. Многие проекты провалились потому, что в них не участвовали
пользователи, тогда как истории позволяют легко привлекать пользователей к участию
в проектировании предназначенного для них же программного обеспечения.
Совместное проектирование (participatory design) [39], [48] предполагает, что пользова­
тели системы становятся частью команды, проектирующей поведение их системы. Такое
участие не диктуется кем-то сверху; пользователи становятся частью команды только
потому, что имеют самое непосредственное отношение к требованиям и используемой
методике проектирования. Так, при совместном проектировании пользователи вовлека­
ются в прототипирование пользовательского интерфейса сразу же, не дожидаясь, пока
им будет предоставлен для ознакомления первоначальный вариант прототипа.
Противоположностью совместному проектированию является эмпирическое проекти­
рование (empiric design), отличительной чертой которого является то, что разработчики
принимают решения, исходя из результатов наблюдения за предполагаемыми пользова-
Часть III. Часто обсуждаемые вопросы
телями и ситуациями, в которых программный продукт будет использоваться. В этом ме­
тоде интенсивно применяется опрос пользователей и наблюдение за их поведением, но
пользователи при этом не становятся истинными участниками процесса проектирования.
Ввиду того, что в пользовательских историях и сценариях полностью отсутствует тех­
нический жаргон, они совершенно понятны и пользователям, и заказчикам. Несмотря
на то что в хорошо написанных вариантах использования тоже можно избежать при­
менения технического жаргона, их читатели должны быть, как правило, знакомы со
спецификой используемого при этом формата. Лишь немногие из тех, кто впервые стал­
кивается с вариантами использования, хорошо понимают смысл таких часто встречаю­
щихся в них полей, как расширения (extensions), предусловия (preconditions) и гарантии
(guarantees). Типичные же требования в стиле IEEE 830 не только допускают включение
технической терминологии, но и с трудом воспринимаются из-за больших размеров со­
ответствующего иерархически структурированного документа.
Большая доступность историй и сценариев побуждает пользователей становиться
активными участниками процесса проектирования. Кроме того, по мере привыкания
пользователей к новому для них способу описания своих пожеланий в виде историй,
непосредственно используемых разработчиками, последние еще активнее привлекают
пользователей к работе. Такое эффективное взаимодействие выгодно для всех, кто во­
влечен в разработку или использование программного обеспечения.
Работа с историями способствует обмену опытом
Поскольку в работе с историями основной упор делается на личном общении участ­
ников проекта, истории способствуют достижению взаимопонимания внутри команды.
Чем интенсивнее проекты обсуждаются разработчиками и заказчиками, тем лучше чле­
ны команды понимают друг друга и тем эффективнее может быть выполнена работа.
Когда истории могут быть неэффективными
Ознакомившись с рядом причин, по которым истории могут считаться эффективным
подходом к определению требований для agile-проектов, рассмотрим их недостатки.
Одна из проблем состоит в том, что в случае больших проектов со множеством исто­
рий отслеживание взаимосвязей между ними становится затруднительным. Остроту
этой проблемы можно снизить за счет введения пользовательских ролей и поддержа­
ния историй на среднем или высоком уровне до тех пор, пока команда не будет готова
к тому, чтобы приступить к их разработке. Варианты использования обладают присущей
им иерархией, облегчающей работу с большими объемами требований. Посредством
входящих в него основного успешного сценария и расширений один вариант использо­
вания может вобрать в себя множество пользовательских историй, которые в силу этого
окажутся структурированными в виде одной сущности.
Другая проблема, связанная с пользовательскими историями, заключается в том,
что, когда трассируемость требований является обязательным условием вашего процесса
разработки, вам, возможно, понадобится присоединить к историям дополнительную до­
кументацию. К счастью, обычно это делается очень просто. Например, в одном проекте,
где мы выступали в качестве субподрядчика для одной крупной компании, имеющей
сертификат ISO 9001, от нас потребовали продемонстрировать возможность трассиров-
Глава 13. Зачем нужны пользовательские истории
ки проекта от требований до тестов. Мы добились этого очень простым способом. В на­
чале каждой итерации создавался документ, содержащий каждую историю, выполнение
которой было запланировано на данную итерацию. По мере разработки тестов их имена
добавлялись в этот документ. Документ обновлялся путем внесения записей о добавле­
нии или удалении историй на данной итерации. Ежемесячно у нас уходило на это около
одного часа.
Наконец, несмотря на то что истории — это фантастическое средство для обмена
опытом внутри команды, в случае больших команд данный подход может не работать.
Однако еще неизвестно, что лучше — множество людей, знающих немногое (из пись­
менной документации, требующей длительного изучения), или небольшое количество
людей, знающих многое (из личного общения с другими людьми, требующего лишь не­
значительных затрат времени).
Резюме
• Пользовательские истории смещают акцент в сторону устного общения. В отли­
чие от других методов определения требований, полностью основанных на ис­
пользовании письменной документации, пользовательские истории отводят зна­
чительную роль обсуждениям между разработчиками и заказчиками.
• Смещение акцента в сторону устного общения обеспечивает быструю обратную
связь между разработчиками с одной стороны и заказчиками или пользователя­
ми — с другой, что способствует достижению лучшего взаимопонимания между
ними.
• Пользовательские истории понятны как разработчикам, так и пользователям.
Спецификации требований к программному обеспечению в стиле IEEE 830, как
правило, перенасыщены техническим или деловым жаргоном.
• Размер пользовательских историй, границы которых обычно уже границ вариан­
тов использования и сценариев, но шире границ утверждений IEEE 830, хорошо
подходит для планирования. Планирование, а также программирование и тести­
рование историй могут осуществляться без какого-либо их дальнейшего объеди­
нения или разбиения.
• Пользовательские истории хорошо вписываются в итеративную разработку, по­
скольку можно легко начать с эпической истории, а затем расчленить ее на не­
сколько пользовательских историй меньшего размера.
• Пользовательские истории стимулируют откладывать рассмотрение деталей на
более поздние периоды. Отдельные пользовательские истории можно написать
очень быстро, а кроме того, чрезвычайно просто писать истории различного раз­
мера. Менее значимые аспекты, т.е. те, которые не будут разрабатываться сра­
зу же, достаточно оставить в виде эпических историй, тогда как другие истории
можно написать более подробно.
• Пользовательские истории стимулируют разработку со свободным принятием
решений, при которой команда может легко смещать точку приложения усилий
между высоким и низким уровнями детализации, в зависимости от обстоятельств.
• Пользовательские истории способствуют обмену опытом между членами команды.
Часть III. Часто обсуждаемые вопросы
• Пользовательские истории стимулируют не эмпирическое проектирование, а со­
вместное, при котором пользователи становятся активными и полноправными
участниками проектирования поведения программного обеспечения.
• Несмотря на то что для использования историй существует множество причин,
у них есть и определенные недостатки. В больших проектах могут возникать труд­
ности с организацией хранения сотен и тысяч историй. Может понадобиться до­
полнять истории вспомогательной документацией, обеспечивающей трассировку
требований. И несмотря на замечательные возможности обмена знаниями о про­
екте в процессе личного общения, обсуждения не могут полностью заменить до­
кументацию в больших проектах.
Обязанности разработчика
• Вы обязаны принимать осознанные решения при выборе какой бы то ни было
методики. Если команда принимает решение об использовании историй, вы обя­
заны понимать, почему было принято такое решение.
• Вы обязаны знать о преимуществах других методов определения требований,
а также уметь определять, когда использование какого-либо из них становится
целесообразным. Например, если вы работаете с заказчиком и вам не удается
найти с ним взаимопонимание относительно какой-либо возможности, то не ис­
ключено, что в этой ситуации вас может выручить обсуждение сценария проекти­
рования взаимодействия или разработка варианта использования.
Обязанности заказчика
• Одним из наибольших преимуществ пользовательских историй, по сравнению
с другими подходами к определению требований, является то, что они стимули­
руют совместное проектирование. Вы обязаны становиться активным участником
проектирования всего того, что будет делать ваше программное обеспечение.
Контрольные вопросы
13.1. Назовите четыре веские причины использования историй для выражения требо­
ваний.
13.2. Каковы могут быть два нежелательных последствия использования историй?
13.3. В чем состоит ключевое различие между совместным и эмпирическим подходами
к проектированию?
13.4. Что не так сформулировано в следующем требовании: “Все страницы многостра­
ничных отчетов должны нумероваться”?
Глава 14
Каталог запахов историй
В этой главе будет представлен каталог “дурных запахов”, т.е. индикаторов того, что
в процессе применения историй к проекту кое-что упущено. Ниже представлено описа­
ние каждого “запаха” с приведением одного или нескольких соответствующих решений.
Заниженный размер историй
Симптомы. Часто возникает необходимость в пересмотре оценок.
Обсуждение. Небольшой размер историй часто становится причиной трудностей
с оценкой и планированием историй. Это происходит из-за того, что оценки, присвоен­
ные небольшим историям, могут резко меняться в зависимости от очередности, в кото­
рой реализуются истории. Рассмотрим, например, следующие две небольшие истории.
• Результаты поиска можно сохранить в виде XML-файла.
• Результаты поиска можно сохранить в виде HTML-файла.
Совершенно очевидно, что эти истории в значительной мере пересекаются. Время,
затраченное на одну из них, сократит время, затрачиваемое на другую историю.
Истории, подобные этим, следует объединять в целях планирования. При включении
истории в итерацию ее можно будет разбить на несколько меньших историй, но до тех
пор, пока в этом нет прямой необходимости, их следует оставлять объединенными.
Взаимозависимые истории
Симптомы. Трудности с планированием итераций из-за зависимостей между исто­
риями.
Обсуждение. Если несколько историй зависят друг от друга, возникают трудности
с их планированием по итерациям. Команда оказывается в ситуации, когда включение
одной истории в итерацию требует одновременного включения и другой истории в ту же
итерацию. Но та история, в свою очередь, требует включения третьей истории и т.д. Это
происходит, когда истории либо слишком малы, либо разбиты неподходящим образом.
Если возникли подозрения, что истории слишком малы, то простейшим выходом бу­
дет объединение взаимозависимых историй в одну. Если же во всех остальных отноше­
ниях размер историй вполне подходящий, посмотрите, по какому принципу были разде­
лены взаимозависимые истории. В главе 7 уже обращалось внимание на то, что истории
следует разбивать таким образом, чтобы результаты разбиения представляли “целые ку­
ски пирога”, т.е. включали функциональность со всех уровней приложения.
Часть III. Часто обсуждаемые вопросы
Украшательство
Симптомы. Разработчики добавляют возможности, которые не были запланированы
для итерации, или допускают свободную интерпретацию историй и выходят за рамки
того, что необходимо для реализации истории.
Обсуждение. Украшательством (goldplating) называют добавление разработчиками
возможностей, в которых нет необходимости. Некоторые разработчики склонны к тому,
чтобы по собственной инициативе вводить улучшения или выходить за рамки того, что
требуется для удовлетворения установленных потребностей заказчика. Это может проис­
ходить по нескольким причинам. Во-первых, некоторым разработчикам нравится “по­
ражать” заказчиков, а если с заказчиком налажено тесное ежедневное сотрудничество,
то сделать ему “неожиданный сюрприз” и вызвать восторженные возгласы, столь при­
ятные сердцу некоторых разработчиков, становится труднее.
Во-вторых, участвуя в управляемых историями agile-проектах с короткими итера­
циями, разработчики обычно испытывают значительное давление, цель которого — за­
ставить их постоянно выдавать результаты. Украшательство позволяет разработчикам
на короткое время избавиться от этого давления. В конце концов, если данная возмож­
ность не будет вовремя закончена, то никто даже не узнает о том, что ее разработка во­
обще начиналась.
Наконец, разработчикам доставляет удовольствие ставить на проекте собственную
“фирменную метку”, и добавление нескольких “безделушек” является одним из спосо­
бов достижения этой цели.
▼------------------------------------------------------------------------------▼
Пример украшательства
В одном проекте, в котором я участвовал, мы работали с историей, предназначен­
ной для того, чтобы избавиться от перегруженного экрана и ввести вместо него диа­
логовое окно с вкладками, повысив тем самым удобство использования программы.
Закончив вносить это изменение, разработчик улучшил низкоуровневый код вкладки
в данном приложении таким образом, чтобы ее можно было переместить в другое ме­
сто на экране. Заказчик об этом не просил. Разработчики всегда должны концентриро­
вать свои усилия на историях, которым заказчик отдает приоритет. Если у разработчика
возникла замечательная идея новой истории, он должен обсудить с заказчиком воз­
можность ее включения в следующую итерацию.
▲------------------------------------------------------------------------------▲
Если разработчики проекта чрезмерно увлекаются украшательством, от этого мож­
но избавиться, повысив прозрачность задач, над которыми работает каждый разработ­
чик, Например, проводите ежедневные брифинги, где каждый рассказывает, над чем он
в данный момент работает. Такая прозрачность обеспечивает своеобразный самокон­
троль в команде и затрудняет занятия украшательством.
Точно так же выявить элементы украшательства помогут итоговые собрания коман­
ды по завершении итерации, на которых заказчику и другим заинтересованным лицам
новая функциональность демонстрируется во всех подробностях. Вносить исправления
на этой итерации будет уже слишком поздно, но зато на следующей итерации никто
украшательством заниматься не будет.
Наконец, если в проекте предусмотрена группа контроля качества, то ее сотрудники
также могут помочь с выявлением случаев украшательства, особенно если они участву­
ют в обсуждениях между программистами и заказчиком.
Глава 14. Каталог запахов историй
Чрезмерное количество деталей
Симптомы. Тратится слишком много времени на сбор деталей задолго до начала реа­
лизации истории, а на написание историй тратится больше времени, чем на их обсуж­
дение.
Обсуждение. Одним из преимуществ написания историй на небольших карточках яв­
ляется то, что места на таких карточках не так уж много. На ней вам не удастся описать
множество деталей. Включение чрезмерного количества деталей в историю может сви­
детельствовать о том, что документации уделяется слишком много внимания и предпо­
чтение отдается ей, а не обсуждению.
Том Поппендик [45] заметил: “Если вам не хватает места, используйте еще меньшие
карточки”. Это блестящая идея, поскольку она заставляет авторов историй сознательно
включать меньше деталей в истории.
Преждевременное включение деталей
пользовательского интерфейса
Симптомы. В проекте (особенно если это проект разработки нового продукта) слиш­
ком рано написаны истории, включающие детали пользовательского интерфейса.
Обсуждение. На некоторой стадии проекта команда, несомненно, напишет пользо­
вательские истории с непосредственными допущениями относительно деталей пользо­
вательского интерфейса (или с точным их описанием), например “Соискатель может
просмотреть информацию о компании, предлагающей работу, на странице Описание
вакансии”. Однако вы должны как можно дольше воздерживаться от написания исто­
рий с таким уровнем детализации.
На ранних стадиях проекта вам еще не известно, что будет существовать страница
Описание вакансии, поэтому не ограничивайте проект, связывая истории с этой стра­
ницей. Вместо приведенной выше истории напишите другую: ’’При просмотре подроб­
ного описания вакансии Соискатель может просмотреть информацию о компании,
предлагающей работу”.
Опережение событий
Симптомы. Истории с трудом умещаются на карточках; вместо карточек хочется ис­
пользовать программное обеспечение, причем это желание не обусловлено многочис­
ленностью или разбросанностью команды; кто-то предлагает шаблон истории, фиксиру­
ющий все детали, необходимые для историй, или же поступило предложение оценивать
истории с большей точностью (например, в часах, а не днях).
Обсуждение. Этот “запах” особенно распространен среди команд, привыкших к вы­
полнению обширного предварительного анализа требований. Чтобы избавиться от дан­
ного недостатка, команде может понадобиться пройти переподготовку, прослушав курс
о сильных сторонах историй. При использовании историй фундаментальное значение
имеет признание того факта, что для большинства задач невозможно заранее продумать
все требования. Хорошее программное обеспечение появляется в результате многократ­
ного повторения итераций, на каждой из которых в программу добавляется все большее
Часть III. Часто обсуждаемые вопросы
количество деталей. Истории хорошо вписываются в такой подход вследствие той про­
стоты, с какой могут выражаться детали в более поздних версиях истории. Возможно,
команде потребуется вспомнить о своем предыдущем опыте разработки, который при­
вел их к освоению работы с историями.
Разбиение слишком большого количества историй
Симптомы. Частое разбиение историй при планировании итераций, которое требует­
ся выполнять, чтобы обеспечить включение в итерацию историй подходящего размера.
Обсуждение. Когда разработчики и заказчик выбирают истории, которые они будут
включать в итерацию, им иногда приходится разбивать историю на несколько составных
историй. Обычно разбиение историй в процессе планирования приходится выполнять
по одной из следующих двух причин.
1. История слишком велика для включения в итерацию.
2. История содержит как высоко-, так и низкоприоритетные подчиненные истории,
а заказчик хочет, чтобы в предстоящей итерации выполнялись только высокоприо­
ритетные истории.
Ни один из этих случаев не составляет проблему. Во многих проектах и у многих ко­
манд время от времени возникает необходимость в разбиении историй с целью подгон­
ки под длительность спринта и согласования со скоростью разработки, которой придер­
живается команда. Ситуация начинает дурно пахнуть, если команде приходится делать
это часто.
Если истории приходится разбивать при планировании чаще, чем это делается обыч­
но, просмотрите все оставшиеся истории и поищите среди них те, которые следует раз­
бить до их планирования.
Заказчик испытывает проблемы
с назначением приоритетов историй
Симптомы. Выбор историй и назначение им приоритетов часто вызывают трудности,
но иногда ранжирование историй становится настолько затруднительным, что это мож­
но считать “запахом”.
Обсуждение. Если у заказчика трудности с ранжированием историй, то вначале сле­
дует обратить внимание на их размер. Когда истории слишком велики, ранжировать
их бывает затруднительно. Предположим крайний случай, когда проект BigMoneyJobs
включает лишь следующие три истории.
• Соискатель может осуществить поиск вакансий.
• Компания может публиковать вакансии.
• Рекрутер может осуществить поиск кандидатов.
Остается только пожалеть бедного заказчика, которому придется назначать приори­
теты этим историям! Его реакция, вероятно, будет такой: “А нельзя ли мне взять часть
отсюда, а часть — оттуда?” В данном случае следует расстаться с этими историями и за­
менить их меньшими, чтобы заказчик мог выбрать те части, которые захочет.
Глава 14. Каталог запахов историй
Затруднения с ранжировании историй могут возникать и в тех случаях, когда
история написана так, что обеспечиваемая ею бизнес-ценность не видна заказчику.
Предположим, например, что заказчику предоставлены следующие истории.
• Пользователь подключается к базе данных посредством пула соединений.
• Пользователь может просматривать подробную информацию об ошибках, сохра­
ненную в файле журнала.
Заказчику очень трудно ранжировать истории такого типа, ведь бизнес-ценность
каждой из них совершенно не очевидна. Истории следует переписать так, чтобы их
бизнес-ценность была ясна заказчику. Как это следует делать, зависит от уровня тех­
нической подготовки заказчика, и именно поэтому наилучшая рекомендация состоит
в том, чтобы истории писал сам заказчик. Вот переписанные версии приведенных выше
историй.
• Пользователь может запустить приложение, не ощущая заметных задержек, вы­
званных необходимостью подключения к базе данных.
• Всякий раз, когда возникает ошибка, пользователю предоставляется достаточный
объем информации, чтобы он знал, как устранить эту ошибку.
Отказ заказчика от написания и ранжирования историй
Симптомы. Заказчик проекта не берет на себя ответственности за написание или ран­
жирование историй.
Обсуждение. В организации, работающей в атмосфере взаимных упреков, всегда най­
дутся отдельные личности, которые используют любую возможность, чтобы бы не брать
на себя вообще какую бы то ни было ответственность. Если ты ни за что не отвечаешь,
то в случае неудачи с тебя и взятки гладки, зато при благоприятном исходе всегда най­
дется повод каким-то образом приписать себе хотя бы часть заслуг. Люди с таким скла­
дом характера всегда будут стремиться уходить от принятия каких-либо сложных реше­
ний, таких как ранжирование функциональных возможностей при их включении или
исключении из выпусков. Они всегда будут использовать отговорки наподобие “Это не
моя проблема, что вы не успеваете закончить все в срок, вы сами должны найти способ,
как это обеспечить”.
Я выработал для себя следующую тактику поведения в подобных ситуациях, позво­
ляющую заказчику думать, что ему удается “соскочить с крючка”. Я нахожу какой-либо
мягкий способ, как упросить его выразить свое мнение. Если получится, это может быть
частная беседа. Если я работаю с несколькими заказчиками, то говорю одному из них,
что уже собрал информацию от всех остальных и очередь остается только за ним, но
ответственность за принятие окончательного решения несу я, даже если рекомендации
кого-то из заказчиков окажутся неудачными.
Резюме
В этой главе было рассказано о существовании следующих “запахов”:
• чрезмерно заниженный размер историй;
• взаимозависимые истории;
Часть III. Часто обсуждаемые вопросы
• украшательство;
• добавление слишком большого количества деталей в истории;
• преждевременное включение деталей пользовательского интерфейса;
•
•
•
•
опережение событий;
разбиение слишком большого количества историй;
проблемы с ранжированием историй;
отказ заказчика от написания и ранжирования историй.
Обязанности разработчика
• Как и заказчик, вы обязаны знать о существовании перечисленных выше “запа­
хов”, а также других, которые вы можете обнаружить, и несете совместную с за­
казчиком ответственность за принятие мер по устранению тех “запахов”, которые
влияют на ваш проект.
Обязанности заказчика
• Как и разработчики, вы обязаны знать о существовании перечисленных выше
“запахов”, а также других, которые вы можете обнаружить, и несете совместную
с разработчиками ответственность за принятие мер по устранению тех “запахов”,
которые влияют на ваш проект.
Контрольные вопросы
14.1. Каковы будут ваши действия в случае, если команда постоянно сталкивается
с трудностями при планировании очередной итерации?
14.2. Каковы должны быть действия команды в случае, если она постоянно сталкивает­
ся с нехваткой места на карточках для написания историй?
14.3. По какой причиное заказчик может испытывать трудности с ранжированием
историй?
14.4. По каким признакам вы можете судить, что вынуждены разбивать намного боль­
ше историй, чем следовало бы?
Глава 15
Использование историй
в методологии Scrum
Пользовательские истории возникли как часть методологии экстремального програм­
мирования, поэтому нет ничего удивительного в том, что они прекрасно вписываются
в другие его методики. Однако историям находится место и при определении требова­
ний для других процессов.
Одним из таких процессов, в которых важную роль играют пользовательские исто­
рии, является Scrum1. В этой главе при первом употреблении терминов из лексикона
Scrum они будут выделяться курсивом.
Итеративная и инкрементная природа Scrum
Подобно ХР, Scrum является как итеративным, так и инкрементным процессом.
Поскольку очень часто эти термины употребляются без объяснения их смысла, дадим
их определение.
Итеративными называют процессы, которые развиваются через ряд последователь­
ных уточнений. Команда разработчиков создает своего рода первое приближение к сис­
теме, зная, что оно не завершено и некоторые (иногда многие) его возможности разрабо­
таны пока что слабо. После этого разработчики итеративно улучшают эти возможности
до получения удовлетворительного продукта. С каждой итерацией программное обе­
спечение усовершенствуют, добавляя в него все более мелкие детали. Так, экран поис­
ка, закодированный на первой итерации, может поддерживать лишь возможности про­
стейшего поиска. На второй итерации могут быть добавлены дополнительные поисковые
критерии. Наконец, на третьей итерации может быть добавлена обработка ошибок.
Хорошей аналогией этого процесса может служить создание скульптуры. Сначала
скульптор подбирает камень подходящего размера. Затем он высекает из него предва­
рительную общую форму конечной скульптуры. Не исключено, что на этой стадии уже
можно будет различить голову и торс и понять, что ваяется скульптура человека, а не,
скажем, птицы. Далее скульптор улучшает свою работу, добавляя детали. Однако вряд
ли скульптор будет считать любую часть формы завершенной до тех пор, пока работа не
будет полностью закончена.
Инкрементными, или пошаговыми, называются процессы, в которых программ­
ное обеспечение создается и поставляется по частям. Каждая часть, или приращение
(инкремент), предоставляет пользователям законченный набор функциональных воз­
можностей. Размеры инкрементов могут быть самыми разным, начиная, например,
от простого окна входа в систему и заканчивая чрезвычайно гибким набором экранов
1 Полное описание Scrum см. в [49].
Часть III. Часто обсуждаемые вопросы
управления данными. Для каждого инкремента пишется полный исходный код, кото­
рый обязательно тестируется, и в целом предполагается, что результаты работы на дан­
ной итерации не будут требовать пересмотра.
Действующий пошагово скульптор также берется за одну часть работы и сосредото­
чивается полностью на ней, пока она не будет завершена. Он может выбрать инкремен­
ты либо небольшого размера (сначала нос, затем глаза, потом рот и т.д.), либо большого
(голова, торс, ноги, руки). Однако, независимо от размеров инкремента, скульптор по­
пытается доработать его настолько полно, насколько это возможно.
Как Scrum, так и ХР — итеративные инкрементные процессы. Они являются ите­
ративными, поскольку предполагается, что результаты работы, выполненной на одной
итерации, будут улучшены на протяжении последующих итераций. Они являются также
инкрементными, поскольку результатом завершенной работы сразу же можно восполь­
зоваться в проекте.
Основы Scrum
Проекты Scrum проходят через последовательность 30-дневных итераций, называе­
мых спринтами (sprints). В начале каждого спринта команда определяет объем работы,
который должен быть выполнен за этот период. Конкретные работы выбираются из
ранжированного списка функциональных возможностей, который называется журналом
запросов на выполнение работ (product backlog). Работы, которые, по мнению команды,
могут быть завершены в течение спринта, помещаются в журнал Scrum, называемый
списком заданий спринта (sprint backlog). Графическое представление Scrum-процесса,
являющееся адаптированной версией схемы, взятой с веб-сайта Кена Швабера по адре­
су www. controlchaos. com, приведено на рис. 15.1.
Команда Scrum
В состав типичной команды Scrum входит от четырех до семи разработчи­
ков. Несмотря на то что в состав Scrum-команды могут включаться разработчикиспециалисты (например, тестировщики и администраторы базы данных), команда рабо­
тает по принципу “мы все в одной лодке” (“we are all in this together”). Если необходимо
провести тестирование, а выделенного тестировщика нет, вместо него это сделает кто-то
другой. Вся работа принадлежит коллективу в целом. Scrum-команды — это самоорга­
низующиеся образования. Это значит, что не будет никаких указаний от руководства,
согласно которым Мэри должна заниматься исходным кодом, а Билл — выполнять те­
стирование. Поэтому никакого распределения ролей, например программиста, архитек­
тора или тестировщика, в Scrum-командах не существует. Команда сама решает, как ей
выполнять свою работу.
Этот костяк команды дополняется двумя ключевыми фигурами — владельцем про­
дукта (Product Owner) и Scrum-мастером (ScrumMaster). Владелец продукта в Scrum вы­
полняет, по сути, те же функции, что и заказчик в экстремальном программировании.
Его основной обязанностью является ведение журнала запросов на выполнение работ
и присвоение приоритетов разрабатываемым возможностям. Роль Scrum-мастера экви­
валентна роли менеджера продукта, за исключением того, что эта роль больше связана
с лидерством, чем с управлением. Поскольку Scrum-команды — самоорганизующиеся
Глава 15. Использование историй
в методологии
Scrum
и им предоставляется большая свобода действий в том, как выполнить работу, включен­
ную в спринт, Scrum-мастер проекта, скорее, служит интересам команды, а не управляет
ею. Обычно он устраняет факторы, препятствующие продвижению проекта, и оказывает
команде помощь в следовании нескольким простым правилам Scrum.
Рис. 15.1. Графическое представление Scrum-процесса
Журнал запросов на выполнение работ
Журнал запросов на выполнение работ — это основной перечень всех функциональ­
ных возможностей, которые ожидаются в продукте. Никаких особых усилий к тому,
чтобы уже в самом начале проекта сформировать исчерпывающий список всех пред­
сказуемых возможностей, не прилагается. Обычно владелец продукта вместе с командой
включают в этот список все, что можно сразу же назвать, а этого почти всегда будет
более чем достаточно для первого спринта. Впоследствии, по мере ознакомления с про­
дуктом и общения с его заказчиками, в журнал будут вноситься изменения, и он будет
пополняться новыми записями.
В табл. 15.1 приведен пример журнала запросов на выполнение работ, взятый из ре­
ального проекта. Из таблицы видно, что записи журнала могут относиться к задачам
технического характера (“Выполнить рефакторинг класса Login для генерации исклю­
чения”) или ориентироваться в большей степени на пользователя (“Разрешить отмену
операций на экране установки”).
Таблица 15.1. Пример журнала запросов на выполнение работ
№ п/п
Описание
1
Закончить разработку системы контроля версий для базы данных
2
Избавиться от ненужных включений Java-кода в базе данных
3
Выполнить рефакторинг класса Login для генерации исключения
Часть III. Часто обсуждаемые вопросы
Окончание табл. 15.1
№ п/п
Описание
4
Добавить поддержку коллективных лицензий
5
Добавить поддержку ознакомительных лицензий
6
Добавить поддержку метасимволов при поиске
7
Сохранять пользовательские настройки
8
Разрешить отмену операций на экране установки
Владелец продукта сортирует элементы этого списка в порядке приоритета. Более
того, ему разрешено (а фактически, от него ожидают этой инициативы) менять местами
элементы списка по мере изменения приоритетов из месяца в месяц.
Собрания по планированию спринтов
Собрания по планированию спринта (sprint planning meeting) проводятся в начале каж­
дого спринта. Такое собрание обычно занимает целый день; в нем участвуют владелец
продукта, Scrum-мастер и команда разработчиков в полном составе. Кроме того, на со­
брании могут присутствовать представители руководства организации или заказчика,
а также другие заинтересованные лица.
В течение первой половины собрания владелец продукта описывает команде воз­
можности с наивысшим приоритетом, ожидающие разработки. Команда задает владель­
цу продукта вопросы, которые помогут ей определить, какие задачи следует переместить
из журнала запросов на выполнение работ в список заданий спринта, что будет сделано
во время второй половины собрания.
От владельца продукта не требуется давать описание всех работ, перечисленных
в журнале. В зависимости от размера журнала и производительности команды, он может
ограничиться описанием лишь тех работ, которые обладают наивысшим приоритетом,
оставив обсуждение работ с более низким приоритетом для последующих собраний по
планированию спринтов. Как правило, Scrum-команда сама определяет, в какой момент
прекратить дальнейший просмотр журнала, поскольку уже имеется достаточно большой
объем задач, являющихся кандидатами для отбора на предстоящий спринт.
Команда и владелец продукта совместно определяют цель спринта (sprint goal), т.е.
кратко формулируют, чего они планируют добиться в данном спринте. В конце спринта
проводится собрание по обзору результатов спринта (sprint review meeting), на котором
команда оценивает свою работу, причем критерием успеха является не выполнение каж­
дого из пунктов, отобранных в журнале запросов на выполнение работ, а достижение
цели спринта.
Во второй половине собрания по планированию спринта участвует только команда
разработчиков, которые обсуждают все, что они перед этим услышали, и окончатель­
но решают, какие именно работы будут выполняться в течение предстоящего спринта.
Происходить это должно примерно так. Команда просматривает ранжированный спи­
сок с самого начала и подводит черту под последней из высокоприоритетных задач, ко­
торые, по ее мнению, она сможет выполнить. На практике же вполне допустимо, если,
например, команда сначала выберет пять высокоприоритетных задач, а затем дополнит
их связанными с ними двумя задачами из нижней части списка. В некоторых случаях
Глава 15. Использование историй в методологии Scrum
это потребуется согласовать с владельцем продукта, но лишь команда может решать, ка­
кой объем работ она обязуется выполнить.
▼------------------------------------------------------------------------------------ ▼
Основные правила Scrum
Перед началом каждого спринта созывается собрание по его планированию.
Каждый спринт должен заканчиваться созданием работоспособного и полностью
протестированного кода, представляющего что-либо ценное для конечных пользовате­
лей или заказчиков.
Владелец продукта назначает приоритеты историям, включенным в журнал запро­
сов на выполнение работ.
Команда коллективно решает, какой объем работ включить в спринт.
С началом спринта лишь команда может дополнять список заданий.
В любое время можно добавить новые записи в журнал запросов на выполнение
работ и изменить приоритеты перечисленных в нем историй.
Ежедневно проводятся короткие Scrum-собрания. Каждый участник проекта отве­
чает на следующие вопросы: “Что ты делал вчера? Что ты будешь делать сегодня? Что
тебе мешает?”
Лишь активные участники спринта (а не заинтересованные наблюдатели или не
участвующие в спринте ключевые заинтересованные лица) имеют право высказывать
свое мнение на коротких Scrum-собраниях. Результат спринта демонстрируется в кон­
це спринта на собрании по обзору результатов спринта.
Во время обзора результатов спринта демонстрируется работающее программное
обеспечение. Никакие слайд-шоу не допускаются.
На подготовку к обзору результатов спринта может быть потрачено не больше двух
часов.
▲-------------------------------------------------------------------------------------▲
После того как началось выполнение спринта, добавлять в него новые задания раз­
решается лишь команде. Главный исполнительный директор компании не может об­
ращаться к команде с какими-либо просьбами относительно того, о чем не говорил
владелец продукта. Продавец не может просить о добавлении еще одной возможности
для особого заказчика, а владелец продукта не может изменить свое решение и просить
о введении дополнительных возможностей. Единственная возможность для добавления
работы в спринт возникает тогда, когда команда опережает график. В этом случае ко­
манда может обратиться к заказчику с просьбой, чтобы тот оказал помощь в определе­
нии одной или двух дополнительных задач.
В обмен на свое обязательство выполнить выбранную работу в течение спринта ко­
манда получает обязательство организации, что она не изменит содержание спринта на
всем его протяжении. Если произойдет нечто столь значительное, что организация по­
чувствует необходимость в изменении спринта, то текущий спринт прекращается и за­
пускается новый, который начинается с собрания по его планированию.
По мере того как команда выбирает записи из журнала запросов на выполнение ра­
бот, она расширяет их в журнале спринта, который в большей степени ориентирован на
задачи. Каждая запись из журнала запросов на выполнение работ может расширяться до
нескольких задач в журнале спринта, что позволяет команде более эффективно распре­
делять работу в команде.
Часть III. Часто обсуждаемые вопросы
Собрания по обзору результатов спринта
Необходимо, чтобы каждый спринт доставлял потенциально готовое к поставке при­
ращение (инкремент) продукта. Это означает, что в конце каждого спринта длительно­
стью в один месяц команда должна производить протестированное и полностью рабо­
тоспособное программное обеспечение. “Готовое к поставке” означает, что по выбору
организации программное обеспечение может быть поставлено заказчикам (или остав­
лено для внутреннего использования), если включенной в приращение новой функ­
циональности достаточно для того, чтобы оправдать накладные расходы, связанные
с поставкой или развертыванием новой версии. Вряд ли, например, коммерческий дис­
трибьютор будет ежемесячно поставлять новую версию, учитывая, какие хлопоты такое
обновление доставит его заказчикам. Однако технология Scrum требует, чтобы разработ­
чики выдавали потенциально поставляемую версию каждый месяц.
В конце каждого спринта проводится собрание по обзору результатов спринта (sprint
review meeting). Во время этого собрания команда показывает, чего им удалось добиться
в данном спринте. Обычно это выглядит как демонстрация новых возможностей.
На таких собраниях намеренно создается неформальная обстановка, что обычно
подкрепляется введением правил, согласно которым в качестве вспомогательных мате­
риалов запрещается использовать демонстрационные слайды PowerPoint, а подготовка
к собранию должна занимать не более двух часов. Собрание не должно превращаться
в отвлекающий фактор и заметно мешать работе команды; оно должно играть роль есте­
ственного результата спринта.
В работе собраний по обзору результатов участвует вся команда, а также владелец
продукта и Scrum-мастер. При желании такие собрания могут посещать и остальные
лица, заинтересованные в проекте (руководство организации, заказчики и технический
персонал из других проектов).
Во время собрания проект оценивается через призму цели спринта, которая была
перед этим определена на собрании по планированию спринта. Будет идеально, если
команда завершит разработку каждого пункта, запланированного для спринта, но гораз­
до важнее, чтобы была достигнута общая цель спринта.
Ежедневные собрания Scrum
Вероятно, Scrum — это первый документированный процесс, который включает ко­
роткие ежедневные мероприятия 17], называемые ежедневными Scrum-собраниями (the daily
scrum). Эта идея, однако, очень быстро распространилась на другие agile-процессы, такие
как ХР или разработка, управляемая свойствами (Feature Driven Development). При любой
возможности следует выбирать такую форму сбора информации о проекте и обмена ею,
которая занимает меньше всего времени и доставляет всем меньше всего хлопот. Во
многих отношениях ежедневные Scrum-собрания в точности соответствуют этой цели.
Ежедневные Scrum-собрания по возможности проводятся каждый день как можно
раньше, но после того, как все члены команды прибудут на работу. Обычно это происхо­
дит в 9:00 или 9:30 утра. На собрании должны присутствовать все члены команды, вклю­
чая программистов, тестировщиков, владельца продукта и Scrum-мастера. Собрания
проводятся очень быстро: обычно на это уходит не более 15 минут, но в любом случае их
длительность не должна превышать 30 минут. Чтобы не затягивать время, в некоторых
командах требуется, чтобы все участники собрания стояли, а не сидели.
Глава 15. Использование историй в
методологии
Scrum
Во время проведения ежедневного Scrum-собрания каждый член команды отвечает
на следующие три вопроса.
1. Что ты сделал вчера?
2. Что ты будешь делать сегодня?
3. Что тебе мешает?
Очень важно, чтобы ежедневные собрания не превращались в своего рода допрос,
проводимый Scrum-мастером. Одна из целей собрания состоит в том, чтобы каждый
разработчик взял на себя определенные обязательства перед своими коллегами. Это обя­
зательства друг перед другом, а не перед руководством.
По возможности ежедневные собрания должны строго придерживаться рассмотре­
ния только трех перечисленных выше вопросов, а не обсуждать особенности дизайна
отдельных частей системы или решения поднятых проблем. Такие вопросы лишь отме­
чаются во время собрания, но разрешаются после него. Вполне можно назначить груп­
пу из членов команды, которая займется тем или иным вопросом, но сами вопросы не
должны решаться во время проведения собрания. Например, кто-то из членов команды
мог спросить, следует ли начинать использовать версию 5.0 сервера приложений, недав­
но выпущенную поставщиком, с которым сотрудничает команда. В этом случае команда
может принять решение о том, что сразу после собрания будет созвано другое собрание,
в котором примут участие:
• технический архитектор, который может оценить технические последствия ис­
пользования нового сервера приложений;
• владелец продукта, который является сотрудником маркетингового отдела и мо­
жет лучше остальных оценить, какую версию сервера следует развернуть — ста­
рую или новую;
• представитель команды тестировщиков, который может оценить последствия за­
мены сервера приложений для его группы.
Scrum-мастеру хорошо подходят функции посредника, облегчающего выполнение про­
екта (facilitator), и он следит за тем, чтобы собрание фокусировалось на рассмотрении
указанных трех вопросов и продвигалось быстрыми темпами. Присутствие владельца
продукта необходимо, поскольку в идеальном случае у него также могла быть работа,
о которой он мог бы доложить, как и любой другой член команды (“Я закончил написа­
ние тестов для истории Добавить книгу в покупательскую корзину, а сегодня собираюсь
провести маркетинговое исследование относительно того, какие платежные карты нам
следует принимать к оплате. Я смогу разделаться с этим к концу дня”).
Одним из преимуществ ежедневных Scrum-собраний является то, что они служат
своего рода внеплановыми контрольными точками для высшего руководства и любых
других лиц, заинтересованных в проекте. Постоянно собираясь в одно и то же время дня
и приглашая к необязательному участию в них других заинтересованных лиц, команда
получает возможность избегать посещения более обременительных ежемесячных собра­
ний по обзору результатов проекта. Однако если на ежедневные собрания приглашаются
люди, не являющиеся членами команды, обязательно установите правило, в соответ­
ствии с которым право задавать вопросы во время проведения собрания имеют только
те, кто непосредственно задействован в проекте. Поэтому Большой Босс может посе­
щать такие собрания и слушать, сколько ему угодно. Однако задавать вопросы и тем са­
мым нарушать ход работы собрания он права не имеет.
V
Часть III. Часто обсуждаемые вопросы
Благодаря ежедневным Scrum-собраниям каждый член команды получает картину
состояния дел в проекте. Это также великолепная возможность для того, чтобы при не­
обходимости перепоручить работу другим исполнителям. Пусть, например, Рэнди со­
общил, что история, над которой он работает, занимает больше времени, чем он рас­
считывал, а Эндрю сказал, что он значительно опережает график. В таком случае может
оказаться целесообразным, чтобы Эндрю поработал один день в паре с Рэнди над его
задачами или полностью взял на себя ответственность за выполнение некоторых задач
Рэнди.
Во время ежедневных собраний Scrum-мастер должен придерживаться правильной
линии поведения. Он должен поддерживать быстрый темп работы собрания, но это
должно делаться так, чтобы не создавалось впечатление, будто собрание проводится ис­
ключительно в его интересах. Никогда не следует задавать вопросы наподобие “Сколько
времени тебе еще осталось работать над историей Заказать книгу?” Эта информация
крайне важна, но если такие вопросы будут задаваться на ежедневных собраниях, то все
собрание сведется к обсуждению оценок и чисел. Чтобы не мешать работе ежедневных
собраний, я прошу команду обновлять свои оценки на общей доске или с помощью
программного обеспечения, которое мы используем в тех случаях, когда команда рас­
средоточена по разным местам.
Добавление историй в Scrum
Получив общее представление о подходе Scrum в целом, рассмотрим, как его можно
улучшить благодаря использованию историй.
Истории и журнал запросов на выполнение работ
Мне вполне успешно удалось выразить записи в журнале запросов на выполнение
работ Scrum в виде пользовательских историй [18]. Вместо того чтобы включать в эти
записи описания новых возможностей, вопросы, требующие выяснения, дефекты, под­
лежащие устранению, и т.п., журнал ограничивается включением в него лишь пользова­
тельских историй. Каждая история в журнале должна описывать нечто, представляющее
ценность для пользователей или владельца продукта.
Ограничение содержимого журнала пользовательскими историями значительно
упрощает ранжирование включенных в него задач владельцем продукта. Видя перед со­
бой записи журнала, выраженные понятным ему языком, владелец продукта может без
труда принимать решения о том, какой возможностью можно пожертвовать в пользу
другой.
Как и в экстремальном программировании вообще, в Scrum не обязательно, что­
бы владелец продукта определял все требования заранее. Однако во многих случаях не
помешает, если уже с самого начала будут сделаны какие-то наброски этих требова­
ний. Scrum не предписывает и даже не рекомендует никаких подходов, которые мож­
но использовать для начального заполнения журнала запросов на выполнение работ.
Традиционно это происходило через обсуждения, в которых принимают участие владе­
лец продукта, Scrum-мастер и один или несколько разработчиков. Однако я обнаружил,
что путем первоначального определения ролей и последующей концентрации усилий на
историях для этих ролей технология Scrum объединяется с мощной методикой опреде­
ления требований.
Глава 15. Использование историй в методологии Scrum
Использование историй на собраниях по планированию спринтов
Во время проведения собрания по планированию спринта владелец продукта и ко­
манда обсуждают элементы журнала запросов на выполнение работ, обладающие выс­
шим приоритетом. После этого команда определяет элементы, которые она обязует­
ся выполнить на протяжении спринта. Затем команда разбивает эти задачи на более
мелкие, чтобы разработчики могли браться за отдельные задачи по мере выполнения
спринта.
Включение историй в журнал приводит к тому, что каждая его запись выражает цен­
ность, понятную заказчику. Именно поэтому я обнаружил, что собрания по планиро­
ванию спринтов проводятся легче и быстрее, если заставлять команду рассказывать за­
казчику о тех преимуществах, которые обеспечивают такие задачи, ориентированные
в основном на технологические аспекты проекта, как “Выполнить рефакторинг класса
Login для генерации исключений”.
Кроме того, истории хорошо вписываются в планирование спринта, поскольку, как
мы уже видели в главе 10, их легко расчленить на составляющие задачи.
Использование историй на собраниях по обзору результатов спринта
Использование историй благотворно сказывается на проведении собраний по обзору
результатов спринтов Scrum, поскольку они упрощают оценку того, какие части спринта
можно считать завершенными. В проектах Scrum, в которых журнал запросов на выпол­
нение работ представляет собой неструктурированную совокупность технических задач,
требований, проблемных вопросов и обнаруженных ошибок, команда может испыты­
вать трудности с демонстрацией того, как каждый из элементов нашел свой путь в про­
дукт, созданный на протяжении этого спринта. Если же весь журнал состоит из историй,
описывающих элементы, представляющие ценность для заказчика или пользователей,
то демонстрация этих элементов обычно упрощается.
Истории и ежедневные Scrum-собрания
Я обнаружил, что использование историй приносит пользу ежедневным Scrumсобраниям, так как они помогают добиться того, чтобы внимание сосредоточивалось на
пожеланиях заказчика и конечных пользователей. Поскольку спринтам не предшествует
предварительное определение требований или фаза анализа, каждый спринт начинается
лишь с частичным пониманием того, что именно следует создать. Команда может знать
о том, что планируется добавление экрана поиска, но она может не знать, по каким по­
лям будет осуществляться поиск, какие критерии поиска можно сочетать и т.д. Истории
оказываются полезными, потому что они напоминают команде о том, что именно долж­
но быть создано в результате разработки. По ходу спринта команда может использовать
историю (а также ведущиеся с владельцем продукта обсуждения этой истории), чтобы
установить, достаточно ли далеко или насколько дальше, чем планировалось, она про­
двинулась в программировании конкретной истории.
Конкретный пример
В качестве примера добавления историй в Scrum рассмотрим проект, в работе над
которым я участвовал. Небольшая акционерная компания, для удобства назовем ее
V
Часть III. Часто обсуждаемые вопросы
Cosmodemonic Biotech, была разработчиком программного обеспечения в сфере био­
технологий. Компания как раз завершила длившийся девять месяцев проект и собира­
лась представить новый продукт, предназначенный для специалистов в области генети­
ки. Вскоре после выпуска бета-версии компания объявила о том, что ее купила другая
компания.
Компания-поглотитель была заинтересована в списке заказчиков, который шел вме­
сте с продуктом. Однако она решила, что программное обеспечение необходимо пере­
писать по ряду причин.
• Клиентские технологии оригинального продукта (HTML) не вписывались в стра­
тегическое видение нового владельца.
• Целевой рынок продукта изменился — от очень крупных фармацевтических ком­
паний с мультитерабайтовыми базами данных до академических исследователь­
ских лабораторий и небольших биотехнологических компаний с базами данных
намного меньшего объема.
• Относительно плохая реализация значительной части исходного кода.
Оригинальный продукт разрабатывался в очень жестких рамках подхода на основе
каскадной модели на протяжении девяти месяцев командой, насчитывающей около
100 разработчиков. Новый продукт должен был обеспечить по сути ту же функциональ­
ность, но разрабатывать его должна была команда численностью не более семи человек.
Для этого мы использовали технологию Scrum, дополненную пользовательскими
историями, как уже описывалось в данной главе. Проект оказался успешным во всех
отношениях. Для выполнения того объема работ, на который у команды, работающей
в соответствии с каскадной моделью, ушло девять месяцев, Scrum-команде понадоби­
лось двенадцать месяцев. Однако поскольку численность Scrum-команды ни на одной
стадии разработки не превышала семи человек, включая владельца продукта и Scrumмастера, для выполнения проекта потребовалось 54 человеко-месяца. Версия, разраба­
тывавшаяся в соответствии с каскадной моделью, потребовала 540 человеко-месяцев.
Объем исходного кода, написанного командой, работавшей по каскадной модели,
составил 58000 инструкций на языке Java, исключая комментарии. Scrum-команда, ра­
ботавшая с пользовательскими историями и располагавшая меньшими ресурсами, соз­
дала код объемом 51000 инструкций. Отсюда следует, что в пересчете на один человекомесяц объем кода, выражаемый количеством инструкций Java, составил 120 для
команды, работающей в соответствии с каскадной моделью, и 840 для Scrum-команды.
Подробные числовые характеристики обоих процессов представлены в табл. 15.2.
Таблица 15.2. Сравнение двух подходов к реализации одного и того же проекта
Каскадная модель
Страниц вариантов использования
Историй
Календарных месяцев
Человеко-месяцев
Строк Java-кода
Строк Java-кода на человеко-месяц
Scrum с историями
3000
0
0
1400
9
12
540
54
58000
51000
120
840
Глава 15. Использование историй в методологии Scrum
Резюме
• Scrum — итеративный и инкрементный процесс.
• Проекты Scrum развиваются в виде последовательности 30-дневных итераций,
называемых спринтами.
• Scrum-мастер выполняет функции, аналогичные роли менеджера продукта, но
является скорее лидером и посредником, чем руководителем.
• В состав типичной Scrum-команды входит от четырех до семи человек.
• Журнал запросов на выполнение задач — это список всех требуемых возможно­
стей, которые пока что либо не были добавлены в продукт, либо не запланирова­
ны на текущий спринт.
• Журналом спринта служит список задач, которые команда обязалась выполнить
на протяжении текущего спринта.
• Владелец продукта в Scrum выполняет функции, аналогичные роли заказчика
в экстремальном программировании.
• В начале каждого спринта команда выбирает, что именно и в каком объеме она
обязуется выполнить на протяжении текущего спринта.
• Подход Scrum предусматривает проведение коротких ежедневных собраний. Во
время этих собраний каждый участник команды сообщает о том, что он сделал
вчера, что сделает сегодня и что ему мешает.
• Каждый спринт обязан заканчиваться выпуском потенциально готового к постав­
ке инкремента продукта.
• В конце спринта команда демонстрирует созданное программное обеспечение на
собрании по обзору результатов спринта.
Контрольные вопросы
15.1. Опишите различия между инкрементными и итеративными процессами.
15.2. Как соотносятся между собой журнал запросов на выполнение работ и список за­
дач спринта?
15.3. Что означает выражение “потенциально готовое к поставке приращение про­
дукта”?
15.4. Кто отвечает за ранжирование и выбор работ, которые команда будет выполнять
в течение итерации?
15.5. Какие вопросы задаются каждому члену команды на ежедневных Scrum-собра­
ниях?
Глава 16
Дополнительные вопросы
Предыдущие главы были посвящены вопросам, которые нередко возникают при об­
суждении пользовательских историй. В частности, было показано, чем именно поль­
зовательские истории отличаются от других методов определения требований и почему
в некоторых случаях им следует отдавать предпочтение. Также были изучены некото­
рые “запахи”, т.е. признаки потенциальных проблем, с которыми можно столкнуться,
работая с пользовательскими историями, и демонстрировались способы их устранения.
В этой главе мы рассмотрим ряд дополнительных вопросов, а именно:
• обработка нефункциональных требований;
• должна ли команда вести бумажные карточки историй или применять программ­
ный инструментарий;
• влияние пользовательских историй на интерфейс пользователя;
• целесообразность хранения пользовательских историй после завершения их раз­
работки;
• связь между отчетами об ошибках и историями.
Обработка нефункциональных требований
У команд, которые только начинают работать с пользовательскими историями, часто
возникает ощущение, будто абсолютно все, что имеет отношение к проекту, должно на­
ходить свое отражение в историях, и это становится для них камнем преткновения.
Нефункциональные требования могут касаться самых разнообразных потребностей
системы. Наиболее распространенные типы нефункциональных требований относятся
к одной из следующих категорий:
• производительность (performance);
• точность (accuracy);
• переносимость (portability);
• возможность повторного использования (reusability);
• удобство сопровождения (maintainability);
• способность к взаимодействию (interoperability);
• доступность (availability);
• удобство использования (usability);
• безопасность (security);
• нагрузка (capacity).
Часть III. Часто обсуждаемые вопросы
Многие требования можно рассматривать как ограничения, налагаемые на пове­
дение системы. Например, нередко в проект включаются такие требования, как “Код
системы должен быть написан на языке Java”. Это требование явно играет роль огра­
ничения в отношении проектирования остальной части системы. Как обсуждалось
в главе 7, наилучшим способом обработки ограничений является их запись на карточке
с пометкой “ОГРАНИЧЕНИЕ”. В большинстве случаев для обеспечения контроля за
соблюдением ограничения можно написать (и выполнять по крайней мере раз в день)
автоматизированный тест. Лишь немногие ограничения не поддаются реалистичному
тестированию или не заслуживают того. Первое, что приходит на ум в связи с этим, —
ограничение “Код системы должен быть написан на языке Java”. Несомненно, что для
контроля соблюдения подобных ограничений найдутся более простые способы.
Примеры некоторых типичных ограничений приведены в табл. 16.1. При наличии
дополнительных ограничений, которым должна подчиняться система, можно, помимо
их записи на карточке, сообщить о них в любой приемлемой или общепринятой фор­
ме. Если, например, вы считаете, что система только выиграет от того, что в ней будет
словарь данных, отображающий размеры и типы для всех переменных системы, просто
создайте его.
Таблица 16.1. Примеры ограничений для ряда типичных нефункциональных требований
Категория
Пример ограничения
Производительность
В 80% случаев поиска в базе данных результаты будут возвращаться
на экран в течение не более двух секунд
Точность
Программное обеспечение будет правильно предсказывать победи­
теля футбольного матча по крайней мере в 55% случаев
Переносимость
В системе не должны использоваться технологии, затрудняющие ее
перенос на платформу Linux
Возможность повтор­
ного использования
База данных и код доступа к ней будут повторно использовааться
в будущих приложениях
Удобство сопрово­
ждения
Для всех компонентов должны существовать автоматизированные
модульные тесты.
Автоматизированные тесты должны выполняться в полном объеме
по крайней мере раз в сутки
Способность к взаи­
модействию
Исходный код системы должен быть написан на языке Java.
Вся конфигурационная информация должна храниться в XML-файлах. База данных будет храниться в MySQL
Нагрузка
База данных будет способна хранить данные о 20 миллионах эле­
ментов на заданном оборудовании, удовлетворяя при этом критерии
производительности
Бумага или программное обеспечение?
Еще чаще, чем обычный для продовольственных магазинов вопрос “Вам пластико­
вый пакет или бумажный?”, приходится слышать вопрос о том, какой вариант запи­
си пользовательских историй лучше: бумажные карточки или программные средства.
Многие члены сообщества экстремального программирования являются ярыми привер-
Глава 16. Дополнительные вопросы
женцами бумажных карточек ввиду их простоты. Экстремальное программирование на
первое место ставит простоту решений, а что может быть проще бумажных карточек?
Кроме того, карточки стимулируют взаимодействие и обсуждение. В процессе планиро­
вания их можно произвольно перетасовывать на столе, образуя различные комбинации,
складывать в стопки и сортировать, принести на любое собрание и т.п.
С другой стороны, существуют программные продукты, предназначенные специаль­
но для отслеживания пользовательских историй (VersionOne1, XPlanner-plus2, Select Solu­
tion Factory3), а также программное обеспечение общего назначения, которое можно
использовать для работы с историями (электронные таблицы, трассировщики дефектов
и вики-сайты).
Одно из основных преимуществ карточек по сравнению с программными продук­
тами состоит в том, что, будучи не связанными с какими-либо техническими средства­
ми, они постоянно напоминают нам о некоторой недосказанности историй. Истории,
отображаемые программой на экране, могут создавать впечатление требований в стиле
IEEE 830, и в силу этого те, кто пишет истории, будут стараться включать в них ненуж­
ные дополнительные детали.
На типичной карточке может уместиться лишь ограниченный объем текста, есте­
ственный верхний предел которого задается размерами карточки. В случае программных
альтернатив такое ограничение отсутствует. В то же время среди тех, кто пользуется кар­
точками, общепринятой практикой является написание образцов приемочных тестов на
оборотной стороне карточки. Во многих случаях размер карточек начинает играть про­
тив этого.
▼----------------------------------------------------------------------------- ▼
Компания ClickTactics остановила выбор на программном
обеспечении
ClickTactics — поставщик маркетинговых решений, который создает программные
компоненты, доступные через Интернет. Они начали с бумажных карточек, но затем
перешли к использованию программного обеспечения V1:XP от компании VersionOne.
Марк Мошолдер, главный менеджер продукта в VlickTactics, сказал, что одной из
причин послужило то, что их менеджеры по продажам и высшее руководство разбро­
саны по разным офисам. Заинтересованным лицам в удаленном офисе не скажешь
“иди посмотри на доску”, и поэтому значительную часть времени приходится тратить на
обновление информации для руководства и других заинтересованных лиц в удаленных
офисах. Кроме того, при работе с карточками бывало и так, что они иногда терялись,
а неделями позже их случайно обнаруживали где-то под столом.
Сохранение пользовательских историй в электронном виде с помощью программ­
ного обеспечения VersionOne позволило компании ClickTactics применять методологию
ХР в качестве инструмента продаж. Благодаря VersionOne они предоставили некото­
рым заказчикам ограниченную возможность визуального контроля за прохождением
итерационного процесса. В свою очередь, это способствовало ускорению сдачи новых
версий заказчикам, которым они теперь могли говорить: “Мы сможем предоставить
вам новую функциональность через три недели”.
▲------------------------------------------------------------------------------▲
1 CM.www.versionone.com.
2 См. http://xplanner-plus.sourceforge.net/.
3 См. http://www.selectbs.com/analysis-and-design/select-solution-factory.
Часть III. Часто обсуждаемые вопросы
В проектах, следующих процедуре ISO (International Organisation for Certification —
Международная организация по стандартизации) или аналогичным ей, которые тре­
буют обеспечивать сквозной контроль проекта от формулирования требований до го­
тового кода и тестов, более предпочтительным будет, пожалуй, сохранение карточек
в электронном виде. Обеспечить соблюдение требований стандарта ISO можно было бы
и с карточками, написанными вручную, однако из-за неудобств, связанных с необходи­
мостью технического сопровождения соответствующих процедур контроля, все преиму­
щества карточек в этом случае были бы утеряны.
Точно так же территориально рассредоточенная команда, скорее всего, предпочтет
карточкам программное обеспечение. Если один или несколько разработчиков, а осо­
бенно заказчик, дистанционно удалены от остальных членов команды, то работать с бу­
мажными карточками становится очень трудно.
К дополнительным преимуществам бумажных карточек можно отнести то, что их
легко сортировать, причем это можно делать самыми различными способами. Карточки
историй можно раскладывать по стопкам, соответствующим высокому, среднему и низ­
кому приоритетам. А можно сложить карточки и в более точном порядке, чтобы первая
история имела более высокий приоритет, чем вторая, вторая — более высокий приори­
тет, чем третья, и т.д.
В отличие от ярых приверженцев какой-либо одной методики, я считаю, что вполне
приемлемо использовать оба подхода. Рекомендую начать с карточек и посмотреть, как
они работают в вашей среде. Если впоследствии возникнут веские причины использо­
вать электронные версии карточек, можете применить и такой способ.
▼------------------------------------------------------------------------------▼
Опыт использования технологии Вики в Diaspar Software Services
Джо Рейнсбергер — основатель компании Diaspar Software Services, занимаю­
щейся разработкой программного обеспечения и предоставлением консультацион­
ных услуг. Давая консультации, он не всегда может находиться рядом с заказчиками.
Для улучшения возможностей общения с удаленными заказчиками в таких ситуациях
Джо использует технологию Вики. Это набор специальных веб-страниц, которые могут
редактироваться каждым, кто их просматривает. В качестве своего вики-сайта он ис­
пользует FitNesse. Вместо того чтобы писать истории на карточках, Джо создает новую
страницу для каждой истории.
По словам Джо, в его последнем небольшом проекте эта методика сработала пре­
восходно. Если у него возникали вопросы по поводу историй, он записывал вопрос на
странице и снабжал его пометкой “todo” ("сделать”). Несколько раз в неделю заказчик
посещал вики-сайт, задавал поиск меток “todo” и отвечал на вопросы. Срочные вопро­
сы решались по телефону, однако методика с использованием вики-сайта оказалась
настолько эффективной, что ситуации, требующие экстренного принятия решений, воз­
никали крайне редко. Джо Рейнсбергер уже работал с бумажными карточками в других
проектах, но говорит, что в данном проекте с удаленным заказчиком у него ни разу не
возникало желания иметь бумажные карточки наряду с их вики-аналогом.
Несмотря на то что для написания выполняемых тестов для каждого проекта он ис­
пользует FitNesse, Джо Рейнсбергер подчеркивает, что "если все члены команды рабо­
тают в одном помещении, то размещение историй на вики-сайте становится излишним”.
Глава 16. Дополнительные вопросы
Истории и пользовательский интерфейс
Ранее уже отмечалось, что гибкая методология разработки в значительной мере иг­
норирует проблемы проектирования пользовательского интерфейса. В определенной
степени это вполне объяснимо: agile-процессы отличаются ярко выраженным итератив­
ным характером, тогда как традиционные подходы к проектированию интерфейса осно­
ваны на тщательной предварительной разработке всех без исключения деталей. При
использовании гибкого подхода, основанного на использовании историй, очень важно
знать о потенциальных рисках, которые могут возникать в случае приложений, в кото­
рых пользовательский интерфейс играет заметную или важную роль.
Возможность итеративного уточнения свойств системы является одним из подвод­
ных камней гибкой разработки. Пользовательские истории позволяют нам откладывать
обсуждения вплоть до того момента, когда разработчики уже будут готовы к тому, чтобы
добавить поддержку истории в программу. Из-за этого разработчикам иногда приходит­
ся переделывать существующие части приложения. Однако по всеобщему убеждению
стоимость этих незначительных переделок более чем оправдана экономией времени на
обсуждении требований к тем возможностям, которые впоследствии оказываются от­
брошенными, а также тем преимуществом, что заказчик может в течение всего процесса
вносить мелкие изменения, направляющие разработку продукта в нужное русло.
Если эти изменения касаются уровней приложения, расположенных ниже уровня
интерфейса пользователя, то такую убежденность можно считать оправданной. Но что
произойдет, если изменения будут затрагивать пользовательский интерфейс? Ларри Константайн [20] говорит по этому поводу следующее:
“Архитектура пользовательских интерфейсов — общая организация, нави­
гационные средства, поведение и внешний вид — должна проектироваться
так, чтобы вписываться во все многообразие охватываемых задач. Ее уточ­
нение на более поздних этапах менее приемлемо, чем для остальной части
архитектуры приложения, поскольку это означает изменение системы для
пользователей, которые успели изучить или освоить уже имеющийся интер­
фейс. Внесение даже малейших изменений в расположение или внешний
вид элементов интерфейса способно создать проблемы для пользователей”.
Это означает, что если пользовательский интерфейс играет важную роль в определе­
нии успешности нашего продукта, то нам, возможно, придется продумать его с самого
начала. Если изменение пользовательского интерфейса создаст проблемы для пользо­
вателей, то это, пожалуй, будет означать существование следующего неписаного огра­
ничения в проекте: “Как только начата разработка интерфейса пользователя, вносимые
в него изменения должны быть минимальными”.
В качестве выхода из подобных ситуаций Константайн и Локвуд [22] предлагают про­
ектирование, ориентированное на пользователя (usage-centered design). Оно управляется
ключевыми вариантами использования (essential use cases) или типовыми задачами (task
cases), а не пользовательскими историями. Однако мы можем заменить ключевые вари­
анты использования историями, что приводит нас к следующей разновидности гибкого
процесса на основе историй.
1. Выполните моделирование пользовательских ролей.
2. Осуществите сбор требований для высокоуровневых пользовательских историй.
Часть III. Часто обсуждаемые вопросы
3. Установите приоритеты пользовательских историй.
4. Разбейте истории с высоким и средним приоритетом на меньшие истории.
5. Организуйте истории в группы.
6. Создайте бумажный прототип.
7. Уточните прототип.
8. Приступайте к программированию.
Первое, что необходимо сделать, — это смоделировать пользовательские роли, дей­
ствуя в соответствии с описанием данного процесса, приведенным в главе 3. Для выпол­
нения следующих нескольких пунктов проведите собрание по написанию пользователь­
ских историй, о чем говорилось в главе 4. В начале собрания сосредоточьтесь на сборе
высокоуровневых историй, ориентируясь на то, чтобы их количество в большинстве
случаев не превосходило двух десятков.
Затем сгруппируйте истории в соответствии с тремя уровнями приоритета. Исто­
риям, которые должны быть включены в предстоящий выпуск, присвойте высокий
приоритет, историям, которые желательны для включения в предстоящий выпуск, —
средний приоритет, а историям, которые могут быть отложены до следующего выпу­
ска, — низкий приоритет. Отложите низкоприоритетные истории в сторону и разбейте
истории с высоким и средним приоритетом на меньшие истории. Размер этих историй
должен быть таким, чтобы их можно было использовать для планирования выпуска.
После этого распределите истории с высоким и низким приоритетом по группам так,
чтобы в каждой группе оказались истории, которые, вероятнее всего, будут выполняться
вместе. Далее создайте для каждой группы историй прототипы на бумаге. Получив бу­
мажные прототипы, покажите их пользователям (или, если нет другого выхода, предста­
вителям пользователей) и уточните прототипы на основании полученных комментариев.
Добавляя описанные этапы в свой проект, по возможности принимайте меры к тому,
чтобы это не приводило к усложнению всего процесса. Некоторые истории, которые
уже были определены и включаются в виде прототипов в пользовательский интерфейс,
в конечном счете могут быть исключены из проекта еще до того, как начнут разрабаты­
ваться. Старайтесь избегать излишних затрат времени на данной стадии. В большинстве
случаев на это может потребоваться от нескольких дней до нескольких недель (для ком­
мерческого программного обеспечения с удаленными пользователями).
▼----------------------------------------------------------------------------- ▼
Пишите оба варианта
Несколько лет назад, работая над одним проектом, мы пригласили Уорда Каннин­
гема, чтобы он проконсультировал нас и оценил проект. В тот момент нас волновали
проблемы пользовательского интерфейса. Имели место многочисленные жаркие де­
баты относительно того, какой вариант будет более предпочтительным для пользовате­
лей — интерфейс на основе браузера или традиционное настольное приложение. Наша
маркетинговая группа провела опрос пользователей, но мы не были уверены в том, что
он был достаточно представительным или выполнен так, как следует.
Уорд предложил следующее: “Напишите два пользовательских интерфейса”. Его
логика основывалась на том, что написать любой из двух вариантов интерфейса не со­
ставит большого труда, зато оба вместе они в любом случае обеспечат работоспособ­
ность среднего уровня приложения. При наличии двух вариантов интерфейса никакая
Глава 16. Дополнительные вопросы
часть функциональности не перемещалась бы зря на клиентский уровень, если бы это
означало, что данная часть должна быть написана дважды.
Рекомендация Уорда была правильной. Мы, конечно, не прислушались к ней, посчи­
тав разработку двух полноценных интерфейсов слишком дорогим удовольствием. Ког­
да продукт был уже готов, наши заказчики “обрадовали” нас, сообщив, что технология
пользовательского интерфейса была выбрана неверно. Нам пришлось срочно возо­
бновить работу над проектом для добавления второго пользовательского интерфейса.
▲----------------------------------------------------------------------------- ▲
Хранение историй
Споры относительно целесообразности хранения историй не являются редкостью.
По одну сторону баррикад находятся те, кто утверждает, что удовольствие, доставляемое
разрыванием карточек, когда разработка соответствующих историй завершена, переве­
шивает любую возможную пользу от сохранения карточек. По другую сторону баррикад
находятся те, кто настроен более консервативно и готов скорее сохранить истории, чем
допустить риск того, что истории, которые впоследствии могут понадобиться, окажутся
в числе выброшенных.
Если вы сохраняете истории в электронном виде, то для уничтожения завершенных
историй вряд ли найдутся веские причины. Возможно, уничтожение электронных вер­
сий историй, играющее роль своеобразного символа завершения работ, и доставит вам
определенное удовольствие и чувство удовлетворения, но, по всей видимости, эти чув­
ства не будут столь же яркими, как те, которые испытываешь, разрывая пополам реаль­
ную бумажную карточку.
Если же вы пользуетесь бумажными карточками, то в их разрывании на две части по
завершении соответствующей истории действительно есть нечто неуловимо приятное.
Я пользовался карточками в качестве кратких руководств по написанию данной кни­
ги, и всякий раз, когда заканчивал написание или редактирование очередного раздела,
я рвал карточку. Однако когда я работаю над программным проектом, а не над книгой,
то предпочитаю сохранять карточки, перевязывая их резиновой лентой и складывая на
полке в целях архивации.
На протяжении многих лет я не раз сталкивался с ситуациями, когда был благодарен
судьбе за то, что сохранил ранее использовавшиеся требования. Вот лишь некоторые из
таких случаев.
• Компания, на которую я работал, была куплена другой компанией. Наш упро­
щенный процесс разработки программного обеспечения весьма заинтересовал
компанию-поглотителя, однако они использовали свой, в значительной мере
ориентированный на каскадную модель подход с его многочисленными “шлюза­
ми” (gates) и “точками выхода” (sign-off points), через которые должен проходить
каждый проект. Поскольку я мог реально продемонстрировать им наш процесс
(от историй до кода и тестов), они разрешили нам продолжать использовать его
и не переходить на принятый в компании стандарт. В конечном счете, нам даже
удалось добиться того, чтобы наш процесс взяли на вооружение и в других отде­
лах этой же компании.
• В разное время мне пришлось неоднократно принимать участие в полном пере­
писывании кода коммерческих продуктов. В одном из таких случаев первая вер­
сия продукта потерпела коммерческий крах из-за неудачного выбора технологии.
Часть III. Часто обсуждаемые вопросы
Продукт бьи полностью переписан, что обеспечило ему средний коммерческий
успех. Еще один продукт, выполненный в виде приложения с клиент-серверной
архитектурой, пользовался ошеломительным успехом, и пять лет спустя компания
захотела переписать его, чтобы сделать доступным в Интернете. В этом нам при­
годились даже самые старые истории и требования, которые были задействованы
в новом проекте.
• Однажды я в очередной раз оказался в ситуации подобного рода, когда сотрудни­
чал с небольшой начинающей компанией, пытавшейся совершить сделку с гораз­
до более крупной компанией. Удачная сделка открывала перед компанией широ­
кие перспективы, так что в случае успеха босс пообещал выплатить каждому
разработчику бонусы, выражаемые пятизначными суммами. Меня попросили
“предоставить копию требований”. Сначала я попытался объяснить заказчикам,
что вместо подготовки формализованных требований мы используем другую ме­
тодику, в которой основной акцент делается на обсуждениях и сотрудничестве,
однако почувствовал, что такой разговор добром не кончится, а мечты о при­
быльности компании и больших бонусах разработчиков тают буквально на глазах.
Мне пришлось изменить тактику, и я просто рассказал присутствующим, что мы
готовим требования в виде пользовательских историй. Идея всем понравилась.
К счастью, наши истории хранились в проекте в электронном виде. Мы скопи­
ровали их, вставили в документ Word, добавили обложку и страницу подписей,
и в конечном итоге все остались счастливы.
Вспоминая, сколько раз меня выручали истории, которые я не выбрасывал, а сохра­
нял, могу дать лишь один совет — действуйте точно так же. Если вы используете для
этого программное обеспечение, то либо не удаляйте его из системы, либо выведите на
печать соответствующий отчет и храните его где-нибудь в папке.
Истории для устранения ошибок
Очень часто задают вопрос о том, как соотносятся между собой истории и отчеты
об ошибках. Я пришел к выводу, что лучше всего рассматривать каждый отчет об
ошибках как отдельную историю. Если ожидается, что устранение ошибки займет при­
мерно столько же времени, что и типичная история, обращайтесь с этой ошибкой как
с любой другой историей. Однако если команда считает, что некоторые ошибки удастся
устранить очень быстро, их следует объединить в одну или несколько историй. В случае
карточек это легко сделать, скрепив их вместе с карточкой-обложкой. После этого всю
коллекцию ошибок можно рассматривать в целях планирования как единую историю.
▼----------------------------------------------------------------------------- ▼
Использование карточек разного цвета
Многие команды используют карточки разного цвета, которые соответствуют исто­
риям различного типа. Например, традиционные белые карточки можно использовать
для обычных историй, красные карточки могут относиться к историям для ошибок, си­
ние — для задач технического характера и т.д.
Что касается лично меня, то использование цветных карточек всегда казалось мне
неплохой идеей, но только в теории, тогда как на практике это превращается в источ­
ник лишних хлопот. Вместо того чтобы держать в кармане про запас одни только пу-
Глава 16. Дополнительные вопросы
стые белые карточки, я должен следить за тем, чтобы под рукой всегда было несколько
карточек каждого цвета. Если заканчиваются карточки какого-то цвета, я должен ис­
пользовать карточки тех цветов, которые имеются, а затем переписывать истории на
карточки нужного цвета. Но если вы считаете, что использование разных цветов помо­
жет вам лучше организовать карточки, то почему бы не испытать это на практике. Я же
придерживаюсь более простого способа — запасаюсь большим количеством карточек
белого цвета.
Резюме
• Нефункциональные требования (например, те, которые касаются производитель­
ности, точности, переносимости, возможности повторного использования, удоб­
ства сопровождения, способности к взаимодействию и др.) часто могут обрабаты­
ваться путем создания карточек ограничений. Если к системе предъявляются бо­
лее строгие требования, дополните ваш подход, основанный на пользовательских
историях, любым другим форматом или методикой, которые позволяют лучше
всего выразить эти требования.
• Ни бумажные карточки, ни программные средства не являются наилучшим спо­
собом записи историй на все случаи жизни. Выбирайте тот способ, который луч­
ше соответствует потребностям проекта и команды.
• Итеративные процессы могут приводить к итеративным изменениям пользова­
тельского интерфейса. Пользователи, привыкшие к весьма специфическим осо­
бенностям интерфейса, не любят изменений, которые заставляют их изменять
уже знакомый им способ работы с программным обеспечением. Чтобы избежать
итеративных переделок пользовательского интерфейса, дополнительно задей­
ствуйте гибкие методы проектирования, ориентированного на пользователя.
• Уничтожение карточки после того, как разработка записанной на ней истории
завершена, доставляет определенное удовольствие. Однако существуют причины
и для того, чтобы сохранять карточки. Старайтесь поступать именно так, чтобы
обезопасить себя на случай непредвиденных обстоятельств.
• Скрепляйте вместе небольшие отчеты об ошибках, снабжая их карточкой-облож­
кой, и рассматривайте их как единую историю.
Обязанности разработчика
• Вы обязаны предлагать и использовать альтернативные методики и способы вы­
ражения требований, если это может помочь делу.
• Вы вместе с остальным коллективом отвечаете за принятие решения относитель­
но того, что лучше подходит для вашего проекта: бумажные карточки или про­
граммные средства.
• Вы вместе с остальным коллективом обязаны понимать преимущества и недо­
статки описания пользовательского интерфейса в самом начале проекта.
Часть III. Часто обсуждаемые вопросы
Обязанности заказчика
• Вы обязаны (а также должны добиваться этого от других) использовать альтерна­
тивные методики и способы выражения требований, если видите, что некоторые
требования недостаточно точно отображаются пользовательскими историями.
• Вы вместе с остальным коллективом отвечаете за принятие решения относитель­
но того, что лучше подходит для вашего проекта: бумажные карточки или про­
граммные средства.
• Вы вместе с остальным коллективом обязаны понимать преимущества и недо­
статки описания пользовательского интерфейса в самом начале проекта.
Контрольные вопросы
16.1. Как следует обработать требование, в котором говорится о том, что система долж­
на допускать масштабирование, обеспечивающее одновременную работу вплоть
до 1000 пользователей?
16.2. Что вы предпочитаете: записывать истории на карточках или использовать для
этого программные средства? Обоснуйте свой ответ.
16.3. Какое влияние оказывает итеративность процесса на пользовательский интерфейс
приложения?
16.4. Приведите примеры систем, в которых рассмотрение пользовательского интер­
фейса на более ранних стадиях, чем это обычно принято в agile-проектах, могло
бы принести пользу.
16.5. Как бы вы рекомендовали поступать с историями после завершения их разработ­
ки: сохранять или выбрасывать? Обоснуйте свой ответ.
ЧАСТЬ IV
Пример
Эта часть книги посвящена демонстрации всего изложенного ранее материала на одном
конкретном примере. В последующих главах мы познакомимся с компанией South Coast
Nautical Supplies и ее сотрудниками, создающими веб-сайт, который должен дополнить
уже имеющийся печатный каталог продукции компании. Вам представится хорошая
возможность приобщиться к определению ролей пользователей, написанию пользова­
тельских историй вместе с Лори (вице-президентом South Coast по продажам и марке­
тингу и заказчиком данного проекта), оценке трудоемкости историй, созданию плана
выпуска, а также написанию ряда приемочных тестов для историй, включенных в пер­
воначальный план.
Глава 17
Пользовательские роли
На протяжении пяти глав мы будем заниматься разработкой небольшого гипотетическо­
го проекта. В этой главе мы начнем с определения ключевых пользовательских ролей.
В следующих главах мы перейдем к написанию историй, их оценке, планированию вы­
пуска и написанию приемочных тестов для историй, включенных в выпуск.
Проект
Компания South Coast Nautical Supplies в течение вот уже тридцати лет занимается
продажей товаров для яхтсменов, используя для этой цели печатный каталог. Каталог
включает перечень таких товаров, как устройства GPS, часы, метеорологическое обо­
рудование, навигационные и регистрирующие приборы, спасательные плоты, надувные
спасательные жилеты, справочные таблицы, карты и книги. До сих пор присутствие
компании в Интернете бьшо ограничено простейшим веб-сайтом с одной-единственной
страницей, посетителям которой предлагалось заказать каталог, сделав бесплатный зво­
нок по указанному номеру телефона.
Наш босс наконец-то пришел к выводу, что компания должна идти в ногу со време­
нем и осуществлять продажу товаров через Интернет. При этом он решил начать не с са­
мых дорогих товаров, а с книг. Некоторые товары, числящиеся в каталоге, стоят свыше
10 тысяч долларов, и до тех пор, пока не будет уверенности в том, что сайт работает
нормально и заказы не теряются, рисковать с продажей дорогостоящих изделий он не
хочет. Но если будет видно, что идея оформления заказов в онлайновом режиме при­
шлась клиентам по душе, а сайт работает бесперебойно, то мы расширим онлайновую
торговлю, включив в нее весь ассортимент товаров.
И последнее. Босс сказал, что сайт должен быть сдан в эксплуатацию через тридцать
дней, так как это даст нам шанс увеличить объем продаж на пике летнего сезона.
Определение заказчика
У проекта должен быть заказчик, который поможет написать пользовательские исто­
рии. Вообще говоря, заказчиками в рассматриваемом проекте выступают яхтсмены, по­
купающие книги, но все они находятся за пределами компании. Поэтому нам нужен
внутренний заказчик, который смог бы представлять интересы реальных заказчиков.
Эту роль босс отвел Лори, вице-президенту компании по продажам и маркетингу.
Во время первой встречи Лори с разработчиками она более подробно рассказала
о системе, которая ей нужна. Сайт видится ей как “типичный электронный книжный
магазин”. Она хочет, чтобы сайт позволял заказчикам находить нужные им книги са­
мыми разными способами (мы не настаивали на более подробных разъяснениях) и что-
Часть IV Пример
бы пользователи сайта могли вести список книг, которые они впоследствии хотели бы
купить, оценивать покупаемые ими книги и публиковать свои отзывы о них, а также
контролировать состояние заказа. Мы видели множество подобных сайтов в Интернете
и поэтому сказали Лори, что готовы сразу же приступить к работе.
Определение начальных ролей
Первое, что мы делаем, — это организуем встречу разработчиков с Лори в комнате
с большим столом. Лори уже изучила рынок и знакома с демографическим составом на­
ших типичных клиентов. Лори и разработчики подготавливают карточки перечислен­
ных ниже ролей пользователей и раскладывают их на столе, как показано на рис. 17.1.
• Ветеран (Hardcore Sailor).
• Любитель (Novice Sailor).
• Новичок (New Sailor).
• Покупающий в подарок (Gift-Buyer).
• Супруг (Non-Sailing Spouse).
• Администратор (Administrator).
• Вице-президент по продажам (Sales Vice President).
• Капитан (Charter Captain).
• Опытный мореплаватель (Experienced Sailor).
• Школа (Sailing School).
• Библиотека (Library).
• Инструктор (Instructor).
■ Рис. 17.1. Расположение карточек ролей пользователей
Глава 17. Пользовательские роли
Объединение и сужение ролей
После того как названия ролей записаны на карточках, мы должны устранить их
полное или частичное дублирование, проанализировать возможности их объединения
и прийти к уточненному списку ролей, с которыми будет начат проект. Проще всего
приступить к этому, попытавшись удалить те карточки, которые располагаются целиком
поверх других карточек, указывая на то, что их автор считает данные роли дублирующими.
В нашем случае карточка Новичок (New Sailor) была помещена поверх карточки
Любитель (Novice Sailor). Авторы этих карточек объяснили, что они подразумевают под
этими ролями, и каждый желающий смог сделать свои замечания. Оказалось, что роли
Любитель и Новичок различаются между собой. Новичок — это тот, кто недавно начал
заниматься парусным спортом; возможно, в настоящее время он только берет уроки или
уже успел выйти под парусом несколько раз. Автор карточки Любитель имел в виду, что
эта роль будет представлять тех, кто занимался яхтингом на протяжении нескольких лет,
но не настолько часто, чтобы достичь в этом мастерства. Группа решила, что хотя меж­
ду этими ролями и существуют незначительные различия, они не настолько разнятся
между собой, чтобы для них вводились две роли. Обе роли были объединены в одну —
Любитель, а карточку Новичок порвали и выбросили.
Затем группа рассматривает перекрывающиеся карточки Школа (Sailing School)
и Инструктор (Instructor). Автор карточки Инструктор объясняет, что эта роль представ­
ляет преподавателей, обучающих парусному спорту. Он говорит, что инструкторы часто
покупают книги для своих учеников во многих экземплярах и могут составлять списки
книг, которые ученики должны прочитать. Автор карточки Школа указывает, что при­
мерно то же самое имел в виду и он, когда предлагал свой вариант, однако считает, что
более типичным пользователем, выступающим в этой роли, будет администратор шко­
лы, а не инструктор. Лори, являющаяся заказчиком, разъясняет нам, что выбор админи­
стратора школы в качестве кандидата на эту роль почти ничего не даст, поскольку мно­
гие его характеристики будут совпадать с характеристиками инструктора. Ввиду того что
название роли Инструктор более четко представляет определенную персонификацию,
чем общее название Школа, карточка Школа рвется.
Карточка Ветеран (Hardcore Sailor) частично перекрывается карточками ролей
Инструктор, Опытный мореплаватель (Experienced Sailor) и Капитан (Charter Captain).
В процессе обсуждения этих ролей группа выясняет, что по замыслу автора роль Вете­
ран (Hardcore Sailor) соответствует тем яхтсменам, которым обычно хорошо известно,
какие книги им нужны. Например, Ветеран отлично знает, какая книга по навигации
самая лучшая. Поэтому его шаблоны поиска будут значительно отличаться от шабло­
нов поиска, используемых менее сведущими яхтсменами, в том числе и Опытным мо­
реплавателем. Роль Опытный мореплаватель представляет людей, отлично знакомых
с продукцией, которую им будет предлагать веб-сайт, но не способных с ходу назвать
лучшие книги по данной тематике.
После обсуждения карточки Капитан команда решает, что это, по сути, та же самая
роль, что и Опытный мореплаватель, и карточка рвется.
К этому моменту команда решила оставить карточки ролей Любитель, Инструктор,
Ветеран и Опытный мореплаватель. Были выброшены карточки Новичок, Капитан
и Школа. Однако еще предстоит рассмотреть карточки Покупающий в подарок (Gift
Buyer), Супруг (Non-Sailing Spouse), Администратор (Administrator) и Вице-президент по
продажам (Sales Vice President). Авторы карточек этих ролей объясняют свои намерения.
Часть IV Пример
Роль Покупающий в подарок представляет тех, кто сам не увлекается парусным
спортом, но покупает подарки для тех, кто им занимается. Автор роли Супруг сказал,
что то же самое имел в виду и он, предлагая эту роль. После обсуждения этих двух ро­
лей команда решает объединить их и оставить только карточку Покупающий в подарок,
тогда как карточка роли Супруг рвется.
Автор роли Администратор объясняет, что эта роль представляет тех, кто выполняет
функции, относящиеся к одному или нескольким администраторам. В их обязанности
входит загрузка данных в систему и выполнение всех других необходимых операций по
обеспечению работы системы. Это первая из обсуждаемых командой ролей, которая не
относится к покупателям товара, предлагаемого на сайте. После ее обсуждения команда
решает, что она важна, а Лори замечает, что у нее будет несколько историй, связанных
с обслуживанием системы и способами добавления новых записей в список товаров.
Следующей обсуждается роль Вице-президент по продажам. Это еще одна роль,
которая не относится к категории покупателей. Однако главный исполнительный ди­
ректор компании поставил обязательное условие, чтобы за работой новой системы ве­
лось тщательное наблюдение с целью изучения ее влияния на объем продаж. Команда
размышляет над тем, не исключить ли вообще эту роль, поскольку считает, что найдет­
ся не так уж много историй, предназначенных специально для нее. В конечном счете
команда решает сохранить роль, но под более общим названием — Читатель отчетов
(Report Viewer).
Далее обсуждается роль Библиотека (Library). В какой-то момент команда решила,
что, возможно, эта роль совпадает с ролью Школа или же Супруг. Однако группа отбро­
сила эту идею и сохранила роль Библиотека. В то же время, придерживаясь той точки
зрения, что создаваемые роли должны представлять отдельных пользователей, группа
порвала карточку Библиотека и заменила ее карточкой Библиотекарь.
К данному моменту команда остановилась на составе ролей, представленном на
рис. 17.2.
■ Рис. 17.2. Состав ролей после их объединения и обсуждения
Моделирование ролей
Далее команда рассматривает каждую роль по отдельности и добавляет описания де­
талей в соответствующие карточки. Конкретные детали могут быть самыми разными,
Глава 17. Пользовательские роли
в зависимости от специфики предметной области и типа программного обеспечения, но
к числу универсальных факторов, заслуживающих внимания, относятся следующие.
• Предполагаемая частота использования программного обеспечения.
• Профессиональный опыт пользователя в данной предметной области.
• Умение пользователя обращаться с компьютерами и программным обеспечением.
• Наличие у пользователя опыта эксплуатации программного обеспечения, анало­
гичного разрабатываемому.
• Цели пользователя, которые он надеется реализовать, переходя к использованию
данного программного обеспечения. Для одних это удобство эксплуатации про­
граммы, для других — возможность обогатить свой опыт и т.д.
Эти вопросы обсуждаются группой применительно к каждой роли. Пустовавшие до
того карточки ролей заполняются следующей информацией.
Новичок. Имеет опыт совершения покупок через Интернет. Ожидается, что он
сделает 6 покупок в течение первых 3 месяцев занятий парусным спортом. Иногда
обращается на сайт с целью приобретения конкретной книги, а иногда нужда­
ется в помощи с выбором книги, которая ему нужна. Хочет, чтобы на сайте он
мог получить более квалифицированную помощь при выборе подходящей книги
(хорошо подобранный материал, изложенный на достаточно профессиональном
уровне), чем в обычном книжном магазине.
Инструктор. Ожидается, что он будет часто пользоваться сайтом; нередко это бу­
дет происходить раз в неделю. Часто делает ряд однотипных заказов (например,
заказывает 20 экземпляров одной книги), звоня в отдел продаж компании. Умеет
пользоваться веб-сайтом, но обычно чувствует себя несколько неуверенно, когда
работает за компьютером. Обзоры и любые другие “излишества” его не интересуют.
Ветеран. Как правило, не имеет опыта работы с компьютером. Приобретает мно­
гие товары, указанные в каталоге компании, однако покупка книг для него яв­
ляется редкостью. Его основные покупки — это всевозможное дополнительное
оборудование. Обычно точно знает, что ему нужно. Не хочет чувствовать себя ту­
пицей, пытаясь воспользоваться услугами сайта.
Опытный мореплаватель. Хорошие навыки работы с компьютером. Ожидается,
что заказы от него будут поступать один или два раза в квартал, хотя летом это
может происходить чаще. Знает многое о парусном спорте, но обычно это связано
лишь с определенным регионом. Заинтересован в продукции, о которой имеются
прекрасные отзывы от других яхтсменов, и хочет побольше узнать о наилучших
местах для яхтинга.
Покупающий в подарок. Обычно хорошо владеет компьютером (иначе не покупал
бы подарки через Интернет). Не увлекается парусным спортом и в лучшем случае
лишь поверхностно знаком с соответствующей терминологией. Обычно будет об­
ращаться за какой-то очень специфической книгой, но может искать и книгу по
определенной тематике.
Библиотекарь. Хорошо владеет компьютером. В точности знает, что ищет, и пред­
почитает заказывать книги по номеру ISBN, а не по автору или названию. Не осо­
бенно заинтересован в таких дополнительных услугах, как обертывание подарка
Часть IV Пример
в красивую упаковку или отправка уведомления о его вручении. Число ежегодных
заказов обычно невелико, но каждый заказ будет делаться на большее количество
книг по сравнению с индивидуальными заказами.
Администратор. В совершенстве владеет компьютером. Имеет по крайней мере
поверхностное представление о парусном спорте. В процессе выполнения своих
функциональных обязанностей ежедневно обращается к серверной части системы.
Заинтересован в скорейшем изучении программного обеспечения, но впослед­
ствии захочет пользоваться возможностями на уровне продвинутого пользователя.
Читатель отчетов. Средний уровень владения компьютером; главным образом
работает с такими программами, как электронные таблицы и текстовые процес­
соры. Заинтересован в получении самых подробных сведений о работе системы,
а также данных о том, какие посетители совершают покупки и какими навига­
ционными или поисковыми средствами сайта они пользуются. Готов жертвовать
скоростью ради полноты и степени детализации получаемых сведений.
Добавление личностей
Иногда стоит затратить еще несколько минут и добавить к тому, что уже сделано,
личность (persona). Команда спрашивает Лори, какая из имеющихся пользовательских
ролей представляет пользователей, чье мнение будет определяющим в оценке успешно­
сти нового веб-сайта. Лори отвечает, что в этом отношении важны Ветераны, которые,
как правило, становятся постоянными клиентами. Однако, хотя эта категория потенци­
альных пользователей сайта и посвящает значительную часть жизни парусному спор­
ту, книги они покупают редко. С другой стороны, важными клиентами можно считать
многочисленную категорию Опытных мореплавателей, поскольку заметная часть книг
покупается ими. Завершает свои рассуждения Лори тем, что самой важной ролью явля­
ется, пожалуй, роль Инструктора. Через инструкторов школ на протяжении года можно
продать сотни книг. Более того, продолжает Лори, как только заработает новый сайт,
она продумает способы материального поощрения тех инструкторов, которые будут на­
правлять на наш сайт своих учеников.
Приняв во внимание полученную информацию, команда решает ввести в проект две
личности. Одна из них — Тереза — увлекается парусным спортом уже четыре года. Она
работает главным исполнительным директором в одной биотехнологической компании
и может совершенно спокойно осуществлять свои покупки через Интернет. В плавание
Тереза отправляется в основном в летнее время, поэтому сайтом она будет пользоваться
на протяжении весны или лета, готовясь к очередному круизу. Она очень занята, так что
наш сайт поможет ей сэкономить время и найти книги, которых она до этого не видела.
Тереза замужем за Томом, который сам не плавает, но уже составил Терезе компанию
в паре круизов по Средиземному морю.
Вторая личность — капитан Рон — ходит под парусом в течение вот уже 40 лет и со­
держит школу парусного спорта в Сан-Диего. Пять лет назад он оставил преподаватель­
скую деятельность в средней школе и с тех пор обучает яхтингу других, выступая в каче­
стве инструктора. В течение последних десяти лет он постоянно делает заказы через наш
каталог. Он все еще немного робеет перед стоящим в его офисе компьютером, однако
в достаточной степени заинтригован возможностью заказа книг через Интернет, кото­
рую мы надеемся ему предоставить.
Глава 17. Пользовательские роли
О целесообразности введения личностей Терезы и капитана Рона
Вопрос о том, стоит ли добавлять личности в нашу систему, является спорным. Вво­
дите личности в проект лишь в тех случаях, когда это поможет вашей команде проду­
мать истории для пользователей, максимально полное удовлетворение потребностей
которых будет иметь решающее значение для успешности системы. В случае описан­
ной системы South Coast Nautical Supplies дополнительные усилия в этом направлении
были бы, вероятно, неоправданными.
Однако поскольку личности могут значительно обогатить ваш арсенал доступных
средств, я включил в проект личности Терезы и капитана Рона для полноты рассматри­
ваемого нами примера.
Глава 18
Истории
Для составления начального списка историй команда решает созвать собрание по напи­
санию историй (story writing workshop), на котором члены команды постараются пред­
ложить как можно больше историй в течение выделенных для этого одного-двух часов.
Один из возможных подходов состоит в том, чтобы просто записывать истории в лю­
бом порядке, независимо от того, какие роли или личности в них фигурируют. Можно
поступить и по-другому — начать с конкретной роли или личности пользователя и на­
писать для нее все истории, которые может предложить команда, и только после этого
перейти к написанию историй для очередной роли или личности. При любом подходе
результат будет одним и тем же. В нашем случае команда, предварительно обсудив этот
вопрос, решает последовательно прорабатывать каждую роль или личность.
Истории для Терезы
Команда решает начать с Терезы — личности, определенной в предыдущей главе, по­
скольку Лори, играющая в команде роль заказчика, сказала, что для нового веб-сайта
критически важно, чтобы он удовлетворял потребности Терезы. Команда знает, что
Тереза заинтересована в скорости и качестве обслуживания. Она является по-настоя­
щему продвинутым пользователем и не будет иметь ничего против введения незначи­
тельных усложнений в работу с сайтом, если это позволит ускорить процедуру поиска.
Первой из написанных для нее историй была история, отображенная на карточке 18.1.
Пользователь может осуществлять поиск книг по автору, названию
и номеру ISBN.
■ Карточка истории 18.1
У разработчиков возникли некоторые вопросы относительно этой истории. Напри­
мер, следует ли предоставлять пользователю возможность выполнять поиск одновре­
менно по автору, названию и ISBN-номеру книги или же Лори предпочитает, чтобы
в одно и то же время поиск можно было проводить только по одному из критериев?
Разработчики решили пока не выслушивать ответы на эти вопросы и сосредоточились
на написании менее детализированных историй, носящих предварительный характер.
Далее Лори сказала, что после выполнения поиска пользователь должен иметь воз­
можность просмотреть подробную информацию о книге. Она приводит несколько при­
меров, поясняющих, какую именно информацию она имеет в виду, и записывает исто­
рию, отображенную на карточке 18.2.
Часть IV. Пример
Пользователь может просмотреть детальную информацию о книге.
В частности, это может быть количество страниц в книге, дата
публикации и краткое описание.
■ Карточка истории 18.2
Вероятно, кроме этой дополнительной информации о книге, она могла бы указать
и еще кое-что, но разработчики смогут расспросить ее об этом позднее, когда приступят
к написанию исходного кода данной истории.
Создавая типичный сайт интернет-магазина, разработчики, безусловно, знают о том,
что пользователям понадобится виртуальная покупательская корзина (shopping cart),
в которую они смогут “откладывать” приобретаемые книги. Кроме того, заказчик в лице
Лори замечает, что пользователи должны иметь возможность удалять книги из корзины,
прежде чем заказ будет обработан. Так появляются истории, отображенные на карточках
историй 18.3 и 18.4.
Пользователь может поместить книги в 'покупательскую корзину”
и купить их лишь после окончательного выбора книг
■ Карточка истории 18.3
Пользователь может удалять книги из своей корзины, прежде чем заказ
будет выполнен.
■ Карточка истории 18.4
Для фактической обработки заказа с помощью кредитной карты системе должна
быть сообщена информация о самой кредитной карте, с которой необходимо снять
деньги, а также некоторая адресная информация. Это приводит к истории 18.5.
Чтобы купить книгу, пользователь вводит адрес плательщика, адрес
доставки и данные кредитной карты.
■ Карточка истории 18.5
Лори напоминает разработчикам, что поскольку Тереза занимается яхтингом всего
четыре года, она не всегда имеет точное представление о том, какую именно книгу она
хотела бы купить. С точки зрения Терезы сайт должен включать средства, позволяющие
Глава 18. Истории
клиентам давать свою оценку книгам и публиковать отзывы. Это приводит Лори к на­
писанию истории 18.6.
Пользователь может присваивать книгам рейтинги публиковать
отзывы о них.
■ Карточка истории 18.6
Поскольку Тереза хочет, чтобы оформление заказа выполнялось как можно быстрее,
команда решает, что система должна запоминать платежную информацию и адрес до­
ставки. Некоторые клиенты сайта, например те, которые представлены ролью Поку­
пающий в подарок, могут не захотеть создавать учетную запись ввиду того, что редко
совершают покупки. Точно так же любые дополнительные действия, если их придется
выполнять уже при первом посещении, могут отпугнуть капитана Рона, который всегда
предпочитает сначала присмотреться к новому сайту. Поэтому Лори решает, что поль­
зователь может покупать книги как с созданием учетной записи, так и без этого, и за­
писывает истории 18.7 и 18.8.
Пользователь может создать учетную запись, в которой будут
сохраняться платежные данные и адрес доставки.
■ Карточка истории 18.7
Пользователь может изменить данные своей учетной записи (номер
кредитной карты, адрес доставки, адрес плательщика и т.п.)
■ Карточка истории 18.8
Команда также знает, что для Терезы важно иметь возможность вести список книг,
которые она хотела бы приобрести, но не может сделать этого в настоящее время. Она
либо сама купит их позже, либо попросит своего мужа Тома, и тот купит для нее книги
из составленного ею списка. В связи с этим Лори пишет истории 18.9 и 18.10.
Пользователь может помешать книги в "список пожеланий”, доступный
для просмотра другим посетителям сайта.
■ Карточка истории 18.9
Часть IV. Пример
Пользователь может переместить книгу из “списка пожеланий” (даже
если это не его список) в свою покупательскую корзину.
■ Карточка истории 18.10
Мы хотим быть уверенными в том, что кто бы ни программировал историю 18.10,
ему будет известно, что пользователь может выбирать книги не только из собственного
списка, но даже из списка другого пользователя. Этого можно добиться, записав на кар­
точке примечание (в данном случае оно заключено в скобки).
Поскольку для Терезы важна скорость обслуживания, Лори вводит ограничение, ка­
сающееся производительности, которое устанавливает допустимые пределы времени на
оформление заказа книги. Она пишет историю 18.11.
Клиент, посещающий сайт не в первый раз, должен иметь возможность
Затрачивать на поиск одной книги и ее заказ не долее 90 секунд.
(Ограничение)
■ Карточка истории 18.11
В данном случае Лори решила сфокусировать внимание на времени, которое может
затратить на поиск книги и оформление заказа пользователь, неоднократно посещав­
ший сайт в прошлом. Это пример хорошо сформулированного требования, поскольку
оно отражает все аспекты пользовательского опыта работы с сайтом. Ни поразительно
быстрое выполнение запросов к базе данных, ни высокопроизводительный сервер при­
ложений ничего не значат, если интерфейс пользователя настолько неудачен, что до­
браться до экрана поиска пользователь сможет лишь минуты за три. Данная история
отражает все эти факторы гораздо лучше, нежели история “Поиск должен выполняться
в течение двух секунд”. Естественно, Лори может добавить дополнительные ограниче­
ния, касающиеся производительности, но обычно достаточно выбрать лишь несколько
широких ограничений, подобных тому, которое использовано в данной истории.
Истории для капитана Рона
К этому моменту становится ясно, что команда исчерпала истории для роли Опыт­
ный мореплаватель в лице Терезы. Поэтому все соглашаются переключить свое вни­
мание на капитана Рона, который заведует школой парусного спорта и чувствует себя
за компьютером не так уверенно, как Тереза. Оказавшись на сайте, капитан Рон, как
правило, в точности знает, что именно он ищет. Это приводит Лори к написанию исто­
рий 18.12 и 18.13.
Эти истории позволяют капитану Рону обратиться к своим предыдущим заказам
и повторно закупить указанные в них книги. Однако Лори отмечает, что у капитана
Рона может возникнуть желание купить также книги, которые ранее он лишь просма­
тривал, но не купил. В связи с этим Лори пишет историю 18.14.
Глава 18. Истории
Пользователь может просмотреть состояние всех своих предыдущих
заказов.
■ Карточка истории 18.12
Пользователь может <5ез труда совершать повторные покупки книг;
просматривая предыдушиезаказы.
■ Карточка истории 18.13
Сайт всегда уведомляет посетителя о последних Ъ (Я) просмотренных
им книгах и предоставляет ссылки на такие книги. (Это средство
работает даже при переключениях между сеансами.)
■ Карточка истории 18.14
Истории для новичка
После этого команда переходит к рассмотрению роли Новичок. Потребности нович­
ка в основном пересекаются с потребностями Терезы и капитана Рона. Но Лори решает,
что для новичка будет очень полезно иметь возможность просматривать список наших
рекомендаций. В этом списке новичок мог бы найти книги, рекомендуемые для чтения
по самому широкому ряду тем. Лори пишет историю 18.15.
Пользователь может просматривать список рекомендуемой нами
литературы по ряду тематик.
■ Карточка истории 18.15
Истории для покупающего в подарок
Перейдя к рассмотрению роди Покупающий в подарок, команда обсуждает, до
какой степени простым должен быть для посетителя поиск списка пожеланий друго­
го пользователя сайта. Начинается обсуждение различных вариантов проектных реше­
ний и полей, которые должны предоставляться для выполнения поиска, но тут команда
вспоминает, что технические детали проекта пока не должны обсуждаться, поскольку
это должно делаться позже. В связи с этим Лори пишет историю 18.16.
Часть IV. Пример
Пользователь, особенно покупающий в подарок, может легко находить
списки пожеланий других пользователей.
■ Карточка истории 18.16
Лори также знает, что система должна поддерживать заказ поздравительных откры­
ток и подарочных упаковок. Она пишет истории 18.17 и 18.18.
Пользователь может заказать доставку товара в подарочной
упаковке
■ Карточка истории 18.17
Пользователь может заказать вложение в подарок поздравительной
открытки с предоставленным им текстом поздравления.
■ Карточка истории 18.18
Истории для читателя отчетов
Лори говорит, что в системе должна быть предусмотрена генерация отчетов о со­
вершении покупок, посещаемости и т.д. О детальном составе таких отчетов она еще не
думала, поэтому разработчики пишут простую историю-заместитель, которая напомнит
им о необходимости разработки средств для генерации отчетов. О содержимом отчетов
они смогут подумать позже. А пока что Лори пишет историю 18.19.
Читатель отчетов может просматривать списки ежедневных покупок,
развитые по категориям книг показателям спроса и т.п.
■ Карточка истории 18.19
Размышления над отчетами напомнили Лори о том, что в них будет содержаться ин­
формация, не предназначенная для открытого доступа. Разумеется, нельзя допустить,
чтобы к отчетам можно было получать доступ с основного сайта, который видят все
клиенты. Однако Лори добавляет, что отчеты должны быть доступными лишь для опре­
деленных лиц внутри компании. Под этим можно понимать либо то, что человек, имею­
щий право доступа к одному отчету, может получать доступ и ко всем другим отчетам,
либо то, что определенные пользователи могут получать доступ лишь к определенным
Глава 18. Истории
отчетам. На данном этапе разработчики не требуют от Лори никаких дополнительных
разъяснений по этому поводу, и она записывает историю 18.20.
Прежде чем просматривать отчеты, пользователь должен пройти
процедуру аутентификации.
■ Карточка истории 18.20
Лори замечает, что для повышения информативности отчетов веб-сайт должен ис­
пользовать ту же базу данных, что и нынешняя система, основанная на приеме заказов
по телефону. Это приводит Лори к написанию ограничения, отображенного на карточке
истории 18.21.
Заказы, сделанные через ве^-сайт, должны фиксироваться в той же
^азе данных, что и телефонные заказы.
(Ограничение)
Карточка истории 18.21
Административные истории
На следующем этапе команда сосредоточивает свое внимание на пользователях,
представленных ролью Администратор. Команде немедленно приходят на ум истории
18.22 и 18.23.
Администратор может добавлять на сайт новые книги.
■ Карточка истории 18.22
Администратор должен утвердить или отвергнуть отзыв, прежде чем
он появится на сайте,
■ Карточка истории 18.23
История, касающаяся добавления новых книг, напомнила команде о том, что, если
при добавлении книги была введена неверная информация, администратор должен
иметь возможность удалять книги из списка или редактировать сведения о них. Поэтому
пишутся истории 18.24 и 18.25.
Часть IV Пример
Администратор может удалить книгу из списка.
■ Карточка истории 18.24
Администратор может изменить информацию об имеющейся книге.
■ Карточка истории 18.25
Подведение итогов
К этому моменту фантазия Лори в отношении предложения новых историй начала
иссякать. До этого каждая история немедленно приходила ей на ум, а теперь, пытаясь
предложить очередную историю, она должна напрягать память. Поскольку процесс раз­
работки проекта будет итеративным и инкрементным, вовсе не обязательно, чтобы за­
казчик продумал все истории наперед. Даже если идея новой истории появится у Лори
уже после того, как проект начнется, у нее останется возможность добавить историю
в выпуск вместо другой истории, имеющей примерно такую же оценку.
Разработчики спрашивают Лори, есть ли у нее еще какие-нибудь истории, которые
она, возможно, упустила из виду. Лори пишет историю 18.26.
Пользователь может проверить состояние своих последних заказов.
Если заказ еще не был доставлен, пользователь может добавить или
удалить из него книги, изменить способдоставки, адрес доставки
и данные кредитной карты.
■ Карточка истории 18.26
Кроме того, Лори напоминает разработчикам, что хотя к масштабируемости сайта
и не предъявляются какие-то особые требования, он должен обеспечивать одновремен­
ную работу по крайней мере 50 пользователей. Разработчики записывают соответствую­
щее ограничение на карточке истории 18.27.
Система должна выдерживать пиковую нагрузку при одновременном
подключении до 60 пользователей.
(Ограничение)
■ Карточка истории 18.27
Глава 19
Оценка историй
Текст истории
Пользователь может осуществлять поиск книг по автору, названию и номеру ISBN
Пользователь может просмотреть детальную информацию о книге. В частности, это может
быть количество страниц в книге, дата публикации и краткое описание
Пользователь может поместить книги в покупательскую корзину и купить их лишь после
окончательного выбора книг
Пользователь может удалять книги из своей корзины, прежде чем заказ будет выполнен
Чтобы купить книгу, пользователь вводит адрес плательщика, адрес доставки и данные кредитной карты
Пользователь может присваивать книгам рейтинг и публиковать отзывы о них
Пользователь может создать учетную запись, в которой будут сохраняться платежные данные
и адрес доставки
Пользователь может изменить данные своей учетной записи (номер кредитной карты, адрес
доставки, адрес плательщика и т.п.)
Пользователь может помещать книги в “список пожеланий”, доступный для просмотра другим посетителям сайта
Пользователь может переместить книгу из “списка пожеланий” (даже если это не его список) в свою покупательскую корзину
Клиент, посещающий сайт не в первый раз, должен иметь возможность затрачивать на поиск
одной книги и ее заказ не более 90 секунд
(Ограничение)
Пользователь может просмотреть состояние всех своих предыдущих заказов
Пользователь может без труда совершать повторные покупки книг, просматривая предыдущие заказы
Сайт всегда уведомляет посетителя о последних 3 (?) просмотренных им книгах и предоставляет ссылки на такие книги. (Это средство работает даже при переключениях между сеансами)
Часть IV. Пример
Окончание табл. 19.1
Текст истории
Пользователь может просматривать список рекомендуемой нами литературы по ряду тематик
Пользователь, особенно покупающий в подарок, может легко находить списки пожеланий
других пользователей
Пользователь может заказать доставку товара в подарочной упаковке
Пользователь может заказать вложение в подарок поздравительной открытки с предоставленным им текстом поздравления
Читатель отчетов может просматривать списки ежедневных покупок, разбитые по категориям книг, показателям спроса и т.п.
Прежде чем просматривать отчеты, пользователь должен пройти процедуру аутентификации
Заказы, сделанные через веб-сайт, должны фиксироваться в той же базе данных, что и телефонные заказы
Администратор может добавлять на сайт новые книги
Администратор должен утвердить или отвергнуть отзыв, прежде чем он появится на сайте
Администратор может удалить книгу из списка
Администратор может изменить информацию об имеющейся книге
Пользователь может проверить состояние своих последних заказов. Если заказ еще не был
доставлен, пользователь может добавить или удалить из него книги, изменить способ доставки, адрес доставки и данные кредитной карты
Система должна выдерживать пиковую нагрузку при одновременном подключении до 50
пользователей
(Ограничение)
Чтобы создать план выпуска, необходимо иметь оценку каждой истории. Как вам
уже известно из главы 8, разработчики будут оценивать истории в баллах, которые могут
представлять идеальное время, сложность или какую-то другую меру, смысл которой по­
нятен команде.
Первая история
Начинать с истории, числящейся в списке первой (“Пользователь может осущест­
влять поиск книг по автору, названию и номеру ISBN”), вовсе не обязательно, одна­
ко в данном случае она вполне подходит для того, чтобы рассмотреть ее первой. Когда
Лори написала эту историю, разработчикам не было до конца понятно, имела ли она
в виду, что пользователь может осуществлять поиск по всем полям сразу или по одному
за раз. Поскольку оценка в значительной мере зависела от ответа Лори, стоило разузнать
об этом более подробно.
Естественно, Лори ответила, что она предпочла бы иметь оба варианта. Она выска­
зала пожелание, чтобы мы предусмотрели режим простого поиска, при котором поиск
по автору или названию книги можно было бы осуществлять путем ввода исходных дан­
ных в одном из этих полей. Она также хотела бы иметь экран расширенного поиска,
на котором в качестве поисковых критериев можно было бы задавать значения любого
из перечисленных в пользовательской истории полей или любую их комбинацию. Даже
Глава 19. Оценка историй
если бы история предусматривала оба режима поиска, ее размер все равно не был бы
чрезмерно большим. Однако между двумя названными режимами поиска существуют
столь явные различия, что вполне естественно разбить эту историю на две отдельные —
19.1 и 19.2.
"Пользователь может осуществлять простой поиск по слову или фразе,
введенным в полях автора и названия книги.
■ Карточка истории 19.1
"Пользователь может осуществлять поиск книг используя любую
комбинацию значений, введенных в полях автора, названия и |5#Ы
■ Карточка истории 19.2
Три программиста — Ральф, Джей и Мария — и Лори (заказчик) собираются вместе
в одной комнате, чтобы приступить к оценке историй. Они приносят с собой карточ­
ки историй и несколько десятков пустых карточек. Программисты обсуждают карточку
истории 19.1, выясняют недостающие детали, задавая вопросы Лори, а затем каждый
из них записывает свою оценку на учетной карточке. После этого каждый программист
выставляет свою карточку так, чтобы ее могли видеть все остальные. На карточках за­
писаны следующие результаты.
Ральф
Джей
Мария
1
1/2
2
Трое разработчиков начинают обсуждать оценки. Мария объясняет, почему она оце­
нила эту историю в два балла. Она говорит о том, что им необходимо выбрать поиско­
вый движок, подключить его и лишь после этого можно будет написать код экранов для
реализации истории. Джей сказал, что он уже знаком со всеми вероятными вариантами
организации поиска и сможет достаточно уверенно продвигаться в нужном направле­
нии, и поэтому его оценка оказалась гораздо более низкой.
По результатам обсуждения каждый программист записывает новые оценки и пока­
зывает их. На этот раз результаты были следующими.
Ральф
Джей
Мария
1
1
1
Все объясняется очень просто. Джей решил повысить свою оценку, а Марию убе­
дили, что команда сможет завершить разработку истории быстрее, чем первоначально
предполагалось. Теперь все разработчики одинаково оценили историю в один балл,
и эта оценка будет использоваться для истории 19.1. Программисты приступают к за­
писи оценок, как показано в табл. 19.2.
Обратите внимание на то, что в процессе оценивания историй Лори, выступающая
в качестве заказчика, все время находится рядом с программистами, но никакого уча-
Часть IV. Пример
стия в оценке историй не принимает. Поскольку Лори не выполняет в проекте функ­
ции программиста, ей не разрешено участвовать в выставлении оценок. Если она будет
это делать, то тем самым помешает нормальному ходу процесса. Разумеется, если Лори
услышит оценку, заметно выпадающую из общего ряда (либо слишком низкую, либо
слишком высокую), то, возможно, понадобятся некоторые замечания или разъяснения
с ее стороны. Например, она может сказать: “Я понимаю, что, согласно вашему описа­
нию, это действительно можно оценить в десять баллов, но мне кажется, что стоит по­
смотреть на вещи проще. Все, что мне на самом деле нужно, это...”
Таблица 19.2. Начало записи оценок для историй
Оценка
История
Пользователь может осуществлять простой поиск по слову или фразе, введенным
в полях автора и названия книги.
1
Расширенный поиск
Далее обсуждается карточка истории 19.2, описывающая расширенный поиск.
Программисты вновь записывают свои оценки на учетных карточках. Закончив, участ­
ники показывают свои карточки, на которых отображены следующие результаты.
Ральф
Джей
Мария
2
1
2
Ральф говорит, что для написания кода расширенного поиска потребуется больше
времени, чем для простого, поскольку придется учитывать большее количество параме­
тров поиска. Джей соглашается с ним, однако замечает, что к этому времени код ба­
зового поиска уже будет готов, благодаря чему сроки разработки расширенного поиска
сократятся. Мария возражает, говоря, что истории не зависят друг от друга и поэтому
не известно, какая из них будет завершена первой. Лори, как заказчик, говорит, что она
сама еще не определилась относительно того, какая из этих двух историй должна разра­
батываться первой. Она склонна считать, что первым должен быть разработан базовый
поиск, но сможет сказать об этом более уверенно, когда узнает окончательные оценки
каждой истории (т.е. сможет судить о соответствующих трудозатратах).
После проведения еще одного или двух раундов обсуждения, в ходе которых на кар­
точках проставляются оценки историй, все сходятся на том, что, хотя над расширен­
ным поиском и придется поработать немного дольше, чем над базовым, эта разница не
слишком существенна, так что и эта история оценивается в один балл.
Оценка следующих историй не вызвала никаких затруднений, и ни одна из них не
нуждалась в разбиении на более мелкие истории. Разработчики пришли к оценкам,
представленным в табл. 19.3.
Таблица 19.3. Создание списка оценок для историй
История
Пользователь может осуществлять простой поиск по слову или фразе, введенным
в полях автора и названия книги
Оценка
1
Глава 19. Оценка историй
Окончание табл. 19.3
История
Оценка
Пользователь может осуществлять поиск книг, используя любую комбинацию значе­
ний, введенных в полях автора, названия и ISBN
1
Пользователь может просмотреть детальную информацию о книге. В частности, это
может быть количество страниц в книге, дата публикации и краткое описание
1
Пользователь может поместить книги в покупательскую корзину и купить их лишь
после окончательного выбора книг
1
Пользователь может удалять книги из своей корзины, прежде чем заказ будет выпол­
нен
1/2
Чтобы купить книгу, пользователь вводит адрес плательщика, адрес доставки и дан­
ные кредитной карты
2
Рейтинги и отзывы
Следующая история (“Пользователь может присваивать книгам рейтинг и публико­
вать отзывы о них”) немного сложнее. Прежде чем написать оценки и показать их друг
другу, разработчики обсуждают историю. С рейтинговой частью затруднений не пред­
видится, а вот с отзывами не все так просто. Для их ввода придется предусмотреть со­
ответствующий экран и, вероятно, предоставить пользователям возможность предвари­
тельного просмотра отзывов перед их публикацией. Будут ли отзывы вводиться в виде
простого текста или в виде HTML? Следует ли предоставлять пользователям возмож­
ность публикации отзывов лишь на те книги, которые они у нас приобрели?
Поскольку публикация отзывов потребует от разработчиков больших усилий, чем
присвоение рейтингов, было принято решение разбить эту историю на две отдельные —
19.3 и 19.4.
Пользователь может присваивать книгам рейтинг от 1 (низкий) до 5
(высокий). Оцениваемые пользователем книги не обязаны принадлежать
к числу тех, которые он купил у нас
■ Карточка истории 19.3
Пользователь может написать отзыв о книге и предварительно
Просмотреть его перед отправкой. Книги, отзывы на которые
пользователь может публиковать, не обязаны принадлежать к числу тех,
которые он купил у нас
■ Карточка истории 19.4
Часть IV. Пример
Программисты оценивают историю 19.3 в два балла, а историю 19.4 — в четыре балла.
Одновременно с обсуждением историй, связанных с присвоением книгам рейтинга
и публикацией отзывов о них, программисты рассмотрели и историю “Администратор
должен утвердить или отвергнуть отзыв, прежде чем он появится на сайте”. Эта история
может быть как совсем простой, так и сложной, если потребовать, чтобы администратор
указывал причину отказа в публикации и, возможно, направлял автору отзыва свой от­
вет по электронной почте. Программисты прийти к выводу, что Лори вряд ли захочет
усложнять эту историю, и в результате обсуждения оценили ее в два балла.
Учетные записи
Следующая история (“Пользователь может создать учетную запись, которая будет
использоваться для запоминания платежной информации и адреса доставки”) кажется
простой, и разработчики оценивают ее в два балла.
Далее разработчики приступают к оценке истории “Пользователь может изменить
данные своей учетной записи (номер кредитной карты, адрес доставки, адрес плательщи­
ка и т.п.)”. Несмотря на то что эта история не является слишком большой, она легко раз­
бивается на меньшие истории. Разбиение историй наподобие рассматриваемой зачастую
оказывается целесообразным, поскольку это обеспечивает дополнительную гибкость на
стадии планирования выпуска и позволяет заказчику устанавливать приоритеты работ на
более детальном уровне. Например, в нашем случае Лори может прийти к выводу, что
для пользователей возможность изменения данных платежной карты важна, тогда как
предоставление им возможности изменять информацию об адресах можно отложить
на несколько итераций. Первоначальная история разбивается на истории 19.5 и 19.6.
Пользователь может изменить данные о кредитной карте, хранящиеся
в его учетной записи.
■ Карточка истории 19.5
Пользователь может изменить адреса доставки и плательшикз,
хранящиеся в его учетной записи.
■ Карточка истории 19.6
Ни одна из этих историй не кажется трудной, и поэтому программисты оценивают
историю 19.5 в 1/2 балла, а историю 19.6 — в один балл.
Завершение процесса оценивания историй
Описанный процесс повторяется для каждой оставшейся истории. Лишь некоторые
из них заслуживают отдельных замечаний. Прежде всего, это неточно сформулирован­
ная история “Пользователь, особенно покупающий в подарок, может легко находить
Глава 19. Оценка историй
списки пожеланий других пользователей”. Когда Лори спросили, что она под этим
подразумевает, она дала достаточно подробные объяснения, что позволило переписать
историю в следующем виде (история 19.7).
Пользователь, особенно покупающий в подарок, может искать
список пожеланий по имени его владельца и состоянию заказа.
■ Карточка истории 19.7
Затем все сходятся во мнении, что история “Пользователь может проверить состоя­
ние своих последних заказов. Если заказ еще не был доставлен, пользователь может до­
бавить или удалить из него книги, изменить способ доставки, адрес доставки и данные
кредитной карты” нуждается в разбивке. Одна история будет охватывать проверку со­
стояния последних заказов, а вторая — изменение заказов, которые еще не были достав­
лены. Это привело к историям 19.8 и 19.9.
Пользователь может проверить состояние своих последних заказов.
■ Карточка истории 19.8
Егсли заказ еще не <5ыл доставлен, пользователь может добавить или
удалить из него книги, изменить способ доставки, адрес доставки и
данные кредитной карты.
■ Карточка истории 19.9
Наконец, следующие три истории являются ограничениями.
• Клиент, посещающий сайт не в первый раз, должен иметь возможность затрачи­
вать на поиск одной книги и ее заказ не более 90 секунд.
• Заказы, сделанные через веб-сайт, должны фиксироваться в той же базе данных,
что и телефонные заказы.
• Система должна выдерживать пиковую нагрузку при одновременном подключе­
нии до 50 пользователей.
Будучи ограничениями, эти истории оказывают влияние на другие истории, но не
требуют написания для них собственного кода.
Полная сводка оценок историй
Полная сводка оценок историй приведена в табл. 19.4.
Часть IV. Пример
Таблица 19.4. Полный список историй и их оценок
История
Оценка
Пользователь может осуществлять простой поиск по слову или фразе, введенным
в полях автора и названия книги
1
Пользователь может осуществлять поиск книг, используя любую комбинацию значе­
ний, введенных в полях автора, названия и ISBN
1
Пользователь может просмотреть детальную информацию о книге. В частности, это
может быть количество страниц в книге, дата публикации и краткое описание
1
Пользователь может поместить книги в покупательскую корзину и купить их лишь
после окончательного выбора книг
1
Пользователь может удалять книги из своей корзины, прежде чем заказ будет вы­
полнен
1/2
Чтобы купить книгу, пользователь вводит адрес плательщика, адрес доставки и дан­
ные кредитной карты
2
Пользователь может присваивать книгам рейтинг от 1 (низкий) до 5 (высокий).
Оцениваемые пользователем книги не обязаны принадлежать к числу тех, которые
он купил у нас
2
Пользователь может написать отзыв о книге и предварительно просмотреть его перед
отправкой. Книги, отзывы на которые пользователь может публиковать, не обязаны
принадлежать к числу тех, которые он купил у нас
4
Администратор должен утвердить или отвергнуть отзыв, прежде чем он появится
на сайте
2
Пользователь может создать учетную запись, которая будет использоваться для запо­
минания платежной информации и адреса доставки
2
Пользователь может изменить данные о кредитной карте, хранящиеся в его учетной
записи
1/2
Пользователь может изменить адреса доставки и плательщика, хранящиеся в его
учетной записи
1
Пользователь может помещать книги в “список пожеланий”, доступный для просмо­
тра другим посетителям сайта
2
Пользователь, особенно покупающий в подарок, может искать список пожеланий по
имени его владельца и состоянию заказа
1
Пользователь может проверить состояние своих последних заказов
1/2
Если заказ еще не был доставлен, пользователь может добавить или удалить из него
книги, изменить способ доставки, адрес доставки и данные кредитной карты
1
Пользователь может переместить книгу из “списка пожеланий” (даже если это не его
список) в свою покупательскую корзину
1/2
Клиент, посетивший сайт не в первый раз, должен иметь возможность затратить на
поиск одной книги и ее заказ не более 90 секунд
0
Пользователь может просмотреть состояние всех своих предыдущих заказов
1
Пользователь может без труда совершать повторные покупки книг, просматривая
предыдущие заказы
1/2
Глава 19. Оценка историй
Окончание табл. 19.4
История
Оценка
Сайт всегда уведомляет посетителя о последних 3 (?) просмотренных им книгах
и предоставляет ссылки на такие книги. (Это средство работает даже при переключе­
ниях между сеансами)
1
Пользователь может просматривать список рекомендуемой нами литературы по ряду
тематик
4
Пользователь может заказать доставку товара в подарочной упаковке
1/2
Пользователь может заказать вложение в подарок поздравительной открытки с пре­
доставленным им текстом поздравления
1/2
Читатель отчетов может просматривать ежедневные покупки, разбитые по катего­
риям книг, показателям спроса и т.д.
8
Прежде чем просматривать отчеты, пользователь должен пройти процедуру аутенти­
фикации
1
Заказы, сделанные через веб-сайт, должны фиксироваться в той же базе данных, что
и телефонные заказы
0
Администратор может добавлять на сайт новые книги
1
Администратор может удалить книгу из списка
1/2
Администратор может изменить информацию об имеющейся книге
1
Система должна выдерживать пиковую нагрузку при одновременном подключении
до 50 пользователей
0
Глава 20
План выпуска
Создание плана выпуска предусматривает выполнение следующих действий.
1. Выбор длительности итерации.
2. Оценка производительности команды.
3. Установление приоритетов историй.
4. Распределение историй по одной или нескольким итерациям.
Поскольку возможности нового веб-сайта должны стать доступными для пользова­
телей через четыре недели, команда решает использовать итерации длительностью в две
недели. Таким образом, до установленного крайнего срока разработчики успеют выпол­
нить две итерации. Для уверенности в том, что их разработка будет завершена в срок,
команда включает разработку функциональных возможностей с наивысшим приорите­
том в первую итерацию. После первой итерации команда сможет оценить ход выпол­
нения проекта и решить, какой объем работ можно спланировать для второй итерации.
Оценка производительности команды
Функции программистов в проекте будут выполнять Мария и Ральф. Джей помо­
гал им в оценке историй, но имеющиеся у него другие обязательства препятствуют его
дальнейшему участию в проекте. Поскольку данный проект не похож на предыдущие
веб-сайты, которые нашим программистам приходилось создавать ранее, они не в со­
стоянии оценить скорость разработки нового проекта. Поэтому все, что они могут сде­
лать, — выдвинуть относительно этого некие обоснованные предположения.
В процессе оценки историй Мария и Ральф пользовались свободным определени­
ем балла истории как одного идеального дня программирования. Они решили, что в их
случае один идеальный рабочий день будет эквивалентен двум-трем реальным рабочим
дням. Исходя из того, что длительность итерации составляет две недели (10 рабочих
дней), а разработка ведется силами двух программистов, мы получаем 20 человеко-дней
на одну итерацию. Мария и Ральф пришли к выводу, что в течение каждой итерации
они смогут выполнять объем работ, оцениваемый в 7—10 баллов. Решив быть более
сдержанными в оценке своих возможностей на первой итерации, они приняли для ско­
рости разработки значение, равное 8 баллов.
Установление приоритетов историй
Приоритеты историй устанавливает заказчик в лице Лори. Основным фактором, от
которого зависит приоритет истории, является обеспечиваемая ею бизнес-ценность.
Однако при этом Лори придется учитывать и оценку трудоемкости каждой истории
Часть IV Пример
в баллах. Иногда даже весьма желательные для заказчика истории должны уступить ме­
сто другим, если учесть их стоимость (оценку).
Прежде чем назначать историям приоритеты, Лори, исходя из того, насколько важ­
ным является завершение разработки конкретной истории в установленный срок, ко­
торый наступит через четыре недели, раскладывает карточки историй в четыре стопки,
соответствующие категориям “обязательно”, “желательно”, “возможно” и “необяза­
тельно”. Истории, отнесенные Лори к категории обязательных для разработки, пред­
ставлены в табл. 20.1.
Таблица 20.1. Истории, включение которых в начальный выпуск является
обязательным
История
Оценка
Пользователь может осуществлять простой поиск по слову или фразе, введенным
в полях автора и названия книги
1
Пользователь может поместить книги в покупательскую корзину и купить их лишь
после окончательного выбора книг
1
Пользователь может удалять книги из своей корзины, прежде чем заказ будет выполнен
1/2
Чтобы купить книгу, пользователь вводит адрес плательщика, адрес доставки и дан­
ные кредитной карты
2
Пользователь может создать учетную запись, которая будет использоваться для запо­
минания платежной информации и адреса доставки
2
Заказы, сделанные через веб-сайт, должны фиксироваться в той же базе данных, что
и телефонные заказы
0
Администратор может добавлять на сайт новые книги
1
Администратор может удалить книгу
1/2
Администратор может изменить информацию об имеющейся книге
1
Система должна выдерживать пиковую нагрузку при одновременном подключении
до 50 пользователей
0
Суммарная оценка историй, выбранных Лори для обязательной разработки, равна
девяти. Поскольку скорость разработки составляет восемь баллов на итерацию, а всего
будет две итерации, то имеется возможность добавить в выпуск некоторые истории, от­
несенные Лори к категории желательных для разработки. Из стопки карточек этой ка­
тегории Лори выбирает истории, представленные в табл. 20.2. Теперь отобранные для
разработки обязательные и желательные истории суммарно оцениваются в 15,5 балла,
что очень близко к 16 баллам, соответствующим объему работ, который программисты
считают посильным для выполнения на протяжении двух итераций.
Таблица 20.2. Желательные для разработки истории, которые Лори добавила
в план выпуска
История
Оценка
Пользователь может осуществлять поиск книг, используя любую комбинацию значений, введенных в полях автора, названия и ISBN
1
Пользователь может изменить данные о кредитной карте, хранящиеся в его учетной
записи
1/2
Глава 20. План выпуска
Окончание табл. 20.2
История
Оценка
Пользователь может изменить адреса доставки и плательщика, хранящиеся в его
учетной записи
1
Пользователь может просматривать список рекомендуемой нами литературы по ряду
тематик
4
Окончательный план выпуска
Окончательный план выпуска, представленный в табл. 20.3, передается в остальные
подразделения организации. Мария и Ральф приложат все усилия к тому, чтобы своев­
ременно выполнить работы, запланированные на первую итерацию. Если все у них пой­
дет хорошо, они смогут переместить одну или две дополнительные истории в первую
итерацию. Если же они увидят, что отстают от графика, то посоветуются с Лори и пере­
местят одну или две истории из первой итерации во вторую.
Таблица 20.3. Окончательный план выпуска
Итерация 1
Итерация 2
Пользователь может осуществлять простой поиск по
слову или фразе, введенным в полях автора и названия
книги
Администратор может изменить
информацию об имеющейся книге
Пользователь может поместить книги в покупатель­
скую корзину и купить их лишь после окончательного
выбора книг
Пользователь может осуществлять
поиск книг, используя любую ком­
бинацию значений, введенных
в полях автора, названия и ISBN
Пользователь может удалять книги из своей корзины,
прежде чем заказ будет выполнен
Пользователь может изменить дан­
ные о кредитной карте, хранящиеся
в его учетной записи
Чтобы купить книгу, пользователь вводит адрес пла­
тельщика, адрес доставки и данные кредитной карты
Пользователь может изменить
адреса доставки и плательщика,
хранящиеся в его учетной записи
Заказы, сделанные через веб-сайт, должны фиксиро­
ваться в той же базе данных, что и телефонные заказы
Пользователь может просматривать
список рекомендуемой нами лите­
ратуры по ряду тематик
Пользователь может создать учетную запись, которая
будет использоваться для запоминания платежной ин­
формации и адреса доставки
Администратор может добавлять на сайт новые книги
Администратор может удалить книгу
Система должна выдерживать пиковую нагрузку при
одновременном подключении до 50 пользователей
Глава 21
Приемочные тесты
Приемочное тестирование историй используется для проверки того, что функциональ­
ные возможности программного обеспечения полностью соответствуют ожиданиям
заказчика. Отсюда следует, что ответственность за спецификацию тестов лежит на за­
казчике. Однако во многих случаях заказчику помогает в этом тестировщик проекта.
Поскольку наш проект небольшой и команда не имеет возможности выделить отдель­
ного участника на роль тестировщика, Лори заручается поддержкой Марии и Ральфа.
Положительным эффектом такого сотрудничества является то, что, помимо составления
списка приемочных тестов, Лори и программисты получают дополнительную возмож­
ность общения друг с другом.
Тестирование поиска
Возможности поиска, разработка которых в соответствии с приоритетами, установ­
ленными Лори, включена в первую итерацию, отображены на карточках историй 21.1
и 21.2. Ниже приведены тесты для истории 21.1.
• Искать слово, о котором известно, что оно входит в название книги, но вероят­
ность того, что оно встретится в имени автора книги, мала; например, “навигация”.
• Искать слово, которое может входить в имя автора книги, но вероятность того,
что оно встретится в названии книги, мала; например, “John”.
• Искать слово, вероятность вхождения которого как в полное имя автора книги,
так и в ее название крайне мала; например, “wookie”.
Пользователь может осуществлять простой поиск по слову или срразе,
введенным в полях автора и названия книги.
■ Карточка истории 21.1
Тесты для истории 21.2 выглядят следующим образом.
• Использовать в полях автора и названия книги значения, которые соответствуют
по крайней мере одной книге.
• Использовать в полях автора и названия книги значения, которые не соответству­
ют ни одной книге.
• Выполнить поиск книги по номеру ISBN.
Часть IV Пример
Пользователь может осуществлять поиск книг; используя любую
комбинацию значений, введенных в полях автора, названия и iS^N.
■ Карточка истории 21.2
Тестирование покупательской корзины
Карточки историй 21.3 и 21.4 связаны с использованием покупательской корзины.
Пользователь может поместить книги в покупательскую корзину и
купить их лишь после окончательного выбора книг
■ Карточка истории 21.3
Пользователь может удалять книги из своей корзины, прежде чем заказ
будет выполнен.
■ Карточка истории 21.4
Лори и программисты обсуждают эти истории и приходят к выводу, что с ними еще
связаны некоторые неясности. Могут ли пользователи помещать в свои корзины кни­
ги, отсутствующие на складе? Что можно сказать о книгах, которые еще не вышли из
печати? Кроме того, команда вдруг осознает, что хотя случай уменьшения количества
заказанных экземпляров какой-либо книги (вплоть до О) охватывается историей 21.4,
возможность увеличения количества заказанных экземпляров какой-либо книги не
предусмотрена. Это можно было бы учесть написанием отдельной истории для данно­
го случая, но вместо этого команда решает изъять карточку истории 21.4 и заменить ее
карточкой истории 21.5.
Пользователь может корректировать количество экземпляров
какой-либо книги в своей корзине. Установка количества экземпляров
книги в О приводит к удалению данной книги из корзины.
■ Карточка истории 21.5
Важность результата этого обсуждения состоит в том, что система упростилась.
Решив не создавать отдельную историю для удаления заказанной книги из покупатель­
ской корзины, команда повысила удобство использования системы и одновременно из­
бежала потенциальной необходимости выполнять дополнительную работу в будущем.
Глава 21. Приемочные тесты
Тесты для истории 21.3 приведены ниже.
• Поместить в корзину книгу, отсутствующую на складе. Убедиться в получении
пользователем извещения о том, что книга будет доставлена, как только появится
на складе.
• Поместить в корзину книгу, еще не вышедшую из печати. Убедиться в получении
пользователем извещения о том, что книга будет доставлена, как только появится
на складе.
• Поместить в корзину книгу, имеющуюся на складе.
• Поместить в корзину второй экземпляр какой-либо книги. Убедиться, что значе­
ние счетчика увеличилось на единицу.
Тесты для истории 21.5 приведены ниже.
• Изменить количество заказанных экземпляров книги с одного до десяти.
• Изменить количество заказанных экземпляров книги с десяти до одного.
• Удалить книгу, установив количество заказанных экземпляров равным нулю.
Покупка книг
Карточка истории 21.6 касается фактической покупки книг. В процессе обсуждения
этой истории программисты получают некоторые разъяснения от Лори. Лори хочет, что­
бы пользователи могли вводить адрес плательщика и адрес доставки по отдельности или
указывать, что эти адреса совпадают. Сайт будет принимать к оплате только платежные
карты Visa и MasterCard.
Чтоды купишь кишу, пользователь вводит адрес плательщика, адрес
доставки и данные кредитной карты.
■ Карточка истории 21.6
Тесты для истории 21.6 приведены ниже.
• Ввести адрес плательщика и указать, что адрес доставки должен быть таким же.
• Ввести по отдельности адрес плательщика и адрес доставки.
• Тестировать с указанием города и почтового индекса, который соответствует дру­
гому городу, и убедиться в том, что данная ошибка обнаруживается.
• Проверить, что адресом, по которому будет доставляться книга, является адрес
доставки, а не адрес плательщика.
• Тестировать с действительной картой Visa.
• Тестировать с действительной картой MasterCard.
• Тестировать с действительной картой American Express (не проходит).
• Тестировать с просроченной картой Visa.
Часть IV. Пример
• Тестировать с картой MasterCard, кредитный лимит которой исчерпан.
• Тестировать с картой Visa, в номере которой пропущена цифра.
• Тестировать с картой Visa, в номере которой переставлены цифры.
• Тестировать с картой Visa, для которой указан неверный номер.
Учетные записи пользователей
Карточка истории 21.7 охватывает создание учетных записей пользователей. Тесты
для нее приведены ниже.
• Пользователи могут оформлять заказы без создания учетной записи.
• Создать учетную запись, а затем войти в нее и просмотреть сохраненную инфор­
мацию.
Пользователь может создать учетную запись, в которой будут
сохраняться платежные данные и адрес доставки.
■ Карточка истории 21.7
Карточки историй 21.8 и 21.9 дают возможность пользователям изменять информа­
цию, сохраненную в их учетных записях. Тесты для истории 21.8 приведены ниже.
• Изменить номер кредитной карты так, чтобы он стал недействительным.
• Изменить дату окончания срока действия кредитной карты на прошедшую дату.
Убедиться в выводе соответствующего предупреждения для пользователя.
• Изменить номер кредитной карты на другой действительный номер и убедиться
в том, что он сохранился.
• Изменить дату окончания срока действия кредитной карты на будущую дату
и убедиться в том, что она сохранилась.
Пользователь может изменить данные о кредитной карте, хранящиеся
в его учетной записи.
■ Карточка истории 21.8
Тесты для истории 21.9 приведены ниже.
• Изменить различные части адреса доставки и убедиться в том, что изменения со­
храняются.
• Изменить различные части адреса плательщика и убедиться в том, что изменения
сохраняются.
Глава 21. Приемочные тесты
Пользователь может изменить адреса доставки и плательщика,
хранящиеся в его учетной записи.
■ Карточка истории 21.9
Администрирование
Карточка истории 21.10 позволяет администратору добавлять на сайт новые книги.
Тесты для этой истории приведены ниже.
• Протестировать возможность добавления книги на сайт администратором.
• Протестировать невозможность добавления книги на сайт пользователем, не яв­
ляющимся администратором.
• Протестировать, что книга будет добавлена только в том случае, если указаны все
необходимые данные.
Администратор может добавлять на сайт новые книги.
■ Карточка истории 21.10
Карточка истории 21.11 позволяет администратору удалять книги. Тесты для этой
истории приведены ниже.
• Проверить, что администратор может удалить книгу.
• Проверить, что пользователь, не являющийся администратором, не может уда­
лить книгу.
• Удалить книгу, а затем убедиться в том, что это не помешает выполнению теку­
щих заказов на данную книгу.
Администратор может удалить книгу из списка.
■ Карточка истории 21.11
Карточка истории 21.12 позволяет администратору изменить информацию о книге.
Обсуждая историю 21.12, программисты и Лори выясняют, как обрабатывать недостав­
ленные заказы, включающие книгу, для которой изменилась цена. Это становится од­
ним из тестов для данной истории.
• Проверить, что такие параметры заказа, как название книги, автор, количество
страниц и т.п., могут быть изменены.
• Проверить, что цену можно изменить, но это не коснется ранее оформленных
(однако не оплаченных или не доставленных) заказов.
Часть IV. Пример
Администратор может изменить информацию об имеющейся книге.
■ Карточка истории 21.12
Тестирование ограничений
Истории, которым Лори назначила приоритеты для первого выпуска, содержат два
ограничения, представленные на карточках 21.13 и 21.14.
Заказы, сделанные через вебсайт, должны фиксироваться в той же
базе данных, что и телефонные заказы.
■ Карточка истории 21.13
Система должна выдерживать пиковую нагрузку при одновременном
подключении до 60 пользователей.
■ Карточка истории 21.14
Единственный тест для истории 21.13 состоит в том, чтобы проверить базу данных
и убедиться в том, что заказ, отправленный через веб-сайт, сохраняется в ней.
• Сделать заказ. Открыть базу данных телефонных заказов и убедиться в том, что
заказ сохранился в ней.
Лори берет карточку истории 21.14, переворачивает ее и делает следующую запись.
• Тестировать с имитацией пятидесяти пользователей, одновременно выполняю­
щих различные операции поиска и размещения заказов. Убедиться в том, что на
отображение любого экрана уходит не более четырех секунд и что заказы не те­
ряются.
Завершающая история
Единственная оставшаяся история представлена на карточке 21.15.
Пользователь может просматривать список рекомендуемой нами
литературы по ряду тематик.
■ Карточка истории 21.15
Глава 21. Приемочные тесты
Лори вместе с разработчиками обсуждают карточку истории 21.15 и решают, что она
будет реализована в виде простой статической страницы, отображающей список реко­
мендованной литературы по ряду различных тематик. Они пишут следующие тесты.
• Выбрать тему (например, Навигация или Круизы) и просмотреть список реко­
мендованной литературы по ней. Убедиться в том, что отображаемые ссылки со­
ответствуют запросу.
• Щелкнуть на элементе списка для проверки того, что браузер переходит на стра­
ницу, содержащую информацию о соответствующей книге.
ЧАСТЬ V
Приложения
Чтобы прочитать данную книгу и извлечь из нее пользу, глубокие познания в области
экстремального программирования не потребуются. Но так как пользовательские исто­
рии уходят корнями в экстремальное программирование, вам будет полезно ознако­
миться с кратким введением в эту дисциплину в приложении А. В приложении Б при­
ведены ответы на контрольные вопросы, которыми завершается большинство глав.
Приложение А
Обзор экстремального
программирования
Это приложение служит кратким введением в основные концепции экстремального про­
граммирования (Extreme Programming, ХР). Если вы уже знакомы с ХР, то, пропустив
этот материал, ничего не потеряете. В противном случае ознакомьтесь с ним, чтобы по­
лучить первоначальное представление об ХР, а затем обратитесь к одной из множества
превосходных книг, посвященных подробному описанию методологии экстремального
программирования1.
Сначала мы рассмотрим роли, представляющие различных людей, которые участву­
ют в проекте ХР. Затем будут описаны двенадцать основных приемов ХР. В заключение
будет рассказано о ценностях, которые должны культивироваться в ХР-командах.
Роли
В ХР заказник (customer) отвечает за написание историй и установку их приоритетов,
а также за написание и выполнение тестов, призванных продемонстрировать, что раз­
работка историй привела к ожидаемым результатам. Заказчиком в ХР может быть поль­
зователь создаваемой системы, хотя это вовсе не обязательно. В роли заказчика часто
выступает менеджер по продукту (product manager), менеджер проекта (project manager)
или бизнес-аналитик (business analyst).
В некоторых проектах заказчиком может быть целая команда, включающая несколь­
ко человек с высокой степенью мотивации. В состав команды заказчика часто включа­
ются тестировщики, оказывающие помощь в создании приемочных тестов (acceptance
tests). Для подобных проектов очень важно, чтобы от команды заказчика исходило еди­
ное мнение. Этого можно добиться разными способами, но обычно это достигается пу­
тем назначения в команде заказчика одного человека, являющегося, так сказать, пер­
вым среди равных.
Роль программиста в ХР охватывает широкий спектр технических специальностей.
В проектах ХР стараются не проводить различий между программистами, дизайнерами,
администраторами баз данных и т.п. Ожидается, что все программисты будут работать
как одна команда и совместно исполнять многие из обязанностей, которые в проектах,
не являющихся проектами ХР, были бы закреплены за отдельными людьми. Почти во
всех разновидностях ХР-процессов предполагается, что программисты подвергают свой
код модульному тестированию (unit testing). В ХР к этому относятся в высшей степени
серьезно, причем предполагается, что автоматизированные модульные тесты будут раз­
рабатываться программистами для любого написанного ими кода.
1 В частности, см. [4]; [36]; [53].
Часть V. Приложения
Наконец, во многих случаях ХР-команды усиливают, вводя в их состав наставника,
или координатора, и, возможно, менеджера проекта. Иногда эти две роли сочетаются
в одном физическом лице. Координатор обязан следить за тем, чтобы команда придер­
живалась ключевых стратегий ХР, и направлять ее на путь истинный, если она с него
собьется. Менеджер проекта — это не руководитель, а, скорее, лидер команды, который
берет на себя выполнение всех бюрократических функций и по возможности устраняет
все препятствия, мешающие работе команды.
Двенадцать основных приемов ХР
Экстремальное программирование базируется на двенадцати основных приемах
(practices), описанных в оригинальной “белой книге” Кента Бека [4]. При разработке
проектов с использованием методологии ХР настоятельно рекомендуется внедрять эти
приемы в комплексе. Все они взаимосвязаны, и только их совместное применение обе­
спечивает эффект синергии. Каждый из приемов усиливает действие любого другого.
Например, выполнять рефакторинг значительно легче, если он дополняется вопло­
щением на практике идей парного программирования, простоты дизайна, совместно­
го владения кодом, непрерывной интеграции кода и разработки через тестирование.
Указанные двенадцать приемов — это не просто случайное собрание хороших идей, из
которого команда ХР вольна выбирать те, которые ей нравятся больше. С адаптацией
ХР “под себя” лучше повременить до тех пор, пока вы не накопите достаточный опыт
проектирования с применением идей ХР и будете в состоянии формировать свои прави­
ла относительно того, чем в том или ином подходе можно пренебречь, а что, возможно,
лучше видоизменить.
Указанные двенадцать приемов ХР перечислены ниже:
• частые выпуски версий (Small releases);
• игра в планирование (Planning game);
• рефакторинг (Refactoring);
• разработка через тестирование (Test-driven development);
• парное программирование (Pair programming);
• оптимальный рабочий ритм (Sustainable расе);
• совместное владение кодом (Team code ownership);
• стандарты кодирования (Coding standard);
• простота дизайна (Simple design);
• метафора системы (Metaphor);
• непрерывная интеграция (Continuous integration);
• присутствие заказчика в команде (On-site customer).
Частые выпуски версий
Проекты ХР развиваются через ряд последовательных циклов, называемых итерация­
ми, длительность которых обычно составляет от одной до трех недель. За одну итерацию
Приложение А. Обзор экстремального программирования
команда обязана реализовать функциональные возможности, описанные в соответству­
ющих пользовательских историях, в полном объеме. Частичная реализация возможно­
стей не допускается. Точно так же не допускается разработка возможностей в полном
объеме в ущерб запланированному качеству. К концу каждой итерации команда обязана
получить полностью работоспособный и протестированный код, готовый к немедленно­
му использованию.
В начале проекта команда определяет продолжительность одной итерации, которая
будет оставаться неизменной на протяжении всего проекта. Продолжительность итера­
ции обычно составляет одну-две недели, но в любом случае не должна превышать че­
тыре недели. Команда должна выбирать итерации как можно меньшей длительности,
но так, чтобы конечный результат кааждой итерации по-прежнему представлял некую
реальную деловую ценность. Если вам трудно остановиться на одном из двух вариантов,
выбирайте более короткий.
Итерациями устанавливаются жесткие временные рамки циклов разработки. Команда
не может достигнуть последнего планового дня итерации и решить, что ей требуется еще
два дополнительных дня. Итерация заканчивается в запланированный день. Чтобы впи­
саться в итерацию, корректируется объем работ, выполняемых командой (но не их каче­
ство).
Игра в планирование
Игра в планирование (Planning Game) — так называют в ХР процесс планирования
выпусков и итераций, в ходе которого разработчики и заказчик в сотрудничестве друг
с другом делают разумные предположения относительно этапов будущей разработки.
Прежде чем приступить к планированию, заказчик пишет истории на бумажных или
картонных карточках, а разработчики оценивают трудоемкость (cost), или размеры (mag­
nitude), каждой истории и записывают соответствующую оценку на карточке истории.
Приступая к планированию, разработчики оценивают, какой объем работ они смо­
гут выполнить за одну итерацию с выбранной в проекте длительностью. Затем заказчик
просматривает все карточки историй и выбирает те из них, которые с его точки зрения
имеют наивысший приоритет, для включения в первую итерацию. Ему разрешается вы­
бирать истории таким образом, чтобы сумма их оценок была близка к оценке объема ра­
бот, который разработчики берутся выполнить в течение первой итерации, но не превы­
шала ее. После того как отобраны истории для заполнения первой итерации, заказчик
переходит к выбору историй для второй и последующих итераций.
Заполнив историями некоторое количество итераций, заказчик решает, что общее
количество включенных в них историй достаточно для того, чтобы все вместе они со­
ставили выпуск (release). Можно почти с полной уверенностью утверждать, что план
выпуска не будет точно отражать то, какие именно возможности будут разрабатываться
и в какой очередности. План выпуска — это лишь гипотетическое описание того, как
может проходить разработка, и он будет обновляться в начале каждой итерации по мере
того, как будут изменяться приоритеты, будет выясняться реальная производительность
команды, а разработчики смогут более точно судить о трудоемкости каждой истории.
Перед началом каждой итерации разработчики и заказчик составляют ее план. Пла­
нирование итерации включает выбор историй с наивысшим приоритетом, которые мо­
гут быть выполнены за время итерации, и последующее определение конкретных задач,
необходимых для реализации истории.
Часть V. Приложения
Рефакторинг
Рефакторинг [28], [55] — это процесс реструктуризации или переработки кода с целью
его улучшения без изменения внешнего поведения. Со временем код постепенно засо­
ряется. Метод, предназначенный для какой-либо цели, может претерпеть изменения для
обработки особых условий. Затем возникает необходимость вновь переработать этот ме­
тод, чтобы учесть другое особое условие. И так может продолжаться до тех пор, пока код
метода не станет слишком хрупким, чтобы выдерживать дальнейшие модификации.
В ХР настоятельно рекомендуется непрерывно выполнять рефакторинг кода. От про­
граммиста требуется, чтобы при внесении любого изменения, после которого следовало
бы выполнить рефакторинг, он обязательно сделал это. Выполнение рефакторинга не
просто ожидается от программиста — оно требуется от него. Тем самым удается избе­
жать медленной, иногда трудноуловимой деградации кода, в конечном счете делающей
его дальнейшую модификацию практически невозможной. Рефакторинг — одна из ме­
тодик, используемых в ХР взамен проектирования в полном объеме до начала написа­
ния кода. Вместо того чтобы заранее продумывать все требования, когда не написано
еще ни одной строки кода и можно выдвигать лишь предположения о некоторых аспек­
тах поведения системы, ХР-системы подвергаются непрерывному рефакторингу и по­
стоянно поддерживаются в состоянии, идеально соответствующем известным реализо­
ванным требованиям.
Разработка через тестирование
Замечательно то, что ХР фокусируется на тестировании. В проектах ХР разработчики
пишут автоматизированные модульные тесты (automated unit tests), а заказчики — прие­
мочные тесты (acceptance tests), которые часто автоматизируются либо самими заказчи­
ками, либо заказчиками при содействии разработчиков. Многие разработчики на прак­
тике почувствовали все преимущества частого тестирования на самых ранних стадиях
разработки. Кроме того, исчезло и традиционное сопротивление разработчиков прове­
дению тестированию, поскольку модульные тесты ХР обычно автоматизируются путем
написания кода теста, который выполняет рабочий код, благодаря чему одновременно
с тестированием разработчики решают и свои задачи программирования.
В традиционных процессах разработки тесты пишутся (если это вообще предусмо­
трено) уже после того, как написан тестируемый код. Это создает определенные про­
блемы, поскольку при наличии написанного кода, который по всем признакам работает
нормально, программистам свойственно не утруждать себя его дальнейшей доработкой.
Поэтому многие разработчики спешат завершить работу с кодом, заявляя при этом, что
он протестирован. (Я знаю об этом не понаслышке, поскольку сам был таким.) ХР кар­
динально изменяет нашу точку зрения, делая основной упор на упреждающее тестиро­
вание, что нашло свое отражение в подходе, получившем название разработка через те­
стирование, или разработка, управляемая тестами (test-driven development) [3]; [5].
При использовании данного подхода сначала пишется тест и лишь затем — код, ко­
торый обязан пройти этот тест. Разработчики следуют очень коротким (исчисляемым
минутами, а не часами) циклам разработки “тест-код-тест-код...” и т.д. Программисты
соблюдают жесткое правило: новый код пишется исключительно для того, чтобы до­
биться прохождения теста. Поэтому сначала пишется тест, который заведомо не должен
проходить, а затем запускается программа с целью проверки того, что тест действитель-
Приложение А. Обзор экстремального программирования
но не проходит. Лишь после этого программист пишет код, который должен обеспечить
успешное прохождение теста программой.
Разработка через тестирование гарантирует, что код все время остается хорошо
структурированным и тестируемым. Удобство сопровождения такого кода всегда выше,
чем обычно, поскольку фактически он находится в состоянии сопровождения уже с са­
мого начала своего существования.
Кроме тестирования модулей, выполняемого программистами, важной составляю­
щей ХР является выполнение тестов заказчиками. Для каждой истории заказчик обязан
написать ряд тестов, которые используются для подтверждения того, что код разработан
в полном соответствии с ожиданиями и пожеланиями заказчика. Во многих отношениях
такие написанные заказчиком приемочные тесты заменяют документированные требо­
вания каскадной модели.
Парное программирование
Одной из спорных концепций ХР является так называемое парное программирование
(pair programming). Так называют процесс программирования, в ходе которого два про­
граммиста работают за одной клавиатурой и одним монитором и пишут код совмест­
ными усилиями. Пока один программист набирает строки кода с помощью клавиатуры
(при этом мысленно забегая на несколько строк кода вперед), второй лишь наблюдает за
процессом, тем самым получая возможность свободно анализировать, к каким результа­
там может привести данный код и с какими проблемами можно столкнуться. Програм­
мисты, работающие в паре, часто меняются ролями и парами.
Несмотря на то что парное программирование может показаться крайне неэффек­
тивным, результаты соответствующего исследования, проведенного Алистером Кобер­
ном и Лори Уильямс [17], продемонстрировали, что это не так. Они выяснили, что це­
ной увеличения общего времени программирования на 15% парное программирование
позволяет добиться следующего:
• уменьшение количества дефектов;
• уменьшение объема кода, решающего поставленную задачу;
• более оперативное устранение проблем;
• увеличение количества людей, понимающих любой участок кода;
• получение разработчиками большего удовлетворения от работы.
Парное программирование играет очень важную роль в ХР, помогая следовать другим
стратегиям ХР, требующим определенной дисциплины. Ведь для того чтобы выполнять
рефакторинг кода, если замечено, что он плохо структурирован, или постоянно следить
за тем, чтобы сначала всегда писались тесты и лишь после этого — сам рабочий код,
разработчик должен прилагать дополнительные усилия. Без сидящего рядом партнера
всегда может возникнуть соблазн опустить переработку или тестирование кода, оправ­
дывая себя спасительной мыслью “Ну, это только разок...”
Оптимальный рабочий ритм
Команды ХР работают в оптимальном рабочем ритме (sustainable расе), без “авралов”
и сверхурочной работы. Команда исходит из того, что продвижение разработки в по­
стоянном естественном рабочем темпе позволит на протяжении определенного периода
V
Часть V. Приложения
времени сделать больше, чем в случае работы в чрезмерно высоком темпе, которого ко­
манда просто не сможет вынести в течение длительного времени. Это не означает, что
ХР-команда работает строго 40 часов в неделю, безмятежно проводя остальное время.
Сами участники определяют подходящий для них темп работы, и, скорее всего, он будет
разным у разных команд.
Эффективность парного программирования и разработки через тестирование обе­
спечивается тем, что программисты, работающие в паре, могут предельно концентриро­
вать свое внимание на создаваемом коде. Лишь немногие способны сохранять высокий
уровень концентрации на выполняемой работе в течение длительного времени. Обычно
команда отводит примерно шесть часов в день программированию в паре, тогда как
остальное время дня посвящается другим видам деятельности.
Следить за тем, чтобы команда не “выдохлась”, входит в обязанности координато­
ра ХР. Если координатор замечает в команде признаки усталости, он должен вернуть ее
к оптимальному для нее ритму работы.
Совместное владение кодом
В командах, применяющих подходы, отличные от ХР, ответственность за разработку
различных участков кода несут отдельные программисты. В этом смысле любая часть
системы всегда будет принадлежать какому-то одному разработчику, по крайней мере,
до тех пор, пока он не перейдет в другой проект и код останется ничейным. Подобный
подход к владению кодом часто приводит к тому, что от разработчиков можно услышать
такие, например, комментарии: “Мы сможем изменить код обработки платежей лишь
после возвращения Ивана из отпуска”. Более того, если разработчика все же уговорят
взяться за этот код, пока Иван находится в отпуске, то вернувшегося из отпуска Ивана
вмешательство в “его” код выведет из себя.
В ХР-командах принят совершенно иной подход к владению кодом: весь код при­
надлежит в равной степени каждому. В рамках этой модели совместного владения кодом
(team code ownership) любая пара программистов может вносить изменения в любой код.
В действительности, с учетом необходимости постоянного выполнения рефакторинга
кода, изменение парой программистов “чужого” кода является скорее правилом, чем
исключением.
Индивидуальное владение кодом (individual code ownership) практикуется для сохране­
ния уверенности в сквозной согласованности проектирования и сбалансированности
разработки всех функциональных возможностей на уровне модулей. В ХР это бремя воз­
лагается на разработку через тестирование. Строгий набор модульных тестов гарантиру­
ет, что вносимые программистами изменения не приведут к непредвиденным побочным
эффектам.
Стандарты кодирования
Ввиду того что ХР-команда владеет кодом совместно, очень важно, чтобы все ее чле­
ны соблюдали одни и те же стандарты написания кода (coding standards). Стандарт коди­
рования определяет основные правила и соглашения, регламентирующие порядок име­
нования переменных и методов, форматирование строк и т.п., которыми при написании
кода должна руководствоваться вся команда.
В небольшой команде, все члены которой работают в тесном контакте друг с другом,
можно обойтись без письменного, формализованного стандарта кодирования. В этом
Приложение А. Обзор экстремального программирования
случае о нем можно просто договориться. В большинстве команд, насчитывающих за­
метное количество разработчиков, стандарты кодирования лучше готовить в письмен­
ном виде, стараясь, чтобы они были как можно более краткими и содержали описания
лишь наиболее существенных элементов стиля.
Простота дизайна
ХР-команды стремятся реализовать нужные заказчикам возможности как можно бо­
лее простыми способами. В качестве критериев простоты дизайна Кент Бек [4] предла­
гает использовать следующие четыре признака.
1. Рабочий код и код тестов полностью отражают намерения программиста в отноше­
нии поведения этого кода.
2. Отсутствует дублирование кода.
3. В системе используется минимально возможное число классов.
4. В системе используется минимально возможное число методов.
Метафора системы
Требование простоты дизайна поддерживается в ХР-командах нахождением подходя­
щей метафоры (metaphor), применимой ко всей системе в целом. Метафора обеспечива­
ет аналогию, с помощью которой легче продумывать систему. Так, в одном из проектов
метафорой нашей система была классная доска, на которой различные части системы
могли записывать свою информацию. По завершении работы с системой пользователь
мог либо сохранить содержимое доски, либо стереть его. Такой упрощенный взгляд на
систему предоставил нам удобную и простую аналогию, облегчающую продумывание
реального поведения системы.
Непрерывная интеграция
Не так давно у меня состоялся разговор с руководителем одной из крупнейших ком­
паний, занимающихся интернет-торговлей. Он сказал, что наибольшей проблемой для
большинства команд была интеграция кода, написанного разными разработчиками. Он
предпочитал, чтобы его команды выполняли интеграцию раз в месяц, так как это по­
зволяло избегать более серьезных проблем, которые могли бы возникать, если бы инте­
грация кода проводилась реже. Я спросил его, а что произойдет, если его команды раз­
работчиков перейдут на ежедневную интеграцию кода?
Ответ на этот вопрос хорошо известен ХР-командам, которые интегрируют код еже­
дневно. Обо всех преимуществах, обеспечиваемых ежедневной сборкой и дымовыми те­
стами (smoke tests) [24], мы уже давно знаем. В ХР-командах этот процесс доведен до
более или менее непрерывной интеграции кода (continuous integration). Например, если
разработчик внес какое-нибудь небольшое изменение, он регистрирует его в хранилище
исходного кода (source code repository), где процесс замечает это изменение и инициирует
полную сборку. По завершении сборки запускается набор автоматизированных тестов.
В случае неудачного прохождения любого из этих тестов разработчику направляется
электронное сообщение, извещающее о неудачном исходе тестирования. Проблемы ре­
шаются постепенно, небольшими порциями по мере их возникновения.
Часть V. Приложения
Присутствие заказчика в команде
Раньше бывало так, что заказчик готовил документ с требованиями, перебрасывал
его через стенку программистам, которые писали исходный код системы и, в свою оче­
редь, перебрасывали написанный код через другую стенку тестировщикам. В ХР все
“стенки” исчезают, так как предполагается, что заказчик находится в одном помещении
с командой разработчиков, являясь ее полноправным членом. Заказчик пишет истории
и приемочные тесты, а также отвечает на задаваемые ему разработчиками вопросы сразу
же, как только они возникают.
Наличие заказчика в команде (on-site customer) весьма существенно влияет на успеш­
ность подхода, основанного на использовании пользовательских историй, поскольку
многие вопросы разработчики должны обсуждать непосредственно с заказчиком. Если
заказчик не находится на месте, могут возникнуть задержки, нарушающие прогнозируе­
мость хода выполнения работ ХР-командой.
Ценности ХР
Кроме основных приемов, в ХР проповедуются четыре ценности (values): общение
(communication), простота (simplicity), обратная связь (feedback) и смелость (courage)2.
Общение ценится в ХР, но не все его разновидности считаются одинаково ценными.
Самой желательной формой общения является личное устное общение, когда можно
просто разговаривать друг с другом, отвечать на реплики, жестикулировать и делать на
доске поясняющие записи. Обмен письменными документами менее желателен. ХР уси­
ливает возможности общения за счет внедрения таких концепций, как парное програм­
мирование.
Простота дизайнерских решений представляет ценность для ХР-команд, поскольку
это способствует концентрации внимания на создании решений для задач, актуальных
сегодня, а не для задач завтрашнего дня. ХР-команды строят архитектуру систем, не вы­
ходя за рамки того, что необходимо для разработки возможностей, запланированных на
текущую итерацию. Их усилия постоянно сконцентрированы на создании простейших
вещей, способных обеспечить необходимое функциональное поведение системы.
В командах, работающих по методологии ХР, ценится обратная связь, и чем теснее
эта связь, тем благотворнее она сказывается на работе команды. В ХР разработчики
сталкиваются с этим в процессе парного программирования, когда один разработчик
может указать на возможные проблемы у другого разработчика, являющегося его на­
парником. Оба они получают обратную связь от часто выполняемых ими автоматизиро­
ванных тестов. Обратная связь образуется также вследствие непрерывного (по крайней
мере, раз в день) выполнения процесса интеграции кода. Заказчики, которые являются
членами команды и даже территориально располагаются рядом с разработчиками, так­
же обеспечивают обратную связь благодаря постоянному взаимодействию с командой
и приемочным тестам, которые они пишут.
Наконец, в ХР-командах ценится смелость. Например, их разработчики не боятся
выполнять рефакторинг кода (поскольку их решимость в этом поддерживается выпол­
нением автоматизированных тестов). Они смело продвигают разработку, не имея перед
глазами готовой картины основной архитектуры, поскольку будут использовать мета2 В последней редакции ХР указана дополнительная, пятая, ценность — уважение (respect):
http: //www.extremeprogramming. org/values .html. — Примеч. ред.
Приложение А. Обзор экстремального программирования
фору и поддерживать простоту дизайна за счет выполнения рефакторинга и разработки
через тестирование.
Принципы ХР
Кроме ценностей и приемов, в ХР придерживаются следующих пяти общих принци­
пов: быстрая обратная связь (rapid feedback), стремление к простоте (assuming simplicity),
постепенность изменений (incremental change), готовность к изменениям (embracing change)
и качественная работа (doing quality work) [4]. Сразу же после зарождения ХР разгорелись
жаркие дебаты относительно того, можно ли считать, что команда работает по методоло­
гии ХР, если в ней применяются, например, одиннадцать из исходных двенадцати прие­
мов. Можно ли считать команду по-прежнему работающей по методике ХР, если она от­
кажется от использования парного программирования? А можно ли считать, что команда
работает по методике ХР, если она соблюдает принцип простоты дизайна, но начинает
с того, что предварительно тратит несколько недель на моделирование?
Я считаю, что ответом на подобные вопросы должно быть “да”. Команды работают
в стиле ХР, если в своей деятельности они руководствуются следующими общими прин­
ципами ХР:
• обеспечивают обратную связь с заказчиком и благодаря этому узнают многое
о системе;
• предпочитают простоту и всегда пытаются применить простое решение, прежде
чем переходить к более сложному;
• улучшают программное обеспечение путем постепенного внесения в него неболь­
ших изменений;
• готовы вносить изменения на сколь угодно поздних этапах разработки проекта,
поскольку стремятся к как можно более полной адаптации системы к нуждам по­
требителей продукта;
• стремятся к тому, чтобы программное обеспечение на любом этапе разработки яв­
ляло собой образец мастерства высокого уровня.
Безусловно, такие команды могут считаться командами ХР, даже если они позволили
себе отступить от одной или двух концепций.
Резюме
• В ХР заказчик отвечает за написание историй и приемочных тестов для каждой
истории и территориально располагается в одном офисе с командой разработчиков.
• В проектах ХР нет четких различий между ролями разработчика и тестировщи­
ка. Программисты пишут модульные тесты для тестирования собственного кода,
а тестировщики программируют автоматизированные приемочные тесты.
• В ХР-проект включается координатор и, возможно, отдельный менеджер проекта,
которые отвечают за общее руководство командой и устранение факторов, пре­
пятствующих ее нормальной работе.
Часть V. Приложения
Экстремальное программирование включает следующие основные приемы:
• частые выпуски версий;
• игра в планирование;
• рефакторинг;
• разработка через тестирование;
• парное программирование;
• оптимальный рабочий ритм;
• совместное владение кодом;
• стандарты кодирования;
• простота дизайна;
• метафора системы;
• непрерывная интеграция кода;
• присутствие заказчика в команде;
Оно признает следующие ценности:
• общение;
• простота;
• обратная связь;
• смелость;
• уважение.
Оно также базируется на следующих ключевых принципах:
• быстрая обратная связь;
• стремление к простоте;
• постепенность изменений;
• готовность к изменениям;
• качественная работа.
Приложение Б
Ответы на контрольные вопросы
Глава 1. “Общий обзор”
1.1.
Назовите три составляющие пользовательской истории.
Ответ. Карточка, обсуждение, подтверждение.
1.2.
Кто входит в состав команды заказчика?
Ответ. В состав команды заказчика включаются люди, которые обеспечивают со­
ответствие программного обеспечения потребностям предполагаемых пользова­
телей. В их число могут входить тестировщики, менеджер по продукту, реальные
пользователи и проектировщики взаимодействия.
1.3.
Какие из приведенных ниже историй не могут считаться хорошими? Почему?
Ответ. См. табл. Б.1.
Таблица Б.1. Ответ на вопрос 1.3
История
Ответ
А. Пользователь может запустить систему
Это хорошая история
в Windows ХР и Linux
Б. Построение всех графиков и диаграмм
будет выполняться с помощью сторонней
библиотеки
В. Пользователь может отменить результаты
выполнения вплоть до 50 предыдущих ко­
манд
Эта история не является хорошей.
Пользователю безразлично, как именно стро­
ятся графики и диаграммы
Это хорошая история
Г. Программное обеспечение будет выпущено Эта история не является хорошей. Это огра­
к 30 июня
ничение, которое должно рассматриваться
при планировании выпуска
Д. Программное обеспечение будет написано Пожалуй, эта история не является хорошей,
на языке Java
Е. Пользователь может выбрать страну из
раскрывающегося списка
но все зависит от продукта. Если продукт —
библиотека классов, предназначенная для
Java-программистов, то для этой категории
пользователей имеет значение, какой язык
используется
Это хорошая история, но ее можно было бы
немного расширить
Часть V Приложения
Окончание табл. Б.1
История
Ответ
Ж. Для записи всех сообщений об ошибках
в файл система будет использовать би­
блиотеку Log4J
В той форме, как она записана, данная история
не является хорошей. В ней не следовало ука­
зывать, что в качестве механизма ведения жур­
нала будет использоваться библиотека Log4J
3. Каждые 15 минут пользователю будет пред­ Это хорошая история
лагаться сохранить результаты работы, если
этого не было сделано ранее
И. Пользователю предоставляется возмож­
ность выбрать вариант “Экспорт в XML”
Это хорошая история
К. Пользователю предоставляется возможность Это хорошая история
экспортировать данные в формат XML
1.4.
Каковы преимущества устного обсуждения требований по сравнению с их опреде­
лением в виде формальной документации?
Ответ. Письменная документация заставляет невольно предполагать исчерпы­
вающую точность описания, чего в действительности может и не быть. Пользо­
вательские истории, в которых карточки служат напоминаниями о том, что еще
подлежит дальнейшему обсуждению, позволяют избежать создания ложной види­
мости того, что все определено очень точно. Одна лишь запись требований еще
не является гарантией того, что заказчики получат то, чего они хотят; в лучшем
случае они получат то, что записано. Частые обсуждения, особенно те, которые
проводятся непосредственно перед разработкой обсуждаемой возможности или
даже в процессе самой разработки, обеспечивают лучшее понимание предмета
обсуждения и углубляют взаимопонимание между разработчиками и заказчиками.
1.5.
Почему содержимое тестов должно записываться на оборотной стороне карточек?
Ответ. Написание тестов на оборотной стороне карточек предоставляет заказ­
чику замечательную возможность сообщить другим участникам проекта о своих
ожиданиях и допущениях относительно истории.
Глава 2. “Написание историй”
2.1.
2.2.
Укажите для каждой из приведенных ниже историй, может она считаться хоро­
шей. Если нет, то почему?
Ответ. См. табл. Б.2.
Разбейте эпическую историю “Пользователь может создавать и изменять автомати­
зированные агенты поиска вакансий” на составные истории подходящего размера.
Ответ. Эту историю следует разбить как минимум на две: для создания и измене­
ния агентов. Однако для ее разбиения на меньшие истории существует множество
самых разных способов, выбор которых определяется предполагаемой длитель­
ностью разработки каждой из результирующих историй. Один из возможных спо­
собов подобного разбиения приводится ниже.
• Пользователь может создать автоматизированный агент поиска вакансий.
Приложение Б. Ответы на контрольные вопросы
• Пользователь может изменить поисковые параметры автоматизированного
агента поиска вакансий.
• Пользователь может изменить расписание запуска автоматизированного агента
поиска вакансий.
• Пользователь может изменить способ создания отчетов о результатах работы
автоматизированного агента поиска вакансий.
Таблица Б.2. Ответ на вопрос 2.1
История
Ответ
А. Пользователь может быстро освоить
Эта история должна быть изменена. В ней не кон­
кретизировано, что именно означают слова “бы­
стро” и“освоить”
систему
Б. Пользователь может изменить адрес,
указанный в резюме
В. Пользователь может добавить, изме­
нить и удалить несколько резюме
Г. Система может аппроксимировать
распределения квадратичных форм
в нормальных координатах методом
седловой точки
Возможно, эта история слишком мала, но и она
может вполне подойти, в зависимости от того,
сколько времени потребуется разработчикам для ее
реализации
Это составная история, которую следует разбить на
несколько отдельных историй
Если эту историю написал заказчик, то он, надо
полагать, знает, что все это означает. Однако, если
эта история разработчикам непонятна, то заказчик
должен переписать ее (или, по крайней мере, под­
робно ее разъяснить), чтобы разработчики смогла
оценить ее трудоемкость
Д. Все ошибки времени выполнения за­ Это хорошая история, не требующая никаких из­
носятся в журнал унифицированным менений
способом
Глава 3. “Моделирование пользовательских ролей”
3.1.
Загляните на сайт eBay.com. Какие пользовательские роли вы могли бы опреде­
лить для него?
Ответ. Ваш список должен включать примерно следующие роли: Случайный
продавец (One-time Seller), Мелкий продавец (Small Seller), Регулярный прода­
вец (Frequent Seller), Редкий покупатель (Infrequent Buyer), Регулярный покупа­
тель (Frequent Buyer), Корпоративный продавец (Corporate Seller), Производитель
(Manufacturer), Финансовый оператор (Payment Processor), Коллекционер (Col­
lector), Член клуба (Club Member), Разработчик ПО (Software Developer), Партнер
(Affiliate).
3.2.
Объедините роли, список которых вы определили при ответе на предыдущий вопрос,
и покажите, каким образом вы расположили бы их карточки. Поясните свой ответ.
Ответ. Исходя из приведенного выше списка, я ввел для продавцов одну обоб­
щенную роль Продавец и три специализированные: Мелкий продавец, Регу­
лярный продавец и Корпоративный продавец. Точно так же я ввел одну обоб­
щенную роль Покупатель и три специализированные: Редкий покупатель,
Часть V. Приложения
Регулярный покупатель и Коллекционер. Также я оставил роли Финансовый
оператор, Партнер и обобщенную роль Пользователь Wi-Fi.
3.3.
Составьте описание личности для одной из наиболее важных пользовательских
ролей.
Ответ. Бренда — регулярный покупатель. Обычно она заглядывает на сайт по
крайней мере раз в день и в среднем совершает одну-две покупки в неделю. Как
правило, она покупает кинофильмы и книги, но покупала также садовый и ку­
хонный инвентарь. Она работает риелтором, и посещение нашего сайта не пред­
ставляет для нее сложностей, хотя освоение новейшего программного обеспече­
ния и требует от нее некоторых усилий. Обычно она посещает сайт, используя для
подключения к Интернету домашнее низкоскоростное подключение, но иногда
может воспользоваться для этой цели и более быстрым офисным соединением.
Глава 4. “Сбор историй”
4.1.
Возникновения проблем какого рода следует ожидать, если для сбора требований
команда использовала только анкеты?
Ответ. Работа с анкетами может занять много времени, поэтому завершение про­
екта может несколько затянуться. Кто-то должен собрать и интерпретировать ре­
зультаты опроса, а с этим связан риск искажения информации. Поскольку анке­
тирование не обеспечивает истинного двухстороннего общения, команде трудно
организовать обратную связь с опрашиваемыми, чтобы выяснить, в правильном
ли направлении она движется.
4.2.
Переформулируйте приведенные ниже вопросы таким образом, чтобы придать им
открытость и контекстную независимость: “Считаете ли вы, что пользователь дол­
жен вводить пароль?”, “Должна ли система автоматически сохранять результаты
работы пользователя каждые 15 минут?”, “Должен ли пользователь иметь возмож­
ность просматривать записи в базе данных, сделанные другим пользователем?”
Ответ. Приведенные выше вопросы можно переформулировать множеством спо­
собов. Вот лишь некоторые примеры.
• Опишите, как в системе должна быть организована защита уязвимых данных.
• Как поступать пользователю в случае критического сбоя системы в процессе
работы?
4.3.
• Что вы можете сказать относительно доступности данных, сохраненных поль­
зователем?
Почему наиболее эффективными являются открытые, контекстно-независимые
вопросы?
Ответ. Контекстно-независимые вопросы не являются наводящими (“Вы ведь
хотите, чтобы эта возможность была реализована?”) и поэтому не заставляют ре­
спондента подыскивать “правильный” ответ. Вопросы с открытым множеством
ответов позволяют дать подробный ответ, выходящий за рамки простого “да” или
“нет”. Контекстно-независимые вопросы с открытым множеством ответов явля­
ются наилучшими, поскольку не оказывают влияния на ответ и допускают широ­
кий ряд альтернативных ответов.
Приложение Б. Ответы на контрольные вопросы
Глава 5. “Работа с представителями пользователей”
5.1.
Какие проблемы могут возникать в случае выбора менеджера пользователей в ка­
честве их представителя?
Ответ. Даже если менеджер пользователей сам является текущим пользователем
данного программного обеспечения, его потребности, несомненно, будут почти
всегда отличаться от потребностей рядовых пользователей. Более того, если он яв­
ляется бывшим пользователем, то его знания системы устарели.
5.2.
Какие проблемы могут возникать в случае выбора специалиста в предметной об­
ласти в качестве представителя пользователей?
Ответ. Одна из проблем заключается в том, что такой специалист может не быть
пользователем системы. Даже если это не так, то он использует систему иначе, не­
жели менее квалифицированные пользователи. Суть второй возможной проблемы
состоит в том, что в конечном счете вы получите систему, которая идеальным об­
разом устраивает специалистов, но непригодна для использования теми, кто об­
ладает меньшими знаниями в данной предметной области.
Глава 6. “Приемочное тестирование
пользовательских историй”
6.1.
Кто определяет тесты? Кто ему в этом помогает?
Ответ. Тесты определяет заказчик. В реальных ситуациях заказчик, как правило,
создает тесты совместно с программистом или тестировщиком, но, как минимум,
заказчик должен специфицировать такие тесты, которые можно будет использо­
вать для установления того факта, что история надлежащим образом разработана.
6.2.
Почему необходимо определять тесты еще до написания кода истории?
Ответ. Тесты определяются еще до начала кодирования историй, поскольку они
представляют собой полезный и эффективный метод, с помощью которого за­
казчик может сообщить разработчикам о своих пожеланиях в отношении новой
функциональности.
Глава 7. “Советы по написанию хороших историй”
7.1.
Предположим, что история “Соискатель может осуществить поиск вакансий”
слишком велика, чтобы ее можно было поместить в одну итерацию. Как бы вы
разбили ее?
Ответ. Вероятно, разбиение данной истории можно выполнить, исходя из под­
держиваемых параметров поиска, таких как местоположение, ключевые слова,
название должности, диапазон заработных плат и др. Кроме того, возможны раз­
личные способы представления результатов поиска. Начальная история могла бы
охватывать простой список вакансий, удовлетворяющих заданным критериям
поиска. Эту историю можно было бы дополнить другой историей, улучшающей
способ представления полученных результатов за счет, например, отображения
V
Часть V Приложения
описания каждой вакансии, предоставления пользователю возможности выбора
порядка сортировки результатов или состава отображаемых полей, а также предо­
ставления ссылок на более подробные описания вакансий.
7.2.
Какая из приведенных ниже историй имеет подходящий размер и может считаться законченной?
Ответ. См. табл. Б.З.
Таблица Б.З. Ответ на вопрос 7.2
История
Ответ
А. Пользователь может сохранить
предпочтительный набор конфигу­
рационных параметров
В зависимости от системы, эта история может быть
как законченной, так и незаконченной. Если сохра­
нение предпочтительных параметров — это как раз
то, чего хочет пользователь, то эта история, пожалуй,
может считаться законченной. Возможно, ее размер
маловат, но, опять-таки, он также может считаться
вполне нормальным, в зависимости от системы и ко­
манды, которая ее создает
Б. Пользователь может изменить
данные кредитной карты, исполь­
зуемой по умолчанию для оплаты
покупок
Это законченная история подходящего размера
В. Пользователь может регистриро­
ваться в системе
Эта история не является законченной и, вероятно,
имеет слишком малый размер
7.3.
Внесением каких небольших изменений можно улучшить историю “Пользователи
могут размещать свои резюме на сайте”?
Ответ. История, написанная в такой форме, оставляет неясным, может ли каж­
дый пользователь опубликовать несколько своих резюме. Несомненно, этот во­
прос выяснится в процессе обсуждения, но лучше написать историю с более от­
четливой формулировкой: “Соискатель может разместить на веб-сайте одно или
несколько резюме”.
7.4.
Как бы вы тестировали ограничение “Программа должна быть проста в использо­
вании”?
Ответ. Чтобы протестировать эту историю, необходимо прежде всего опреде­
лить, что именно подразумевается под выражением “проста в использовании”.
Означает ли это, что умелый пользователь может выполнять обычные операции
с помощью минимального количества нажатий клавиш? Или же это означает, что
новичок может очень быстро научиться работать с данным программным обеспе­
чением? Чаще всего именно это имеется в виду. Если это так, определите один
или несколько тестов наподобие приведенного ниже.
• Спустя 30 минут после того, как новый пользователь впервые увидел систему,
он должен быть в состоянии осуществить поиск вакансии, зарегистрироваться
в системе и добавить свое резюме.
7.5.
Такие тесты не могут выполняться в ходе ночных сборок проекта, но их можно
запускать в виде нерегулярных тестов для проверки удобства использования си-
Приложение Б. Ответы на контрольные вопросы
стемы, в ходе которой пользователям демонстрируют программное обеспечение
и наблюдают за их поведением в процессе работы с ним.
Глава 8. “Оценка пользовательских историй”
8.1.
На собрании по оценке историй три программиста оценивают историю. Их оцен­
ки составили, соответственно, два, четыре и пять баллов. Какую оценку следует
использовать?
8.2.
Ответ. Они должны продолжать обсуждение до тех пор, пока их оценки не станут
достаточно близкими.
В каких целях используется триангуляция оценок?
8.3.
Ответ. Триангуляция используется для улучшения качества оценивания путем
проверки того, что каждая из оценок разумна в сопоставлении с другими оцен­
ками. Если история, оцененная в два балла, действительно воспринимается как
требующая в два раза больше трудозатрат, чем история, оцененная в один балл, то
в этом же смысле она должна восприниматься как половина истории, оцененной
в четыре балла.
Дайте определение скорости разработки.
8.4.
Ответ. Скорость разработки — это количество баллов историй, выполняемых ко­
мандой за одну итерацию.
На протяжении последней двухнедельной итерации команда А выполнила объем
работ на 43 балла. Команда В работает над отдельным проектом и насчитывает
в два раза больше разработчиков. За время своей двухнедельной итерации они
также выполнили объем работ на 43 балла. Как такое может быть?
Ответ. Баллы историй, соответствующие объему работ, выполненных одной ко­
мандой, нельзя сопоставлять с баллами историй другой команды. Из той инфор­
мации, которой мы владеем, нельзя заключить, что команда А работает в два раза
продуктивнее команды В.
Глава 9. “Планирование выпусков”
9.1.
Назовите три способа оценки начальной скорости работы команды.
Ответ. Можно воспользоваться опытом предыдущих разработок, сделать относи­
тельно скорости разработки разумные предположения или выполнить начальную
итерацию и использовать в расчетах фактическое значение скорости, полученное
для этой итерации.
9.2.
Предполагая, что длительность итерации составляет одну неделю, а команда со­
стоит из четырех разработчиков, ответьте, сколько времени понадобится этой
команде для завершения проекта, оцененного в 27 баллов, если скорость работы
команды равна 4?
Ответ. При скорости, равной 4, и объеме работ, оцененном в 27 баллов, для за­
вершения проекта команде потребуется 7 итераций.
Часть V. Приложения
Глава 10. “Планирование итераций”
10.1. Разбейте на составляющие задачи следующую историю: “Пользователь может
просмотреть подробную информацию о гостинице”.
Ответ. Разумеется, это можно сделать многими способами; один из возможных
вариантов приводится ниже.
• Спроектировать внешний вид веб-страниц.
• Написать HTML-код для отображения фотографий гостиницы и комнат.
• Написать HTML-код для отображения карты, на которой обозначено, где рас­
положена гостиница.
• Написать HTML-код для отображения списка услуг и дополнительных удобств,
предоставляемых гостиницей.
• Продумать, как генерировать карты.
• Написать SQL-запросы для извлечения информации из базы данных.
• И многое другое.
Глава 11. “Измерение и мониторинг производительности”
11.1. Для завершения истории, оцененной в один балл, фактически потребовалось
два дня. Какой вклад эта история внесет в скорость разработки, рассчитываемую
в конце итерации?
Ответ. Вклад истории составит один балл.
11.2. О чем можно узнать из ежедневного графика объема невыполненных работ, чего
нельзя увидеть на итерационном графике невыполненных работ?
Ответ. Ежедневный график объема невыполненных работ отражает прогресс ко­
манды на протяжении итерации. Вы можете использовать эту информацию в ка­
честве калибровочной, чтобы определить, сможет ли вся запланированная работа
быть выполнена к концу итерации. Если становится очевидно, что не вся работа
может быть выполнена, команда может обсудить с заказчиком во время итерации,
какую работу можно отложить.
11.3. Какие выводы можно сделать из рис. 11.7? Какой исход для завершения проекта
наиболее вероятен: раньше срока, позже срока или точно по плану?
Ответ. Эта команда стартовала немного успешнее, чем прогнозировалось для
первой итерации. Команда ожидала, что скорость разработки возрастет на второй
и третьей итерациях, а затем стабилизируется. Уже после двух итераций она до­
стигла скорости, на которую рассчитывали лишь после прохождения трех итера­
ций. В этот момент они опережают график, но после всего лишь двух итераций
следует проявлять сдержанность в прогнозах.
11.4. Какова скорость работы команды, которая завершила итерацию с результатами,
представленными в табл. 11.3?
Приложение Б. Ответы на контрольные вопросы
Ответ. Шестнадцать. Частично завершенные истории не вносят никакого вклада
в скорость разработки.
11.5. Какие обстоятельства могут быть причиной того, что итерационный график объе­
ма невыполненных работ будет отображать восходящий тренд?
Ответ. Итерационный график объема невыполненных работ демонстрирует
подъем, если объем добавляемых работ растет быстрее известного объема выпол­
ненных работ или если команда решает, что значительная часть работ, запланиро­
ванных на будущие периоды, была недооценена.
11.6. Заполните до конца табл. 11.4, вписав в нее недостающие значения.
Ответ. Завершенную табл. 11.4 представляет табл. Б.4.
Таблица Б.4. Ответ на вопрос 11.6
Итерация 1
Итерация 2
Итерация 3
Количество баллов в начале итерации
100
76
34
Выполнено за итерацию (в баллах)
35
40
36
Изменение оценки (в баллах)
5
-5
0
Количество баллов новых историй
6
3
2
Количество баллов в конце итерации
76
34
0
Глава 12. “Чем не являются истории”
12.1. В чем состоят ключевые различия между пользовательскими историями и вариан­
тами использования?
Ответ. Как правило, границы охвата пользовательских историй уже, чем у вари­
антов использования. Пользовательские истории теряют свою полезность по за­
вершении итерации, в которой они разрабатывались, тогда как варианты исполь­
зования часто являются постоянными артефактами проекта.
12.2. В чем состоят ключевые различия между пользовательскими историями и специ­
фикациями требований IEEE 830?
Ответ. Спецификации требований в стиле IEEE 830 фокусируются на атрибутах
решения, тогда как пользовательские истории фокусируются на целях, стоящих
перед пользователями. Спецификации требований IEEE 830 стимулируют ко­
манду к написанию всех без исключения требований наперед, а не итеративным
способом, как в случае пользовательских историй. При написании спецификаций
требований большое внимание уделяется тому, чтобы слова правильно передавали
нужный смысл; пользовательские истории отдают приоритет обсуждениям, в ходе
которых выясняются детали.
12.3
В чем состоят ключевые различия между пользовательскими историями и сцена­
риями проектирования взаимодействия?
Ответ. Сценарии проектирования взаимодействия более детализированы по
сравнению с пользовательскими историями и часто предоставляют подробные
Часть V. Приложения
описания личности, использующей систему, и контекста использования. Кроме
того, у сценариев границы охвата часто шире, чем у пользовательских историй.
12.4. Почему невозможно заранее определить абсолютно все требования для скольконибудь серьезного проекта?
Ответ. Попытки написания всех требований в самом начале проекта заведомо
игнорируют важность обратной связи с пользователями. Когда предполагаемые
пользователи начинают знакомиться и взаимодействовать с системой, на ум всег­
да приходят новые требования.
12.5. Почему гораздо плодотворнее думать о целях, которые преследуют пользователи,
чем о списке атрибутов создаваемого программного обеспечения?
Ответ. Список атрибутов не даст тому, кто его читает, той полноты понимания
продукта, которая обеспечивается историями и обсуждениями. Кроме того, если
нашей работой управляет список атрибутов, то лучшее, что мы можем сказать по­
сле завершения проекта, — это то, что поставленный продукт обладает свойства­
ми, перечисленными в списке. Это не то же самое, что сказать: “Поставленный
продукт соответствует целям, которые выдвигаются пользователями”.
Глава 13. “Зачем нужны пользовательские истории”
13.1. Назовите четыре веские причины использования историй для выражения требо­
ваний.
Ответ. Пользовательские истории делают акцент на устном общении, они по­
нятны каждому, имеют подходящие для планирования размеры, поддерживают
итеративную разработку, поощряют откладывание разработки деталей на более
поздние периоды, поддерживают спонтанную разработку, поощряют совместное
проектирование и способствуют взаимному обмену опытом.
13.2. Каковы могут быть два нежелательных последствия использования историй?
Ответ. В больших проектах организация хранения сотен и даже тысяч историй
может быть затруднительной, а для отслеживания историй может потребоваться
присоединение к ним дополнительной документации. И хотя истории чрезвы­
чайно способствуют взаимному обмену знаниями в процессе личного общения,
в случае больших проектов обсуждения не способны адекватно охватить весь круг
вопросов и полностью заменить письменную документацию.
13.3. В чем состоит ключевое различие между совместным и эмпирическим подходами
к проектированию?
Ответ. При совместном проектировании предполагаемые пользователи системы
становятся частью команды, проектирующей поведение этой системы. В эмпири­
ческом проектировании предполагаемые пользователи вместо этого становятся
объектами изучения и наблюдения со стороны проектировщиков программного
обеспечения, которые впоследствии принимают все необходимые решения по
проекту.
13.4. Что не так сформулировано в следующем требовании: “Все страницы многостра­
ничных отчетов должны нумероваться”?
Приложение Б. Ответы на контрольные вопросы
Ответ. Неясно, что именно означают слова “должны нумероваться”. Означает ли
это, что программисты могут закодировать эту функциональность, но не обяза­
ны это делать? Означает ли это, что страницы будут нумероваться, только если на
странице есть свободное место?
Глава 14. “Каталог запахов историй”
14.1. Каковы будут ваши действия в случае, если команда постоянно сталкивается
с трудностями при планировании очередной итерации?
Ответ. Возможны и другие причины, но прежде всего вы должны посмотреть, не
слишком ли много у вас независимых историй, а также не слишком ли мал или
велик их размер.
14.2. Каковы должны быть действия команды в случае, если она постоянно сталкивает­
ся с нехваткой места на карточках для написания историй?
Ответ. Они должны использовать еще меньшие карточки, чтобы приучить себя
исключать детали из описаний историй.
14.3. По какой причиное заказчик может испытывать трудности с ранжированием
историй?
Ответ. Возможно, истории имеют неподходящий размер (слишком большой или
слишком маленький) или недостаточно отчетливо выражают, какую ценность они
предоставляют пользователям или заказчикам.
14.4. По каким признакам вы можете судить, что вынуждены разбивать намного боль­
ше историй, чем следовало бы?
Ответ. Вы должны полагаться на внутреннее чутье. Истории часто и вполне за­
кономерно подлежат разбиению либо потому, что с самого начала они намерен­
но писались как эпические, либо потому, что слишком велики, дабы уложиться
в итерацию. Если вы видите, что вам часто приходится разбивать истории в силу
других причин, то, скорее всего, вы делаете это под давлением обстоятельств.
Глава 15. “Использование историй в методологии Scrum”
15.1. Опишите различия между инкрементными и итеративными процессами.
Ответ. Процесс является итеративным, если он развивается через рад последова­
тельных уточнений. Инкрементным называют процесс, в котором программное
обеспечение создается и доставляется по частям.
15.2. Как соотносятся между собой журнал запросов на выполнение работ и список за­
дач спринта?
Ответ. В начале спринта элементы журнала запросов на выполнение работ пере­
носятся в список задач спринта.
15.3. Что означает выражение “потенциально готовое к поставке приращение продукта”?
Ответ. К концу каждого спринта Scrum-команда обязана создать потенциально
готовое к поставке приращение продукта. Это означает, что программное обеспе­
чение закодировано, протестировано и может быть передано пользователям.
Часть V. Приложения
15.4. Кто отвечает за ранжирование и выбор работ, которые команда будет выполнять
в течение итерации?
Ответ. Приоритеты работ устанавливает владелец продукта, но именно команда
выбирает работу, которая будет выполняться на протяжении спринта. При этом,
естественно, ожидается, что команда будет выбирать работу среди задач, имею­
щих наивысший приоритет.
15.5. Какие вопросы задаются каждому члену команды на ежедневных Scrum-собраниях?
Ответ. Что ты сделал вчера? Что ты будешь делать сегодня? Что тебе мешает?
Глава 16. “Дополнительные вопросы”
16.1. Как следует обработать требование, в котором говорится о том, что система долж­
на допускать масштабирование, обеспечивающее одновременную работу вплоть
до 1000 пользователей?
Ответ. Вы должны записать это как ограничение, а затем дополнить его соответ­
ствующими тестами. В зависимости от системы, вы можете начать с тестирования
для 100 одновременно работающих пользователей в одной итерации и постепенно
нарастить их количество до 1000 на протяжении нескольких итераций.
16.2. Что вы предпочитаете: записывать истории на карточках или использовать для
этого программные средства? Обоснуйте свой ответ.
Ответ. Простота и непривязанность карточек к системе делает их идеальным ин­
струментом для многих проектов. Кроме того, на карточках мало свободного ме­
ста, что способствует краткости историй. Поскольку карточки можно легко пере­
мещать на столе или стене из одного места в другое, они идеально подходят для
планирования. Однако если команда территориально рассредоточена или должна
соблюдать жесткие требования, касающиеся отслеживания историй, то, возможно,
она предпочтет использовать для работы с историями программное обеспечение.
16.3. Какое влияние оказывает итеративность процесса на пользовательский интерфейс
приложения?
Ответ. Итеративная разработка системы может усложнять для пользователей
процесс ее изучения. Любые изменения меню или функциональных возможно­
стей системы заставляют пользователей заново изучать ее.
16.4. Приведите примеры систем, в которых рассмотрение пользовательского интер­
фейса на более ранних стадиях, чем это обычно принято в agile-проектах, могло
бы принести пользу.
Ответ. Вот лишь некоторые из возможных примеров.
• Коммерческий продукт, сохраняющий конкурентные позиции на рынке глав­
ным образом благодаря простоте использования.
• Программное обеспечение, ориентированное на новичков.
• Программное обеспечение, которое будет использоваться редко, но весьма ин­
тенсивно (например, в период сдачи налоговых деклараций).
• Программное обеспечение для людей с нарушениями зрения или опорно­
двигательного аппарата.
Список литературы
1.
Adolph, Steve, Paul Bramble, et al. Patterns for Effective Use Cases. Reading, Mass.:
Addison-Wesley, 2002.
2.
Anton, Annie I., and Colin Potts. “The Use of Goals to Surface Requirements for
Evolving Systems,” in Proceedings of the 20th International Conference on Software
Engineering (ICSE 98), April 1998: 157-166.
3.
Astels, Dave. Test Driven Development: A practical guide. Upper Saddle River, N.J.:
Prentice Hall, 2003.
4.
Beck, Kent. Extreme Programming Explained: Embrace change. Boston: Addison Wesley,
2000.
Кент Бек. Экстремальное программирование. Библиотека программиста, Питер,
2002 г.
5.
Beck, Kent. Test Driven Development: By Example. Reading, Mass.: Addison-Wesley,
2003.
Кент Бек. Экстремальное программирование: разработка через тестирование,
Питер, 2003 г.
6.
Beck, Kent, and Martin Fowler. Planning Extreme Programming. Reading, Mass.:
Addison-Wesley, 2000.
Кент Бек, Мартин Фаулер. Экстремальное программирование: планирование, Питер,
2003 г.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Beedle, Mike, et al. “SCRUM: A Pattern Language for Hyperproductive Software
Development.” In Neil Harrison et al. (Eds.), Pattern Languages of Program Design 4.
Addison-Wesley: 1999, pp. 637-651.
Boehm, Barry. “A Spiral Model of Development and Enhancement.” IEEE Computer 28,
no. 5 (May 1988): 61-72.
Boehm, Barry. Software Engineering Economics. Englewood Cliffs, N.J.: Prentice Hall,
1981.
Bower, G. H., J. B. Black, and T. J. Turner. “Scripts in Memory for Text.” Cognitive
Psychology 11 (1979): 177-220.
Carroll, John M. “Making Use a Design Representation.” Communications of the ACM
37, no. 12 (December 1994): 29-35.
Carroll, John M. Making Use: Scenario-based design in human-computer interaction.
Cambridge, Mass.: The MIT Press, 2000.
Carroll, John M. “Making use is more than a matter of task analysis.” Interacting with
Computers 14, no. 5 (2002): 619-627.
Carroll, John M., Mary Beth Rosson, George Chin Jr., and Jurgen Koenemann.
“Requirements Development in Scenario-Based Design.” IEEE Transactions on Software
Engineering 24, no. 12 (December 1998): 1156-1170.
Cirillo, Francesco. “Education of an extreme programmer.” At http://www.
fcgarage.com/2 0 03/01/education-of-an-extreme-programmer.html. FC
Garage, 2003.
Часть V. Приложения
16.
Cockbum, Alistair. Writing Effective Use Cases. Upper Saddle River, N.J.: AddisonWesley, 2001.
Алистер Коберн. Современные методы описания функциональных требований к си­
стемам, Лори, 2011 г.
17.
Cockburn, Alistair, and Laurie L. Williams. “The Costs and Benefits of Pair
Programming.” In Giancarlo Succi and Michele Marchesi (Eds.), Extreme Programming
Examined. Upper Saddle River, N.J.: Addison-Wesley, 2001.
18.
Cohn, Mike. “The Upside of Downsizing.” Software Test and Quality Engineering 5, no.
1 (January 2003): 18-21.
19.
Constantine, Larry. “Cutting Comers.” Software Development (February 2000).
20.
Constantine, Larry. “Process Agility and Software Usability: Toward lightweight and
usage-centered design.” Information Age (August-September 2002).
21.
Constantine, Larry L., and Lucy A. D. Lockwood. Software for Use: A practical guide to
the models and methods of usage-centered design. Reading, Mass.: Addison-Wesley, 1999.
22.
Constantine, Larry L., and Lucy A. D. Lockwood. “Usage-Centered Engineering for
Web Applications.” IEEE Software 19, no. 2 (March/April 2002): 42—50.
23.
Cooper, Alan. The Inmates Are Running the Asylum. Indianapolis: SAMS, 1999.
Алан Купер. Психбольница в руках пациентов, Символ-Плюс, 2009 г.
24.
Cusumano, Michael A., and Richard W. Selby. Microsoft Secrets: How the world’s most
powerful software company creates technology, shapes markets, and manages people. New
York: The Free Press, 1995.
25.
Davies, Rachel. “The Power of Stories.” XP 2001. Sardinia, 2001.
26.
Djajadiningrat, J.P., W. W. Gaver and J. W. Frens. “Interaction Relabelling and Extreme
Characters: Methods for exploring aesthetic interactions.” Symposium on Designing
Interactive Systems 2000, 2000: 66—71.
27.
Fowler, Martin. “The Almighty Thud.” Distributed Computing (November 1997).
28.
Fowler, Martin, et al. Refactoring: Improving the design of existing code, Reading, Mass.:
Addison-Wesley, 1999.
Мартин Фаулер, Кент Бек, Джон Брант, Дон Робертс, Уильям Апдайк. Рефак­
торинг. Улучшение существующего кода, Символ-Плюс, 2009 г.
29.
Gilb, Tom. Principles of Software Engineering Management. Reading, Mass.: AddisonWesley, 1988.
30.
Guindon, Raymonde. “Designing the Design Process: Exploiting opportunistic thoughts.”
Human-Computer Interaction 5, 1990.
31.
Grudin, Jonathan, and John Pruitt. “Personas, Participatory Design and Product
Development: An Infrastructure for Engagement.” In Thomas Binder, Judith Gregory,
and Ina Wagner (Eds.), Participation and Design: Inquiring into the politics, contexts and
practices of collaborative design work, Proceedings of the Participatory Design Conference
2002'. 2002: 144-161.
32.
IEEE Computer Society. IEEE Recommended Practice for Software Requirements Speci­
fications. New York, 1998.
Список ЛИТЕРАТУРЫ
33.
Jacobson, Ivar. Object-Oriented Software Engineering. Upper Saddle River, N.J.: AddisonWesley, 1992.
34.
Jacobson, Ivar, Grady Booch, and Janies Rumbaugh. The Unified Software Development
Process. Reading, Mass: Addison-Wesley, 1999.
А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программного
обеспечения, Питер, 2002 г.
35.
Jeffries, Ron. “Essential ХР: Card, Conversation, and Confirmation.” XP Magazine
(August 30, 2001).
36.
Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed.
Boston: Addison-Wesley, 2000.
37.
Kensing, Finn, and Andreas Munk-Madsen. “PD: Structure in the Toolbox.”
Communications of the ACM 36, no. 6 (June 1993): 78-85.
38.
Kovitz, Ben L. Practical Software Requirements: A manual of content and style. Greenwich,
Conn.: Manning, 1999.
39.
Kuhn, Sarah, and Michael J. Muller. “Introduction to the Special Section on Par­
ticipatory Design.” Communications of the ACM 36, no. 6 (June 1993): 24—28.
40.
Lauesen, Soren. Software Requirements: Styles and techniques. London: Addison- Wesley,
2002.
41.
Lundh, Erik, and Martin Sandberg. “Time Constrained Requirements Engineering
with Extreme Programming: An experience report.” In Armin Eberlein and Julio Cesar
Sampaio do Prado Leite (Eds.), Proceedings of the International Workshop on Time
Constrained Requirements Engineering, 2002.
42.
Newkirk, James, and Robert C. Martin. Extreme Programming in Practice. Upper Saddle
River, N.J.: Addison-Wesley, 2001.
43.
Pamas, David L., and Paul C. Clements. “A Rational Design Process: How and why to
fake it.” IEEE Transactions on Software Engineering 12, no. 2 (February 1986): 251—7.
44.
Patton, Jeff. “Hitting the Target: Adding interaction design to agile software
development.” Conference on Object Oriented Programming Systems Languages and
Applications (OOPSLA 2002). New York: ACM Press, 2002.
45.
Poppendieck, Tom. The Agile Customer’s Toolkit. In Larry L. Constantine (Ed.),
Proceedings offorUSE 2003. Rowley, Mass.: Ampersand Press: 2003.
46.
Potts, Colin, Kenji Takahashi, and Annie I. Antyn. “Inquiry-Based Requirements
Analysis.” IEEE Software 11, no. 2 (March/April 1994): 21—32.
47.
Robertson, Suzanne and James Robertson. Mastering the Requirements Process. Reading,
Mass.: Addison-Wesley, 1999.
48.
Schuler, Douglas, and Aki Namioka (Eds.). Participatory Design: Principles and practices.
Hillsdale, N.J.: Erlbaum, 1993.
49.
Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper Saddle
River, N.J.: Prentice Hall, 2002.
50.
Stapleton, Jennifer. DSDM: Business Focused Development. Reading, Mass.: AddisonWesley, 2003.
51.
Swartout, William, and Robert Balzer. “On the Inevitable Intertwining of Specification
and Implementation.” Communications of the ACM 25, no. 7 (July 1982): 438-440.
▼
Часть V. Приложения
52.
Wagner, Larry. “Extreme Requirements Engineering.” Cutter IT Journal 14, no. 12
(December 2001).
53.
Wake, William C. Extreme Programming Explored. Reading, Mass: Addison-Wesley, 2002.
54.
Wake, William C. “INVEST in Good Stories, and SMART Tasks.” At www. xpl23. com,
2003.
55.
Wake, William C. Refactoring Workbook. Reading, Mass.: Addison-Wesley, 2003.
56.
Weidenhaupt, Klaus, Klaus Pohl, Matthias Jarke, and Peter Haumer. “Scenarios in
System Development: Current practice.” IEEE Software 15, no. 2 (March/April 1998):
34-45.
57.
Wiegers, Karl E. Software Requirements 2. Redmond, Wash.: Microsoft Press, 2003.
Карл И. Вигерс. Разработка требований к программному обеспечению, Русская
Редакция, 2004 г.
58.
Williams, Marian G., and Vivienne Begg. “Translation between software designers and
users.” Communications of the ACM 36, no. 6 (June 1993): 102-3.
Предметный указатель
D
DSDM 108
Ж
Журнал запросов на выполнение ра­
бот 166; 167
F
FitNesse 84
3
IEEE 830 137
INVEST 35
Заказчик 73; 229; 236
Законченная история 90
Замыкание задач 90
Запах 159
M
И
MoSCoW 108
Игра в планирование 231
Идеальный рабочий день 99
Интеграционное тестирование 84
Интервьюирование 59
Итеративный процесс 31
Итерация 28; 117; 230
длительность 27
I
N
NUT 99
P
PERT 21
R
RUP 140
S
Scram 165; 170
A
Анкетирование 61
Б
Баллы историй 28; 99; 102
В
Вариант использования 140
ключевой 143
Владелец продукта 166
Выпуск 107
Г
К
Карточка истории 22; 36
Каскадная модель 26
Команда заказчика 26; 77
Л
Личность 53; 194
м
Менеджер
пользователей 69
разработчиков 70
Метафора 235
Минимизация рисков 111
н
Наблюдение 62
Непрерывная интеграция 235
Нефункциональные требования 177
График объема работ 125; 126; 128
О
д
Объединение историй 44
Ограничение 91
Оперативное проектирование 119
Диаграмма PERT 21
Длительность итерации 112
Дорожная карта разработки продукта 107
Предметный указатель
п
Стандарт кодирования 234
Стресс-тестирование 85
Сценарий 142;144
Сюжет сценария 145
Парное программирование 104; 120; 233
Персонаж 140;145
Плавающие единицы времени 99
План выпуска 27; 114; 215
Пользовательская история 22
атрибуты 35
оценка в баллах 28
приоритеты 28
сложная 43
составная 41
эпическая 24
Представитель пользователей 69
Приемочное тестирование 29; 81; 219
Примечание 38
Приоритеты историй 108
Производительность 123
Прототип 63
Тема 107
Тест 38
автоматизация 44
Тестирование
интеграционное 84
интерфейса 85
приемочное 29; 81
производительности 85
удобства использования 85
Тип пользователя 26
Требования 57
Триангуляция 102
Р
э
Разбиение историй 41
Разработка
управляемая свойствами 170
через тестирование 232
Рациональный унифицированный про­
цесс 140
Рефакторинг 232
Роль 189; 229
атрибут 52
моделирование 49
пользовательская 47
С
Скорость разработки 27; 103; 113; 123; 125
Собрание
по написанию историй 27; 62; 197
по обзору результатов спринта 168; 170
по планированию итераций 117
по планированию спринта 168
Совместное владение кодом 234
Совместное проектирование 155
Спайк 40; 43
Специальная пользовательская группа 75
Спиральная модель разработки 111
Список заданий спринта 166
Спонтанная разработка 154
Спринт 166
Сродство 28; 109
т
Экстремальное программирование 229
основные приемы 230
принципы 237
ценности 236
Экстремальный персонаж 54
Эмпирическое проектирование 155
Разработка программного обеспечения
Пользовательские истории
Гибкая
разработка программного обеспечения
Майк Кон
этой книге, выхода которой с нетерпением ожидало сообщество сторонников гибких
методологий разработки программного обеспечения, описывается процесс подготовки
требований к разрабатываемой системе, который позволяет экономить время, избавляет от
необходимости в переделках и ведет к созданию более совершенных программ.
В
Лучший способ создать программное обеспечение, максимально полно удовлетворяющее
потребностям пользователей, — начать с пользовательских историй. Это простые, понятные и
краткие описания функциональности, которая представляет деловую ценность для реальных
пользователей. В книге приводятся подробные рекомендации относительно того, как следует
писать пользовательские истории и включать их в жизненные циклы разработки проекта.
Вы узнаете, что такое хорошие пользовательские истории и что делает истории плохими. Вы
познакомитесь с практическими методами сбора историй, позволяющими добиться хороших
результатов даже тогда, когда возможность непосредственного общения с пользователями отсут­
ствует. Автор демонстрирует, как систематизировать подготовленные пользовательские истории,
установить для них приоритеты и эффективно применять для решения задач планирования, раз­
работки и тестирования программного обеспечения.
Моделирование пользовательских ролей.
Сбор историй: опрос пользователей, анкетный метод, наблюдение, собрания.
Работа с менеджерами, инструкторами, продавцами и другими представителями
пользователей.
Написание пользовательских историй для приемочного тестирования.
• Использование историй для ранжирования задач, составления графиков работ и оценки
трудозатрат.
• В конце каждой главы приводится список контрольных вопросов и упражнений
для самопроверки.
Книга будет полезна разработчикам, тестировщикам, аналитикам и менеджерам проектов,
использующим любую гибкую методологию программного обеспечения: ХР, Scrum... и даже соб­
ственный гибкий подход.
МАЙК КОН — один из основателей некоммерческой организации Agile Alliance и руководитель
одной из ее программ — Articles Program. Профессионально занимается программированием
с 1984 г., а начало его деятельности в качестве руководителя разработки программных проектов
относится к 1988 г., причем список его клиентов включает такие известные компании, как Fidelity
Investments, Viacom, Procter & Gamble, NBC и Citibank. В настоящее время Майк является вицепрезидентом по вопросам разработки программного обеспечения в компании Fast 401 К, кото­
рая предоставляет услуги по обслуживанию частных пенсионных счетов в США. Автор ряда книг,
посвященных различным вопросам программирования.
Изображение на обложке: замок Нойшванштайн.
Фото А. В. Слепцова
www.williamspublishing.com
A Addison-Wesley
Pearson Education