Наши три «П» только начало.

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

Если мы закончим цикл, модель будет выглядеть так, как на стр. 158.

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

 

Разрабатывайте, держа в голове ясную картину

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

• Программисты могут начать писать код.

• Тестировщики – составить план тестирования и начать его выполнять.

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

• Технические писатели – написать или обновить файлы справки, а также другие текстовые документы.

Самое важное здесь, чтобы все эти люди держали в голове одну и ту же картину, которую они создали, разговаривая друг с другом.

Здесь я хочу сделать паузу. Подумайте об этом.

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

Передача всех подробностей истории кому-то еще для реализации не работает. Не делайте этого.

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

 

Заложите традицию устного рассказа

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

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

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

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

 

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

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

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

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

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

 

Это не для вас

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

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

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

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

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

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

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

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

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

 

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

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

Гуру разработки Agile, уже упоминавшийся здесь мой друг Алистер Коберн, однажды сказал мне: «В бэклог историй нужно отправлять не одну написанную тобой историю, а три».

На мой вопрос «Почему?» он ответил: «Просто делай это».

«Что же мне писать в двух других историях?» – спросил я.

«Не имеет никакого значения».

«Что ты имеешь в виду? – удивился я. – Мне же нужно там что-то написать!»

«Ну хорошо, – сказал Алистер, – если тебе так уж нужно, запиши то, что хочешь разработать, на первой карточке, а на второй напиши: “Исправить первую карточку”. Потом на третьей – “Исправить вторую”. Если ты не пройдешь этот цикл трижды для каждой истории, то никогда ничему не научишься».

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

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

Стратегия Моны Лизы, использованная Майком и Аароном из главы 4, помогла им разделить каждую историю на маленькие компактные части, которые, правда, нельзя было представить пользователям, но они позволяли ребятам обучаться быстрее и управлять бюджетом разработки, в результате чего работа была завершена вовремя.

Это две замечательные стратегии обучения. Попробуйте их. Изобретите собственную. Только, пожалуйста, не думайте, что вы правы всегда и во всем! Уверяю, вас ждет великое разочарование.

 

Не только программы

В 2011 году Кент Бек – создатель метода историй – начал одну из первых конференций Lean Startup с пересмотра манифеста Agile. Будь на его месте, например, я, это было бы, пожалуй, святотатством; но Кент, один из авторов манифеста, знал, что делает. Он пересмотрел принцип, касающийся работающего ПО, и отныне он читается так: «Эмпирическое обучение важнее работающего продукта».

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

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

Попробуйте метод историй для организации любой работы независимо от того, касается она разработки программных продуктов или нет.

 

Планируйте изучение и учитесь планировать

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