Текст книги "Гибкое управление IT-проектами. Руководство для настоящих самураев"

5.4. Чем можно пожертвовать

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

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

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

Чем-то придется жертвовать. Вопрос – чем?

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

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

Испытание

1. Какие факторы наиболее важны при реализации софтверного проекта?

А. Качество.

Б. Время.

В. Объем работ.

Г. Бюджет.

2. Если требуется сделать слишком много, а времени на это недостаточно, то как лучше поступить?

А. Уменьшить объем работ.

Б. Привлечь к проекту дополнительных работников.

В. Отодвинуть дату завершения проекта.

Г. Пожертвовать качеством.

3. Что больнее всего?

А. Идти по огню.

Б. Жевать битое стекло.

В. Танцевать «Макарену».

Г. Запрашивать у спонсора дополнительное финансирование.

Как бы вы ответили на эти вопросы?

Ловите ли вы себя на мысли «Смотря по обстоятельствам»?

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

Давайте научимся иметь дело с этими силами и укрощать их. Сейчас вы узнаете о секретах… Неистовой четверки.

Неистовая четверка

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

Они сопровождают нас в каждом проекте, все время привнося в работу хаос и беды:

♦ расписание срывается;

♦ бюджеты урезаются;

♦ список багов (ошибок) растет;

♦ нам приходится слишком много делать.

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

Время

Время конечно. Его нельзя ни создавать, ни запасать. Нужно просто максимально использовать то время, которое у нас есть.

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

Итак, при гибкой разработке нужно следить за временем.

Бюджет

Бюджет подобен времени. Он тоже фиксирован, конечен, и, как правило, его не хватает.

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

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

Качество

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

Это значит, что качество также имеет фиксированный уровень и должно стремиться к идеалу.

Объем работ

Приходится мириться с тем, что время, бюджет и качество – фиксированные величины, но остается одна сила, которая подчиняется ходу проекта: объем работ (функционал).

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

Некоторых моих учеников это напрягало. Многие приходили ко мне в додзё[11]11
  Зал для занятий восточными единоборствами. – Примеч. пер.


[Закрыть], будучи уверенными, что планы являются фиксированными, незыблемыми, окостенелыми, никогда не изменяются и не оптимизируются. Нет ничего более ошибочного, чем думать подобным образом.

Дата может быть фиксированной. Но план – нет.

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

Теперь можно поговорить об индикаторах компромиссов.

Индикаторы компромиссов

Индикаторы компромиссов (trade-off sliders) – это полезное средство, которым разработчик может пользоваться при решении вопросов с клиентом, в частности при обсуждении влияния Неистовой четверки на проект.

Обучение и разработка

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

Однако обучение – это одно, а разработка – совсем другое.

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

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

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

Большинство клиентов понимают, что в ходе проекта чем-то приходится жертвовать. Если они начнут нервничать, определяя такие неприоритетные детали, напомните, что все элементы важны. То есть, если качество представляется не таким приоритетным, как время, это еще не значит, что качество будет неважно. Мы просто напоминаем, что в любом случае не можем отодвинуть дату выпуска продукта. Следовательно, время имеет более высокий приоритет.

Время и бюджет – это еще не все

Зададимся некоторыми вопросами.

♦ Чем хороша компьютерная игра, если в нее неинтересно играть?

♦ Будет ли существовать сайт знакомств, если на нем никто не пытается флиртовать?

♦ Какой репертуар будет у интернет-радиостанции, если ее никто не слушает?

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

Возможно, эти факторы интуитивно отличались при работе со стартовой колодой. Или на них указывали участники семинаров по сбору пользовательских историй (см. раздел 6.4).

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

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

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

5.5. Определение средств, необходимых для достижения результата

Вы почти у цели!

У вас есть видение проблемы.

У вас есть план.

Теперь давайте сформулируем, что необходимо сделать и сколько это будет стоить.

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

Начнем с команды.

Подбор команды

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

На этом этапе самое время поговорить о ролях и разделении ответственности (см. главу 2) и определить, какие ожидания возлагаются на всех участников данного проекта.

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

Сможет ли клиент уделить этому время?

Уполномочен ли клиент принимать необходимые решения?

Желает ли клиент направлять развитие проекта и руководить им?

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

Еще одна деталь, которую требуется выяснить заранее (особенно если у проекта несколько владельцев), – кто командует.

Определение того, кто командует

Ничто не вносит в работу команды такой неразберихи, как незнание того, кто руководит работой.

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

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

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

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

Даже если вы думаете, что знаете, кто командует, все равно задайте данный вопрос. Это не только позволит устранить всяческие сомнения, но и окончательно объяснит команде и всем владельцам, за кем на самом деле будет последнее слово.

А теперь поговорим о деньгах.

Оценка стоимости работ

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

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

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

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

Теперь все суммируем и поможем клиенту принять решение – начинать или не начинать проект.

Все вместе

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

♦ Когда все будет готово?

♦ Сколько это будет стоить?

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

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

Завершение формирования стартовой колоды

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

Просто посмотрите на картинку и истории, которые совместно сформулировали вы, ваша команда, ваш спонсор и ваш клиент. Вместе вы смогли узнать следующее:

♦ что мы будем делать и зачем;

♦ что выдающегося в нашем проекте;

♦ какие большие преграды нам придется преодолеть;

♦ кто работает вместе с нами;

♦ как будет выглядеть наше решение;

♦ с какими основными проблемами и рисками нам придется столкнуться;

♦ насколько велик реализуемый проект;

♦ какие участки работы допускают гибкий подход;

