Пользовательские истории. Искусство гибкой разработки ПО

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

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

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

Врезки используются для описания:

• интересных, но не критически важных аспектов. Возможно, они развлекут вас, по крайней мере я на это надеюсь;

• конкретных упражнений. Вы сможете использовать их, чтобы начать практиковаться в чем-либо специфическом;

• историй и примеров, предоставленных другими. Возможно, вы почерпнете из них хорошие идеи и сможете применить их в своей компании.

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

Как устроена эта книга

Однажды я купил замечательный лазерный принтер. Первое, что я увидел, открыв коробку, был бумажный буклет, на котором красовалась надпись большими яркими буквами: «СНАЧАЛА ПРОЧТИТЕ ЭТО». Я задумался, стоит ли так поступать на самом деле, ведь, как правило, я пренебрегаю инструкциями. Но позже очень радовался, что послушался этого предупреждения, потому что, как оказалось, в разных местах внутри принтера было закреплено много пластиковых деталей, чтобы уберечь его от повреждений при транспортировке, и, если бы я включил принтер, не убрав их, скорее всего, он был бы безнадежно испорчен.

Эта история, наверное, кажется здесь неуместной, но это не так.

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

Построение карт историй с высоты птичьего полета

Главы 1–4 дадут вам общее представление о построении карт историй. Если вы уже используете их и имеете некоторый опыт, эта часть книги обеспечит достаточно материала, чтобы немедленно приступить к делу.

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

Интуитивное понимание пользовательских историй

В главах 6–12 рассказано многое о пользовательских историях: как они работают в реальности, как организовать их использование в проектах Agile или Lean наилучшим образом. В дополнение к картам историй там приведены несколько маленьких примеров, которые могут оказаться полезными в ежедневной практике разработки. Даже если вы ветеран Agile, обещаю, вы узнаете об историях что-то новое для себя. А если вы в историях новичок, то узнаете достаточно, чтобы поразить самого заносчивого Agile-всезнайку в офисе.

Лучшие бэклоги

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

Лучшая разработка

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

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

Перейдем к делу.

Сначала прочтите это

В этой книге нет введения.

Да, вы все прочитали правильно. И сейчас, наверное, задаетесь вопросом: «Почему же в книге Джеффа нет введения? Может быть, он забыл его написать? Не пора ли ему на покой? Или введение съела его собака?»

Нет, я не забыл написать введение. И мне не пора на покой (по крайней мере я туда не собираюсь). И моя собака не съедала введения, хотя насчет морской свинки своей дочери я не был бы так уверен. Это просто потому, что за долгое время я убедился: авторы тратят кучу времени, пытаясь убедить меня прочесть их книгу, и большая часть этого времени приходится на введение. Самое интересное во всех книгах начинается примерно с третьей главы. Кроме того, я уверен, что не я один всегда пропускаю введение.

Так что эта книга начинается прямо здесь.

И вам ни в коем случае нельзя пропускать эту часть, так как на самом деле она самая важная. Я буду доволен, если вы вынесете из книги всего две мысли. Вот эти две мысли.

• Цель работы с историями не написание идеальных историй.

• Цель разработки продуктов не создание продуктов.

Сейчас я все объясню.

Игра в испорченный телефон

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

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

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

Перед вами обложка книги Джен Ятис «Торты, которым не повезло», опубликованной в издательстве Эндрю Мак-Милла (спасибо Джен и Джону Ятис за предоставление иллюстрации). Книга получилась по мотивам ее очень забавного сайта cakewrecks.com (только не ходите туда, если у вас нет по меньшей мере часа свободного времени). На сайте собрана коллекция по-идиотски украшенных тортов, логика их создателей не поддается объяснению, хотя Джен и предпринимает попытки сделать это. Так, одна из самых часто встречающихся и в книге, и на сайте тем – неверно понятые требования. Джен, конечно, не называет их требованиями, ведь это слишком формальный термин, вместо этого она употребляет слово «записи», так как исполнитель слушает и записывает, понимая буквально то, что слышит. Глядя на эти фото, я могу вообразить сотрудника кондитерской, который слушает заказчика и записывает его пожелания, а потом передает их кому-то, кто будет украшать торт.

Заказчик: «Здравствуйте, я хотел бы заказать торт».

Работник: «Конечно, что бы вы хотели на нем написать?»

З.: «Вы могли бы написать “Всего хорошего, Алиса” фиолетовым цветом?»

Р.: «Конечно».

З.: «А вокруг надписи пусть будут звезды».

Р.: «Без проблем. Я записал ваши пожелания и прямо сейчас передам их кондитеру-декоратору. Торт будет готов к завтрашнему утру».

Вот что получилось в результате.

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

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

Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов[2 - Подробности этой истории многократно освещались в прессе, вот одна из статей: http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/. – Примеч. пер ]? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.

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

Общие документы не дают единого понимания.

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