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