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

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

 

Оцените свою командную работу

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

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

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

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

Рецепт командного осмысления и оценки продукта

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

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

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

На семинаре необходимо уделить внимание трем темам: продукту, плану и процессу .

Продукт

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

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

•  Обсудите качество пользовательского взаимодействия . Не только то, как выглядит графический интерфейс, но и то, насколько комфортна работа с продуктом. Соответствует ли качество вашим ожиданиям? Оцените свою работу по пятибалльной шкале (5 – высшая оценка).

•  Обсудите функциональное качество . Прошло ли тестирование гладко, или обнаружилось много багов? Тестировщики обнаружили больше багов, потому что добавилось больше кода или потому, что получили больше времени на тестирование? Оцените свою работу по пятибалльной шкале (5 – высшая оценка).

•  Обсудите качество кода . Код, который вы написали, будет легко расширять и поддерживать? Или вы просто написали очередную порцию унаследованного кода? Оцените свою работу по пятибалльной шкале (5 – высшая оценка).

Запишите истории для исправления проблем качества, обнаружившихся в вашем продукте.

Если вы участвуете как в работе по исследованиям, так и в реализации (как и должно быть), обсудите свою исследовательскую работу в последнем цикле. Что вы делали? Что нового узнали?

План

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

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

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

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

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

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

Процесс

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Достаточно

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

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

 Бизнес-партнеры. Для них может быть достаточно добавления функциональности, критической с точки зрения привлечения новых заказчиков. Или, возможно, им достаточно полученных вами сведений о деталях, которые обязательно нужно включить в эту функциональность для обеспечения конкурентоспособности.

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

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

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

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

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

 

Учитесь у пользователей

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

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

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

 

Извлекайте уроки из пользовательских релизов

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

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

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

• встраивать в продукт показатели, которые позволят вам отслеживать использование новых функциональностей;

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

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

 

Результаты по расписанию

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

А сейчас я должен напомнить вам несколько горьких истин о разработке программного обеспечения.

Программное обеспечение никогда не бывает законченным.

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

Результаты всегда непредсказуемы.

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

Улучшения, внесенные после релиза, самые ценные.

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

 

Используйте карты для оценки готовности релиза

Вы продвигаете свой продукт к релизу – историю за историей. Как только намеченная вами дата релиза начинает угрожающе приближаться (а такая дата есть всегда), задайтесь вопросом о каждой основной пользовательской линии действий: «Если бы нужно было выпустить продукт прямо сейчас, какую оценку мы бы поставили сами себе?» Если вы используете буквенные оценки вроде тех, что приносят из школы мои дети, то в конце концов получите целый табель для своего продукта.

Например, если у вас продукт или функциональность с пятью основными линиями действий пользователей, а в табеле написано: A, A-, B+, D, B+, то, разумеется, за оставшиеся до релиза недели вам следует сосредоточиться на той части, которая получила оценку D. Если в конце релиза вы получаете только А и В, это довольно хорошо. Конечно, быть круглым отличником лучше, но уложиться в срок в мире разработки гораздо важнее.

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

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