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

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

Это подходящий момент, чтобы поздравить друг друга с отличной работой. Очень здорово видеть реальный прогресс. В традиционном подходе к разработке программного обеспечения возможность увидеть результаты тяжелой работы предоставляется куда реже и, как правило, не всегда доходит до команды. В типичном процессе 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] Какая ирония – в мире программного обеспечения все происходит ровно наоборот.

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

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