• Это типа конспект в виде презентации
• Презентация сделана "на коленке"
• Много текста т.к. много цитат

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

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

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

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

• ­Обычно создается команда заказчика (customer team). В нее входят люди, отвечающие за то, чтобы программный продукт удовлетворял требованиям пред-полагаемых пользователей. В ее состав могут включаться тестировщики, менеджер по продукту, конечные пользователи и проектировщики взаимодействия
• ­При изучении проекта, управляемого историями (story-driven project), в первую очередь бросается в глаза то, что заказчики и пользователи участвуют в нем на протяжении всего процесса разработки. Ослабление этого участия по ходу проекта не только не приветствуется, но и не допускается.

• ­Работа идет итерациями
• ­Команда заказчика приоритезирует истории
• ­Команда разработки оценивает истории
• ­Команда заказчика "раскидывает" истории по итерациям, составляя план релиза

• ­В самом начале разработки, разработчики могут начать писать код, а команда заказчика может начать описывать тесты. Тесты могут принимать разные формы (от текста до автотестов)
• ­Ранее оформление тестов помогает команде заказчика сформулировать ожидания, а также является напоминанием для разработчиков

Пользовательские истории:

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

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

• Independence
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

• ­По мере возможности старайтесь избегать создания зависимостей между историями. Такие зависимости порождают проблемы при установлении приоритетов историй и планирования.
• ­Но что делать если заказчик выбрал в разработку высокоприоритетную историю, которая зависит от низкоприоритетной
  • ­Объедините их в одну истории
  • ­Разделите истории по-другому

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

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

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

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

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

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

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

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

Примеры того как плохие истории превратить в хорошие

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

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

Существуют три основные причины, по которым трудоемкость истории может не поддаваться количественной:

• Разработчикам недостает знаний в данной предметной области
• Разработчикам недостает технического опыта
• История слишком велика по размеру

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

• ­Слишком большие и слишком маленькие истории - плохо.
• ­Не бойтесь разбивать истории и объединять их.

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

Пользовательская роль (user role) - это собрание описательных атрибутов, характеризующих некоторую совокупность пользователей и предполагаемые типы их взаимодействия с системой.

• ­Определение начального набора ролей методом "мозгового штурма"
• ­Организация начального набора
• ­Объединение ролей
• ­Уточнение ролей

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

• ­Одна роль - один пользователь
• ­Роль система - только для особых случаев

• ­Личности. Можно придумать конкретные личности, вместо сухих ролей. Например, Женя живет в Таганроге и работает пекарем, но всю жизнь мечтал повидать Санкт-Петербург. Он хочет найти самые дешевые отели в этом городе для исполнения своей мечты (в книге пример на 10 строк)
• ­Экстремальные персонажи. Вместо придумывания обычных персонажей, стоит рассмотреть экстремальные случаи. Возможно мы найдем что-то новое. Например, как бы нашим сервисом мог воспользоваться наркоторговец, папа римский или президент какой-нибудь африканской республики

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

• ­Не смотря на то, что мы знаем, что не можем заранее описать все истории для проекта, нам необходимо описать истории на ближайшее будущее (1-3 месяца)
• ­Пользовательские истории можно писать на разных уровнях детализации.
  • ­Пока мы ничего не знаем об истории, мы можем выделить очень большой кусок работы в 1 историю. Например "Поиск отелей на карте"
  • ­В последствии, когда мы начнем работу, мы сможем декомпозировать эту историю на ряд меньших, более полезных историй.
• ­Описывая истории на необходимом сейчас уровне, мы тратим намного меньшее время, чем при использовании методик, основанных на документировании требований.

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

Эти методы:

• ­Интервьюирование пользователей
• ­Анкетирование
• ­Наблюдение
• ­Собрания по написанию историй (различные форматы для генерации историй - от брейнштормов до черновиков CJM)

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

• ­Менеджер продукта
• ­Менеджер разработки
• ­Продавец
• ­Техподдержка
• ­Специалисты в предметной области
• ­Маркетинговая группа
• ­Аналитики
• ­И тд и тп

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

Целесообразно установить связь с реально работающими пользователями. Лучше всего это сделать, создав специальную пользовательскую группу (user task force). В эту группу может входить произвольное число реальных пользователей - от небольшого их количества до двух десятков человек. Любые идеи отрабатываются на этой группе, но окончательное решение остается за представителем пользователей. Такая группа создаст своего рода "подушку безопасности", защищающую от принятия неверных решений.

• ­Комбинируйте разных представителей пользователей
• ­Смотрите на конкурирующие продукты
• ­Выпустите бета версию и получите пользователей

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

Тестирование лучше всего представлять в виде двухэтапного процесса.

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

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

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

• ­Начинайте с целевых историй
• ­Пишите законченные истории (приносящую пользу для конечного пользователя)
• ­Карточки ограничений (например, важные НФТ можно описать ограничениями)
• ­Размер и точность истории зависит от горизонта реализации истории (чем ближе срок реализации истории, тем меньшее и точнее истории)
• ­Не беритесь за пользовательский интерфейс как можно дольше
• ­Включайте пользовательские роли в истории
• ­Истории пишет заказчик
• ­и другие

• ­Легкость изменения оценок при изменении истории
• ­Применимы к большим и малым историям
• ­Не требует больших затрат времени
• ­Дают информацию о текущем прогрессе и оставшемся объеме работ
• ­Применимы с учетом неточности оценок

• ­Оценка в SP - это оценка в абстрактных очках сложности. Хотя можно использовать и идеальные дни (выбор Майка Кона) или часы.
• ­Оцениваете задачи всей командой. Такие оценки будут более точными
• ­Используйте шкалу Фибоначи (1,2,3,5,8,13 и тд) для оценок.
• ­Триангулируйте оценки. Т.е. проверяйте, что всякая задача с оценкой 5 сложнее, чем всякая задача с оценкой 2.
• ­Чем больше оценка, тем ниже точность

• ­Оценки в SP работают, потому что

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

• ­Т.е. оценки команды разработчиков - случайные величины и ошибки распределяются законом нормального распределения (т.е. компенсируют друг друга)
• ­Теперь вспомните свой опыт. Действительно ли "Бл*, мы не успеваем" мы слышим также часто как "Ура! Мы сделали раньше, чем ожидали"?

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