♦ приблизительное количество времени и денег, которые нам понадобятся.

МАСТЕР: Расскажи мне, что ты уже усвоил о стартовой колоде.

УЧЕНИК: Теперь я понимаю, как важно задавать сложные вопросы и приходить к общему мнению еще до того, как проект начнется.

МАСТЕР: Очень хорошо. Что еще?

УЧЕНИК: Я понял, что формулирование проекта не обязательно требует нескольких месяцев анализа требований и планирования. Работая со стартовой колодой, мы можем анализировать требования и формулировать перспективы быстро, обычно на это уходит всего пара дней.

МАСТЕР: А что особенно важно в духе, объеме или назначении изменений, вносимых в проект? Что делается после них?

УЧЕНИК: Состав колоды уточняется. При каждом изменении колода прорабатывается заново, и мы убеждаемся, что общее мнение и единое понимание целей проекта сохранилось.

МАСТЕР: Очень хорошо. Мы можем продолжать путь.

Что дальше?

Определив цели проекта, давайте еще раз проработаем некоторые детали, кратко описанные в этой главе.

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

И первым делом рассмотрим предмет, с которого начинаются все гибкие проекты: обычная пользовательская история.

Часть III
Планирование проекта при гибкой разработке

Глава 6
Сбор пользовательских историй

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

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

Для начала рассмотрим, как собирать требования и какие проблемы связаны со стремлением все записать.

6.1. Проблема с документацией

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

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

А если просто написать побольше документации?

Проблема сбора требований в виде документации заключается не только в большом объеме этой документации, но и в сложности обмена информацией.

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

На самом ли деле требование является требованием?

Адепты гибкой методологии не верят в существование требований. Понятие «требование» совершенно неверное, о чем в своей книге Extreme Programming Explained: Embrace Change [Bec00] рассказывает Кент Бек, один из величайших специалистов по гибкой разработке.

«Разработка ПО пошла в ложном направлении из-за слова “требование”. Требование – это нечто обязательное. Слово имеет коннотацию абсолютности и незыблемости, а это мешает учитывать изменения. И слово “требование” просто совершенно неверное».

«Из тысяч страниц, на которых описываются требования, можно выбрать 5, 10 или 20 % полезной информации, которая позволит понять всю практическую пользу, которую должна обеспечивать система. Хорошо, а что насчет остальных 80 %? Это не требования, так как данная информация не является необходимыми условиями».

Помню, как Мартин Фаулер жаловался, что, даже потратив несколько лет на написание книги, он поражался тому, как часто люди не понимали того, что он хотел сказать.

В наихудших случаях грамматические ошибки могут обходиться компаниям в миллионы долларов[12]12
  http://www.nytimes.com/2006/10/25/business/worldbusiness/25comma.html.


[Закрыть]. Но обычно письменные требования просто плохо описывают и заключают в себе то, что клиенты хотели бы видеть в своей программе.

Из этого вытекает один из важнейших принципов гибкой разработки.

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

6.2. Знакомство с пользовательскими историями

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

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

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

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

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

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

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

6.3. Элементы хороших пользовательских историй

Первый полезный элемент пользовательской истории – ее суть. Что считать полезным? То, за что клиент готов заплатить.

Например, в какой ресторан клиент пойдет ужинать?

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

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

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

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

Кроме того, хорошие пользовательские истории имеют следующие характеристики:

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

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

Любую отдельно взятую историю всегда можно реализовать несколькими способами. Мы можем выполнить любую возможность в версиях, условно соответствующих «Форду-Фокус», «Хонде-Аккорд» и «Порше-911».

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

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

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

Билл Уэйк придумал удобную аббревиатуру INVEST (Independent, Negotiable, Valuable, Estimatable, Small and Testable – независимые, доступные для обсуждения, ценные, поддающиеся оценке, небольшие и удобные для тестирования).

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

Но хватит теории. Займемся делом и соберем несколько историй для того парня с предыдущей фотографии, который собрался заняться серфингом.

Добро пожаловать в магазин Дэйва по прозвищу Большая Волна, где можно приобрести все необходимое для серфинга

Помогать клиентам формулировать пожелания – это нормально

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

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

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

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

Давайте определим, что нужно Дэйву

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

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

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

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

Посмотрим, можно ли извлечь из слов Дэйва о сайте шесть пользовательских историй. Не старайтесь написать идеальную историю. Просто предположите, что клиент хочет видеть в программе именно то, о чем говорит, и уже после этого формулируйте истории.

Теперь сравним все наши истории с критериями INVEST, упомянутыми выше.

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

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

Что вы думаете о двух последних историях из списка?

♦ Сайт должен работать очень быстро!

♦ Дизайн должен быть привлекательным.

Качественные это истории или нет? И почему?

Если вам кажется, что пожелание «Сайт должен работать очень быстро!» – расплывчатое и неточное, то вы правы! «Очень» – это насколько быстро? А как удостовериться, что конкретный посетитель действительно считает дизайн сайта «привлекательным»?

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

Иногда ограничения удается преобразовать в теории, поддающиеся проверке.

Например, пожелание «Сайт должен работать очень быстро!» можно выразить так:

Такое пожелание, безусловно, становится яснее (теперь мы понимаем, что такое «очень быстро»). И, разумеется, такое пожелание уже можно тестировать.

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

Шаблон пользовательской истории

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

Если ваша команда – из таких, попробуйте формулировать пользовательские истории по такому шаблону:

Например, с помощью такого шаблона можно придать некоторым историям Дэйва Большой Волны следующий вид:

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

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

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