Главная » Компьютеры » Пользовательские истории. Искусство гибкой разработки ПО

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон (2014)

Пользовательские истории. Искусство гибкой разработки ПО
Пользовательские ситуации – это способ описания притязаний к разрабатываемому продукту. В книжке поведано, как верно применить эту технику, дабы сфокусироваться на установленной задачке и пожеланиях покупателя, а не распыляться на реализации второстепенных функций. Создатель книжки демонстрирует, как этот расклад не только ускоряет и классифицирует разработку, но и улучшает взаимопонимание в команде.
Уже достаточно большое количество организаций ввело у себя методологии Agile и Lean, в следствие этого, абсолютно ,вполне вероятно, что вы уже успели попасться в одну из ловушек, образующихся по причине неправильного осознания концепции ситуаций. Вот кое-какие из них. Книжка несомненно поможет вам:
Потому что ситуации дают возможность для вас сосредоточиться на разработке маленьких фрагментов ПО, просто закончить и рассмотреть неделимую картину. В итоге выходит обычный продукт-франкенштейн, любому юзеру которого бесспорно, собственно что он произведен из разрозненных, не связанных частей с иной частью.
Когда вы трудитесь над продуктом значимых объемов, создание малехоньких частичек одного за иной, вынуждает людей думать, когда же вы в конце концов закончите и собственно , что же выйдет в итоге. Как будто вы строитель.
Потому что ключевое в концепции ситуаций — это рассмотрение, люди нередко запамятывают производить записи. В итоге вещь обсуждения и достигнутые соглашения забываются.
Потому что в не плохих ситуациях ожидается присутствие критериев приемки, мы сосредоточиваемся на определении данных критериев. Но данный процесс и описание создаваемого продукта — не одно и то же. В итоге команда не имеет возможность окончить запланированную работу в запланированные , нужные сроки.
Потому что неплохие ситуации обязаны быть написаны с позиции юзера, но есть большое количество качеств, коих юзер элементарно не лицезреет, члены команды говорят: «У сего продукта нет юзеров, например собственно , что тут пользовательские ситуации не подходят».
В случае если вы уже угодили в 1 из данных ловушек, я (автор) стараюсь прояснить все вызвавшие
их недоразумения. Вы спрашиваете, как расценить совершенную картину, продуктивно дискуссировать цели и задачки юзеров и делать неплохое ПО.
Для кого ещё данная книжка:
Для вас, естественно. Тем более в случае если вы ее уже приобрели. Я вот считаю, собственно , что вы создали мудрую инвестицию. Во всяком случае, чтение книжки станет тем более нужным для знатоков надлежащих областей.
Продукт-менеджеры и UX-специалисты в платных компаниях, производящих продукты, обязаны прочитать данную книжку, дабы перебросить мостик от мира пользовательского навыка и работы продукта к тактическим намерениям и составляющим бэклога. В случае если вы чувствуете проблемы, пробуя перебежать от представления о продукте к отдельным составным частям, которые обязана сделать ваша команда, описания вам несомненно помогут. В случае если для вас непросто вынудить иных людей поставить себя на пространство юзеров, карта ситуаций для вам несомненно поможет. В случае если вы никоим образом не сможете увязать совместно добрый дизайн взаимодействия и практическое проектирование продукта, для вас книга станет помощником. И в случае если пробуете выполнить опыт в манере стартапа Lean, она также станет помощником.
Адепты клиентов, бизнес-аналитики, а еще продукт-менеджеры в организациях, занятых в сфере информационных технологий, обязаны прочитать эту книжку, дабы взвести мосты меж юзерами, разработчиками и другими заинтересованными сторонами. В случае если вы тратите большое количество усилий, дабы все заинтригованные лица в вашей фирме пришли в конце концов к какому-либо договору, карты ситуаций помогут. А в случае, если создатели затрудняются, пробуя нарисовать неделимую картину, ситуации будут полезны и тут.
Тренеры процессов Agile и Lean, в случае если они желают помогать командам и отдельным людям работать эффективнее, обязаны прочитать эту книжку. Не считая такого, задумайтесь, как неправильное представление о ситуациях развилось у служащих вашей организации! Используйте ситуации, обычные упражнения и практики, описанные в данной книжке, дабы посодействовать вашим командам развиваться.
И в конце концов, все другие. При применении процессов Agile мы почаще всего ждем плодотворной работы с ситуациями от людей, исполняющих прямые обязанности бизнес-аналитиков или же адептов клиентов, но на самом деле действенной работа будет, в случае если почвы станут популярны и доступны всем. В случае если люди не знают самых простых вещей, вы нередко будете слышать претензии о том, что ситуации дурно расписаны, или же очень длинные, или же мало детализированные.
Данная книжка несомненно поможет, но не так, как вы ждете. Вы совместно с другими читателями спрашиваете: создание ситуаций — это не метод чем какого-либо другого строчить запросы, а дорога к большим, продуктивным и санкционированным дискуссиям. Данное издание поможет вам сконструировать такие облики дискуссий, которые помогут вам владеть нужной информацией.

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон читать онлайн бесплатно полную версию книги

Перейти

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

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

© ООО Издательство "Питер", 2017

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

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

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

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

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

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

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

Оставить комментарий