Страница 1 из 7

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

Паттон Джефф

Джефф Паттон

Посвящается Стейси, Грейс и Зоэ. Без вашей поддержки у меня ничего бы не вышло.

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

Предисловие Мартина Фаулера

Одно из самых выгодных последствий популярности разработки программного обеспечения (ПО) по методологии Agile – распространение идеи разбиения больших, объемных требований на компактные фрагменты. Благодаря этим фрагментам – историям – отслеживать прогресс разработки проекта намного проще. Когда истории реализуют постепенно, каждый раз полностью интегрируя их в проект, всем очевидно, что проект понемногу растет. Рассматривая истории, которые приносят пользователям очевидную выгоду, разработчики могут планировать развитие проекта и определять, над чем нужно работать в следующую очередь. К тому же такая прозрачность подталкивает пользователей к активному участию в разработке – они больше не гадают месяцами и годами, чем занята команда разработки.

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

Построение карт историй (story mapping) – это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.

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

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

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

Предисловие Алана Купера

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

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

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

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

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

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

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

Метод построения карт историй, созданный Джеффом, находят полезным разработчики, и точно так же его оценивают дизайнеры. Карты историй – Розеттский камень нашего цифрового века.

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

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

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