Никаких заданий. Нам нужны истории и факты

⇐ ПредыдущаяСтр 6 из 13Следующая ⇒

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

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

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

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

Затем надо обратить внимание на то, что мы хотим сделать в первую очередь. Обычно это лишь часть работы, с которой мы начинаем наш процесс и на которой всегда можем его остановить, хотя по плану (или по списку) таких частей много и, конечно, мы должны следовать всему процессу.

Наконец, нужно подумать о мотивах. Почему выбранный нами персонаж хочет эту вещь? Как она будет ему служить, чем будет радовать его как потребителя? Определенно, этот момент оказывается ключевым. Личная заинтересованность придает колорит всему.

Мой любимый пример связан с интернет‑ мемом, который был популярен несколько лет назад. Это картинка с изображением капитана Жана‑ Люка Пикара[37]в знаменитом звездолете «Энтерпрайз» с подписью: «Как капитан космического корабля я хотел бы, чтобы в бортовом журнале автоматически использовалась сегодняшняя звездная дата…» Это высказывание приобретает некий смысл, только если задуматься. Вас никогда не удивляло, что в далеком будущем капитану космического корабля приходится в ручном режиме вводить дату, когда он заполняет бортовой журнал? «Дневник капитана. Звездная дата 4671.7. Планета Марс так хорошо смотрится с орбиты…» Даже нам не приходится делать так, когда мы оставляем запись у себя в блоге. Так почему же это делает он? Но ключевой вопрос, который остается без ответа на этой картинке, – зачем? Зачем ему нужна такая функция? Для какой цели? Чтобы отслеживать порядок записей? Или что‑ то более серьезное? Должны ли эти записи исключать возможность внесения изменений в целях проверок и расследований криминалистами Звездного флота? Две совсем разные цели. Одна – бытовая, другая – имеет весьма вескую причину. Команде нужно разобраться, что капитан на самом деле хочет делать, при этом они могут найти совершенно иной подход к выполнению задачи, так что капитан будет получать гораздо более важную информацию, о которой он, возможно, даже и не задумывался, но которая была бы ему очень полезна.

Потребности разных персонажей, как правило, совсем разные. Представьте себе такой случай, когда ситуация меняется на противоположную. Предположим, вы произносите: «Мне нужна машина, чтобы ездить на работу». А теперь начните предложение так: «Как жителю пригорода, постоянно ездящему в центр на работу…» Или ровно наоборот: «Как фермеру Южной Дакоты с ее плохими дорогами…» В результате вы получите два совершенно разных представления об идеальном автомобиле.

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

Короткие истории

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

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

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

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

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

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

Тим Стол – один из тех парней, о которых обычно говорят: прошел огонь, воду и медные трубы. Сейчас он хороший специалист, работающий с разными командами, чтобы те умели выполнять свое дело быстро. Тим служил медиком в спецназе, прошел Ирак и Афганистан, работал по контракту на ЦРУ, был офицером полиции и занимался там опасными преступниками, – теперь он скрам‑ тренер. Как Тим сам говорит, он всегда и был скрам‑ тренером, даже когда руководил операциями спецназа.

«В спецназе, – рассказывает он, – мы не называем это историей. Мы говорим: “план действий”. Но суть та же». Вот одна из немногих историй из практики спецназа, которые Тим может рассказывать открыто, – медицинская миссия в Лаосе. «У нас было два своих “эпика”. Первый эпик – по курсу медицинской подготовки, поскольку мы обучали отряды самообороны навыкам тактической медицины. Второй – по операциям по разминированию неразорвавшихся боеприпасов на освобожденных территориях».

