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

Здесь есть возможность читать онлайн «Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Санкт-Петербург, Год выпуска: 2017, ISBN: 2017, Издательство: Издательство Питер, Жанр: org_behavior, popular_business, popular_business, Программирование, foreign_comp, popular_business, foreign_business, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

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

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

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

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

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

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

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

Но все это не будет работать, если:

• нет совместной работы – кто-то один описывает, что нужно сделать, а все остальные слушают;

• разговор идет только о критериях приемки, но никто не вспоминает об истории и о «Кто?», «Что?», «Почему?»;

• не рассматриваются варианты реализации как с функциональной, так и с технической стороны.

Планирование спринта или итерации

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

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

Быть среди своих

Никола Адамс и Стив Барретт, RAC Insurance (Perth, Australia)

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

Никола Адамс

Контекст

Историю трансформации от методологии водопада к Agile в компании RAC Incurance (Западная Австралия) рассказывает Никола, квалифицированный бизнес-аналитик с большим опытом в традиционном подходе к разработке программного обеспечения. В ее обязанности входило сотрудничество с бизнесом, понимание предметной области и составление функциональных спецификаций, в соответствии с которыми команда IT создавала продукт. Коммуникация происходила по следующей схеме.

Наибольшее внимание уделялось детальным спецификациям где старались не - фото 125

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

С чего все началось?

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

Чтобы передать требования команде на сессиях разработки, Никола:

• собирала требования партнеров по бизнесу;

• глубоко анализировала требования и данные;

• создавала последовательности действий пользователя (каждая занимала от одной до пяти страниц), где описывались требования, дизайн решения и критерии приемки;

• излагала эти требования команде с использованием проектора и отвечала на вопросы присутствующих.

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

После одной из сессий Сэм, эксперт в предметной области, одновременно играющий роль владельца продукта, заметил: «Если это и есть проект Agile, я не желаю в этом участвовать!»

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

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


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

Обсуждение, отзывы о книге «Пользовательские истории. Искусство гибкой разработки ПО» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x