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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать
Предметом всех обсуждений до этого момента были детали но мы погружались в них - фото 124

Предметом всех обсуждений до этого момента были детали, но мы погружались в них ровно настолько, чтобы принять необходимые на тот момент решения. Теперь же нужно принимать решения, чтобы точно ответить на вопрос: «Что конкретно мы разрабатываем?»

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

Рецепт семинара по историям

Используйте семинары по историям, чтобы довести понимание до совершенства и точно определить, что конкретно должна создать команда разработки. Семинар – это обсуждение продукта (поддерживаемое множеством данных и картинок), которое поможет команде принять необходимые решения и определить признаки готовности, то есть критерии приемки того, что было решено разработать.

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

Небольшое количество людей – условие продуктивности семинара . От трех до пяти человек – наилучший вариант.

Тщательно подбирайте участников . Чтобы обсуждение было эффективным, включите:

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

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

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

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

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

Тщательно анализируйте и рассматривайте варианты . Используйте обсуждения, чтобы детально проанализировать:

• кто конкретно ваши пользователи;

• как конкретно, по мнению команды, они будут использовать продукт;

• как конкретно будет выглядеть продукт, то есть его интерфейс;

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

• сколько времени потребует разработка продукта с учетом всех технических деталей (на этом этапе мы обсуждаем все настолько подробно, что оценки могут быть довольно точными).

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

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

• По каким критериям можно будет определить, что работа над программным обеспечением закончена?

• Что будет происходить во время демонстрации программного обеспечения, когда мы будем оценивать его все вместе?

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

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

Интервал:

Закладка:

Сделать

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

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


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

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

x