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

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

 

Разные люди, разные обсуждения

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

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

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

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

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

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

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

 

Нам понадобится карточка побольше

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

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

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

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

Если я возьму из картотеки карточку, на ней будет ровно столько информации, сколько нужно для поиска книги. Скорее всего, там указаны название, автор, аннотация, количество страниц, жанр – скажем, «научно-популярная литература», – а также код (помните десятичную классификацию Дьюи?), с помощью которого можно найти экземпляр этой книги в хранилище. Карточка – просто символ, который легко хранить и просто найти. Никто не перепутает карточку с книгой. Библиотечная картотека очень удобна, так как занимает намного меньше места, чем тысячи книг. А карточки можно сортировать множеством способов, например по авторам или по темам.

Ваши истории должны работать примерно так же: вы можете записать их на карточках, разместить на большом листе либо занести в свой любимый инструмент для планирования или систему, которую используют все в вашей компании (периодически ругая на все корки). Находясь в библиотеке, вы знаете, что там есть нужная книга, и если нашли в картотеке нужную карточку, то и книгу с легкостью найдете. То же с историями: вы знаете, что у вас есть растущий объем информации. Она развивается и увеличивается с каждым обсуждением. И если в вашей компании хоть сколько-нибудь ценится прозрачность сведений, найти ее тоже будет легко.

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

Как создатели инструментов проводят удачные обсуждения историй

Это мой друг Шериф, который работает в компании под названием Atlassian. Шериф занимается Confluence – популярной вики-системой, используемой огромным количеством организаций для хранения информации, с которой они работают, и управления ею наряду с прочим. Кроме того, они создали JIRA – один из самых популярных инструментов для управления разработкой по методологии Agile. Разумно предположить, что компания, которая специализируется на создании инструментов для электронного хранения информации и управления ею, и сама пользуется своей продукцией – как говорится, «сами ешьте еду своей собаки» [19] , – и в Atlassian это действительно так. Но кроме того, в этой компании понимают, как важны плодотворные обсуждения историй лицом к лицу.

Осматривая офис Atlassian в Сиднее, я видел стены, увешанные стикерами, разрисованными досками и эскизами экранов. Присмотревшись, на стикерах можно было заметить номера задач в системах для управления работой, которыми пользовалась команда. Ребята ловко перемещались от систем к физическому пространству и обратно. Когда Шериф показал мне, как и что они хранят в Confluence, я был поражен сочетанием фотографий, коротких видео, а также множества обсуждений.

 

Борьба и единство радиатора и морозилки

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

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

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

Что на самом деле должно содержаться на карточке истории

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

В общем случае на карточке, скорее всего, будет следующее.

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

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

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

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

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

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

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

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

•  Статус. Запланирована ли история для определенного релиза? Началась ли работа над ней? Идет ли разработка? История завершена?

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

Вы можете делать на карточке любые нужные вам пометки. Можно также перевернуть ее и на другой стороне что-то записать или перечислить критерии приемки.

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

На карточке умещается не так уж много сведений, и это в общем хорошо. Помните: это только символ, который вы применяете для планирования. Вы можете использовать карточки или стикеры. Наличие бумажных карточек упрощает обсуждение: рассказывая, вы можете просто говорить: «вот это» или «то» – и указывать на карточку на столе или на доске. Бумажные карточки можно перемещать по столу, сортировать по важности, развешивать на стенах. Можете размахивать ими во время разговора, чтобы подчеркнуть важность того, что говорите. Если вы попробуете проделать это с увесистым многостраничным документом, то, скорее всего, случайно ударите кого-то, а то и самого себя. И конечно, кучу карточек можно организовать в карту историй, чтобы составлять более длинные и сложные истории.

 

Эта штука здесь не поможет!

 

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

«Эй! – говорит дровосек. – Кажется, у тебя неподходящий инструмент, дружище. Попробуй-ка это!» – и протягивает человеку пилу.

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

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

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

 

Выработка единого понимания

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

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

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

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

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

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

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

 

Запоминание

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

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

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

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

 

Трекинг

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

Это диаграмма объема сделанной работы, сгенерированная с помощью JIRA, – продукта Atlassian. На рисунке хорошо видны работа, которую мы делаем, и изменение ее статуса с течением времени. Делать такой график вручную – очень скучная и трудоемкая работа.

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

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

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

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