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

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

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

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

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

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

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

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

Интервал:

Закладка:

Сделать

Но этот подход – не единственный из возможных.

Вот простой рецепт, который поможет вам избежать самых распространенных проблем.

Подготовка

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

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

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

Планирование

Начните с обсуждения стратегической цели предстоящего цикла. Вы выбрали несколько историй, над которыми собираетесь работать. Как именно эта группа историй будет способствовать прогрессу решения, которое вы планируете выпустить?

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

Дайте командам время на самостоятельное планирование . Помните: толпа не может сотрудничать. А специалистам, которые будут разрабатывать и тестировать программный продукт, необходимо продумать собственные рецепты создания историй – точно так же, как делала Сидни из главы 10. Дайте командам примерно час на то, чтобы они разбились на небольшие группы и хорошенько обдумали свои истории. Если вы владелец продукта, UI-дизайнер или бизнес-аналитик, оставайтесь где-то поблизости. Наблюдайте, если хотите. Будьте готовы ответить на вопросы, которые помогут им продвигаться быстрее.

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

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

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

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

Используйте карту историй во время разработки

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

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

Интервал:

Закладка:

Сделать

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

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


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

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

x