Эвристика пользовательских историй
Пользовательские истории - это, вероятно, наиболее широко распространенная техника в плане требований в мире Agile. Этот скромный шаблон «кто-что-почему» изначально был создан командой Connextra в Лондоне и быстро получил широкое распространение: Я, являясь кем-то, хочу сделать что-то, чтобы получить некий результат или некое преимущество. Действительно, очень просто. Многие традиционные техники сбора и определения требований остаются актуальными в Agile, просто их результат не выливается в огромный документ. Agile подчеркивает, что требования текущего момента важнее приготовлений загодя. Человек, представляющий требования, будь то владелец продукта, бизнес-аналитик, менеджер продукта или кто-то еще, воплощает понимание того, что нужно, а пользовательские истории отображают, какая работа должна быть проделана. Пользовательские истории имеют три характеристики, хорошо вписывающихся в Agile:
Из-за этого третьего атрибута пользовательские истории являются моим выбором: они подходят всем. Заказчики могут с ними взаимодействовать. Многие другие техники превосходят их в плане анализа, строгости и полноты. Но эти преимущества имеют и свою существенную цену: они создают барьер между техническими экспертами и теми, кто ими не является (заказчиками). Простота пользовательских историй помогает прийти к общему пониманию. Повод для разговораПользовательские истории не являются - даже и не должны - полными требованиями для разработки ПО. Их называют «поводом для разговора», имея в виду, что истории выхватывают суть того, что нужно, но не содержат деталей. Когда дело дойдёт до работы, потребуется дискуссия, что нужно для реализации истории. Я рассматриваю истории как карточки предстоящей работы. Они не являются работой сами по себе - она еще не определена, - но они представляют работу. Эти карточки можно приоритезировать, перемешивать, править, менять, делить и т.д. Когда карточка оказывается наверху стопки, приходит время поработать над историей. Первоначальная задача - это понять, в чем заключается работа. Разговоры об истории не должны вестись лишь между кодером и тем, кто ставит требования. Если в команде есть тестеры, включите и их. Вообще говоря, присутствие тестировщика при таком разговоре даже важнее, чем присутствие кодера. Сами по себе пользовательские истории не обязаны быть идеальными; по факту, самая большая ошибка при работе с пользовательскими историями - это пытаться довести их до совершенства. Они должны быть преходящими и недолговечными, поскольку они не цель, а лишь средство ее достижения. Когда приходит время разговора, постарайтесь провести его лично, а не письменно. Писать документы - это куда дороже, чем обычно считается. Каждый документ приводит к расходам дважды - это время, потраченное на написание, плюс время, потраченное на чтение. Существуют другие, более эффективные формы коммуникации. Обговорить работу вживую может быть дешевле, экономнее по времени и эффективнее переписки по email. В живой беседе люди могут задавать вопросы, что-то пропускать, во что-то углубляться. Поэтому экономьте время и говорите вместо того, чтобы писать. У каждой истории есть бизнес-выгодаКаждая история должна нести некую ценность для бизнеса - увеличивать доход, уменьшать издержки, увеличивать эффективность труда сотрудников или приносить выгоду как-то иначе. Возможно, определение ценности истории потребует прогноза продаж или понимание экономии времени. В идеале мне хотелось бы видеть финансовую оценку по каждой истории - конкретное число в долларах, указывающее ценность в денежном выражении. Зная финансовую ценность историй, очень легко расставлять приоритеты. Я поощряю команды оценивать стоимость истории так же, как некоторые команды оценивают рабочие усилия - покерными картами. Иногда я устраиваю что-то вроде телешоу «Shark Tank» или «Dragon’s Den» и прошу одну команду сделать краткую презентацию историй перед другой. Эта другая команда играет роль инвестора и пытается присвоить ценность каждой истории. Однако указать сумму на карточке истории может быть сложно - и не только потому, что оценивать бывает непросто. Иногда истории невозможно оценить количественно, потому что их результат - нечто нематериальное, или потому что одна история является маленьким кусочком чего-то большего. Некоторые истории улучшают пользовательский интерфейс, другие - качество, а у третьих имеется указание, которого нельзя оспорить: «Это просто должно быть сделано». Даже если выгоду истории нельзя исчислить количественно, нужно ее как-то обозначить. Например, как-то так: «Фред говорит, что польза этой истории в том…» Бизнес-выгода - это что угодно, что помогает бизнесу и его представителям считать историю полезной. Выгода может включать обучение и создание знаний, исследование рынка и демонстрацию лояльности конкретному ключевому лицу. Кто-то где-то хочет реализации данной истории, и эти люди должны уметь объяснить, почему эта история несет выгоду. Ведь если никакой зримой выгоды нет, то зачем вообще ее делать? Пользовательские истории далеки от идеала. Но, перефразируя Уинстона Черчилля, я пришел к убеждению, что пользовательские истории - это худшая техника по работе с требованиями, если не считать всех остальных техник.
Оригинал: http://www.agileconnection.com/print/art[...]ristics-understanding-agile-requirements Об авторе: Аллану Келли доводилось выполнять практически всякую работу в мире ПО - от системного администратора до руководителя проекта, включая программиста и менеджера продукта. Сейчас он работает в Software Strategy, где помогает командам применять и углублять практики Agile. Его специализация - помогать софтверным компаниям подстраивать продукты и процессы под стратегию компании. Он является автором трех книг: «Xanpan - отражение Agile в разработке ПО» (https://leanpub.com/xanpan) «Бизнес-шаблоны для разработчиков ПО» и «Меняя разработку ПО: учимся Agile»; создателем «Ретроспективных Диалогов» (http://www.dialoguesheets.com) регулярным докладчиком на конференциях и частым автором для журналов. Перевод: Александра Родсет |
Еще интересные статьи на эту тему:
|
