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

Поделиться информацией об истории чрезвычайно легко. Любой, кто хорошо понимает историю и ориентируется в информации о ней, с легкостью перескажет ее другому человеку, который хочет ее узнать. Сейчас дело пойдет куда проще, чем на первых обсуждениях, где вам приходилось принимать основополагающие решения (которые, как вы надеетесь, не придется менять позднее). Используйте имеющиеся у вас записи для изложения истории. Рассказывая, указывайте на иллюстрации. Поощряйте вашего слушателя задавать вопросы и вносите изменения в рисунки – это облегчает запоминание. Помогите этому человеку создать свое собственное «отпускное фото» на основе имеющейся информации об истории.

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

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

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

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

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

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

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

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

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

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

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

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

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