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

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

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

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

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

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

Мысль – запись – объяснение – место

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

• Какие новые продукты вы можете создать. • Какие функции добавить в существующий продукт. • Как улучшить создаваемые продукты.

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

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