В конце концов все-таки приходится принять несколько решений, чтобы продвинуться вперед и что-то построить или не построить. Эту ситуацию можно сравнить с решением о покупке товара, не имеющего ярлычка с ценой.
В мире программного обеспечения понятие стоимости в первую очередь связано с временем, которое потребуется на написание кода. На ранних этапах вполне допустимо использовать понятия «очень долго» или «пару дней». Еще лучше сравнить то, что вы обсуждаете, с чем-то уже законченным: «Это похоже на те улучшения для комментариев, которые мы реализовали в прошлом месяце». По мере того как мы все ближе подбираемся к началу разработки, все дольше обсуждаем и принимаем все больше решений, оценки трудозатрат должны становиться все более точными. Но не забывайте: в любом случае мы говорим лишь об оценках, а не об обязательствах.
Сделайте «фото из отпуска»
Поскольку нужно очень многое обсудить и хорошо бы ничего не забыть, убедитесь: вы записали самое важное, что позволит позднее припомнить принятые решения, а также вопросы и предположения, в которых следует хорошенько разобраться. Не забудьте озвучивать ход своих мыслей, чтобы и все остальные понимали, что записывается.
Если вы пишете на бумаге, прихватите ее с собой и заглядывайте в нее позднее. Если записи сделаны на стене, можно просто обращаться к ним по мере надобности. Кроме того, если вы общаетесь как настоящая команда, то обнаружите, что вам не нужно беспрестанно все повторять. Люди и так будут помнить подробности обсуждения, особенно если вы сопровождали его документами и простыми рисунками… теми самыми «фото из отпуска».
Эта небольшая группа сейчас обсуждает историю. По мере обсуждения они визуализируют свои идеи и делают заметки о решениях.
Мой любимый подход именно такой. Я делаю записи на большом листе бумаги или доске прямо во время разговора. Я люблю сделать прямо на доске пометку о том, кто присутствовал на обсуждении, а затем фотографирую свои записи. Затем любым способом отправляю фото всем присутствующим. Я хорошо знаю, что в любую минуту могу припомнить детали или записать их более формально, если вдруг понадобится. Если у меня не получится точно припомнить, что было сказано, наверняка это вспомнит другой участник обсуждения: я всегда знал, что записывать имена участников – хорошая идея.
Придется о многом позаботиться
Да, обсуждение истории включает в себя множество составляющих, и это может немного пугать. В этот момент вы, возможно, с тоской вспоминаете старые добрые времена, когда все, что вам нужно было, – это правильно понять требования, и хотите вернуться туда, где вам не приходилось по-настоящему решать задачи. Вы просто должны были создать, что сказано, а о том, правильны ли инструкции, заботился кто-то другой. Но я уверен, что на самом деле и вам, и почти всем прочим людям нравится решать проблемы. Так что это ваш шанс.
Возможно, обсудив все, о чем мы здесь говорили, вы получите огромный объем информации, которую необходимо хранить и отслеживать, а на стикеры или карточки она никак не помещается. Все в порядке. Так и должно быть. Давайте поговорим о том, что необходимо писать на карточке, а чем можно пренебречь.
Глава 8. Не бросайте на карту всё
Да, короткие заголовки историй на карточках помогут вам запланировать и провести множество обсуждений между людьми, которые умеют писать программы, и людьми, которые разбираются в проблемах, для решения которых предназначаются программы. Но, к сожалению, выпуск полностью готового программного продукта требует участия гораздо большего количества людей.
В обычной команде вы, скорее всего, увидите менеджеров проекта, менеджеров продукта, бизнес-аналитиков, тестировщиков, специалистов по пользовательскому взаимодействию, технических писателей и многих других, о которых я наверняка забыл. Все они могут рассматривать одни и те же карточки, но обсуждения будут различаться, так как эти люди отвечают за решение различных проблем.
Разные люди, разные обсуждения
Если я владелец или менеджер продукта и отвечаю за его успех, мне нужно немного больше, чем другим, знать о целевой аудитории. Мне нужно сформулировать гипотезы о том, как много людей купят или будут использовать этот продукт или как это повлияет на прибыль моей компании. И говорить я хочу об этом.
Если я бизнес-аналитик, я должен погрузиться в море деталей, понять, как должен выглядеть пользовательский интерфейс, а также вникнуть в бизнес-правила компании, которые лежат в его основе.
Если я тестировщик, мне нужно думать о том, в каком случае продукт может дать сбой. Я хотел бы обсудить, что мне нужно учесть при составлении плана тестов.
Если я дизайнер UI, я хочу слушать о том, как должен выглядеть графический интерфейс, не больше, чем разработчик – о том, как должен быть написан код. Мне надо знать, кто будет пользоваться этим интерфейсом, что и почему делают эти люди, в результате чего я смогу создать эффективный и удобный пользовательский интерфейс.
И наконец, если я менеджер проекта, ответственный за координацию действий специалистов, мне нужно уделить внимание всем, поучаствовать во всех обсуждениях, чтобы быть в курсе деталей. Мне нужно учесть зависимости, график и статус разработки, когда она начнется.
Как много обсуждений! Некоторые из них должны пройти раньше остальных. Многие будут повторяться больше одного раза. Поэтому, чтобы быть точными, мы должны добавить еще несколько дюжин «П» к нашим трем «П». Но, к счастью, если вы постараетесь и проведете действительно предметные обсуждения, чтобы по ходу дела родилось одинаковое понимание, то избежите множества недоразумений и корректировок.
Каждую историю придется обсуждать с разными людьми и с разных точек зрения.
Нам понадобится карточка побольше
Я надеюсь, что, читая заголовок, вы вспомнили старый фильм «Челюсти», где, впервые увидев приближающуюся огромную акулу-людоеда, шериф Броуди говорит Квинту: «Кажется, вам понадобится лодка побольше».
Как видите, изначальная идея все та же: я могу взять карточку и написать на одной стороне название. После обсуждения я переворачиваю ее и записываю все детали, наши решения и соглашения, к которым мы пришли. Я могу набросать там же пользовательский интерфейс и разместить много другой информации. На некоторых проектах это и в самом деле может работать. Здорово, если и у вас получится, но, как правило, так бывает в маленьких командах, члены которых тесно связаны друг с другом, а информация известна всем. В таких командах не приходится много записывать, чтобы помнить.
Но я не думаю, что даже Кент и его ребята, которые впервые сформулировали концепцию историй, действительно предполагали, что материалы всех обсуждений, куда вовлечено столько людей, могут храниться на единственной карточке. Такого, как правило, не бывает.
Метафора, которую я хорошо воспринимаю: карточка в библиотечной картотеке (впрочем, если вы не настолько стары, чтобы застать времена, когда в библиотеках были настоящие картотеки, вам не удастся ее оценить). Истории, записанные на карточках, работают примерно так же.
Если я возьму из картотеки карточку, на ней будет ровно столько информации, сколько нужно для поиска книги. Скорее всего, там указаны название, автор, аннотация, количество страниц, жанр – скажем, «научно-популярная литература», – а также код (помните десятичную классификацию Дьюи?[18]), с помощью которого можно найти экземпляр этой книги в хранилище. Карточка – просто символ, который легко хранить и просто найти. Никто не перепутает карточку с книгой. Библиотечная картотека очень удобна, так как занимает намного меньше места, чем тысячи книг. А карточки можно сортировать множеством способов, например по авторам или по темам.
Ваши истории должны работать примерно так же: вы можете записать их на карточках, разместить на большом листе либо занести в свой любимый инструмент для планирования или систему, которую используют все в вашей компании (периодически ругая на все корки). Находясь в библиотеке, вы знаете, что там есть нужная книга, и если нашли в картотеке нужную карточку, то и книгу с легкостью найдете. То же с историями: вы знаете, что у вас есть растущий объем информации. Она развивается и увеличивается с каждым обсуждением. И если в вашей компании хоть сколько-нибудь ценится прозрачность сведений, найти ее тоже будет легко.
Если же вы истинный консерватор, то можете хранить подробности всех обсуждений на больших листах бумаги, развешанных на стене, так что обсуждение можно продолжить в любой момент. Но помните: однажды придется снять их, если вы закончите работу или место на стене закончится. Поэтому не забудьте сфотографировать листы и сохранить снимки на будущее.
Это мой друг Шериф, который работает в компании под названием Atlassian. Шериф занимается Confluence – популярной вики-системой, используемой огромным количеством организаций для хранения информации, с которой они работают, и управления ею наряду с прочим. Кроме того, они создали JIRA – один из самых популярных инструментов для управления разработкой по методологии Agile. Разумно предположить, что компания, которая специализируется на создании инструментов для электронного хранения информации и управления ею, и сама пользуется своей продукцией – как говорится, «сами ешьте еду своей собаки»[19], – и в Atlassian это действительно так. Но кроме того, в этой компании понимают, как важны плодотворные обсуждения историй лицом к лицу.
Осматривая офис Atlassian в Сиднее, я видел стены, увешанные стикерами, разрисованными досками и эскизами экранов. Присмотревшись, на стикерах можно было заметить номера задач в системах для управления работой, которыми пользовалась команда. Ребята ловко перемещались от систем к физическому пространству и обратно. Когда Шериф показ