Kitabı oku: «Пользовательские истории. Искусство гибкой разработки ПО», sayfa 2

Если вы используете истории и страдаете, эта книга – для вас

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

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

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

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

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

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

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

Для кого еще эта книга

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

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

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

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

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

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

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

А если это все-таки вы, давайте начнем.

Используемые соглашения

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

Подзаголовки внутри каждой главы будут подсказывать вам направление темы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов²? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.

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

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

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

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

Единое понимание – это невероятно просто

Мой бывший коллега Люк Баррет первым показал мне этот комикс, чтобы описать проблему. Я спросил, где он его видел, но он так и не вспомнил (кто-то, возможно, не получает авторских отчислений). Годами я наблюдал, как Люк демонстрирует эти четыре слайда в презентации PowerPoint, и всегда воспринимал их как нечто забавное, но довольно банальное. Видимо, я туговато соображаю: лишь много лет спустя осознал, что этот комикс иллюстрирует, наверное, самую важную особенность работы с историями при разработке ПО.

Суть в том, что если у меня есть какая-то идея, я ее записываю на бумаге, а вы затем это читаете, то вполне можете представить что-то совершенно иное, чем я. При этом можно спросить каждого: «Вы согласны с содержанием этого документа?», и все дружно ответят: «Да! Да, мы согласны!» Но если мы соберемся вместе и начнем обсуждение, вы можете описать мне, что думаете, а я смогу задать вопросы. Беседа пойдет живей, если мы можем описать наши мысли, рисуя картинки либо фиксируя идеи на стикерах или карточках. Если у каждого из нас будет возможность объяснить свои мысли с помощью слов и картинок, мы придем к общему мнению. Однако здесь мы осознаем, что все понимают всё по-разному, и это очень неприятно. Но по крайней мере теперь проблема известна.

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

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

Перестаньте пытаться написать идеальную документацию

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

Правильный ответ: просто не занимайтесь документами.

Перестаньте пытаться составлять идеальные документы.

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

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

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

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

Хорошие документы похожи на фотографии из отпуска

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

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

Хорошо это или плохо, но именно так работают документы.

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

Документируйте, чтобы активизировать воспоминания

Я пару раз слышал шутку: «Мы перестали писать документацию, и поэтому у нас теперь Agile». Это называется: кто знает – тот поймет, потому что на самом деле процесс, управляемый историями, требует для работы множества документов. Но зачастую эти документы совсем не похожи на традиционные задокументированные требования.

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

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

Но помните: самое важное и нигде не записанное – это то, что мы вспомним при прочтении. Вот он, фактор фотографии из отпуска.

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

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