Глава 11. Чего изволит заказчик?

В ХР единицей функциональности системы принято считать пожелание пользователя относительно ее работы. Чтобы продемонстрировать заказчику, как продвигается работа над проектом, мы регулярно поставляем ему интегрированный и протестированный программный код, в котором постепенно реализуются все его пожелания относительно функционирования системы. Эти пожелания должны быть понятны как программистам, так и самим заказчикам. Кроме того, программисты должны иметь возможность протестировать каждую задачу, которую ставит перед ними заказчик. Каждое пожелание должно представлять для клиента некоторую ценность и при этом быть небольшого размера, чтобы разработчики успевали реализовать за одну итерацию по 5-6 таких пожеланий.

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

Ключевое слово здесь - «легко». Существует необъятное количество книг, где подробно описываются процесс управления требованиями, проектирование вариантов использования и другие сложные материи. Разумеется, в них содержится очень много полезного, но ХР, как всегда, использует самое простое решение. Главное при работе с пожеланиями – не забывать, что они должны быть очень простыми (вам достаточно будет просто понять, о чем идет речь). Время детализации требований еще не пришло.

Наиболее важные моменты

Заказчик должен сам понимать свои пожелания. Нет смысла оформлять требования к системе настолько сложно, что заказчику потребуется несколько лет обучаться управлению требованиями, прежде чем он сумеет разобраться, что же такое он заказал программистам. Мы записываем все пожелания простым и понятным английским языком (вы будете использовать свой родной, но это не важно). Родной язык понимают все, а вот другие варианты уже, так сказать, чужеродны.

Пожелания заказчика удобно записывать на учетных карточках. Много на карточке не поместится, поэтому описание задачи получается предельно сжатым. К тому же, карточками очень удобно манипулировать при планировании. Разработчики и заказчики могут перебирать карточки, обмениваться ими, какие-то откладывать в сторону, другие убирать в стол, особо важные прикалывать на стену и т.д. Вообще, манипулировать понятиями гораздо легче, когда каждое из них находится на отдельной картонной карточке, а не когда все они представлены в виде общего списка на одном листе бумаги.

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

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

Система должна проверять правописание текста, вводимого в поле для комментариев.

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

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

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

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

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

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

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

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

Оценка трудозатрат: чем вам может помочь заказчик

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

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

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

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

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

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

Как видите, программистам вовсе не требуются мелкие подробности и детали. Достаточно придать пожеланию какую-то конкретную форму, с которой уже можно начинать работать.

Приоритетность пожеланий

Не просите заказчика указывать некую абстрактную приоритетность пожеланий: высокую, среднюю, низкую и т.п. Это делу не поможет. В конце концов, приоритетность высока у всех задач, иначе клиент не стал бы вам их излагать, не так ли? Лучше попросите его ответить на вопрос: «Что бы вы хотели получить в первую очередь, а с чем можно повременить?»

Некоторые пожелания могут состоять сразу из нескольких задач с разными приоритетами, например:

Результаты должны выдаваться не позже, чем через 10 секунд и содержать в себе информацию о текущем состоянии процесса, включая все сопутствующие данные.

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

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

Полный контроль

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

Приемочный тест – это наш вариант контроля над разработкой. Идея контролировать выполнение требований по реализующим их классам системы нам не нравится. Слишком много писанины. Даже если использовать для этого какой-либо специальный инструмент, все равно на согласование всей информации уйдет бездна времени. Мы предлагаем гораздо более простой способ - проследить взаимосвязь между пожеланием и приемочными тестами. Раз тестирование прошло успешно, значит можно считать, что в системе появился код, реализующий соответствующее пожелание клиента. Если позже мы что-то в этом коде изменим, то тесты не пройдут. Вот вам и полный контроль.

Дробление пожеланий

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

1. Информация о текущем состоянии процесса должна быть выдана не позднее, чем через 10 секунд после запроса.

2. Все сопутствующие данные должны быть выданы не позднее, чем через 30 секунд после запроса.

Существует много причин, по которым одно пожелание нужно разбивать на несколько. Например:

l      Вы записываете исходные варианты пожеланий, и ваши разработчики указывают на чересчур объемную задачу.

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

l      В ходе работы вы обнаруживаете, что на данную итерацию у вас было запланировано слишком много задач.

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

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

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

Рюшечки и бантики

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

Как записывать пожелания заказчика

Так и подмывает написать отдельную брошюрку: «Как за 30 минут научиться записывать пожелания к функциональности системы». Она бы существенно упростила жизнь вашим клиентам. Все хорошо, вот только написать ее не проще, чем скажем, книжку о том, как писать книжки. Все, что мы можем вам предложить– это научиться подмечать, какие пожелания записаны плохо (мы сейчас расскажем об этом) и почаще курсировать между заказчиками и программистами, чтобы хорошо ориентироваться в ситуации.

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

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

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

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

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

Когда же, наконец, мы запишем все пожелания заказчика?

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

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

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

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

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

Где хранятся карточки с пожеланиями заказчика

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

Пример. Пожелания заказчика

Когда начинаешь рассказывать о работе с пожеланиями заказчика, возникает проблема с примерами. Мы не имеем права показывать вам реальные карточки с пожеланиями наших клиентов – это проблема конфиденциальности информации, ничего не поделаешь.

Однако когда мы писали эту книгу, нам крупно повезло. Работая в саду у себя на ферме в Орегоне, Кент обнаружил посылку из будущего. В ней содержалось описание проекта, который мы сделали в 24 веке (или правильнее будет сказать «сделаем»?) – систему автоматического бронирования космических путешествий.

Среди всего прочего мы нашли и несколько карточек с пожеланиями заказчика:

Найти самый низкий тариф

Дать пользователю на выбор десять вариантов самых низких тарифов.

Показать информацию о наличии свободных местах в космолетах

Показать информацию о наличии свободных мест в космолетах (в том числе для рейсов с пересадками).

Отсортировать имеющиеся варианты перелетов по удобности

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

Купить билет

Купить билет по кредитной карте. Во время продажи проверить валидность кредитной карты. Помимо этого проверить общие иммиграционные правила (улавианам запрещается посещать Трааль и т.п.)

Создать личную карточку клиента

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

Просмотр заказов

Показать все заказы, которые сделал в этой системе какой-либо клиент.

Отменить заказ

Если клиент отменяет заказ, отменить все виды бронирований: полета, гостиницы и т.д.

Распечатать иммиграционные правила

Распечатать всю информацию, касающуюся въезда и выезда для посещаемых планет (например, «не для вогонов»).

Показать список гостиниц

Показать список гостиниц, расположенных вблизи места назначения.

Показать список гостиниц со свободными номерами

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

Сложный поиск по гостиницам

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

Забронировать номер в гостинице

Забронировать номер в гостинице по кредитной карте. Во время бронирования проверить валидность кредитной карты.

Показать специальные скидки на гостиницы/рейсы

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

Аренда самолета

Дать клиенту возможность арендовать самолет для передвижения по планете. Связать с данными о прибытии на планету. Внести в личную карточку клиента дополнительные сведения о предпочитаемых им самолетах (страховка, ручное или автоматическое управление и т.д.)

*****

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

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

 


Copyright notice

© Copyright Addison-Wesley, 2001, все права защищены
© Copyright maxkir.com, перевод, 2002
© Copyright Издательский дом "Питер", 2002, все права защищены