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

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

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

Шрифт:

-
+

Интервал:

-
+

Закладка:

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

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

Означает ли это, что владельцы продукты или UI-дизайнеры проверили полученный результат?

• Общее количество историй, которые вы считаете сделанными, – это ваша производительность.

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

• Обсудите количество времени, выделенное для исследовательской работы. Использовали ли вы его полностью? Понадобилось ли больше, чем было запланировано? Если потрачено очень мало, это может позднее выйти вам боком, когда вы окажетесь не готовы к разработке и не будете достаточно уверены в правильности выбранного направления. А превышение запланированного времени просто-напросто грозит тем, что вы не уложитесь в сроки разработки.

Процесс

Обсудите, как протекала ваша работа в последнем цикле разработки. Можете ли вы внести какие-то изменения в свою манеру работы, которые изменят качество к лучшему, сделают ваши оценки времени более точными или хотя бы сделают ежедневную работу веселей? Я серьезно: если вы получаете от своей работы удовольствие, честное слово, ваша эффективность растет[32].

• Начните с обсуждения изменений, которые вы запланировали в прошлом цикле. Сработали ли они? Хотите ли вы сохранить их или отменить?

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

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

Оцените свою работу с помощью других сотрудников организации

После того как команда вынесла справедливую оценку своей работе, расширьте аудиторию и включите туда всех заинтересованных из вашей организации. Эти люди должны получить представление о дискуссиях, которые вы провели в рамках команды, и компромиссах, на которые пошли. Помните: с точки зрения законченного продукта те истории, которые вы воплотили в работающее программное обеспечение, – лишь маленькие камушки. Люди, не входящие в команду, могут ожидать продукта с большей степенью готовности. Они, скорее всего, укажут на что-то пропущенное, потому что не участвовали в сессиях планирования и не знают, что вы решили отложить эти аспекты на более позднее время. Будьте готовы к этому. Объясните им, как те фрагменты, что вы сделали, встраиваются в большой план. Проведите все это на сессии оценки заинтересованных сторон.

Рецепт оценки продукта заинтересованными сторонами

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

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

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

Необходимо рассмотреть информацию в двух категориях: исследовательская работа, в которую вы были вовлечены, а также истории, которые реализовали.

Оценка исследовательской работы

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

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

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

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

Оцените разработку

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

Оцените работу по предъявлению продукта, которую вы завершили на уровне «решение за решением». В данном случае вы должны думать о минимально жизнеспособном решении, как о большом камне, что больше соответствует видению партнеров.

Для каждого решения

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

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

Обсудите истории в целом. Если вы следуете стратегии наподобие «Моны Лизы», придется объяснить партнерам, почему программный продукт пока что выглядит незаконченным. Помните: возможно, ваши собеседники предпочли бы увидеть квадратный дюйм законченного портрета, а не набросок во весь холст в эквиваленте программного обеспечения.

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

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

1 ... 71 72 73 ... 75
Перейти на страницу:

Внимание!

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

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