Будучи врачом, Тим отвечал за курс медицинской подготовки. Он говорит, что перед началом своей миссии ему пришлось крепко подумать, что нужно делать, как разбить истории на фрагменты и выстроить их в логической последовательности. Он начал с идей, которые хорошо вписывались в систему Scrum. «Я был военврачом и служил в спецназе, поэтому мне полагалось обучать людей азам анатомии и физиологии, чтобы они могли понимать устройство человеческого тела и как функционирует наш организм», – Тим, когда стал составлять истории, понял, что начинать надо именно с этого, ведь его ученикам придется в будущем уметь оказывать любую первую помощь. «Для начала я рассказал им про кости человеческого скелета, про суставы, сухожилия, связки». Только после того как был заложен фундамент, то есть рассказаны базовые истории, Тим перешел к принципам вправления костей при переломах и суставов при вывихах, освобождению дыхательных путей и остановке кровотечений. Записав все истории, он сразу смог увидеть, что ему нужно для выполнения учебных задач. Нужен был скелет. Нужен был наглядный материал на английском и лаосском. Потом Тим разбил весь процесс обучения на короткие циклы, то есть спринты: «Два дня на перелет в Лаос. Неделя на подготовку. Затем два шестинедельных учебных цикла. Нам нужно было обучить с нуля до уровня младшего специалиста по оказанию первой помощи. И мы сделали это».

Готовность и выполненность

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

Возьмем в качестве примера историю Тима.

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

Есть мнемоническое правило, которое я всегда использую, когда нужно определить, готова ли история. Придумал его вдумчивый исследователь и серьезный программист Билл Уэйк. Билл говорит, что любая история, чтобы считаться готовой, должна соответствовать определенным критериям. Он назвал их критериями INVEST ( I ndependent. N egotiable. V aluable. E stimable. S mall. T estable ).

• Завершенность, выполнимость, независимость (Independent). История должна быть: абсолютно завершенной; осуществимой на практике; независимой от разных обстоятельств.

• Открытость (Negotiable). История до своего завершения должна быть открыта для общего обсуждения; любой участник группы должен иметь возможность внести в нее свои поправки.

• Ценность (Valuable). История должна приносить реальную пользу и увеличивать ценность проекта для заказчиков, пользователей и любых заинтересованных лиц.

• Оценочность (Estimable). История должна быть удобна для оценки объема работы.

• Лаконичность (Small). История должна быть краткой, компактно изложенной и конкретной, чтобы можно было просто и быстро планировать работы. Если история получилась слишком расплывчатой, перепишите ее, а лучше разбейте на мелкие функциональные фрагменты.

• Тестируемость (Testable). История должна пройти проверку на практике, чтобы считаться завершенной. Составьте заранее список критериев, которым должна соответствовать законченная история.

История Тима независима. Он мог выполнять свою операцию по обучению сил самообороны, не задумываясь о таких вещах, как, например, расход топлива вертолета, который доставлял его в лагерь. Его история открыта. Учитывая полевую практику, он мог добавлять ее или, напротив, сокращать в зависимости от того, как быстро усваивались знания его учениками. Его история имеет ценность. Она принесла реальную пользу, поскольку ученики узнали о строении человеческого тела, научились применять свои знания практически. Его история лаконичная. В ней кратко и емко изложены основы анатомии и физиологии. Сложной операции обучаемый не проведет, но первую помощь оказать сможет. Его история тестируема. Тим легко мог проверить по определенным критериям, как усвоен материал.

Любая пользовательская история, которую мы внедряем в практику, должна отвечать двум условиям: «готовность» – то есть соответствует ли она критериям INVEST; «выполненность» – то есть соответствует ли она тем критериям, по которым мы можем судить, что задача выполнена. При работе над реальными проектами мы видим, что если история действительно готова, команда удваивает скорость ее реализации. Когда в конце спринта история выполнена, команда в два раза увеличивает темпы работ в начале следующего спринта. Это один из ловких приемов Scrum, дающий возможность в два раза быстрее выполнить двойной объем работы.

Планирование спринта

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

Быстро решив все вопросы, команда дружно произносит: «Вперед! » – и приступает к работе.

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