Ознакомительная версия. Доступно 15 страниц из 75
Three Amigos
¡Three Amigos! – название заурядного вестерна-комедии 1986 года со Стивом Мартином, Чеви Чейзом и Мартином Шортом в главных ролях. Что общего у этого фильма и разработки по методологии Agile, управляемой историями? Там есть тройка ловких и расчетливых героев, что очень здорово для семинаров по историям. Я не знаю, кто первым назвал их тремя амиго, но, кажется, это прозвище ушло в народ[25] (уверен, если бы фильм посмотрело больше людей, этого не произошло бы).
Как вы, должно быть, помните, под семинарами по историям я подразумеваю самые поздние и продуктивные обсуждения, в ходе которых принимаются конкретные решения о том, что нужно создавать. Именно тогда вступают в дело трое амиго.
В течение последних обсуждений нужно предусмотреть множество деталей и вариантов реализации, поэтому нужен разработчик из команды, которая будет писать код, – в идеале один из программистов, который будет непосредственно работать над задачей.
Чтобы маленький фрагмент программы мог считаться законченным, его нужно протестировать, поэтому необходимо, чтобы в беседе участвовал тестировщик. Тестировщик – первый амиго – часто привносит в дискуссию критический взгляд, выявляя то, что в дальнейшем может привести к ошибкам и сбоям. Как правило, тестировщик лучше всех играет в «Что, если».
И конечно, нужен кто-то, понимающий, что, для кого и почему мы делаем, то есть специалист из команды исследования продукта. Этот человек – второй амиго.
На этой стадии, как правило, не происходит представление новой функциональности, это должно было произойти раньше, на этапе исследования. Сейчас мы уже так или иначе решили что-то делать, поэтому очень важно понять, как должна выглядеть программа и как она будет себя вести. По этой причине очень часто к обсуждению привлекают дизайнера пользовательского интерфейса или бизнес-аналитика, который может работать со всеми этими деталями. Это третий амиго.
Эта группа проработает все детали и придет к соглашению относительно конкретных критериев приемки истории. Как правило, на этом обсуждении оценивается время, которое потребуется на разработку и тестирование программы. Часто здесь также принимают решение о разделении истории на небольшие истории для разработки верного размера, то есть такие, на написание кода и тестов которых потребуется от одного до трех дней.
Истории постоянно обсуждают в процессе движения идеи от одной стадии разработки к другой. На каждом обсуждении не выходите за рамки «полезное», «удобное» и «реалистичное». Привлекайте людей, которые могут дать оценку этим факторам. Избегайте «дизайна в комиссии», возлагая на владельца продукта ответственность за удачный и цельный продукт.
Антишаблон «клиент – исполнитель»
Существует вредный антишаблон, который часто мешает хорошей работе пользовательских историй. Фактически его применение может привести к тому, что в результате совместной работы не получится вообще ничего хорошего.
В этом антишаблоне один участник играет роль клиента, а другой – исполнителя. Задача клиента – знать, чего он хочет, и объяснить исполнителю все детали. Это мы называем требованиями. Работа исполнителя – слушать, вникать, а затем продумать технический подход к реализации того, что хочет клиент. После этого исполнитель оценивает трудозатраты, что в сфере разработки программ часто является синонимом обязательства (кстати, этим часто объясняется страх программистов перед необходимостью давать оценки без тщательного анализа).
Конец истории печален и вполне предсказуем.
Изредка, конечно, оценка снайперски точна, клиент получает именно то, что просил, а просил он именно то, что ему было нужно.
Но в большинстве случаев реализация решения занимает больше времени, чем предсказывал исполнитель. Работник, являющийся исполнителем, может приводить любые оправдания, в том числе, что в требованиях, которые ему дали, плохо проработаны детали или просто «требования никуда не годятся». Клиент может жаловаться на неточную оценку, и, кажется, никому не приходит в голову, что это оксюморон. Когда же решение наконец предъявлено и клиент получает то, что просил, он может попробовать полученное и обнаруживает, что это совсем не то, что ему было нужно, намеченной им цели достичь нельзя.
Самое ужасное здесь то, что клиент понимает свою проблему лучше всех, а вот найти ее решение у него получается хуже, чем у других. А исполнитель отлично понимает технологии, и чаще всего только он обладает достаточной квалификацией, чтобы решить проблему, потому что он работает с этими технологиями и знает, как они могут помочь в данном случае. Более того, большинство технических специалистов искренне хотят помочь, им было бы приятно знать, что результаты их труда полезны людям.
Но в антишаблоне «клиент – исполнитель» обсуждение проблем и решений заменено дискуссиями и соглашениями относительно требований. Проигрывают в такой ситуации все.
Одна из целей метода историй – избавиться от этого антишаблона.
Хороший пример отношений, разрушающих этот антишаблон, – отношения многих из нас со своим врачом. Попробуйте явиться в кабинет врача и предъявить ему свои «требования». Перечислите рецепты, которые вам нужно выписать, и процедуры, которые следует назначить. Если у вас хороший врач, он ответит: «Очень интересно, а сейчас расскажите мне, что вас беспокоит».
Я представляю себе диапазон, на одном конце которого слово «официант», а на другом – «врач». Вам нужно стремиться к тому, чтобы ваши рабочие отношения больше напоминали общение врача и пациента, а не официанта и гостя.
Владелец продукта как продюсер
Если ваша организация работает в традиционной манере разработки программного обеспечения, в ней могут не совсем ясно понимать, чем должен заниматься владелец продукта. Например, вы участвуете в разработке критически важных систем для банков. Банк знает, что реальные продукты – это банковские услуги, которые он продает своим клиентам. Если у вас есть сотрудник на должности менеджера продукта, то его работа – отвечать за определенный тип банковского счета или кредитного продукта. Компьютерные системы, которые поддерживают этот тип услуги, всего лишь шестеренки в большом механизме. Зачастую бывает, что одна и так же IT-инфраструктура поддерживает множество различных банковских продуктов. Понятно, что банк не рассматривает эту инфраструктуру как продукт, и, как правило, нет никого, кто может выступать в роли ее владельца.
Ознакомительная версия. Доступно 15 страниц из 75
