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

Пользовательские истории: гибкая разработка программного обеспечения

Посоветуйте книгу друзьям! Друзьям – скидка 10%, вам – рубли

Эта и ещё 2 книги за 299 ₽

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

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

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

• Моделирование пользовательских ролей.

• Сбор историй: опрос пользователей, анкетный метод, наблюдение, собрания.

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

• Написание пользовательских историй для приемочного тестирования.

• Использование историй для ранжирования задач, составления графиков работ и оценки трудозатрат.

• В конце каждой главы приводится список контрольных вопросов и упражнений для самопроверки.

Книга будет полезна разработчикам, тестировщикам, аналитикам и менеджерам проектов, использующим любую гибкую методологию программного обеспечения: ХР, Scrum… и даже собственный гибкий подход.

Источник

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

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

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

Если вы используете истории и страдаете, эта книга — для вас

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

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

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

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

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

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

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

Для кого еще эта книга

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

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

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

• Тренеры процессов Agile и Lean, если они хотят помогать командам и отдельным людям действовать эффективнее, должны прочесть эту книгу. Кроме того, подумайте только, насколько неверное представление об историях сформировалось у сотрудников вашей организации! Применяйте истории, простые упражнения и практики, описанные в этой книге, чтобы помочь вашим командам развиваться.

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

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

Построение карт историй с высоты птичьего полета

Главы 1–4 дадут вам общее представление о построении карт историй. Если вы уже используете их и имеете некоторый опыт, эта часть книги обеспечит достаточно материала, чтобы немедленно приступить к делу.

Глава 5 предоставит вам отличную возможность попрактиковаться в ключевых концептах, используемых для составления наилучшей карты историй. Попробуйте проделать это в своем офисе с группой коллег — в результате каждый участник получит полезный опыт. Я обещаю: созданные вами карты со временем будут становиться все лучше и лучше.

Интуитивное понимание пользовательских историй

В главах 6–12 рассказано многое о пользовательских историях: как они работают в реальности, как организовать их использование в проектах Agile или Lean наилучшим образом. В дополнение к картам историй там приведены несколько маленьких примеров, которые могут оказаться полезными в ежедневной практике разработки. Даже если вы ветеран Agile, обещаю, вы узнаете об историях что-то новое для себя. А если вы в историях новичок, то узнаете достаточно, чтобы поразить самого заносчивого Agile-всезнайку в офисе.

Лучшие бэклоги

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

Лучшая разработка

Главы 16–18 шаг за шагом посвятят вас в тонкости тактики использования историй. Вы научитесь доводить истории до конца, не упускать их из виду в процессе разработки, добиваться их точного исполнения, а также извлекать опыт из каждой истории, трансформированной вами в рабочее ПО.

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

Об авторе

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

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

В настоящее время Джефф работает как независимый консультант, тренер процессов Agile, тренер процессов дизайна продуктов и инструктор. Множество статей, эссе и презентаций, посвященных различным аспектам разработки продуктов Agile, можно найти на сайте agileproductdesign.com и в Crystal Clear Алистера Коберна. Джефф — основатель и модератор дискуссионной группы Yahoo! по теме юзабилити в Agile, колумнист в StickyMinds.com и IEEE Software, сертифицированный тренер Scrum, а также обладатель премии Agile Alliance’s 2007 Gordon Pask за вклад в развитие Agile.

Для Хаброжителей скидка 25% по купону — Паттон

Источник

Основы пользовательских историй. Часть 1. Введение

Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.

Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании», обе статьи можно найти в блоге. Текущая же статья извлечена из будущей книги «Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий», издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.

О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., «пожелание»). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин «пользовательская история» в несколько официальном ключе и для непосредственных выкладок — «стори». Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.

Основы пользовательских историй

Они были на великом пиру языков, но довольствовались крохами.
— паж Моль к Костарду, «Напрасный труд любви», Уильям Шекспир

Введение

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

Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:

