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

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

Следите за результатами своей работы

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

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

Говоря о качестве, я начинаю дискуссию с трех аспектов.

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

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

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

У меня для вас плохая новость: скорее всего, найдется довольно много вещей, которые можно было бы сделать лучше.

Чтобы все были спокойны, стоит четко разделять два соображения. Первое: сделали ли мы то, что договорились сделать? Второе: если мы видим именно то, что договорились сделать, нужно ли внести какие-то изменения?

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

В этот момент у меня в голове начинает звучать старая песня Rolling Stones. Если вы ее знаете, подпевайте: «You can’t always get what you want. But, if you try sometime, you just might find, you get what you need…»[21] Какая ирония – в мире программного обеспечения все происходит ровно наоборот.

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

Во всяком случае у вас есть возможность что-то исправить. А начать исправление нужно, записав на карточках свои мысли о том, что нужно изменить в программном продукте, чтобы довести его до совершенства. Конечно, все это очень обидно, ведь вы рассчитывали получить хороший результат с первого раза. Но, может быть, Мик Джаггер и прав. Возможно, на самом деле вам нужно было понять, что надеяться оказаться правым с первого раза довольно опрометчиво. Особенно в разработке программного обеспечения.

Это не для вас

Простите меня. Я припас для вас еще немного новостей – снова плохих.

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

Не обманывайте себя.

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

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

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

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

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

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

Разрабатывайте, чтобы изучать

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