Описание книги «Пользовательские истории. Искусство гибкой разработки ПО»
Описание и краткое содержание «Пользовательские истории. Искусство гибкой разработки ПО» читать бесплатно онлайн.
Пользовательские истории – это метод описания требований к разрабатываемому продукту. В книге рассказано, как правильно использовать данную технику, чтобы сфокусироваться на поставленной задаче и пожеланиях клиента, а не распыляться на реализации второстепенных функций. Автор книги показывает, как данный подход не только ускоряет и систематизирует разработку, но и улучшает взаимопонимание в команде.
Пользовательские истории. Искусство гибкой разработки ПО
Посвящается Стейси, Грейс и Зоэ. Без вашей поддержки у меня ничего бы не вышло.
В память Люка Баррета, дорогого коллеги и учителя. Люк оказал огромное влияние на мою жизнь, а также на судьбы многих других людей.
© ООО Издательство «Питер», 2017
Предисловие Мартина Фаулера
Одно из самых выгодных последствий популярности разработки программного обеспечения (ПО) по методологии Agile – распространение идеи разбиения больших, объемных требований на компактные фрагменты. Благодаря этим фрагментам – историям – отслеживать прогресс разработки проекта намного проще. Когда истории реализуют постепенно, каждый раз полностью интегрируя их в проект, всем очевидно, что проект понемногу растет. Рассматривая истории, которые приносят пользователям очевидную выгоду, разработчики могут планировать развитие проекта и определять, над чем нужно работать в следующую очередь. К тому же такая прозрачность подталкивает пользователей к активному участию в разработке – они больше не гадают месяцами и годами, чем занята команда разработки.
Тем не менее такое разбиение может иметь и негативные последствия. В частности, очень легко перестать понимать, в чем заключается общее предназначение ПО – что и как должна делать система. В итоге у вас в руках может оказаться множество кусочков, которые никак не складываются в единую картину. Или вы можете создать бессмысленную и бесполезную систему, так как утонули в деталях и забыли, что в действительности нужно пользователям.
Построение карт историй (story mapping) – это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.
Вот, собственно, и все – описание книги уместилось в одном предложении, но этого вполне достаточно, чтобы оценить преимущества метода. Обзор цельной картины облегчает взаимодействие с пользователями, позволяет избежать разработки ненужных функций, а также ориентирует на релевантный опыт использования. Когда я обсуждаю с коллегами по Thought-Works применяемый ими процесс разработки пользовательских историй, построение карт регулярно упоминается в качестве основной техники. Часто оказывается, что коллеги изучили эту технику как раз на семинарах Джеффа, поскольку именно он разработал ее и лучше всего может ей обучить. С помощью данной книги еще больше людей смогут узнать об этой технике непосредственно из первых уст.
Но эта книга не только для тех, у кого на бедже или в профиле написано что-нибудь вроде «бизнес-аналитик». Наверное, самым большим разочарованием для меня за 10 лет внедрения методологии Agile стало то, что множество программистов рассматривают истории как некие односторонние указания со стороны аналитиков. С самого начала предполагалось, что истории будут вызывать обсуждение. Если вы и в самом деле хотите получить эффективное ПО, которое может органично встроиться в человеческую деятельность, то тех, кто создает программы, необходимо рассматривать как живой источник идей о возможностях, ведь именно программисты лучше всех знают, что могут делать эти программы. Программисты должны хорошо понимать, что хотят получить их пользователи, и взаимодействовать с ними, создавая карты историй, где полностью учитываются пользовательские цели. Программист, умеющий составлять карты историй, может видеть пользовательскую среду куда более широко, чем тот, кто этого не умеет, и, следовательно, принимать участие в проектировании ПО, что улучшит качество работы.
Когда Кент Бек, впервые предложивший термин «история», воплотил свои идеи в разработке ПО, он назвал коммуникацию ключевым моментом эффективности команды. Истории – строительные блоки коммуникации между разработчиками и теми, кто использует результаты их труда. Карты историй организуют и структурируют эти строительные блоки и тем самым стимулируют процесс коммуникации, крайне важный для разработки ПО в целом.
Мартин Фаулер, 18 июня 2014 года
Предисловие Алана Купера
В научно-фантастическом романе Мэри Шелли «Франкенштейн» безумный доктор Франкенштейн создает чудовище из фрагментов тел мертвых людей, а затем оживляет его с помощью диковинной на тот момент силы электричества. Конечно, мы знаем, что на самом деле это невозможно. Вы не можете создать что-то живое, просто сшив вместе случайные части тел.
Тем не менее разработчики программного обеспечения все время пытаются сделать именно это. Они разрабатывают прекрасные новые функции для программ, одну за другой, а потом удивляются, почему лишь немногие пользователи восхищаются их продуктом. Ключ к загадке в том, что в качестве инструмента для проектирования и дизайна программисты используют свои методы разработки ПО, но эти средства совсем не взаимозаменяемы.
Более чем разумно программировать только одну функциональность ПО в каждый момент времени. Это идеальная стратегия, проверенная временем. Кроме того, многолетним опытом разработки было доказано, что использование такого подхода при проектировании цифровых продуктов, как одна функциональность в каждый момент времени, порождает монстров, подобных Франкенштейну, а не качественные программы.
Хотя процессы проектирования программного обеспечения и его непосредственной разработки тесно связаны, по своей сути они совершенно различны и, как правило, их выполняют разные люди с разным набором навыков. Если заставить программистов, подобно дизайнерам интерфейсов, проводить многие часы за наблюдением работы пользователей и выделением поведенческих паттернов, они просто на стену полезут. В то же время дизайнер, погрузившись в код и алгоритмы, почувствует себя выброшенным на необитаемый остров.
Но когда две составляющие одного процесса – проектирование и разработка – выполняются одновременно, работа идет искрометно, а у продукта есть все шансы родиться живым и дышащим. Именно командная работа вдыхает в монстра жизнь и заставляет людей полюбить его.
Хотя идея командной работы не является ни новой, ни особенно революционной, эффективно воплотить ее в жизнь нелегко. Особенности работы программистов – темп, ритм, привычный язык – сильно отличаются от методов, присущих дизайнерам.
Представители каждой из сторон могут быть решительными, способными, дисциплинированными, но у них есть одно общее слабое место: очень трудно описать дизайнерскую проблему в терминах программирования и так же нелегко сделать обратное. Две родственные дисциплины не имеют общего языка. Именно там, на стыке этих двух дисциплин, и работает Джефф Паттон.
Метод построения карт историй, созданный Джеффом, находят полезным разработчики, и точно так же его оценивают дизайнеры. Карты историй – Розеттский камень нашего цифрового века.
На самом деле гибкие методологии – не самая лучшая среда для дизайна приложений, несмотря на популярность противоположного мнения. Да, такая философия разработки дружественна дизайну, и это очень хорошо, но сама по себе она не поможет вам создать продукт, который понравится пользователям. В то же время мы столько раз видели, как отличный, хорошо документированный дизайн передается разработчикам – работающим по Agile или нет, – а они в процессе реализации ухитряются загубить самую его суть.
Метод построения карт историй Паттона перекидывает мост через эту пропасть. Основа дизайна взаимодействия – это выяснение мельчайших потребностей пользователей и верная их интерпретация. Дизайнерская история, являющаяся формальной версией пользовательской истории, остается неизменной на протяжении всего периода разработки.
Современный мир бизнеса доказал, что команде из 200–300 человек почти невозможно создать продукт, который понравится пользователям. В то же время сообществу стартапов известно, что команда из четырех-пяти человек способна создать небольшой продукт, который люди полюбят, но даже эти маленькие продукты со временем растут и теряют свой блеск. Большие программы используются большой аудиторией и решают сложные коммерчески успешные задачи. Ждать, что вы легко их изучите и в процессе работы станете получать удовольствие, сложно да и просто смешно.
Единственный путь создать большую программу, не похожую на ужасного Франкенштейна, – научиться объединять дисциплины проектирования и разработки программного обеспечения. Никто не умеет делать это лучше, чем Джефф Паттон.
Алан Купер, 17 июня 2014 года
Предисловие Марти Когана
Мне невероятно повезло – я имел возможность работать с представителями лучших в мире компаний и групп разработки разных технологий. Эти люди создают программы, которые вы любите и которыми пользуетесь каждый день. Люди, которые буквально меняют мир.
Пользовательские истории. Гибкая разработка программного обеспечения
Майк Кон
В этой книге, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки программного обеспечения, описывается процесс подготовки требований к разрабатываемой системе, который позволяет экономить время, избавляет от необходимости в переделках и ведет к созданию более совершенных программ. Лучший способ создать программное обеспечение, максимально полно удовлетворяющее потребностям пользователей, — начать с пользовательских историй. Это простые, понятные и краткие описания функциональности, которая представляет деловую ценность для реальных пользователей. В книге приводятся подробные рекомендации относительно того, как следует писать пользовательские истории и включать их в жизненные циклы разработки проекта. Вы узнаете, что такое хорошие пользовательские истории и что делает истории плохими. Вы познакомитесь с практическими методами сбора историй, позволяющими добиться хороших результатов даже тогда, когда возможность непосредственного общения с пользователями отсутствует. Автор демонстрирует, как систематизировать подготовленные пользовательские истории, установить для них приоритеты и эффективно применять для решения задач планирования, разработки и тестирования программного обеспечения.
Книга будет полезна разработчикам, тестировщикам, аналитикам и менеджерам проектов, использующим любую гибкую методологию программного обеспечения: XP, Scrum. и даже собственный гибкий подход.
Пользовательские истории Майка Кона
Feb 20, 2017 · 7 min read
Пользовательские истории, на первый взгляд, довольно простой и даже интуитивно простой инструмент, совершенно естественно укладывающийся в итеративный процесс гибкой разработки. И тем пользовательские истории чрезвычайно привлекательны.
Проблемы
Однако на практике, как это часто бывает, возникает целый ряд сложностей. Вот их неполный список:
Книга Майка Кона “Пользовательские истории” — должно быть наиболее часто упоминаемая работа по пользовательским историям и по гибким методологиям вообще. В ней я попытался найти ответы на означенные вопросы. О том, что получилось, какие ответы удалось найти, а какие нет, далее в этом посте.
Что такое пользовательские истории
По запросу “how to write user stories” в поисковике выпадает множество статей и заметок, предлагающих несколько шаблонов пользовательских историй. Вот один их них:
И действительно краткое описание фичи — важная часть пользовательской истории. Но не единственная.
Вторая составляющая пользовательской истории — это приемочные тесты. Для каждой пользовательской истории необходимо кратко описать, каким образом она будет тестироваться, выполнение каких условий позволит считать пользовательскую историю успешно реализованной. Если обходить приемочные тесты умолчанием и отдать их целиком на откуп конкретному разработчику, то велика вероятность столкнуться с необходимостью переделывать и доделывать одну и ту же по сути историю на протяжении нескольких спринтов.
Третий, не очевидный, но едва ли не важнейший компонент — это общение. Общение между заказчиком и командой, между разными членами команды. Собственно ради общения пользовательские истории и создаются.
В основе метода пользовательских историй лежит идея о принципиальной невозможности задокументировать требования к программному продукту во всей их полноте и непротиворечивости. Кон сравнивает написание пользовательских историй с вылавливанием рыбы. Никогда нельзя надеяться, что вы выловите всю рыбу из океана, количество и состав рыбы все время меняется в водных недрах. Метафора эта неполна, потому что и выловленная рыба не есть нечто неизменное. В силу неоднозначности естественного языка: под одной и той же формулировкой заказчик и команда могут понимать нечто совершенно различное. И в силу текучести человеческого миропонимания: между моментом сбора требований и моментом их реализации проходит время, за которое успевает измениться понимание проблемы заказчиком, он больше узнает о ней, больше погружается в тему, иногда и сам контекст меняется. Поэтому Кон настаивает на том, чтобы в пользовательские истории детали не включались, детализацию следует откладывать так долго, как только возможно.
Пользовательские истории — представление, но не документирование требований. Это только темы для начала разговора.
Пользовательские истории таким образом не документируют, не фиксируют требования. Это только тема для начала разговора между людьми, вовлеченными в работу над продуктом. И именно разговор ставится здесь во главу угла, на устное общение возлагается главная надежда в достижении понимания о том, что именно требуется реализовать.
Зачем нужны
Кон заметную часть книги обсуждает отличия пользовательских историй от других методов работы с требованиями, акцентирует преимущества пользовательских историй над стандартными текстовыми требованиями, вариантами использования (use cases) и пользовательскими сценариями. Альтернативы признаются обладающими избыточной полнотой, они не конвертируются напрямую в задачи, в случае вариантов использования они непонятны заказчикам. Особенно много места уделяется обсуждению недостатков текстовых требований: их создание очень трудоемко, их тяжело валидировать, сложно обновлять и дополнять, сложно воспринимать, они не избавлены от неоднозначности естественного языка.
Пользовательские истории же напротив:
Свойства хороших историй
Не каждая история, формально отвечающая шаблону, будет обладать преимуществами, которые от нее можно ожидать. Кон выделяет свойства, которыми должны обладать хорошие пользовательские истории:
Нетрудно заметить, что одни свойства из этого списка входят в противоречение с другими. Нельзя развить их все одновременно и в полной мере. Так, наращивая тестируемость, нам понадобится перебрать все возможные варианты работы с определенной частью продукта, что лишит историю компактности и вплотную приблизит собственно к вариантам использования (use cases).
Свойства хороших пользовательских историй противоречат друг другу.
Аналогично компактность расходится с оцениваемостью: чем меньше деталей нам известно, тем сложнее нам оценить.
Независимость тяжело реализировать и саму по себе и особенно в сочетании с компактностью. Заказчик часто мыслит довольно большими блоками функциональности, большими историями, которые приходится разбивать на меньшие для того, чтобы иметь возможность оценить их, определить тесты, конвертировать в конечные задачи. И связи между историями после такого разбиения все равно остаются. Особенно в ситуации сложного проекта c большой степенью связности разных компонентов. Можно для историй применить те же методы, которые мы применяем для изоляции программных компонентов и модулей в архитектуре ПО. Но тогда борьба против связности историй оборачивается уменьшением понятности истории для заказчика и соотвественно её оцениваемости, обсуждаемости.
Ответы и вопросы
Возвращаясь к списку проблем, с которого начался этот пост, нужно отметить, что о многих пунктах сам Кон упоминает.
В частности он говорит о том, что на практике иногда сложно или даже невозможно обеспечить независимость. Но не предлагает решения, есть только рекомендация стремится к этой независимости. Кон упоминает о необходимости трассировки, фиксации нефункциональных требований. Для этого он предлагает использовать дополнительные инструменты, предлагает отдельно выписывать нефункциональные требования и отдельно вести матрицу трассировки. Обсуждается и вопрос с проектированием, но для Кона кажется тут нет проблемы, напротив, он видит преимущество как раз в том, что вся команда оказывается вовлечена в проектирование. И это верно, вовлеченность на практике действительно повышается, но повышается и доля неопределенности, которая снижает эффективность работы и качество результата. Особенно в ситуации сложного проекта с большой степенью связности различных компонентов.
В книге пользовательские истории преподносятся, как вполне достаточный метод и для работы с требования, и для проектирования, и для оценки, и для планирования, и для постановки задач. Дополнить пользовательские истории предлагается только сторипоинтами (story points) и покером планирования(planning poker game). Но ничего сверх этого. На практике же такая сборка скорее всего будет порождать значительные сложности.
Пользовательские истории могут быть действительно полезным и эффективным инструментом, но только как часть более широкого комплекса практик.
Мой опыт говорит мне, что истории действительно могут быть очень полезны и при сборе требований и при проектировании, но только если они используются как часть более широкого комплекса практик, который нужно выбирать в зависимости от специфики каждого проекта. На сложных проектах пользовательские истории вполне могут быть дополнены вариантами использования, они могут использоваться только на этапе сбора требований для начала работ по прототипированию, их можно и нужно совмещать с инструментами трассировки требований и даже с процессами полноценного документирования требований — если взаимоотношения с заказчиком все таки нужно формализировать.
О самой книге
Что хорошо
Книга Кона обладает четкой структурой, она состоит из пяти частей и прочтения первой, обзорной, уже достаточно для того, чтобы составить общее представление и начать работу. А это всего 70 страниц. Вторая часть более подробно рассказывает об оценке и планировании с помощью покера планирования. По мере повествования затрагиваются и многие другие сопутствующие практики: интервью пользователей, приоретизация пользовательских историй и т.п.
В третьей части перечисляются примеры неправильного использования пользовательских историй, даются рекомендации, как не делать истории слишком большими и слишком и маленькими, как разбивать большие истории, не углублубляясь в детали реализации; как в некоторых случаях можно сделать истории независимыми и т.п. Завершается третья часть кратким экскурсом в Скрам.
Четвертая часть целиком состоит из развернутого рассказа об использовании пользовательских истории на примере разработки интернет-магазина товаров для яхтсменов. Примерами обильно снабжено и основное повествование, четвертая же часть предпринимает попытку собрать все вместе и представляет собой один большой, подробный пример.
Пятая часть рассказывает о практиках экстремального программирования, в контексте которого впервые и возникли пользовательские истории в далеком 1998 году. Правда тогда они определялись по аналогии с вариантами использования. Сейчас же, напротив, принято подчеркивать различия между пользовательскими историями и вариантами использования.
Главы снабжены контрольными вопросами для самопроверки, завершаются краткими резюме, сильно помогающими в усвоении материала, и, что немаловажно, списками обязанностей заказчика и разработчиков. Для успеха проекта, конечно, чрезвычайно важно, чтобы стороны одинаково понимали свои обязанности и полномочия.
Что плохо
Примеры, которыми изобилует книга, к сожалению, слишком просты для того, чтобы высветить реальные сложности практического применения пользовательских историй и сопутствующих практик. В результате многие проблемы даже не упоминаются. Как например, проблема оценки пользовательских историй в ситуации команды без взаимозаменяемых специалистов.
С другой стороны довольно много внимания уделяется обсуждению проблем, которые, на мой взгляд, слишком частные и малозначительные. Нумеровать истории или нет, использовать специализированное ПО или достаточно маркерной доски с листочками — такие вопросы вроде бы не должны вызывать затруднений.
Для чего стоит прочесть
“Пользовательские истории” Майка Кона стоит, конечно, прочесть. Она небольшая и быстро читается. Книга будет полезна прежде всего как первое знакомство с пользовательскими историями, яснее будут идеи, которые лежат за этим методам и соответственно и область применения — с поправкой, конечно, на критическое восприятие примеров Кона. Возможно, имеет смысл прочитать книгу и специалистам, уже имеющим опыт работы с пользовательскими историями. Она позволяет несколько упорядочить свои знания и найти ответы на часть вопросов, которые возникают на практике.
ЧИТАТЬ КНИГУ ОНЛАЙН: Пользовательские истории. Искусство гибкой разработки ПО
НАСТРОЙКИ.
СОДЕРЖАНИЕ.
СОДЕРЖАНИЕ
Пользовательские истории. Искусство гибкой разработки ПО
Посвящается Стейси, Грейс и Зоэ. Без вашей поддержки у меня ничего бы не вышло.
В память Люка Баррета, дорогого коллеги и учителя. Люк оказал огромное влияние на мою жизнь, а также на судьбы многих других людей.
© ООО Издательство «Питер», 2017
Предисловие Мартина Фаулера
Одно из самых выгодных последствий популярности разработки программного обеспечения (ПО) по методологии Agile – распространение идеи разбиения больших, объемных требований на компактные фрагменты. Благодаря этим фрагментам – историям – отслеживать прогресс разработки проекта намного проще. Когда истории реализуют постепенно, каждый раз полностью интегрируя их в проект, всем очевидно, что проект понемногу растет. Рассматривая истории, которые приносят пользователям очевидную выгоду, разработчики могут планировать развитие проекта и определять, над чем нужно работать в следующую очередь. К тому же такая прозрачность подталкивает пользователей к активному участию в разработке – они больше не гадают месяцами и годами, чем занята команда разработки.
Тем не менее такое разбиение может иметь и негативные последствия. В частности, очень легко перестать понимать, в чем заключается общее предназначение ПО – что и как должна делать система. В итоге у вас в руках может оказаться множество кусочков, которые никак не складываются в единую картину. Или вы можете создать бессмысленную и бесполезную систему, так как утонули в деталях и забыли, что в действительности нужно пользователям.
Построение карт историй (story mapping) – это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.
Вот, собственно, и все – описание книги уместилось в одном предложении, но этого вполне достаточно, чтобы оценить преимущества метода. Обзор цельной картины облегчает взаимодействие с пользователями, позволяет избежать разработки ненужных функций, а также ориентирует на релевантный опыт использования. Когда я обсуждаю с коллегами по Thought-Works применяемый ими процесс разработки пользовательских историй, построение карт регулярно упоминается в качестве основной техники. Часто оказывается, что коллеги изучили эту технику как раз на семинарах Джеффа, поскольку именно он разработал ее и лучше всего может ей обучить. С помощью данной книги еще больше людей смогут узнать об этой технике непосредственно из первых уст.
Но эта книга не только для тех, у кого на бедже или в профиле написано что-нибудь вроде «бизнес-аналитик». Наверное, самым большим разочарованием для меня за 10 лет внедрения методологии Agile стало то, что множество программистов рассматривают истории как некие односторонние указания со стороны аналитиков. С самого начала предполагалось, что истории будут вызывать обсуждение. Если вы и в самом деле хотите получить эффективное ПО, которое может органично встроиться в человеческую деятельность, то тех, кто создает программы, необходимо рассматривать как живой источник идей о возможностях, ведь именно программисты лучше всех знают, что могут делать эти программы. Программисты должны хорошо понимать, что хотят получить их пользователи, и взаимодействовать с ними, создавая карты историй, где полностью учитываются пользовательские цели. Программист, умеющий составлять карты историй, может видеть пользовательскую среду куда более широко, чем тот, кто этого не умеет, и, следовательно, принимать участие в проектировании ПО, что улучшит качество работы.
Когда Кент Бек, впервые предложивший термин «история», воплотил свои идеи в разработке ПО, он назвал коммуникацию ключевым моментом эффективности команды. Истории – строительные блоки коммуникации между разработчиками и теми, кто использует результаты их труда. Карты историй организуют и структурируют эти строительные блоки и тем самым стимулируют процесс коммуникации, крайне важный для разработки ПО в целом.
Предисловие Алана Купера
В научно-фантастическом романе Мэри Шелли «Франкенштейн» безумный доктор Франкенштейн создает чудовище из фрагментов тел мертвых людей, а затем оживляет его с помощью диковинной на тот момент силы электричества. Конечно, мы знаем, что на самом деле это невозможно. Вы не можете создать что-то живое, просто сшив вместе случайные части тел.
Тем не менее разработчики программного обеспечения все время пытаются сделать именно это. Они разрабатывают прекрасные новые функции для программ, одну за другой, а потом удивляются, почему лишь немногие пользователи восхищаются их продуктом. Ключ к загадке в том, что в качестве инструмента для проектирования и дизайна программисты используют свои методы разработки ПО, но эти средства совсем не взаимозаменяемы.
Более чем разумно программировать только одну функциональность ПО в каждый момент времени. Это идеальная стратегия, проверенная временем. Кроме того, многолетним опытом разработки было доказано, что использование такого подхода при проектировании цифровых продуктов, как одна функциональность в каждый момент времени, порождает монстров, подобных Франкенштейну, а не качественные программы.
Хотя процессы проектирования программного обеспечения и его непосредственной разработки тесно связаны, по своей сути они совершенно различны и, как правило, их выполняют разные люди с разным набором навыков. Если заставить программистов, подобно дизайнерам интерфейсов, проводить многие часы за наблюдением работы пользователей и выделением поведенческих паттернов, они просто на стену полезут. В то же время дизайнер, погрузившись в код и алгоритмы, почувствует себя выброшенным на необитаемый остров.
Но когда две составляющие одного процесса – проектирование и разработка – выполняются одновременно, работа идет искрометно, а у продукта есть все шансы родиться живым и дышащим. Именно командная работа вдыхает в монстра жизнь и заставляет людей полюбить его.
Хотя идея командной работы не является ни новой, ни особенно революционной, эффективно воплотить ее в жизнь нелегко. Особенности работы программистов – темп, ритм, привычный язык – сильно отличаются от методов, присущих дизайнерам.
Представители каждой из сторон могут быть решительными, способными, дисциплинированными, но у них есть одно общее слабое место: очень трудно описать дизайнерскую проблему в терминах программирования и так же нелегко сделать обратное. Две родственные дисциплины не имеют общего языка. Именно там, на стыке этих двух дисциплин, и работает Джефф Паттон.
Метод построения карт историй, созданный Джеффом, находят полезным разработчики, и точно так же его оценивают дизайнеры. Карты историй – Розеттский камень нашего цифрового века.
На самом деле гибкие методологии – не самая лучшая среда для дизайна приложений, несмотря на популярность противоположного мнения. Да, такая философия разработки дружественна дизайну, и это очень хорошо, но сама по себе она не поможет вам создать продукт, который понравится пользователям. В то же время мы столько раз видели, как отличный, хорошо документированный дизайн передается разработчикам – работающим по Agile или нет, – а они в процессе реализации ухитряются загубить самую его суть.
Метод построения карт историй Паттона перекидывает мост через эту пропасть. Основа дизайна взаимодействия – это выяснение мельчайших потребностей пользователей и верная их интерпретация. Дизайнерская история, являющаяся формальной версией пользовательской истории, остается неизменной на протяжении всего периода разработки.
Современный мир бизнеса доказал, что команде из 200–300 человек почти невозможно создать продукт,