В фильме "Принцесса-невеста" ужасный пират Робертс взбирается по веревке, которую перерезает Виззини. И когда Робертс не падает, Виззини произносит: "Он не упал? НЕВООБРАЗИМО"! На что Иниго Монтойя отвечает: "Почему ты постоянно говоришь это слово? Мне кажется, оно означает не то, что ты думаешь".
Когда я обсуждаю с людьми концепцию гибкой разработки, я чувствую себя как Монтойя в описанной сцене. Подчас мне кажется, что мы говорим о разных вещах. Это вовсе не значит, что я прав, а они нет. Это говорит лишь о том, что вокруг современного значения термина "гибкая разработка" возникло некоторое непонимание. Люди, связанные с программированием, привыкли вкладывать в слова тот смысл, который им самим кажется правильным, особенно когда речь идет о новых технологиях. В какой-то степени это оправдано: технологии меняются так быстро, что легко можно не поспеть за новыми терминами и сокращениями, которые появляются почти ежедневно; в результате мы цепляемся за привычную терминологию в надежде на то, что будем скорее правы, чем нет.
И хотя о гибкой разработке говорят уже давно, многие ученые и практики некорректно употребляют этот термин.
В этом месяце я хочу представить исследование ландшафта гибкой разработки. Для начала нам понадобится дать определение этому термину, что не так-то просто сделать. На самом деле я не уверен, что справлюсь, но все же попробую. Давайте начнем с принципов, а затем обратим внимание на то, как часто они искажаются людьми, у которых сложилось свое личное представление о гибкой разработке. И когда (надеюсь) мы придем к единому мнению о значении этого слова, я расскажу о некоторых книгах и ссылках, которые показались мне полезными для ориентирования в гибкой разработке.
В самом начале...
До февраля 2001 года слово "agile" ("гибкий") означало либо "способный двигаться со стремительным изяществом", либо "обладающий быстрым, продуктивным и адаптирующимся характером". В 2001 году это слово стало приобретать для программистов более специфическое значение. Группа из семнадцати человек, которые называли себя организационными анархистами,[3] но на самом деле были консультантами по программированию и признанными лидерами в разработке программного обеспечения, собрались в Сноуберде, штат Юта, и дали определение гибкой разработки программного обеспечения. Гибкая разработка - это единственный вопрос, в котором они сошлись во мнениях, хотя каждый из присутствующих имел свои взгляды на то, как надо писать высококачественные программы.
Результатом встречи в Сноуберде стало соглашение об общей позиции, которое было названо Манифестом гибкой разработки.[4] Я уже рассказывал об этом манифесте, однако не лишним будет повторить четыре основных положения, поскольку они создают основу понимания предполагаемого значения Гибкой разработки (с заглавной буквы "Г"). Эти пункты формулируются в виде предпочтений, отдаваемых одним аспектам программирования перед другими:
- преимущество людей и взаимодействий перед процессами и инструментами;
- преимущество работающей программы перед всеобъемлющей документацией;
- преимущество сотрудничества с клиентом перед обсуждением условий контракта;
- преимущество реагирования на изменения перед работой по плану.
Вот, собственно, и все. Положения кажутся простыми и понятными. И все же эта формулировка привела к возникновению разных интерпретаций и большему непониманию, чем в случае любого другого известного мне термина. Почему так случилось? Могу предположить три причины.
Во-первых, люди понимают слово "гибкий" в традиционном бытовом смысле. Когда мы говорим о гибкой разработке, люди слышат слово "гибкая" и, как я говорил во введении, применяют свой семантический фильтр, начиная думать, что речь идет о чем-то подвижном, быстро переключающем передачи и часто изменяющемся. Конечно, многие программные проекты быстро изменяются и движутся, но это относится не ко всем из них. Кроме того, та же самая проблема возникла бы в том случае, если бы участники собрания в Сноуберде выбрали любое другое известное слово для описания своего подхода к разработке программ. В то время многие предлагали слово легковесный в противоположность тяжеловесным процессам, которые, по их мнению, навязывались разрабатывающим организациям консультирующими компаниями.
Во-вторых, даже когда люди знают о другом значении слова "гибкий", они невольно думают о собственном определении этого слова. Возможно, они читали статьи и книги о гибкой разработке и даже пытались применить некоторые методы, которые сделали бы их проекты более "гибкими" (согласно своему собственному определению). К сожалению, людям свойственно искажать предполагаемое значение термина "гибкий", и это относится даже к экспертам и тем, кто некоторое время принимал участи в движении за гибкую разработку. Достаточно принять участие в одной из конференций, посвященных гибкой разработке, и вы поймете, что я имею в виду. Многие пришли к выводу, что гибкая разработка подобна искусству: "Я узнаю ее, когда вижу", и "Это очень личное определение". В апреле 2006 года кто-то из участников заявил, что ему удалось реализовать "полномасштабную" гибкую разработку. Когда я спросил, что он имеет в виду, я получил ответ, что это блочное тестирование и постоянная интеграция. Эти подходы можно истолковать в поддержку основных четырех положений гибкой разработки, но сами по себе они не эквивалентны ей.
Последняя причина вытекает из определения основных положений. Эти положения уже не раз обсуждались, однако многие люди, глядя на них, задают вполне справедливый вопрос о содержащихся в них противопоставлениях. Например, "всеобъемлющая документация" противопоставляется "работающей программе". Кажется, что эти определения подразумевают противостояние этих аспектов друг другу, но фактически этому нет логического подтверждения. Так что в результате мы имеем четыре пары ценностей, противопоставленных друг другу создателями Манифеста гибкой разработки. В этой статье я не стремлюсь оспорить обоснованность их выбора, а просто хочу сказать, что вы не можете считать свои процессы гибкой разработкой, если не согласитесь с таким противопоставлением и не окажете предпочтение первой ценности над второй в каждой упомянутой паре. Если вы решите, что всеобъемлющая документация более важна, чем отдельные люди и взаимодействия, то это значит, что вам, строго говоря, не хватает слов для обсуждения гибкой разработки в сопоставительной манере. Это третья причина недопонимания в разговорах о гибкой разработке. Многие из нас не согласны с этими исходными противопоставлениями.
Научный подход
Один из лучших подходов к любому предмету - будь то новому или хорошо известному - заключается в том, что сначала нужно дать определение, а потом, в результате всестороннего анализа, понять, к чему оно ведет. Давайте проделаем это и с гибкой разработкой.
Если принять за исходный документ Манифест гибкой разработки, то можно постановить, что любая организация или проект, которые стремятся внедрить гибкую разработку, должны ценить характеристики, упомянутые первыми в каждом из четырех определений (например, "сотрудничество с клиентом"), выше, чем характеристики, упомянутые вторыми (например, "обсуждение условий контракта"). Как-то Алистер Кокберн (Alistair Cockburn) сказал мне, что гибкая разработка - это лишь одна позиция в пространстве из шестнадцати возможных положений. Они имел в виду, что если рассматривать каждую пару ценностей, то вы можете предпочесть или не предпочесть первую ценность второй. Это двоичное решение, а поскольку пар четыре - возникает шестнадцать возможных комбинаций. Мне кажется, это самый простой и четкий способ представления гибкой разработки. Он позволяет избежать проблем, связанных с попыткой различения степеней гибкой разработки. Опираясь на описание Кокберна, мы можем решить, относится ли организация или проект к гибкой разработке или нет. Если организация обладает этими ценностями и применяет их в своей работе, то можно считать, что она использует гибкую разработку. Если нет - то нет.
Можно также подойти к гибкой разработке с точки зрения отрицания, сославшись на Джеффа Фоксфорти (Jeff Foxworthy).[5] Если вы цените процессы и инструменты не меньше, чем взаимодействие людей, то вы не ведете гибкую разработку. Если вы цените всеобъемлющую документацию не меньше, чем работающую программу, то вы не ведете гибкую разработку. Если вы цените обсуждение условий контракта не меньше, чем сотрудничество с клиентом, то вы не ведете гибкую разработку. Если вы цените работу по плану не меньше, чем реакцию на изменения, то вы опять же не ведете гибкую разработку.
Главный смысл вышесказанного состоит в том, что вам не следует оценивать негибкие аспекты выше гибких. Достаточно ценить их, по крайне мере так же, как гибкие. Если вы заняты системным проектированием, думаю, вы будете ценить строгую работу по плану в той же степени, как и реакцию на изменения. Вы работаете с оборудованием и программным обеспечением и напряженно трудитесь, чтобы и то и другое было готово в соответствии с графиком. И хотя изменить программу сравнительно просто, изменение оборудования зачастую связно с трудностями или вообще невозможно.
Так что осмелюсь заявить - и пусть меня заклюет сообщество гибкой разработки - негибкая разработка - это тоже нормально. Гибкость - это не самоцель. Она лишь является чем-то, к чему можно стремиться, если это имеет смысл для вашего проекта и организации. Если вы поговорите со многими представителями сообщества гибкой разработки, то обнаружите, что они это понимают и принимают. Однако, подобно проповедникам, которые увидели свет и хотят им поделиться, они могут быть столь настойчивы, что их рвение вас обескуражит.
Одно дело заявить, что вы обладаете определенными ценностями, и совсем другое - применить эти ценности на практике. Авторы манифеста сформулировали несколько принципов, которым вы должны следовать, если хотите работать на принципах гибкой разработки.[6] Если вы следуете в своей работе этим принципам, вы ведете себя так, как требует гибкая разработка.
А теперь давайте дадим гибкой разработке определение, которого будем придерживаться в оставшейся части этой статьи. Гибкость определяется как обладание ценностями, описанными в Манифесте гибкой разработки, и следование соответствующему набору принципов - не больше и не меньше.
Что пошло не так?
Определение, которое я только что дал, весьма несложно. Откуда же возникает столько недопонимания и противоположных мнений по поводу того, является ли организация или проект гибкими? Частично проблема заключается в том, что принципы сформулированы таким, что оставляют много места для интерпретации и различных вариантов реализации. Давайте рассмотрим несколько таких принципов.
Один из них гласит: "Стройте проекты вокруг мотивированных личностей. Дайте им необходимую среду и поддержку и доверьте им выполнение работы". Как реализовать этот совет? В первую очередь нужно спросить, кто такие мотивированные личности? Некоторые люди стремятся лишь к материальной выгоде. Другие хотят быть частью замечательной команды. Мотивированные личности одной команды могут разрушительно влиять на другую команду. Если ваш кадровый резерв заранее отобран вашей организацией, есть вероятность, что вам не удастся выбрать для своей проектной группы таких личностей, которые вписываются в ваше определение мотивированности. Можно ли в такой ситуации реализовать гибкую разработку?
Другой принцип гласит: "Гибкие процессы способствуют устойчивой разработке. Спонсоры, разработчики и пользователи должны уметь выдерживать постоянный темп сколь угодно долго". Понятно, что если опустить планку пониже и работать, не напрягаясь, то можно продержаться сколь угодно долго. Очевидно, что под этим принципом подразумевается совсем другое.
Мы можем рассматривать большинство из этих принципов по отдельности и каким-то образом искажать их вопреки духу гибкой разработки. Но если рассматривать их как единое целое, они начинают поддерживать друг друга. Тем не менее остается достаточно много места для их интерпретации. Это создало обширное поле деятельности для всякого рода инструкторов, консультантов, методистов и прочих личностей, которые хотят помочь организациям внедрить гибкую разработку и принять личное мнение консультанта о ней. Также это подтолкнуло многие организации к принятию новых методов и к заявлению о том, что они внедрили гибкую разработку в интерпретации соответствующего методиста.
Иметь интерпретацию гибкой разработки достаточно просто. Куда сложнее прийти к правильной интерпретации. Ни один прорицатель не сможет дать определенного ответа на вопрос, относятся ли ваш проект или организация к гибкой разработке. И вы будете совершенно правы, если спросите: "Ну и что"? Если вы эффективно создаете программы, отвечающие требованиям заинтересованных лиц, то с вами все в порядке. Вы всегда должны стремиться к совершенству, но обязательно ли соответствовать ярлыку? Всегда было проблематично следовать CMM и CMMI, RUP и другим методологиям. Люди и организации зацикливаются на достижении определенного уровня "сертификации" вместо того, чтобы сконцентрироваться на достижении конечной цели, которая заключается в поставке программного обеспечения. Методологии и практические методы - это лишь средство, а не сама цель.
Ну, хорошо, раз все так просто...
Одним из вопросов, заданных на конференции Agile2006 в Миннеаполисе, был вопрос: "Если гибкая разработка столь проста, откуда взялось столько книг, рассказывающих о ее достижении"? Это было сказано как бы в шутку, но в этом вопросе есть и серьезная сторона. В моем школьном кабинете есть целая полка, почти полностью заполненная книгами о гибкой разработке. Их там больше тридцати. И еще пара десятков книг лежит у меня дома. Это очень много. Откуда же взялось столько книг о гибкой разработке?
Ответ достаточно прост - эти книги открывают для консультантов замечательные возможности по продаже своих услуг. Кроме того, они дают возможность преподавателям и практикам высказывать свои мнения по данному вопросу. Книги оказывают влияние не только на людей, но и на уровень развития и практические методы. Любые новые концепции всегда сопровождаются огромным количеством книг, журналов и статей. Для особенно важных концепций создаются конференции. Сектор технологий создает особенно плодородную почву для идей и последующих книг, поскольку, как я отметил в начале этой статьи, для нас, работающих в сфере информационных темноногий, сложно - жонглируя проектами, поспевая к сроку, оставаясь в рамках бюджета в попытке удовлетворить клиентов - следовать последним методам достижения цели без хорошей и самоуправляемой помощи.
Второй ответ заключается в том, что многие авторы, исповедующие актуальность нового подхода, смогли успешно опубликовать свои книги. В результате каждая книга стремится представить нечто новое и интересное в авторской интерпретации ценностей и принципов. Многие из них указывают путь, ведущий к реализации принципов и ценностей. Подобно многим самоучителям, они утверждают, что вы освоите гибкую разработку, если будете следовать их программе. Если вы когда-нибудь пробовали разные диеты, программы релаксации, программы ускорения чтения и т.п., вам хорошо известно, что методика, которая работает для одного человека, не работает для другого. Это относится и ко многим книгам о гибкой разработке. Метод может сработать для проекта А, но полностью провалиться в проекте В. Каждый проект и каждая организация должны найти свой собственный путь к гибкой разработке, если она для них уместна.
Вездесущая гибкость
Сегодня гибкая разработка повсеместна. Это эфир, окружающий разработку программного обеспечения. Если вы готовы потратить на что-то время и усилия, потратьте их на гибкую разработку. Если инструмент стоит изучить и применить в вашем проекте, он должен поддерживать гибкую разработку. На самом деле это скорее маркетинговый ход, нежели реальная потребность. Гибкая разработка подобна новой марке кроссовок, которые мы хотим купить, чтобы наша проектная группа смогла прыгнуть выше и побежать быстрее.
Недавно я заходил в книжный магазин и купил книгу о программировании на языке Ruby. На задней стороне обложки было написано: "Ruby - это гибкий объектно-ориентированный язык программирования ...". Авторы благоразумно не стали писать слово "гибкий" с большой буквы, хотя я не уверен, что среднестатистический читатель обратит на это внимание. Действительно ли Ruby поддерживает ценности, описанные в Манифесте гибкой разработки? Этот вопрос может показаться странным, однако логически он таковым и является. Ведь там, где речь идет о маркетинге, логика может быть не столь важна. Использование слова "гибкий" для привлечения внимания покупателей позволяет вам сделать первый шаг в развитие деловых отношений. (Надеюсь, со временем у нас появятся более сообразительные покупатели, которые зададут нужные вопросы и оценят гибкость разработки объективно.)
Я вовсе не против гибкой разработки. Но я и не апологет гибкости. Я бы скорее представил себя прагматиком, использующим то, что может помочь, и отбрасывающим то, что бесполезно. Иногда гибкая разработка эффективна, иногда мне нужно нечто иное. Мне кажется, что именно так и должно быть.
Лучшие книги и методологии, посвященные гибкой разработке
В оставшейся части этой статьи я хочу представить краткое описание тех книг по гибкой разработке, которые кажутся мне интересными. Я расскажу, чем именно интересна каждая из книг и что она может вам предложить. В начале списка расположены книги, дающие общее описание гибкой разработки, ее ценностей и принципов. Затем я перейду к конкретным методологиям и применению на практике.
Книги о ценностях и принципах гибкой разработки
Гибкая разработка программного обеспечения: кооперативная игра (Agile Software Development: the Cooperative Game), 2-е издание, Алистер Кокберн (Alistair Cockburn), Addison-Wesley Professional, 2006, ISBN 0321482751.
Алистер Кокберн пишет в доступном стиле. Эта книга дает одно из лучших описаний гибкой разработки с точки зрения одного из первых пропагандистов. Книга написана понятно и хорошо сбалансирована. Кокберн описывает гибкую разработку и рассматривает ее в широком контексте. Он с увлечением описывает перспективные стороны методов гибкой разработки, рассказывает, почему они работают, и перечисляет преимущества, которые они дают.
Подход Кокберна нельзя назвать техническим. Он не вдается в тонкости программирования и мелкие детали. Он приводит достаточно материала, чтобы дать общее представление о гибкой разработке. Кокберн известен своим интересом к проблеме межличностных отношений в процессе разработки ПО и уделяет довольно много времени обсуждению человеческого фактора. Если вы ничего не знаете о гибкой разработке программного обеспечения, то эта книга именно для вас.
Гибкая и итерационная разработка программ - руководство для менеджеров (Agile & Iterative Software Development A Manager's Guide), Крэйг Ларман (Craig Larman), Addison-Wesley, 2004, ISBN 0131111558.
Крэйг Ларман - выдающийся учитель программирования. В особенности это касается объектно-ориентированного программирования. Он хорошо знаком с разными методологиями и знает, как их применять. В этой книге Ларман описывает итерационные методы, Scrum, XP, RUP и Evo. Scrum и XP несколько не вписываются в сектор гибкой разработки, тогда как RUP и Evo более традиционны (и опираются на планирование). Ларман сравнивает и противопоставляет разные методологии, чтобы помочь читателям оценить их преимущества и решить, какой процесс наилучшим образом подходит для их проектов и организаций.
Сравнение методологий приведено во второй половине книги, но главную ценность представляют первые шесть глав этого произведения. В этих главах Ларман критически оценивает разработку программного обеспечения, гибкую разработку, итерационную разработку и представляет читателю свидетельства о применении итерационных и гибких методов. Эти свидетельства исходят от исследователей, опытных разработчиков и из других источников. Ларман прекрасно выполнил свою работу.
Баланс гибкости и дисциплины - руководство для обескураженных (Balancing Agility and Discipline A Guide for the Perplexed), Барри Бём (Barry Boehm) и Ричард Тёрнер (Richard Turner), Addison-Wesley, 2004, ISBN 0321186125.
Эта книга обращена к менеджерам, которые вышли из крупных организаций и проектов или обладают приличным опытом проектирования программ (но не программирования).[7] Бём и Тёрнер - преподаватели, имеющие богатый опыт работы с крупными проектами, многие из которых относились к оборонной промышленности. Они подходят к теме, пытаясь выявить перспективные стороны- места, наиболее подходящие для применения той или иной методологии. Бём хорошо известен разработкой модели оценки проекта COCOMO, он написал много конструктивных статей по проектированию программ, включая статьи, описывающие итерационную разработку.[8]
Единственной проблемой при чтении этой книги было то, что у меня не возникло уверенности в том, что Бём и Тёрнер когда-либо сталкивались с проектами того типа, над которыми обычно работаю я, то есть с проектами, которые содержат менее 100 тысяч строк кода. Они фокусируются на огромных проектах, с которыми эффективно работают традиционные методы проектирования программ. И все же я думаю, что эту книгу стоит прочесть, поскольку она оценивает гибкую разработку с большего числа сторон, чем основная часть других книг в этом списке.
Книги о методологиях гибкой разработки
Гибкая разработка программного обеспечения с помощью Scrum (Agile Software Development with Scrum), Кен Швабер (Ken Schwaber) и Майк Бидл (Mike Beedle), Prentice Hall, 2001, ISBN 0130676349.
В последние несколько лет Scrum уделяется много внимания. Этот подход предлагает очень простой способ управления проектами и слабо связан с разработкой ПО. В основном Scrum состоит из нескольких практических методов, которые далеко не новы, но безукоризненно реализованы. Сторонники Scrum утверждают, что применение его к программным проектам любого уровня сулит неизменный успех. В этой методологии нет ни одного практического метода, который я мог бы считать техническим. Все они относятся к управлению проектами.
Книга описывает методологию Scrum словами его создателей, Швабера и Бидла. Эту книгу стоит прочесть хотя бы для того, чтобы понять, как гибкая разработка может использоваться для управления проектами.
Экстремальное программирование: принятие изменений (Extreme Programming Explained: Embrace Change), 2-е издание, Кент Бэк (Kent Beck) и Синтия Андрес (Cynthia Andres), Addison-Wesley Professional, 2004, ISBN 0321278658.
Первое издание этой книги, вероятно, способствовало началу продвижения гибкой разработки в большей степени, чем что-либо иное. На самом деле некоторые практики приравнивают экстремальное программирование (XP) к гибкой разработке. Для разработчиков программ XP представляет собой методологию, направленную на решение проблем, с которыми им приходится сталкиваться. Бэк, к которому во втором издании присоединилась Синтия Андрес, описывает фундаментальные принципы, относящиеся к наиболее применяемым среди разработчиков программ на принципах гибкой разработки (или тем, которые считаются наиболее применяемыми). Я сказал, что они считаются наиболее применяемыми, поскольку есть несколько организаций, которые на самом деле могут использовать все эти методы в своей работе, однако по-прежнему настаивают на применении XP.
Второе издание этой книги увеличилось в объеме по сравнению с первым, но, на мой взгляд, не стало от этого более полезным. В последнее издание добавлены материалы, посвященные стратегиям и модификациям базовой технологии XP. Неудачная попытка. Если вам удастся раздобыть экземпляр первого издания и вы только недавно познакомились с методами гибкой разработки, я рекомендую прочесть именно его, чтобы ощутить вкус экстремального программирования.
Внедрение экстремального программирования (Extreme Programming Installed), Рон Джеффрис (Ron Jeffries), Энн Андерсон (Ann Anderson) и Чет Хендриксон (Chet Hendrickson), Addison-Wesley Professional, 2000, ISBN 0201708426.
Это второй том обширной серии книг об XP, опубликованных издательством Addison-Wesley. Его стоит прочесть, потому что он описывает практические методы применения XP и рассказывает о том, как они использовались членами исходной группы проекта XP.[9] Книга написана очень грамотно, так что вы сполна ощутите, что значит работать с проектом XP. Именно эта книга убедила меня в том, что ни один из практических методов XP не относится к тому типу проектов, с которыми я бы согласился работать. Кроме того, книга убедила меня в существовании ряда действительно полезных методов, с которыми мне следует познакомиться. И хотя с тех пор XP ушло далеко вперед, эта замечательная книга не теряет своей актуальности и рекомендуется к прочтению любой не имеющей опыта группе перед тем, как пускаться в первое путешествие по XP.
Книги практического значения
Разработка, основанная на тестировании: практическое руководство (Test Driven Development: A Practical Guide), Дэвид Астелс (David Astels), Prentice Hall Ptr, 2003, ISBN 0131016490.
Мне кажется, что разработка, основанная на тестировании (TDD), является одним из важнейших методов, давших движение гибкой разработке. Она акцентируется на качестве и возлагает ответственность за качество на разработчика. Она требует сосредоточения на качестве в течение всего цикла разработки, независимо от используемой методологии. Эта книга является превосходным введением в TDD. Именно она продемонстрировала мне силу простого тестирования.
Практика блочного тестирования в Java с помощью JUnit (Pragmatic Unit Testing in Java with JUnit), Эндрю Хант (Andrew Hunt) и Дэвид Томас (David Thomas), The Pragmatic Programmers, LLC, 2003, ISBN 0974514012.
Эта книга дополняет предыдущую практическим советом о том, как реализовать принципы TDD. Издательство The Pragmatic Programmers выпустило удивительную серию книг, рассказывающих программистам о новинках технологий. Эта книга относится к их ранним публикациям. Книгу следует прочесть всем программистам, пишущим на языке Java и желающим преуспеть в написании блочных тестов. Книга рассматривает блочное тестирование в контексте TDD и дает читателю все необходимые средства для написания, управления и автоматизации блочных тестов.
Истории пользователей (User Stories Applied), Майк Кон (Mike Cohn), Addison-Wesley Professional, 2004, ISBN 0321205685.
Похоже на то, что истории пользователей могут стать лучшим методом разработки технических заданий для многих гибких проектов, хотя приемлемы и другие подходы, такие как сценарии использования. История пользователя - это небольшой фрагмент функциональности, который клиент может описать на каталожной карточке. Это соответствует очень малому итерационному подходу, применяемому в XP и других методах гибкой разработки. Подобно написанию сценариев использования, написание историй пользователей представляет собой мастерство, которому нужно научиться, и которое следует применять на практике. Майк Кон дает наилучшее введение в написание историй пользователей из всех, которые я встречал. Его книга имеет такое же значение для историй пользователей, как книга Алистера Кокберна (Alistair Cockburn) для сценариев использования.[10] Если вы работаете со сценариями использования и не читали книгу Кокберна, Кон преподаст вам полный курс написания и применения историй пользователей к вашему проекту. Он приводит множество примеров, сквозь которые явно проглядывает богатый опыт работы с реальными проектами. Если вы аналитик и хоть немного заинтересованы в историях пользователей, обязательно прочтите эту книгу.
Планирование экстремального программирования (Planning Extreme Programming), Кент Бэк (Kent Beck) и Мартин Фоулер (Martin Fowler), Addison-Wesley Professional, 2000, ISBN 0210710919.
Еще одним ключевым практическим методом для проектов XP является игра в планирование. Она представляет собой довольно простой набор действий, которые помогают клиенту и группе разработчиков решить, что происходит в каждой итерации, как оценивать проделанную работу и как отслеживать результаты для повышения качества оценки. Бэк и Фоулер проделали большую работу, описав этот метод так, чтобы заинтересовать разработчиков, менеджеров и всех других членов группы XP.
Прочее
Следующие две книги не попадают в описанные выше категории, но я считаю их полезными и постоянно на них ссылаюсь. Вторую я использую в качестве учебника для своих курсов проектирования программ, которые провожу дважды в год.
Принципы, шаблоны и практические методы гибкой разработки программ (Agile Software Development Principles, Patterns, and Practices), Роберт К. Мартин (Robert C. Martin), Prentice Hall, 2002, ISBN 0135974445.
Это книга для разработчиков, написанная разработчиком разработчиков. Дядюшка Боб Мартин - опытный разработчик, глубоко понимающий принципы объектно-ориентированного и Гибкого программирования. В этой книге дядюшка Боб объединяет эти понятия, демонстрирует разработчикам силу принципов объектно-ориентированной разработки и рассказывает о том, как использовать их в проектах гибкой разработки. Эта книга должна быть в библиотеке каждого разработчика.
Экстремальное проектирование программ: практический подход (Extreme Software Engineering: A Hands-On Approach), Дэниэл Х. Стейнберг (Daniel H. Steinberg) и Дэниэл У. Палмер (Daniel W. Palmer), Prentice Hall, 2003, ISBN 013047812.
Эта небольшая книга предлагает хорошо сбалансированный взгляд на проекты гибкой разработки, отдавая предпочтение XP. Она не догматична и пытается показать, что гибкая разработка - это не бессистемный подход к программированию и не повод для работы в старом стиле. Мои студенты с удовольствием читают эту книгу, тем самым оставляя мне время на выделение тех аспектов разработки программ, которые я считаю важными. С этой книгой можно замечательно провести выходные.
Заключение
Гибкая разработка получила повсеместное распространение. Игнорируя ее, вы потеряетесь в современном техническом диалоге. Изучите ее, и вы сможете принимать разумные решения о том, насколько она вам подходит. Кроме того, для вас не будет проблемой понимание других вновь появляющихся методов. Если вы менеджер и занимаетесь технологиями любого уровня, то для вас это просто жизненно необходимо.
Советую начать читать перечисленные выше книги, а также другие книги таких авторов, как Мэри Поппендик (Разработка в условиях ограниченного бюджета) (Mary Poppendieck, Lean development), Скотт Амблер (Базы данных) (Scott Ambler, Databases), Джим Хайсмит (Практические методы управления) (Jim Highsmith, Management practices) и других авторов, которые либо внесли непосредственный вклад в продвижение гибкой разработки, либо создали принципы и методы, хорошо работающие с группами и проектами гибкой разработки. Надеюсь, что, как и мне, вам встретятся книги, в которых вы найдете идеи, которые сможете опробовать со своими коллегами, проектами и организацией. Несомненно, вы столкнетесь и с множеством бесполезных книг - не потому, что они плохие, а потому, что они не соответствуют вашим потребностям. Станьте информированным потребителем - и вы повысите свою ценность для своей организации.
3 См. историю Манифеста гибкой разработки: http://www.agilemanifesto.org/history.html.
4http://www.agilemanifesto.org.
5 Джефф Фоксфорти (Jeff Foxworthy) - комик, хорошо известный своими шутками в стиле: "Если вы ... то вы - реднек" ("деревенщина", представитель сельского рабочего класса южной части США, которые традиционно считаются простаками).
6http://www.agilemanifesto.org/principles.html.
7 Свое мнение о различии этих понятий я высказал в декабрьской статье 2005 года: http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html.
8 Барри Бём (Barry Boehm), "Спиральная модель разработки и усовершенствования программ" (A Spiral Model of Software Development and Enhancement), ACM SIGSOFT Software Engineering Notes, август 1986.
9 Этот проект, выпустивший тысячу книг, назывался Chrysler Comprehensive Compensation System и был запущен в 1995 году. Считается, что в этом проекте были применены, записаны и преобразованы в методологию, которую теперь мы называем XP, все практические методы экстремального программирования.
10Написание эффективных сценариев использования (Writing Effective Use Cases), , Алистер Кокберн (Alistair Cockburn), Addison-Wesley Professional, 2000, ISBN 0201702258. Если вы работаете со сценариями использования и не читали этой книги, то вы многое потеряли.
Развить навыки по этой теме: Этот материал - часть knowledge path для развития ваших навыков. Смотри Гибкая разработка программного обеспечения