Определить полезную стори — реализовать и оттестировать в рамках короткой итерации — продемонстрировать и/или доставить ее пользователю — получить фидбек — усвоить информацию — повторить в цикле!

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

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

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

В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефакта. Хотя это значительно менее значимое «методологическое распутье», чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.

Для наших целей мы определим пользовательскую историю так:

Пользовательская история — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

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

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

Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.

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

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

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

Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом(2):
Пиджин (pidgin) — упрощенный язык, обычно используемый в торговле, позволяет людям, которые не могут общаться на своем родном языке, тем не менее работать вместе. Пользовательские истории действуют подобным образом. Мы не ждем от заказчика или пользователей точно такого же видения системы, как у разработчиков; стори действуют как пиджин, где обе стороны всегда могут договориться, чтобы эффективно вместе работать.

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

Пользовательские истории — это не требования

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

Литература
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

Источник

Пользовательские истории Майка Кона

Feb 20, 2017 · 7 min read

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

Проблемы

Однако на практике, как это часто бывает, возникает целый ряд сложностей. Вот их неполный список:

Книга Майка Кона “Пользовательские истории” — должно быть наиболее часто упоминаемая работа по пользовательским историям и по гибким методологиям вообще. В ней я попытался найти ответы на означенные вопросы. О том, что получилось, какие ответы удалось найти, а какие нет, далее в этом посте.

Что такое пользовательские истории

По запросу “how to write user stories” в поисковике выпадает множество статей и заметок, предлагающих несколько шаблонов пользовательских историй. Вот один их них:

И действительно краткое описание фичи — важная часть пользовательской истории. Но не единственная.

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

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

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

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

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

Зачем нужны

Кон заметную часть книги обсуждает отличия пользовательских историй от других методов работы с требованиями, акцентирует преимущества пользовательских историй над стандартными текстовыми требованиями, вариантами использования (use cases) и пользовательскими сценариями. Альтернативы признаются обладающими избыточной полнотой, они не конвертируются напрямую в задачи, в случае вариантов использования они непонятны заказчикам. Особенно много места уделяется обсуждению недостатков текстовых требований: их создание очень трудоемко, их тяжело валидировать, сложно обновлять и дополнять, сложно воспринимать, они не избавлены от неоднозначности естественного языка.

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

Свойства хороших историй

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

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

Свойства хороших пользовательских историй противоречат друг другу.

Аналогично компактность расходится с оцениваемостью: чем меньше деталей нам известно, тем сложнее нам оценить.

Независимость тяжело реализировать и саму по себе и особенно в сочетании с компактностью. Заказчик часто мыслит довольно большими блоками функциональности, большими историями, которые приходится разбивать на меньшие для того, чтобы иметь возможность оценить их, определить тесты, конвертировать в конечные задачи. И связи между историями после такого разбиения все равно остаются. Особенно в ситуации сложного проекта c большой степенью связности разных компонентов. Можно для историй применить те же методы, которые мы применяем для изоляции программных компонентов и модулей в архитектуре ПО. Но тогда борьба против связности историй оборачивается уменьшением понятности истории для заказчика и соотвественно её оцениваемости, обсуждаемости.

Ответы и вопросы

Возвращаясь к списку проблем, с которого начался этот пост, нужно отметить, что о многих пунктах сам Кон упоминает.

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

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

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

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

О самой книге

Что хорошо

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

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

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

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

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

Что плохо

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

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

Для чего стоит прочесть

“Пользовательские истории” Майка Кона стоит, конечно, прочесть. Она небольшая и быстро читается. Книга будет полезна прежде всего как первое знакомство с пользовательскими историями, яснее будут идеи, которые лежат за этим методам и соответственно и область применения — с поправкой, конечно, на критическое восприятие примеров Кона. Возможно, имеет смысл прочитать книгу и специалистам, уже имеющим опыт работы с пользовательскими историями. Она позволяет несколько упорядочить свои знания и найти ответы на часть вопросов, которые возникают на практике.

Источник