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

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

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

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

И конечно, нужен кто-то, понимающий, что, для кого и почему мы делаем, то есть специалист из команды исследования продукта. Этот человек – второй амиго.

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

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

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

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

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

Конец истории печален и вполне предсказуем.

Изредка, конечно, оценка снайперски точна, клиент получает именно то, что просил, а просил он именно то, что ему было нужно.

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

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