Манифест Agile-разработки ПО
Мы находим лучшие подходы к разработке ПО, непосредственно участвуя в процессе разработки и помогая другим. В процессе работы мы пришли к тому, что для нас важнее:
- Люди и их взаимодействие, чем процессы и средства
- Работающее ПО, чем исчерпывающая документация
- Сотрудничество с заказчиком, чем обсуждение условий контракта
- Реагирование на изменения, чем следование плану
То есть, мы не ставим под сомнение важность пунктов справа, в то же время для нас гораздо важнее записанное слева.
Кент Бек (Kent Beck) Майк Бидли (Mike Beedle) Ари Ван Биннекум (Arie van Bennekum) Алистэр Коуберн (Alistair Cockburn) Вард Каннингем (Ward Cunningham) Мартин Фаулер (Martin Fowler) |
Джеймс Греннинг (James Grenning) Джим Хайсми (Jim Highsmith) Эндрю Хант (Andrew Hunt) Рон Джеффрис (Ron Jeffries) Джон Керн (Jon Kern) Брайн Марик (Brian Marick) |
Роберт К. Мартин (Robert C. Martin) Стив Мэллор (Steve Mellor) Кен Шваубер (Ken Schwaber) Джефф Сазерленд (Jeff Sutherland) Дэйв Томас (Dave Thomas) |
© 2001, вышеперечисленные авторы. Текст манифеста может свободно копироваться в любой форме с обязательным включением данного уведомления.
Принципы, лежащие в основе манифеста Agile
Мы придерживаемся следующих принципов:
Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им - они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром - непосредственное общение.
Работающее ПО - главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота - искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.
История манифеста Agile
11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты семнадцать человек собрались, чтобы пообщаться, покататься на лыжах, расслабиться и попытаться прийти к общему знаменателю и, конечно же, поесть. Что из этого вышло - Agile-манифест разработки ПО. Съехались представители Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и других подходов, вызванных потребностью в альтернативе к основанным на документации, тяжеловесным процессам разработки ПО.
Тяжело себе представить большее собрание организационных анархистов, поэтому то, во что вылилась эта встреча, было символическим - Манифест для Agile-разработки ПО , подписанный всеми участниками. Единственное замечание прозвучало от Мартина Фаулера (британца для тех, кто его не знает), который предположил, что большинство американцев не знает, как произносится слово Agile .
Поначалу Алистэр считал: "Лично я не ожидал, что эта группа agilities когда-либо придет к согласию в чем-нибудь определенном", - и некоторые участники были с ним согласны. Однако, многие разделили его итоговую оценку встречи: "Если говорить обо мне, то я восхищен завершающей фразой [Манифеста]. Я удивлен, что другие одинаково восхищаются последней фразой. Так мы пришли к согласию в чем-то определенном".
Именую себя "Альянс Agile", эта группа независимых мыслителей по разработке ПО, а иногда конкурентов друг с другом пришла к Манифесту Agile-разработки программ , который приведен на титульной странице данного web-сайта.
Поскольку в Манифесте изложены некоторые специфические идеи, имеются углубленные темы, которые интересуют многих, но, честно говоря, не всех членов альянса. В конце двухдневных совещаний Боб Мартин пошутил, что он был готов высказаться крайне эмоционально. Но, поддавшись шутке, мало кто не согласился с чувствами Боба - так мы все чувствовали преимущество работы с группой людей, которые поддерживали набор непротиворечивых ценностей, набор ценностей, основанных на доверии и уважении друг к другу и продвижении организационных моделей, основанных на людях, сотрудничестве и построении типов организационных сообществ, в которых нам бы хотелось работать. По сути, я верю, что Agile-методологи - действительно "эмоциональны" - они нацелены на поставку хороших продуктов заказчикам, работая в среде, которая является большим, чем разговоры о том, что "люди - наш самый важный ресурс", и на самом деле "ведет себя" так, как будто люди являются самыми важными. И забудьте про слово "ресурс". Так, при конечном анализе, космический всплеск интереса, а иногда и шквальная критика Agile-методологий связана именно с эмоциональной стороной личностных ценностей и культуры.
Например, я думаю, что в конечном счете интерес к Extreme Programming и его использование выросли не из-за парного программирования или рефакторинга, а в следствие того, что взятые вместе практики, определенные сообществам разработчиков, освободились от багажа дильбертовых корпораций. Кент Бек рассказывает историю, случившуюся в самом начале его карьеры. Тогда он оценил трудозатраты на программирование как шесть недель для двух людей. После того, как его начальник перекинул второго программиста на другую работу в начале проекта, Кент завершил проект за двенадцать недель - и ужасно себя из-за этого чувствовал! Босс, разумеется, отчитал его за то, что он очень медленно работал во время последних шести недель. Кент несколько расстроился, поскольку чувствовал себя "программистом-неудачником", но потом понял, что его исходная оценка в шесть недель была очень точна для двух человек, и что его "неудача" на самом деле была ошибкой менеджера. В самом деле, неудача стандартного "фиксированного" взгляда на процесс постоянно терзает нашу отрасль.
Ситуации такого типа происходят каждый день, маркетологи или менеджеры, либо же внешние заказчики или внутренние заказчики и, да-да, даже разработчики - не хотят принимать тяжелые компромиссные решения, так что они возлагают нерациональные требования, используя для этого корпоративные властные структуры. Это является не только проблемой разработчиков ПО, это происходит в дильбертовых организациях.
Для того, чтобы преуспеть в новых экономических условиях, агрессивно прорываться в эру e-бизнеса, e-коммерции и Интернет, компании должны отказаться от проявления дильбертовского подхода к работе и установления загадочных корпоративных правил. Такая свобода от бессодержательных моментов корпоративной жизни привлекает сторонников Agile-методологий и до смерти пугает сторонников традиционного подхода. Если быть совсем откровенным, Agile-подходы отпугивают корпоративных бюрократов, по крайней мере тех из них, кто с радостью осуществляет процесс ради процесса вместо того, чтобы стремиться как можно лучше решить задачу заказчика и поставить нечто реальное вовремя и "как обещали", поэтому они разбегаются и прячутся по щелям.
Agile-движение - вовсе не антиметодология, фактически, многие из нас хотят восстановить доверие к слову "методология". Мы хотим восстановить баланс. Мы включаем моделирование, но не для того, чтобы начертить диаграммы для отчета и добавить их в пыльный корпоративный репозиторий. Мы за работу с документацией, но против сотен страниц никогда не обновляемых и редко используемых томов. Мы планируем, но осознаем ограниченность рамок планирования в бушующем реальном мире. Те, кто станет преподносить сторонников XP или SCRUM, либо другой Agile-методологии как хакеров - не разбираются ни в одной из двух методологий и в значении термина "хакер".
Встреча на Сноуберде возникла после более ранней встречи сторонников XP и нескольких "аутсайдеров", которую организовал Кент Бек в Rogue River Lodge в Орегоне весной 2000 года. На этой встрече участники высказались за поддержку разновидностей "легких методик", однако не произошло ничего формального. В течение 2000 года было написано много статей о "легких" и "легковесных процессах". Многие их этих статей ссылались на "легкие" методологии, такие как Extreme Programming, Adaptive Software Development, Crystal и SCRUM. В разговорах никому не нравилось название "легкие", но на то время термин устоялся.
В сентябре 2000 года Боб Мартин из Object Mentor (Чикаго) назначил следующую встречу, написав электронное письмо: "Я бы хотел собрать небольшую (двухдневную) конференцию в январе-феврале 2001 года здесь, в Чикаго. Цель этой конференции - собрать в одной комнате всех лидеров легковесных методов. Вы все приглашаетесь, и мне также интересно, кого еще следует пригласить". Боб установил Wiki-сайт, и понеслась бурная дискуссия.
Еще ранее Алистэр Коуберн упомянул в своих посланиях, что он cчитает неподходящим слово ‘Light’ (легкий): "Я не возражаю, что методологии могут называться легкими или тяжелыми, но я не уверен, что хочу, чтобы на меня ссылались как на легковесного участника конференции легковесных методологов. Это как-то ассоциируется с горсткой худых, дистрофичных, легковесных людей, пытающихся вспомнить, какое сегодня число".
Серьезные баталии проходили при обсуждении места проведения! Были серьезные возражения против Чикаго в зимнее время года: холодно и нечего делать. В Сноуберде (Юта) тоже холодно, но есть чем заняться, по крайней мере тем, кто катается на лыжах и на своих головах, как в первый же день сделал Мартин Фаулер. В Ангилье на Карибских островах жарко и весело, но дорого добираться. В конечном счете, Сноуберд и катание на лыжах победили, однако несколько человек, например, Рон Джеффрис, высказались за более теплое место в следующее время.
Надеемся, что наша совместная работа - работа альянса Agile помогла другим в нашей профессии рассуждать о разработке ПО, методологий и организаций новыми, более Аgile-способами. Если это так - мы достигли своих целей.
Джим Хайсмит, для альянса Agile
©2001, Джим Хайсмит
Авторы Agile-манифеста
Майк Бидли (Mike Beedle) - основатель и генеральный директор корпорации e-Architects, консалтинговой компании, специализирующейся в области разработки приложений с использованием распределенных объектов и интернет-технологий. Несмотря на занятие бизнесом, Майк остался в строю как консультант на передовой. Так, он применяет Scrum и XP совместно в процессе XBreed. Майк имел привилегию освоить методологию Scrum в период ее зарождения и внедрил Scrum в семи организациях с середины 90-х годов. Майк специализируется на проведении тренингов для компаний по созданию больших, масштабируемых, повторно используемых архитектур, в создании которых задействовано несколько команд разработчиков. Так, на его счету 17 приложений с повторно используемыми компонентами, такими как процессы обработки, визуальные компоненты, транзакции, бизнес-объекты и архитектурные сервисы. Майк публикуется в нескольких областях, включая объектную технологию, шаблоны, компоненты, среды разработки (frameworks), разработку ПО, языки программирования, повторное использование (reusability), процессы обработки (workflow), реинженерии бизнес-процессов (BPR, Business Process Reengineering) и физику. В течение последнего десятилетия он участвовал в организации нескольких конференций по объектно-ориентированным технологиям, шаблонам, компонентам и разработке ПО. Совместно с Кеном Швабером (Ken Schwaber, Prentice Hall, осень 2001 года) он является соавтором "Scrum, Agile-разработка ПО" - книги, которая бросает вызов традиционным взглядам на разработку ПО как на на производственный процесс, каким программная индустрия виделась в последние 20 лет, предлагая рассматривать разработку ПО как разработку нового продукта.
Ари Ван Биннекум (Arie van Bennekum) с 1997 года активно задействован в DSDM (Dynamic System Development Method, Динамический метод разработки систем) и консорциуме DSDM. Перед этим он работал над RAD (Rapid Application Development). Его страсть к Agile-методам основана на поставке заказчикам того, что им действительно нужно, того, что удовлетворяет как конечных пользователей, так и рынок. Из-за понимания важности модерируемых совещаний в методе DSDM, а также страстного увлечения групповыми процессами и человеческим поведением он часто привлекался в проектах в качестве модератора и инструктора-наставника. В настоящее время он является членом совета DSDM Consortium Benelux и аккредитован как DSDM-профессионал, DSDM-тренер, DSDM-консультант и IAF сертифицированный профессиональный модератор (CPF, Certified Professional Facilitator).
Алистэр Коуберн (Alistair Cockburn) - основатель Humans and Technology, известен своими многочисленными интервью с проектными командами. Эти интервью, совместно с его активным участием в реальных проектах, сформировали основу для его методологических проектов - легковесных, но достаточных и саморазвивающихся. Работа Алистэра в 90-х годах прошлого века вылилась в создание семейства Agile-методологий Crystal. Алистэр и Джим Хайсмит (Jim Highsmith) сейчас совместно работают над развитием идей Crystal и Adaptive и созданием на их основе рекомендаций по экосистемам Agile-разработки ПО и приспособлению общей методологии к частным ситуациям проектных команд. Алистэр и Джим участвуют в спонсорской поддержке серии книг по Agile-разработке ПО, в которых будут опубликованы методы персонального роста и примеры успешно примененных Agile-методологий.
Вард Каннингэм (Ward Cunningham) - основатель корпорации Cunningham & Cunningham. Перед этим он работал директором отдела исследований и разработки в Wyatt Software и главным инженером в компьютерной исследовательской лаборатории Tektronix. Вард хорошо известен своим вкладом в развивающуюся практику объектно-ориентированного программирования, вариацию, называемую экстремальным программированием (Extreme Programming), и своими сообществами, которые хостятся на его WikiWikiWeb. Он сотрудничал с Hillside Group и был главой программного комитета на спонсировавшейся им конференции по шаблонным языкам программ. Вард создал метод проектирования на основе CRC, что дает командам возможножность определить базовые объекты в своих программах. Вард публиковался в PLoP, JOOP и OOPSLA по тематике шаблонов, объектов, CRC и смежным темам.
Мартин Фаулер (Martin Fowler) - ведущий научный сотрудник Thoughtworks - компании, занимающейся разработкой ПО и консалтингом. Он десятилетиями занимался вопросами использования объектно-ориентированных методов для информационных систем. Хотя в первую очередь в сферу его интересов попадает проектирование ПО, он никогда не мог избежать процессов разработки ПО и всегда интересовался подходами, которые делают методологию подходящей для людей, а не наоборот. Он является автором книг "Analysis Patterns", "UML. Основы" ("UML Distilled"), "Рефакторинг" ("Refactoring") и "Экстремальное программирование: планирование" ("Planning Extreme Programming").
Джим Хайсмит (Jim Highsmith) - основной разработчик Agile-метода "Adaptive Software Development" ("Адаптивная разработка ПО") и автор одноименной книги. Он докладывал (или посылал доклады) об адаптивной разработке и других Agile-методах на таких конференциях как OOPSLA, Cutter Summit, SD 2001, XP2001 & Flexible Processes, Project World, and XP Universe. Джим в соавторстве с Мартином Фаулером опубликовал статью "The Agile Manifesto" ("Манифест Agile") в августовском номере журнала "Software Development" за 2001 год. Джим и Алистэр Коуберн работают над объединением методов ASD и Crystal, а также совместно редактируют новую серию книг Addison-Wesley по Agile-разработке ПО. Джим работает над книгой, описывающей все Agile-методы.
Эндрю Хант (Andrew Hunt) - партнер в Pragmatic Programmers и соавтор бестселлера "The Pragmatic Programmer: From Journeyman to Master", новой книги "Programming Ruby" и различных статей. В промежутках между писательством, публичными выступлениями, работой по дереву и игрой на пианино Энди находит время для своего консалтингового бизнеса, специализируясь на Agile-разработке ПО. Энди занимался профессиональным созданием ПО с начала 80-х годов для различных отраслей, таких как телекоммуникации, банки, финансовые, коммунальные службы, работа с медицинскими изображениями, графическим искусством и интернет-службы. Энди обосновался в Raleigh NC и в соавторстве с Дэйвом Томасом известен привнесением независимых от метода, прагматичных, зарекомендовавших себя подходов в проекты по разработке ПО на территории Соединенных Штатов. Он является президентом отдела RTP ассоциации Independent Computer Consultant's Association и член ACM и IEEE.
Рон Джеффрис (Ron Jeffries) - владелец XProgramming.com, консультант Object Mentor и автор (совместно с Ann Anderson и Chet Hendrickson) книги Extreme Programming Installed. Рон был первым инструктором по экстремальному программированию и активно дискутировал в связанных с XP интернет-группах, а также был частым докладчиком на конференциях по ПО.
Джон Керн (Jon Kern) применил объектно-ориентированные принципы и принципы системной инженерии к разработке Agile ПО на C++ в ранние периоды. Он писал о методологии инкрементальной и итеративной разработки в (что достаточно странно) руководствах по Lotus Notes 4.5 и 5.0. Его вдохновляла мантра Питера Кода (Peter Coad) о поставке "частого, реального, работающего результата", и с 1994 года Керн использовал возможности объектного моделирования Together для согласованного хранения кода и диаграмм моделирования как два взгляда на одно целое. Джон является соавтором Java Design, работал с Питером и Джеффом де Лука (Jeff De Luca) (главный идеолог FDD) над созданием главы Feature-Driven Development (FDD, функционально-ориентированная разработка) в книге Java Modeling in Color with UML. Джон продолжает пытаться улучшать собственную команду разработчиков, сочетая аспекты XP, FDD и постоянно обучаясь.
Брайн Марик (Brian Marick) - программист и консультант по тестированию ПО. Он приехал в Сноуберд как представитель той части сообщества тестеров, которая разрабатывает подходы к тестированию, делающие упор на исследовании, уменьшает зависимость от документации, повышает приемлемость изменений и понимание того, что проект - постоянный диалог о качестве. На своей web-странице в секции Agile-тестирование он начинает исследование того, что может пониматься под термином "Agile-тестирование" и как это согласуется с Agile-разработкой ПО.
Роберт Мартин (Robert C. Martin) - профессионал в разработке ПО с 1970 года. Он является президентом и основателем корпорации Object Mentor, фирмы, в которой работают специалисты высокой квалификации, занимающиеся консультациями по XP и Agile-процессам, проектированию ПО, тренингами и разработкой ПО для большого количества корпораций по всему миру. В 1995 году Мартин написал бестселлер "Designing Object Oriented C++ Applications using the Booch Method", выпущенной Prentice Hall. В 1997 он был главным редактором книги "Pattern Languages of Program Design 3", изданной Addison Wesley. В 1999 году он редактировал "More C++ Gems", опубликованной издательством Cambridge Press. Также является соавтором книги "XP in Practice" совместно с Джеймсом Ньюкирком (James Newkirk), издательство Addison Wesley, 2001 год. В настоящее время Роберт Мартин работает над "Principles, Patterns, and Practices of Agile Software Development", которая будет опубликована Prentice Hall в 2002 году. С 1996 по 1999 годы он был главным редактором C++ Report. Им опубликованы десятки статей в различных профессиональных журналах, он постоянный докладчик на международных конференциях и профессиональных презентациях.
Кен Шваубер (Ken Schwaber) - президент Advanced Development Methods (ADM), компании, которая занимается улучшением процесса разработки ПО. Он опытный разработчик ПО, менеджер продукта и производственный консультант. В начале 90-х годов Шваубер инициировал революцию в управлении процессами и также работал совместно с Джеффом Сазерлендом (Jeff Sutherland) над формулированием начальной версии процесса разработки Scrum. В течение последних пяти лет он формализовал Scrum, содействовал многим организациям в успешном внедрении продуктов и систем с использованием Scrum’a и в соавторстве с Майком Бидли (Mike Beedle) написал "Scrum, Agile Software Development" (Prentice Hall, осень 2001-го).
Джефф Сазерленд (Jeff Sutherland) - технический директор PatientKeeper - молодой компании, дочерней организации Массачусетского института технологии (MIT), разрабатывающей приложения для мобильных/беспроводных платформ для здравоохранения. Он работал техническим директором и вице-президентом в девяти компаниях, занимающихся программными технологиями, и в каждой из них внедрил Agile-процессы разработки. Его работа над повторно используемыми бизнес-объектами в рамках Object Management Group и OOPSLA Business Object Workshop в прошлом десятилетии привела к созданию новых СУБД, сред разработки ПО, CASE/OOAD средств, а также вертикальных приложений во многих отраслях. Являясь основателем и вице-президентом корпорации Individual, Джефф сделал личную новостную страницу. Во время пребывания на посту вице-президента и технического директора IDX Systems он разрабатывал новые интернет-приложения для медицинских учреждений. Его работы над крупными программными проектами вылились в новшества в банковских, страховых и библиотечных системах, в аэрокосмической отрасли, в системах авиационного лизинга, в ядерной инженерии и робототехнике. Также изобрел процесс разработки SCRUM и благодаря организационному опыту постоянно делал возможным создание высокопроизводительными командами разработчиков программных продуктов мирового класса. Изучайте деятельность Джеффа!
Дэйв Томас (Dave Thomas) верит в то, что сердце любого проекта - отнюдь не методология, а люди. Члены команды должны быть технически компетентны, целеустремленны и сработанны. Такая концентрация на персонале была одной из причин для его соавторства над книгой "The Pragmatic Programmer". Однако технической стороны недостаточно. Каждый член команды должен быть задействован: задействован в своей работе, задействован в команде, задействован в организации. Дейв и Энди в настоящий момент работают над способами оказания помощи людям в осуществлении перехода к Agile-методологиям. |
Страница сайта http://silicontaiga.ru
Оригинал находится по адресу http://silicontaiga.ru/home.asp?artId=4888
|