2. Масштабирование карт пользовательских историй
Чтобы масштабировать и развернуть процесс, команда тренеров, которая начинала работу, приготовила материалы: шаблоны карт, сделанные в программе Excel, шаблоны для персонажей, стандартную повестку дня семинара, выдержки из документации, а также шпаргалки с описанием метода. Кроме этого, было разработано собственное внутреннее приложение для составления карт пользовательских историй.
Но материалы – это одно, а проведение семинара – совершенно другое. Поэтому мы снова настоятельно рекомендуем привлечь к процессу опытного тренера. Чтобы обеспечить организацию достаточным количеством тренеров, первичная тренерская команда подготовила специалистов. Эти начинающие тренеры провели несколько семинаров под присмотром наставников, помогали на индивидуальных сессиях и наконец были готовы руководить семинаром абсолютно самостоятельно. Мы также проводили семинары и тренировки тренеров в других офисах SAP по всему миру. Чтобы обрести уверенность, что мы учимся друг у друга, и для обмена опытом мы запустили огромную сеть для хранения документации и общения, где тренеры могли опубликовать свои вопросы и полезные практики. И конечно, очень многое мы почерпнули из опыта Джеффа.
Наши усилия по масштабированию пользовательских карт историй в конце концов принесли плоды. Мы провели более 200 семинаров под руководством тренеров в различных офисах во многих местах, и сейчас большинство команд способны продуктивно работать с картами пользовательских историй самостоятельно.
Глава 6. Реальные примеры применения историй
Карты историй – невероятно простая идея. Применяя простую карту, вы можете работать с другими людьми, чтобы изложить историю использования продукта и увидеть результат своей работы в целом. Затем вы дробите эту цельную картину на части, чтобы правильно распланировать разработку. Основу всего составляет простая концепция историй в Agile.
Убийственно простая идея Кента
Изначальная идея историй принадлежит невероятно умному парню по имени Кент Бек. В конце 1990-х Кент и его коллеги работали в области разработки программного обеспечения. Кент обратил внимание на то, что одна из крупнейших проблем в разработке программ берет свое начало из традиционной работы с бумажными документами, где подробно описано, чего мы хотим, – их принято называть требованиями. К настоящему моменту вы уже знаете, что с ними не так: разные люди могут читать один и тот же документ и понимать его совершенно по-разному. Они могут даже подписаться под этим документом, свидетельствуя, что пришли к соглашению.
Лишь позднее, когда мы погружаемся в глубину разработки программы – или даже еще немного позднее, когда она предъявлена пользователям, – выясняется, что на самом деле мы думали не об одном и том же. И конечно, большинство людей объясняют отсутствие общего понимания неудачными требованиями.
Давайте задержимся здесь на минуту. Я имел удовольствие работать с множеством команд. Очень часто работа начиналась с обсуждения наших самых больших затруднений. И разумеется, чаще всего я первым делом узнавал о «неудачных требованиях». Каждый тычет пальцем в этот несчастный документ. Автор документа готов сгореть со стыда – наверняка он должен был написать больше или меньше либо, может быть, использовать какие-то новейшие техники составления документации. Те, кто подписал этот документ, ощущают себя не лучше и поэтому занимают оборонительную позицию: «Вы что, ожидали, что я вчитаюсь в каждую деталь? В конце концов мы обсуждали это целыми днями! Я думал, вы поняли, что я сказал. Я вообще не понимаю, откуда взялся этот дурацкий документ!» А те, кто работал над самим программным продуктом, и вовсе сбиты с толку – они выполнили свою задачу, руководствуясь этим злосчастным документом, но оказалось, что все по-прежнему неправильно. В общем, все хотят отправить эти бумаги в печку и немедленно написать новую, лучшую документацию.
Мы оба можем прочитать один и тот же документ, но понять его по-разному.
Но разное понимание документа – это лишь половина проблемы. Мы тратим уйму денег и времени, воплощая в жизнь то, что описывает этот документ, и все только для того, чтобы позднее обнаружить: для решения изначально поставленной задачи нужно совершенно иное. Да, вы поняли меня правильно – все эти документы, как правило, содержат совершенно неверные вещи. Документы обычно описывают то, что нам нужно, но не почему оно нужно. Если некто работающий над программным продуктом может просто поговорить с кем-либо, кто хорошо разбирается в будущих пользователях этого продукта и мотивах их работы с продуктом, чаще всего он найдет гораздо более эффективный и экономичный способ удовлетворить этих пользователей. Не нужно уточнять, что чаще всего у нас попросту нет такой информации.
Лучшие решения – результат сотрудничества между людьми, у которых есть какие-то проблемы, и другими людьми, которые могут их решить.
Простая идея Кента заключалась в том, чтобы прекратить это – перестать тратить силы на написание идеальной документации, а вместо этого собираться вместе и рассказывать истории. Истории получили свое название не потому, что их нужно было записывать, а из-за того, как они должны были использоваться. Разрешите мне подчеркнуть это еще раз для закрепления. Прямо сейчас отложите все дела и громко прочитайте вслух.
Название «истории» произошло от того, как они должны использоваться, а не из-за того, что вы должны их записывать.
Идея Кента очень проста. Если мы соберемся вместе и обсудим проблему, которую решаем с помощью программного продукта, а также поговорим о том, для кого и почему мы это делаем, то в конце концов придем к решению и выстроим одинаковое понимание.
Просто – не значит легко
Некоторое время назад я стал замечать, что развитие работы с историями ушло немного в сторону: множество людей пишут книги, преподают и используют эту технику, концентрируясь на написании историй. Если бы я получал десять центов каждый раз, когда меня спрашивают, как писать хорошие истории, десятицентовиков у меня было бы больше, чем в той куче, которую я упомянул несколькими главами ранее.
Поскольку все вокруг говорили только о написании историй, мне пришлось задать Кенту вопрос: не пропустил ли я чего? Во время длинного обсуждения по электронной почте Кент объяснил мне происхождение идеи: «Я хотел развить известную ситуацию, когда пользователи сами излагают истории работы крутых функций, которые умеет выполнять их рабочая программа. [Например,] когда я впечатываю в поле почтовый индекс, а программа автоматически заполняет город и штат, мне не приходится нажимать ни одной кнопки.
Я думаю, именно этот пример натолкнул меня на мысль. Если вы можете рассказывать истории о том, что делает программа, вызывая интерес и живой отклик у слушателя, почему же не рассказать эти истории еще до того, как программа сможет это делать?» (Кент Бек в личной переписке, август 2010 года).
