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

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

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

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

Мартин Фаулер, 18 июня 2014 года

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

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

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

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

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

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

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

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

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

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

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

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