Пользовательские истории. Искусство гибкой разработки ПО

В оригинале книга называется "User story mapping". Покупал ее именно из-за оригинально названия, в надежде досконально разобраться в этом методе формирования требований к продукту. В итоге разочаровался. В книге, не в методе.

Книга оказалась не столько о построении карты пользовательских историй, сколько о подходе к сбору требований и развитии продукта в целом. Паттон намешал в книге много всего. И собственный метод (тот самый user story mapping), и lean startup, и lean canvas, и пользовательские истории Кона и некоторые фасилитаторские практики. Причем сделал это по верхушкам, без глубоких деталей.

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

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

Софт вырастает из знаний

Отличная книга для того, чтобы разложить все по полочкам. Для тех, кто новичок в этом нелегком деле - быть аналитиком и иметь непосредственное отношение и к продукту, и к клиенту. Книга отвечает на вопросы "зачем", "как" и "почему" нужно иметь конкретный подход к требованиям, а также помогает найти то, с чего действительно необходимо начинать выстраивание своих отношений с аналитической работой.
Автор легко и доступно описывает не только технику написания и последующей работы над историями, но и говорит о более высокостепенных вещах вроде четкого формирования подхода к описанию требований к софту.
Лучшее, что было перенято из этой книги - это прекрасная мысль о том, что софт - это, в первую очередь, знания, и только потом уже - деньги, и все остальное, с чем я непременно и полностью согласна.
Вдохновляюще!

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

Еле дочитал )

Книгу можно было сделать в 10 раз меньше и не потерять ничего. Основная идея про описание пользовательских историй описана страницы на 2. Дальше на 280 страниц идут разные байки про Agile и через все эти 280 страниц идёт одна и та же мысль: прежде чем что-то делать (создавать новый продукт, реализовывать новую фичу) надо убедиться, что то, что вы пытаетесь создать это реально нужно пользователям. Складывается впечатление, что автор имеет много негативного опыта в разработке, когда люди просто делали какие-то предположения и дальше бесценно тратили на создание этого несколько лет, выпускали продукт и выяснялось, что он никому не нужен.
В книге много примеров, когда автор участвовал в таких компаниях и просто задавал правильные вопросы - это приводило к тому, что люди начинали понимать, что они действительно хотят и в итоге получались удачные продукты. Но здесь сам принцип пользовательских историй, на мой взгляд, совершенно не причем. Основная причина успеха - осознанная разработка. Если у вас это есть, то вы сможете применять разные подходы (в том числе и этот) и создать успешный продукт.

Научить составлять пользовательские истории вас эта книга не научит.

water

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