Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон Страница 37
Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон читать онлайн бесплатно
Поскольку нужно очень многое обсудить и хорошо бы ничего не забыть, убедитесь: вы записали самое важное, что позволит позднее припомнить принятые решения, а также вопросы и предположения, в которых следует хорошенько разобраться. Не забудьте озвучивать ход своих мыслей, чтобы и все остальные понимали, что записывается.
Если вы пишете на бумаге, прихватите ее с собой и заглядывайте в нее позднее. Если записи сделаны на стене, можно просто обращаться к ним по мере надобности. Кроме того, если вы общаетесь как настоящая команда, то обнаружите, что вам не нужно беспрестанно все повторять. Люди и так будут помнить подробности обсуждения, особенно если вы сопровождали его документами и простыми рисунками… теми самыми «фото из отпуска».
Эта небольшая группа сейчас обсуждает историю. По мере обсуждения они визуализируют свои идеи и делают заметки о решениях.
Мой любимый подход именно такой. Я делаю записи на большом листе бумаги или доске прямо во время разговора. Я люблю сделать прямо на доске пометку о том, кто присутствовал на обсуждении, а затем фотографирую свои записи. Затем любым способом отправляю фото всем присутствующим. Я хорошо знаю, что в любую минуту могу припомнить детали или записать их более формально, если вдруг понадобится. Если у меня не получится точно припомнить, что было сказано, наверняка это вспомнит другой участник обсуждения: я всегда знал, что записывать имена участников – хорошая идея.
Да, обсуждение истории включает в себя множество составляющих, и это может немного пугать. В этот момент вы, возможно, с тоской вспоминаете старые добрые времена, когда все, что вам нужно было, – это правильно понять требования, и хотите вернуться туда, где вам не приходилось по-настоящему решать задачи. Вы просто должны были создать, что сказано, а о том, правильны ли инструкции, заботился кто-то другой. Но я уверен, что на самом деле и вам, и почти всем прочим людям нравится решать проблемы. Так что это ваш шанс.
Возможно, обсудив все, о чем мы здесь говорили, вы получите огромный объем информации, которую необходимо хранить и отслеживать, а на стикеры или карточки она никак не помещается. Все в порядке. Так и должно быть. Давайте поговорим о том, что необходимо писать на карточке, а чем можно пренебречь.
Да, короткие заголовки историй на карточках помогут вам запланировать и провести множество обсуждений между людьми, которые умеют писать программы, и людьми, которые разбираются в проблемах, для решения которых предназначаются программы. Но, к сожалению, выпуск полностью готового программного продукта требует участия гораздо большего количества людей.
В обычной команде вы, скорее всего, увидите менеджеров проекта, менеджеров продукта, бизнес-аналитиков, тестировщиков, специалистов по пользовательскому взаимодействию, технических писателей и многих других, о которых я наверняка забыл. Все они могут рассматривать одни и те же карточки, но обсуждения будут различаться, так как эти люди отвечают за решение различных проблем.
Если я владелец или менеджер продукта и отвечаю за его успех, мне нужно немного больше, чем другим, знать о целевой аудитории. Мне нужно сформулировать гипотезы о том, как много людей купят или будут использовать этот продукт или как это повлияет на прибыль моей компании. И говорить я хочу об этом.
Если я бизнес-аналитик, я должен погрузиться в море деталей, понять, как должен выглядеть пользовательский интерфейс, а также вникнуть в бизнес-правила компании, которые лежат в его основе.
Если я тестировщик, мне нужно думать о том, в каком случае продукт может дать сбой. Я хотел бы обсудить, что мне нужно учесть при составлении плана тестов.
Если я дизайнер UI, я хочу слушать о том, как должен выглядеть графический интерфейс, не больше, чем разработчик – о том, как должен быть написан код. Мне надо знать, кто будет пользоваться этим интерфейсом, что и почему делают эти люди, в результате чего я смогу создать эффективный и удобный пользовательский интерфейс.
И наконец, если я менеджер проекта, ответственный за координацию действий специалистов, мне нужно уделить внимание всем, поучаствовать во всех обсуждениях, чтобы быть в курсе деталей. Мне нужно учесть зависимости, график и статус разработки, когда она начнется.
Как много обсуждений! Некоторые из них должны пройти раньше остальных. Многие будут повторяться больше одного раза. Поэтому, чтобы быть точными, мы должны добавить еще несколько дюжин «П» к нашим трем «П». Но, к счастью, если вы постараетесь и проведете действительно предметные обсуждения, чтобы по ходу дела родилось одинаковое понимание, то избежите множества недоразумений и корректировок.
Каждую историю придется обсуждать с разными людьми и с разных точек зрения.
Я надеюсь, что, читая заголовок, вы вспомнили старый фильм «Челюсти», где, впервые увидев приближающуюся огромную акулу-людоеда, шериф Броуди говорит Квинту: «Кажется, вам понадобится лодка побольше».
Как видите, изначальная идея все та же: я могу взять карточку и написать на одной стороне название. После обсуждения я переворачиваю ее и записываю все детали, наши решения и соглашения, к которым мы пришли. Я могу набросать там же пользовательский интерфейс и разместить много другой информации. На некоторых проектах это и в самом деле может работать. Здорово, если и у вас получится, но, как правило, так бывает в маленьких командах, члены которых тесно связаны друг с другом, а информация известна всем. В таких командах не приходится много записывать, чтобы помнить.
Но я не думаю, что даже Кент и его ребята, которые впервые сформулировали концепцию историй, действительно предполагали, что материалы всех обсуждений, куда вовлечено столько людей, могут храниться на единственной карточке. Такого, как правило, не бывает.
Метафора, которую я хорошо воспринимаю: карточка в библиотечной картотеке (впрочем, если вы не настолько стары, чтобы застать времена, когда в библиотеках были настоящие картотеки, вам не удастся ее оценить). Истории, записанные на карточках, работают примерно так же.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Comments