Топ за месяц!🔥
Книжки » Книги » Домашняя » Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон 📕 - Книга онлайн бесплатно

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

151
0
На нашем литературном портале можно бесплатно читать книгу Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон полная версия. Жанр: Книги / Домашняя. Онлайн библиотека дает возможность прочитать весь текст произведения на мобильном телефоне или десктопе даже без регистрации и СМС подтверждения на нашем сайте онлайн книг knizki.com.

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 34 35 36 ... 75
Перейти на страницу:
Конец ознакомительного отрывкаКупить и скачать книгу

Ознакомительная версия. Доступно 15 страниц из 75

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

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

Как вновь открыть для себя ценность коротких обсуждений

Мэт Кроппер, ThoughtWorks

Я работал в компании ThoughtWorks бизнес-аналитиком на проекте для правительственного агентства Великобритании. Мы несли ответственность не только за предъявление продукта, но и за обучение команды клиента некоторым практическим приемам методологии Agile. Это было не так-то просто, ведь у нас была большая команда – около 25 технологических или бизнес-специалистов. Представьте себе 25 человек в одной комнате, у каждого свои пожелания о режиме кондиционера, и вы поймете, в какой ситуации мы оказались.

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

«Почему мы должны делать вот так?»

«Эти истории слишком длинные/короткие».

«В этом нет никакого смысла!»

«Я настаиваю, чтобы техническая реализация данного аспекта выполнялась вот так и никак иначе».

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

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

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

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

Шаблонные зомби и снегоочиститель

Термин «шаблонные зомби» впервые появился в книге Тома Де-Марко и его соавторов «Адреналиновые наркоманы и шаблонные зомби: понимание паттернов поведения проектов»[16]. Название говорит само за себя, но я приведу и авторское определение.

«Шаблонный зомби: проектная команда допускает, чтобы работа управлялась шаблонами, а не направляет процесс осознанно, чтобы обеспечить выпуск продукта наилучшим образом».

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

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

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

История может быть историей, даже если она составлена не по шаблону.


Человек на этой фотографии учиться кататься на горных лыжах[17]. Если вы когда-нибудь тоже этому учились и вам помогал инструктор, то вы хорошо знаете, что делает этот человек. Он выполняет прием торможения «плугом» – сводит носки лыж вместе и скользит на внутренних ребрах. Это самый простой способ контролировать скорость и оставаться в вертикальном положении, несмотря на то что к вашим ногам прикреплены две скользкие доски. Это самый лучший прием для начинающих лыжников. Но это не просто самый лучший прием – это самый лучший обучающий прием. В программе соревнований горнолыжников на Олимпийских играх нет упражнения «плуг». Ни один катающийся на склоне горы не будет восхищен вашим великолепным исполнением «плуга». Но, разумеется, стесняться здесь нечего. Видя, что вы катаетесь таким способом, все понимают, что вы новичок и пока учитесь.

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

Ознакомительная версия. Доступно 15 страниц из 75

1 ... 34 35 36 ... 75
Перейти на страницу:

Внимание!

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

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