1. Компания
1.1. Компания не получит того, что хочет, пока пользователи не получат то, чего хотят они
1.2. «Секрет выбора приоритетов при разработке программ – концентрация на конкретных ожидаемых результатах.
2. Истории нужно рассказывать, а не писать
2.1. Говорите и пишите
2.1.1. «Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду].»
2.1.2. «История может быть историей, даже если она составлена не по шаблону.»
2.2. Не дайте словам пропасть
2.3. Пищите на стикере мысль, которую хотите сказать, чтобы освободить мозг и слушать того, кто высказывается
2.4. «Я хотел развить известную ситуацию, когда пользователи сами излагают истории работы крутых функций, которые умеет выполнять их рабочая программа. [Например,] когда я впечатываю в поле почтовый индекс, а програма автоматически заполняет город и штат, мне не приходится нажимать ни одной кнопки. Я думаю, именно этот пример натолкнул меня на мысль. Если вы можете рассказывать истории о том, что делает программа, вызывая интерес и живой отклик у слушателя, почему же не рассказать эти истории еще до того, как программа сможет это делать?»
2.5. «Если вы не собираетесь вместе, чтобы всесторонне обсудить свои истории, то на самом деле вы не используете истори»
2.6. Прааило трех П: «Пишем. Запишите то, что вы хотели бы видеть в программном продукте, на нескольких карточках. Проговариваем. Соберитесь вместе и всесторонне обсудите программный продукт, который создаете, и все, что будет в нем реализовано. Подтверждаем. Договоритесь о способе подтвердить то, что программный продукт готов.»
3. Карта пользовательских историй
3.1. Каркас - операции и высокоуровневые задачи
3.1.1. Скелет ископаемого
3.1.2. «Карты организуются слева направо согласно хронике повествования – порядка, в котором вы рассказываете историю»
3.2. Позвонки - детали разной длинны
3.3. Карты можно строить лишь для части добавляемого функционала
4. «модель расстановки приоритетов. • Конкурентное преимущество – преимущество, которое отличает их от конкурентов. • Спойлер – функциональность, которая стремится перекрыть чужое конкурентное преимущество. • Фактор снижения затрат – функциональность, введенная для снижения затрат организации.»«. • Минимальный пакет – минимальный набор функций, необходимый для успешного конкурирования на рынке.»
5. Использование пользовательских историй
5.1. Проблемы
5.1.1. Не видно целой картины продукт "Франкенштейн"
5.1.2. команда задумывается "когда уже конец"
5.1.3. люди забывают вести записи и не помнит, что обсуждалось
5.1.4. команда не может закончить историю в запланированные сроки
5.1.5. Убеждение, что истории не подходят, так как пользователь не видит часть функционала
5.2. Полезность
5.2.1. Избавляет от продуктового вакуума
5.2.2. Составление карты пользовательских историй поможет вам обнаружить пробелы в ней.
5.2.2.1. «Что будет, если что-то пойдет не так?» или «А что с этими, другими пользователями?». Играйте во «Что, если» с любыми сомнениями, которые у вас есть»
6. Истинная цель пользовательских историй - достижение единого понимания
6.1. Неправильно использовать истории, не обсуждая их с командой
6.1.1. единое понимание заключено в деталях, которые в нем не отражены
6.1.2. Фотография - документ. Рассказывайте историю так, как я рассказал о своем отпуске использую фотографию
6.2. Все, что не записано - проебано
6.2.1. Фотографировать заметки, делать записи обсуждения
6.3. До и после
6.3.1. понимание как эти люди справляются с этими задачами сейчас и что можно поменять для них в будущем
6.3.2. Для кого? Что? Почему?
6.3.3. Видение
6.3.3.1. Что это?
6.3.3.2. Зачем вы это создаете?
6.3.3.3. Какие задачи он будет решать для этих людей?
6.3.3.3.1. «Убедитесь, что проблема, которую вы собираетесь решить, на самом деле существует.»
6.3.3.3.2. «. Они могут работать с приложением, имея различные цели. Они могут применять его в разных обстоятельствах, из-за чего им приходится учитывать интересы других людей или процессов.»
6.3.3.4. Что произойдет когда мы закончим?
6.3.4. Для кого? (Пишем историю для выбранного сегмента)
6.3.4.1. Если бы из всех этих пользователей и задач, которые они хотят решить, надо было выбрать только одну группу, кто бы в нее вошел?
6.3.4.2. Приоритеты: для кого сейчас? Для кого потом?
6.3.4.3. «Ну что ж, давай представим себе будущее. Предположим на минуту, что продукт выпущен и работает, и обсудим день жизни кого-то, кто использует его, а затем начнем составлять истории: сперва он делает одно, затем – другое, третье и т. д.»
6.3.5. Детализируем историю
6.3.5.1. На каждом этапе истории задаем вопросы: В чем особенности действий пользователя на данном этапе? • Какие альтернативные вещи они могут сделать? • Как можно сделать этот этап по-настоящему крутым? • Как исправить ситуацию, если что-то пойдет не так?
6.3.6. Определяем релизы
6.3.6.1. «Фокусируйтесь на результате – что пользователи увидят и будут способны сделать, когда система выйдет в свет, – и запланируйте выпуск только того, что обеспечит этот результат.»
6.3.6.2. «Используйте срезы, чтобы выделить все задачи и детали, соответствующие достижению определенного результата.
6.3.7. Добавить ожидаемые результаты от каждого релиза
6.3.7.1. Не расставляйте приоритеты в функциональности, расставляйте приоритеты в результатах
6.3.7.2. «это конкретные изменения в поведении конкретных людей, вовлеченных в конкретные действия и процессы.»
6.4. Программируйте меньше
6.4.1. Минимализируйте объем работы, максимизируйте результат и долгосрочный эффект
6.4.2. «Концентрируйтесь на результате, который вы надеетесь получить вне системы, чтобы принять решение о происходящем внутри системы.»