Пользовательские истории. Искусство гибкой разработки ПО - [81]
Схема коммуникации изменилась. Никола больше не работала «испорченным телефоном» между бизнесом и IT – теперь она выступала координатором обсуждений между теми, кто понимал цели бизнеса, теми, кто хорошо знал нужды пользователей, и командой разработки, которая знала, что можно реализовать.
И представителям бизнеса, и команде разработки очень понравился новый формат, все они активно включились в процесс. Наконец удалось достичь одинакового понимания проблем, требующих решения, различные точки зрения, существовавшие в группе, позволили команде найти оптимальные решения в условиях ограничений, а Никола уже не чувствовала такого сильного давления и больше времени посвящала работе. Никола наконец ощутила себя своей!
В толпе не может быть сотрудничества
Утомительные совещания по планированию – такая распространенная проблема, что многие команды интуитивно предпочитают проводить обсуждения историй в дни, предшествующие таким совещаниям. Как правило, такие обсуждения занесены в их ежедневники как «совещания по предпланированию», «окончательная обработка бэклога» или «лакировка бэклога». Но что происходит чаще всего? Та самая тягомотина, которую они так ненавидят на планировании, просто переносится на другой день. Словно пытаясь усугубить проблему, членов команды просят прервать их текущую продуктивную работу, чтобы посидеть на скучном совещании. Неудивительно, что никто не испытывает восторга по этому поводу.
Проблема не в том, что обсуждать истории очень сложно. Да, иногда это может вызывать трудности, но абсолютно любые обсуждения станут гораздо тяжелее, если вы попытаетесь привлечь к ним слишком много людей. Если к тому же большая часть этих людей не заинтересована в участии или не мотивирована, считайте, что дело провалено. Вы знаете, о ком я говорю, – эти люди надеются, что никто не замечает их смартфоны, на которых они играют под столом.
Позвольте членам команды самим решать, хотят ли они участвовать в обсуждении. Если позднее они будут жаловаться на принятые решения, просто не забудьте пригласить их в следующий раз.
Если хотят участвовать все, попробуйте шаблон сотрудничества «Аквариум», описанный в следующем примере. В этом случае заинтересованные могут прийти, принять участие, если хотят, или уйти, если обнаружат, что не происходит ничего интересного.
Если среди ваших сотрудников найдется несколько человек, которые очень хотят, чтобы их пригласили на обсуждение, но количество участников и без того так велико, что под угрозу поставлена продуктивность, попробуйте шаблон сотрудничества «Аквариум». Он заключается в том, чтобы дать им возможность присутствовать, не участвуя активно или минимально влияя на окончательный результат. Чаще всего люди обнаруживают, что происходящее не настолько важно, как они ожидали. Спустя какое-то время вы и сами заметите, что они охотно предоставляют другим возможность обсуждать детали, а затем узнают результаты из последующих обсуждений.
Процесс происходит так: от трех до пяти человек работают вместе у доски. Это значит, что они в аквариуме.
Другие находящиеся в комнате могут наблюдать за ними и слушать, но не говорить. Они – вне аквариума.
Если кто-то находящийся вне аквариума хочет принять участие, он может «нырнуть». Но когда один человек заходит извне, кто-то изнутри должен «вынырнуть».
Таким образом обсуждение остается компактным и продуктивным, все информированы и включены в процесс. Кроме того, это хороший способ обучения: новички включаются в процесс, не замедляя его скорости.
Важность компактности
Помните обсуждение торта и капкейков из главы 10? Сейчас как раз настало время разбить наши торты на капкейки наименьшего размера из возможных. Именно сейчас, когда присутствуют разработчики, тестировщики и другие специалисты, непосредственно участвующие в создании программного продукта, можно по-настоящему взяться за разделение истории на части.
Надеюсь, вы знаете, что корень слова software (программное обеспечение), soft, означает «мягкий». Это значение не ограничивается тем, что мы подразумеваем, говоря о губках или булочках. Лучше подойдет ассоциация с большим документом или книгой. Если бы вы писали книгу, как стараюсь делать сейчас я, вы бы не пытались сделать все за один раз. Вы бы написали, допустим, главу в один присест. Я, например, пишу за раз одну главу, а Питер, опытный и доброжелательный редактор, с которым я сотрудничаю, просматривает ее, делая необходимые предложения и поправки.
Но это не значит, что глава готова. До этого еще далеко.
Мне нужно вернуться к ней снова и подумать, где в тексте должны быть иллюстрации. Я должен решить, стоит ли добавить сноски, ссылки, объяснения терминов из глоссария или элементы указателя. Затем другие редакторы издательства проходятся по всем главам, внося финальные правки. Получается, что я разделяю работу, делая ее итерационно, и таким образом вижу, как книга постепенно обретает форму.
Сейчас вы читаете главу «Огранка, полировка, разработка». Если так, то, видимо, это значит, что мой тортик успешно испекся. Если бы я решил позаботиться о финальных критериях приемки, то, наверное, сформулировал бы такие.
