Книга Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон
Шрифт:
Интервал:
Закладка:
Гуру разработки Agile, уже упоминавшийся здесь мой друг Алистер Коберн, однажды сказал мне: «В бэклог историй нужно отправлять не одну написанную тобой историю, а три».
На мой вопрос «Почему?» он ответил: «Просто делай это».
«Что же мне писать в двух других историях?» – спросил я.
«Не имеет никакого значения».
«Что ты имеешь в виду? – удивился я. – Мне же нужно там что-то написать!»
«Ну хорошо, – сказал Алистер, – если тебе так уж нужно, запиши то, что хочешь разработать, на первой карточке, а на второй напиши: “Исправить первую карточку”. Потом на третьей – “Исправить вторую”. Если ты не пройдешь этот цикл трижды для каждой истории, то никогда ничему не научишься».
В традиционном процессе разработки учебу принято связывать с расширением объема разработки или плохими требованиями. В процессе Agile учеба – это ваша цель. Нужно запланировать, что вы изучите при каждой разработке. Кроме того, нужно заложить в план то, что время от времени вы будете терпеть неудачу.
Стратегия Эрика, которую мы рассматривали в главе 3, помогла ему реализовывать небольшие решения и выполнять итерации до тех пор, пока они не становились жизнеспособными. Эрик получал новые знания с каждым выпуском.
Стратегия Моны Лизы, использованная Майком и Аароном из главы 4, помогла им разделить каждую историю на маленькие компактные части, которые, правда, нельзя было представить пользователям, но они позволяли ребятам обучаться быстрее и управлять бюджетом разработки, в результате чего работа была завершена вовремя.
Это две замечательные стратегии обучения. Попробуйте их. Изобретите собственную. Только, пожалуйста, не думайте, что вы правы всегда и во всем! Уверяю, вас ждет великое разочарование.
В 2011 году Кент Бек – создатель метода историй – начал одну из первых конференций Lean Startup с пересмотра манифеста Agile. Будь на его месте, например, я, это было бы, пожалуй, святотатством; но Кент, один из авторов манифеста, знал, что делает. Он пересмотрел принцип, касающийся работающего ПО, и отныне он читается так: «Эмпирическое обучение важнее работающего продукта».
Если вы помните из главы 3, эмпирическое обучение – важнейшая концепция, родившаяся из процессов Lean Startup. Ключевое слово здесь – обучение. Эмпирическое обучение означает, что сначала мы обсуждаем, что именно хотим изучить в процессе какой-то разработки, а затем возвращаемся назад и оцениваем результаты, по которым видно, узнали мы что-то полезное или нет. Кстати, как оказалось, совсем не обязательно для изучения разрабатывать программный продукт, но, как правило, что-то создать или предпринять какие-то действия все-таки нужно.
Мне нравится использовать истории для управления работой по созданию простых прототипов или планированием пользовательских тестов либо интервью. Мне нравится говорить о том, кто это делает, что нужно сделать и почему. Я люблю сначала договориться о том, что мы делаем, а уж потом приступить к работе. Закончив работу, я анализирую ее результаты, чтобы оценить, удалось ли изучить что-нибудь.
Попробуйте метод историй для организации любой работы независимо от того, касается она разработки программных продуктов или нет.
Карты историй полезны для разбиения большого продукта или идеи функциональности на меньшие части. В главах 3 и 4 описано разделение этих меньших частей на фрагменты, удобные для разработки, притом что каждый фрагмент сконцентрирован на изучении чего-то. Но есть еще один способ дробления большого объема работы, вы должны познакомиться с ним и стараться держать его в голове. С помощью этого способа историю можно преобразовать в план работы, который в итоге обеспечит результат. Об этом мы поговорим в следующей главе.
Две недели назад был день рождения моей дочери и нам нужен был торт. У нашей семьи есть собственный кондитер, у которой мы заказываем торты всегда. Не сказать, что мы очень богаты или не умеем печь торты сами, просто Сидни, наш кондитер, делает удивительные, невероятно вкусные торты. Я не знаю точно, какой кулинарной магией она пользуется, чтобы создать такое чудо, но, когда ни спросишь моих детей, какой торт они хотят на день рождения, ответ всегда один: «Мы хотим торт Сидни!» – и от заказа уже не отвертеться.
Чтобы у нас появился торт, я звоню Сидни по телефону. Она всегда спрашивает, для кого торт и по какому случаю. Две недели назад я сказал ей, что Грейс скоро исполнится 12. «А чем она сейчас увлекается?» – спросила Сидни. Мы немного поговорили о Грейс, ее вкусах и интересах. После этого мы обсудили формы тортов, имеющиеся у Сидни, а также подумали, как можно украсить торт, чтобы он был готов вовремя. В этот раз мы остановились на торте в форме птички.
Вот так и работают истории. Сидни задала много вопросов «Кто?», «Что?» и «Почему?». Она осведомилась о контексте – где и когда будет подан торт, сколько человек приглашено. Во время разговора мы рассмотрели несколько разных вариантов. Мы беседовали достаточно долго для того, чтобы выработать единое понимание цели. А поскольку это далеко не первый торт, который мы заказываем у Сидни, у нас уже есть некоторое общее представление о виде и вкусе десерта, который должен попасть к нам на стол. Если бы этого не было, возможно, нам нужно было бы просмотреть несколько фотографий или попробовать несколько кусочков разных тортов, для чего телефона было бы, конечно, недостаточно.
В ходе беседы Сидни обдумывала, как она будет делать торт. Это было необходимо, иначе она не смогла бы оценить вероятность успеть вовремя. Когда приходит время печь торт, у нее уже есть список шагов, которые нужно проделать: отмерить муку, сахар, масло, яйца, молоко и т. д. Сидни должна взбить, смешать, испечь, украсить и, наверное, выполнить еще много секретных действий, о которых я ничего не знаю. Думаю, у нее есть разные рецепты для разных видов тортов и перечень действий, которые надо выполнить для каждого торта, прежде чем он будет помещен в коробку с бантиком и готов к передаче заказчику. Если бы Сидни написала на бумаге, что ей нужно проделать, у нее получился бы рабочий план, состоящий из специфических шагов по изготовлению тортов.
То же самое происходит, когда кто-то приносит историю в команду разработки. Все вместе принимают решение, какой именно продукт нужно создать, и команда составляет план, содержащий много задач на разработку. В команду разработки, кроме программистов, входят тестировщики, графические дизайнеры, технические писатели и прочие специалисты, чьи навыки необходимы для создания программного обеспечения, поэтому далеко не все задачи связаны с написанием кода. Этот план никогда не составляется при обсуждении истории, так же как и Сидни ничего не планировала, пока не поговорила со мной по телефону. План появится после того, как члены команды ознакомятся с историей, сделают заметки, нарисуют эскизы и уточнят множество деталей. Во всяком случае, так все должно происходить.
