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

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

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

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

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

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

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

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

С благодарностью в адрес Бена Хоровица и его книги «Хороший менеджер продукта, плохой менеджер продукта»

Еще никто не приходил ко мне, чтобы поделиться радостью: «Нас попросили добавить вот эту новую функцию, а времени у нас оказалось намного больше, чем нужно!»

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