1-13 февраля 2001 года семнадцать человек собрались на горнолыжном курорте The Lodge At Snowbird на горном хребте Уосатч (штат Юта, США), чтобы поговорить, покататься на лыжах, расслабиться, попытаться найти общий язык, и, конечно же, поесть. То, что родилось в ходе этой встречи, назвали Agile Manifesto. Были собраны представители, придерживающиеся различных методологий разработки: экстремального программирования, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, другие симпатизирующие идее необходимости в альтернативной системе управления документацией и тяжеловесы мира разработки софта.

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

Алистер Коберн выразил опасения, которые в общем-то отражали первые мысли всех участников: “Я лично не ожидал, что эта группа сторонников различных гибких методик сможет единогласно согласиться в чем-то по существу”. Но после встречи он сказал следующее: “Я в восторге от окончательной формулировки манифеста, а также от того, что остальные были в равной степени в восторге от нее. Мы согласились по всем основополагающим моментам.”

Назвав себя “Agile альянс”, эта группа из независимых мыслителей о разработке, а иногда и конкурентов друг другу, договорилась и создала Манифест о гибкой разработке ПО.

Но в то время, как Манифест обозначает некоторые основные идеи, есть и более глубокие идеи, которые двигают некоторыми, но, конечно, не всеми участниками Альянса. По окончании двухдневной встречи, Боб Мартин (организатор встречи, автор книг о разработке) пошутил, что встреча была очень “сентиментальной”. Но несмотря на шутливую форму, мы отчасти согласны с мыслью Боба: все чувствовали большую честь работать в группе, основанной на доверии и уважении друг к другу, из людей, продвигающих организационную модель, основанную на людях, сотрудничестве и типах организации обществ, в которых мы хотели бы работать. По сути, я считаю, гибкие методологии действительно основаны на сентиментальных идеях о создании хороших продуктов для клиентов, работающих в среде, которая делает больше, чем говорит, что люди ее главный актив, а действует, как если бы люди действительно были самым важным в процессе, забывая слово “активом”. Таким образом стремительный взлет интереса (а иногда и критики) к гибким методологиям, это сентиментальные составляющие ценностей и культуры.

Например, я считаю, что в конечном счете экстремальное программирование распространилось и пользуется таким интересом не из-за самой идеи парного программирования или рефакторинга, а потому что методика освобождает сообщество разработчиков от “багажа” дилберт-организаций (прим. Дилберт — имя главного героя и название юмористических комиксов об офисной жизни в разных отделах компании).

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

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

Для того, чтобы добиться успеха в новой экономике, чтобы агрессивно двигаться вперед в эпоху электронного бизнеса, электронной коммерции и web в целом, компании должны избавиться от своих дилберт-проявлений и скрытой политики. Свобода от бессмысленной корпоративной рутины привлекает сторонников Agile методик и отпугивает олдфагов (begeebers) — приверженцев традиционного подхода. Откровенно говоря, гибкие методики пугают корпоративных бюрократов, по крайней мере тех, которые испытывают невероятное удовлетворение от процесса ради процесса, преподносимый как попытка сделать лучше “клиенту”, чтобы показать какой-то результат клиенту своевременно “как и обещали”, потому что у них заканчиваются отговорки.

Гибкие методологии не являются противопоставлением привычным методологиям. На самом деле, многие из нас хотят восстановить доверие к “методологии слова”. Мы хотим восстановить равновесие. Мы используем модели, но не для того, чтобы добавить еще одну диаграмму в пыльные архивы компании. Мы принимаем документы, но не сотни страниц никогда читаемых и редко используемых томов. Мы планируем, но признаем границы планирования в турбулентной среде. Те, кто использует экстремальную разработку, или SCRUM, или любую другую гибкую методологию исключительно из-за громкого названия, похожи на современных хакеров: первые в большинстве своём не знают методологию, вторые — изначального значения термина “хакер”.

Встреча в Snowbird стала плодом идей, зародившихся на более ранних встречах сторонников экстремального программирования и нескольких “аутсайдерских” встречах, организованных Кентом Беком на реке Рог Лодж в штате Орегон весной 2000 года. На встрече на реке участники голосовали за разнообразие “лёгких” методологий, но ничего формально не было сделано или принято. В течение 2000 года был написан ряд статей, которые ссылались на категорию “легких” или “облегченных” процессов. В ряде таких статей была фраза “лёгкие методологии, такие как экстремальное программирование, Adaptive Software Development, Crystal и SCRUM”. В разговорах никто не любил это прозвище “лёгкие”, но всем казалось, что это временное название.

В сентябре 2000 года Боб Мартин из Object Mentor в Чикаго начал созывать очередную встречу такой рассылкой по электронной почте: “Я хотел бы созвать небольшую двухдневную конференцию в январе-феврале 2001 года здесь в Чикаго с целью собрать лидеров всех легких методик разработки. Вы приглашены. И интересно ваше мнение, кого еще необходимо пригласить." Боб создал wiki-сайт, на котором бушевали дискуссии.

Уже на раннем этапе Алистер Коберн внес предложение, которое обозначило общее несогласие с термином «лёгкий»: «Я не против, когда методологии называют лёгкими по нагрузке, но я не уверен, что хочу, чтобы меня упоминали, как “легкий участник” собрания по “лёгким методикам”. Это звучит так, будто куча худых, малодушных, людей, которые мало весят, пытается вспомнить, какой сегодня день.»

Ожесточённая дискуссия была и вокруг места сбора. Была серьезная обеспокоенность по поводу Чикаго: в зимнее время холодно и никаких развлечений. Snowbird, Юта — холодно, но по крайней мере можно покататься на лыжах, большим фанатом которых является Мартин Фаулер. Ангилья в Карибском бассейне — тепло и весело, но на дорогу уйдёт слишком много времени. В конце концов лыжи победили. Тем не менее, несколько человек, например, Рон Джеффрис, хотели бы в следующий раз собраться в более тёплом месте.

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

2001, Джим Хайсмит, для альянса Agile.

Перевод: Кристина Стрельцова

Автор:

Источник