Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

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

Разрешите мне повторить это важное утверждение.

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

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

Если мы реализуем то, что мы все согласились делать, как проверить готовность и правильность полученного продукта?

Ответ на этот вопрос обычно представляет собой короткий список проверок. Его еще иногда называют критериями приемки или тестами историй .

Когда придет время показать результат нашей работы на демонстрации продукта, как это сделать?

Чаще всего ответ на этот вопрос выявляет несколько пробелов в планировании. Например, вы можете закончить разработку, но для демонстрации нужны какие-то реальные данные. Обсуждение демонстрации может добавить еще несколько пунктов в список критериев приемки.

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

Хорошее обсуждение историй всегда требует множества слов и картинок.

Во время обсуждения держите перед глазами критерии приемки, к которым вы пришли. Эта команда использует большие листы бумаги для записи хода обсуждения.

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

А если нет?

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

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

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