Роберт Мартин

••••

Получить доступ

Отзывы на книгу «Чистый Agile»

Проделав огромный путь, Agile, не без помощи того самого Дяди Боба, достиг вершин. Безусловно, эта история знает свои взлеты и падения. Восхитительная книга, которую вы сейчас держите в руках, сочетает в себе историческую хронику и мемуары. Вся мудрость Agile собрана здесь. Если вам интересно, что такое Agile и как он появился, – эта книга для вас.

Гради Буч

Разочарования Дяди Боба пронизывают каждую строку «Чистого Agile», но, поверьте, эти разочарования оправданны. Все, что создано в мире Agile, – просто капля в море по сравнению с тем, что еще можно из него сотворить. Эта книга – взгляд Дяди Боба на перспективу. Его вклад велик. Его стоит послушать.

Кент Бек

Полезно почитать о том, что Дядя Боб думает об Agile. Может быть, вы новичок, а может, уже матерый спец – в любом случае вы найдете в этой книге что-то для себя. Я подписываюсь почти под каждым словом в ней. В некоторых главах я вижу свои собственные недостатки, что греха таить. Теперь я проверяю наш код дважды, а это 85,09 %.

Джон Керн

В этой книге, словно под увеличительным стеклом, можно в подробностях разглядеть методологию Agile. Дядя Боб, несомненно, один из умнейших людей, которых я знаю. Его рвение к программированию бесконечно. Он как никто другой может развеять мистический туман, сгустившийся над Agile.

Из предисловия Джерри Фицпатрика

Всем программистам, кто хоть раз боролся с ветряными мельницами или водопадами

Глава 1. Введение в Agile

В феврале 2001-го группа из семнадцати экспертов в области разработки программного обеспечения собралась в городке Сноуберд, штат Юта. На собрании обсуждалось плачевное состояние отрасли. Тогда большинство программ создавалось посредством неэффективных тяжеловесных фреймворков с большим количеством ритуалов, наподобие каскадной модели и раздутых реализаций Rational Unified Process (RUP). Целью этих экспертов было создание манифеста, который провозглашал бы более эффективный и легковесный подход.

Нельзя сказать, что царило единодушие. У всех семнадцати был разный опыт и, соответственно, сильные расхождения во мнениях. Рассчитывать, что такое собрание быстро придет к общему мнению, было бы слишком наивно. И все же, несмотря на все трудности, согласие было достигнуто, и Манифест Agile увидел свет – так родилось одно из самых мощных и живучих движений в отрасли программного обеспечения.

В этой отрасли практически все движения происходят по одному и тому же пути. Поначалу есть меньшинство, восторженно выступающее в поддержку чего-либо, другое меньшинство заряженных критиков и подавляющее большинство – те, кому, мягко говоря, нет дела.

Многие из этих движений хиреют или никогда не проходят этот этап. Можно вспомнить аспектно-ориентированное программирование, логическое программирование или CRC-карты. Некоторые, однако, способны преодолеть такую пропасть, становясь чрезвычайно популярными и разносторонними. Некоторым удается оставить позади противоречия и занять господствующее положение в современной мысли. Объектно-ориентированное мышление можно считать примером последнего случая. И Agile тоже.

К сожалению, как только движение набирает последователей и начинает распространяться, то сталкивается с искажением и незаконным присваиванием. Продукция и методики, не имеющие ничего общего с оригинальным движением, присваивают чужое имя, чтобы нажиться на его славе и значимости. Так случилось и с Agile.

Эта книга, написанная спустя почти два десятка лет после событий в Сноуберде, ставит своей целью точно передать посыл идеи. Эта книга – попытка в высшей мере кратко и точно описать Agile без брехни и обиняков.

В ней представлены основные принципы Agile. В приукрашивании и расширении этих идей нет ничего плохого. Тем не менее производные от Agile – это уже не сам Agile. Это дополненный Agile со своими опциями. А то, о чем вы узнаете из этой книги, – это и есть тот самый чистый Agile, который всегда был и непременно будет.

История Agile

Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели. Идея постановки небольших промежуточных целей и измерения продвижения после их достижения у человека проявляется на подсознательном уровне, поэтому вряд ли это какая-то настоящая революция.

Когда впервые появился Agile в современном мире? Трудно сказать. В моем представлении, первый паровой двигатель, первая мельница, первый двигатель внутреннего сгорания, первый самолет были созданы с помощью методик, которые сейчас можно отнести к Agile. Я считаю так, потому что предпринимать небольшие измеряемые шаги очень естественно для человека, сложно представить, что это происходит иначе.

Так когда же Agile появился среди программистов? Хотел бы я быть мухой на стене у Алана Тьюринга, когда тот писал свою книгу в 1936 году[4]. По моим догадкам, многие свои «программы» он написал, разбивая работу на мелкие этапы с изобилием отладки по исходному тексту вручную.

Я также хорошо представляю, что первый код, который он написал для автоматической вычислительной машины (Automatic Computing Engine, ACE) в 1946 году, был написан постепенно, маленькими этапами, с частым проведением ручной отладки по исходному тексту и даже с небольшим тестированием в действии.

В первые дни существования программного обеспечения можно найти много примеров решения задач, которые сейчас бы отнесли к Agile. Например, программисты, писавшие код для управления пилотируемым космическим кораблем «Меркурий», работали по этапам с интервалом в полдня с перерывами на модульное тестирование.

Об этом периоде есть много материалов. Крэг Ларман и Вик Базили написали историю, которая кратко изложена в «вики» Уорда Каннингема[5], а также в книге Лармана Agile & Iterative Development: A Manager's Guide[6].

Однако существовал не только Agile. Действительно, есть конкурирующая методология, которая пользовалась значительным успехом в производстве и промышленности в целом: научная организация труда.

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

Научная организация труда, вероятно, такая же древняя, как пирамиды в Египте, Стоунхендж или прочие подобные работы древних времен: с трудом верится, что можно работать по-другому. Еще раз замечу, идея повторять успешный опыт настолько глубоко подсознательно заложена в человеке, что ее сложно охарактеризовать как революционную.

Научная организация труда получила свое название из работ Фредерика Уинслоу Тейлора, написанных в 1880-х. Тейлор сформировал этот подход, придав ему коммерческую ценность и сделав состояние на консультировании по управлению. Метод получил широкий успех и привел к значительному повышению эффективности и производительности в последующие десятилетия.

И так случилось в 1970-е, что мир разработчиков программного обеспечения разделился на два лагеря – сторонников того или иного метода. Прото-Agile (Agile, еще не получивший название «Agile») предлагал предпринимать в зависимости от обстоятельств небольшие случайные шаги, которые можно измерить и выделить, для того чтобы идти в правильном направлении к наилучшему исходу. Научная организация труда призывала откладывать действие до тщательного анализа и проработки заранее подготовленного плана. Прото-Agile прекрасно подходил для проектов с низкой стоимостью внесения изменений, которые решали частично определенные задачи с произвольно поставленными целями.

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

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

В 1970 году Уинстон Ройс в своей работе[7] описал идеи для управления крупномасштабными проектами по разработке программного обеспечения. В этой работе присутствовала схема (рис. 1.1), которая наглядно изображала его план. Ройс не был автором этой схемы и не продвигал ее в качестве плана. В действительности график представлял собой изображение соломенного человечка и помогал Ройсу ориентироваться в последующих страницах своего труда.

Схема была расположена на видном месте. А учитывая, что люди делают логические выводы о содержании статьи, посмотрев схему на первой или второй странице, это привело к резкому сдвигу в отрасли программного обеспечения.

Схема, первоначально составленная Ройсом, гораздо больше напоминала ручей, стекающий вниз со скалистого хребта, чем ныне известную каскадную модель.

Каскадная модель стала логическим продолжением научной организации труда. При использовании этой модели на первый план ставится тщательный анализ, составление подробного плана, а затем уже доведение этого плана до завершения. Хотя Ройс и не рекомендовал такой подход, но именно эту концепцию вынесли из его работы. А потом эта концепция главенствовала в отрасли более трех десятков лет[8].

Как раз тогда и начинается моя история. В 1970-м мне было 18 лет, я работал программистом в компании A.S. C. Tabulating, расположенной в Лейк Блафф, Иллинойс.

У компании был компьютер IBM 360/30 с памятью на магнитных сердечниках 16 килобайт, IBM 360/40 с памятью 64 килобайта и микрокомпьютер Varian 620/f с памятью 6 килобайт. Я писал программы для семейства 360 на COBOL, PL/1, Fortran и ассемблере. Для 620/f я писал только на ассемблере.

Важно помнить, каково в то время было программистам. Мы писали код в программных формулярах с помощью карандашей. У нас были операторы, работающие за перфоратором, которые наносили программы на карты. Мы передавали тщательно выверенные перфокарты операторам ЭВМ, которые проводили компиляцию и тестирование в третью смену, поскольку днем, когда работа кипела, компьютеры были постоянно заняты. От начала написания кода до первой компиляции зачастую проходило несколько дней, каждый цикл разработки вследствие этого занимал, как правило, сутки.

Для меня 620/f выглядел несколько иначе. Эту машину выделили нашей команде, поэтому мы могли работать на ней столько, сколько вздумается. Мы проводили два, три, иногда даже четыре цикла разработки и тестирования за сутки. Вместе со мной в команде были люди, которые, в отличие от большинства программистов того времени, умели печатать. Поэтому мы могли штамповать свои собственные колоды перфокарт, а не зависеть от капризов операторов, работающих за перфоратором.

Какую методологию мы использовали на протяжении того времени? Это, конечно, была не каскадная модель. У нас не было концепций или подробных планов. Мы просто писали код каждый день, компилировали, тестировали и устраняли ошибки. Это был бесконечный цикл без структуры. Также это был не Agile и даже не прото-Agile. В ходе работ мы не придерживались каких-либо правил организации. Тогда не было каких-либо пакетов программ для тестирования и измеряемых временных интервалов. Просто надо было писать код и фиксить баги. День за днем, месяц за месяцем.

Впервые я узнал о каскадной модели из профессиональных журналов около 1972 года. Мне она казалась даром свыше. Неужели мы могли бы проанализировать задачу, потом предложить ее решение, а затем реализовать замысел? Реально ли было на самом деле разработать график, основанный на трех перечисленных этапах?

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

Судя по всему, я был не один, потому что многие другие программисты и центры программирования тоже вошли в кураж. И, как я уже писал, в нашем мышлении начала преобладать каскадная модель.

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

Несмотря на практически нескончаемый поток неудач, мы все равно настаивали на состоятельности каскадной модели. В конце концов, почему возникали неудачи? Почему тщательный анализ задачи, внимательное проектирование решения и последующая реализация нескончаемо терпят зрелищный крах? Никто даже подумать не мог, что дело было в самой стратегии. Задача должна была лечь на наши плечи. Как бы то ни было, что-то мы делали не так.

Чтобы увидеть, насколько каскадная модель захватила наши умы, посмотрите на программные языки того времени. Когда Дейкстра в 1968 году представил структурное программирование, структурный анализ[9] и структурный дизайн[10] не сильно отставали. В 1988 году, когда объектно-ориентированное программирование (ООП) набрало популярность, объектно-ориентированный анализ[11] и объектно-ориентированное проектирование[12] также не сильно отставали. Эта тройка идей, эти три этапа словно держали нас в плену. Мы просто не могли представить, что можно работать как-то по-другому.

А потом оказалось, что можно.

Зародыши преобразований, связанных с Agile, появились в конце 1980-х или в начале 90-х. В сообществе Smalltalk их признаки начали проявляться в 1980-х. В книге Буча по объектно-ориентированному проектированию, вышедшей в 1991-м, были намеки на них. Прочие решения возникли в 1991 г. в книге Кокберна Crystal Methods. Сообщество Design Patterns начало обсуждать это в 1994-м под влиянием статьи, написанной Джеймсом Коплиеном[13].

К 1995 году Бидл[14], Девос, Шэрон, Швобер и Сазерленд написали свои знаменитые труды о Scrum (Скрам)[15]. И затворы открылись. На бастионе каскадной модели образовалась брешь, и пути назад не было.

И здесь я снова возвращаюсь к нашей истории. То, что я расскажу дальше, – мои личные воспоминания, я не сверял их ни с кем из современников, участников событий. Поэтому следует предположить, что в моих воспоминаниях много опущений, недостоверностей или изложены они ужасно беспорядочно. Но не переживайте, я по крайней мере постарался рассказать все занимательно.

В первый раз мы встретились с Кентом Беком в 1994 году на той самой конференции PLoP[16], когда Коплин представил свою работу. Это была неформальная встреча, которая толком ничего не принесла. В следующий раз я встретил его в феврале 1999-го в Мюнхене на конференции, посвященной ООП. Но к тому времени я уже знал о нем намного больше.

В то время я занимался консультированием по C++ и объектно-ориентированному проектированию, летал с места на место, помогал разрабатывать и реализовывать приложения на C++ с помощью методик объектно-ориентированного проектирования.

Клиенты стали расспрашивать меня о процессе. Они слышали, что каскадная модель не применяется в объектно-ориентированном проектировании, и хотели услышать от меня совет. Я согласился с ними[17] и стал дальше думать об этом, мысли захватывали меня все сильнее.

Я даже подумывал написать свою собственную объектно-ориентированную методологию. К счастью, я скоро прекратил эти попытки, поскольку мне в руки попали труды Кента Бека по экстремальному программированию (XP).

Чем больше я читал об экстремальном программировании, тем больше я увлекался им. Идеи были революционны (по крайней мере, я тогда так думал). Они казались разумными, особенно в контексте объектно-ориентированного мышления (опять же на тот момент я думал именно так). Мне не терпелось узнать больше.

К моему удивлению, на той самой конференции в Мюнхене, посвященной объектно-ориентированному программированию, я заметил, что через зал от меня читает лекцию сам Кент Бек. Как-то раз во время перерыва я натолкнулся на него и предложил встретиться как-нибудь за завтраком, чтобы обсудить экстремальное программирование. На том завтраке был заложен фундамент для плодотворного партнерства. Наши обсуждения побудили меня полететь к нему в Медфорд, штат Орегон, чтобы совместно разрабатывать курс по экстремальному программированию.

В ходе этого визита я впервые попробовал поучаствовать в разработке через тестирование, и это меня увлекло.

В то время под моим управлением была компания Object Mentor. В сотрудничестве с Кентом Беком мы хотели предложить пятидневный учебный курс по экстремальному программированию, который назывался XP Immersion. С конца 1999-го по 11 сентября 2001 года[18] он производил настоящий фурор! Мы обучили сотни человек.

Летом 2000 года Кент Бек созвал кворум из сообщества по экстремальному программированию и паттернам. Встреча проходила недалеко от его дома. Он назвал ее встречей ведущих специалистов в области экстремального программирования. Мы катались на лодках и прогуливались по берегу реки Рог. И заодно решали, что делать дальше с экстремальным программированием.

Была идея создать некоммерческую организацию. Я ее горячо продвигал, но многие не разделяли моего энтузиазма. Видимо, у них был неблагоприятный опыт со схожей организацией в поддержку паттернов проектирования. Я был расстроен тем, как прошло заседание. Но Мартин Фаулер поддержал меня и предложил встретиться позже в Чикаго, чтобы все обсудить и выговориться. Я согласился.

С Мартином мы встретились осенью 2000 года в кафе неподалеку от офиса Thought Works, где он работал. Я описал ему свою идею собрать сторонников всех конкурирующих легковесных методологий и составить манифест, провозглашающий единство. Мартин сделал несколько рекомендаций касательно пригласительного списка. Мы вместе начали составлять приглашение. В тот же день, немного позже, я отправил это письмо. Темой письма было проведение встречи по обсуждению легковесных методологий.

Одним из приглашенных был Алистер Кокберн. Он позвонил мне и сказал, что тоже подумывал провести подобную встречу, однако наш список ему понравился больше, чем его собственный. Он предложил объединить наши пригласительные списки и договориться о встрече, если мы согласимся провести ее на горнолыжном курорте Сноуберд неподалеку от Солт-Лейк-Сити.

Итак, встреча намечалась в Сноуберде.

Сноуберд

Я был немало удивлен тем, что так много людей решило посетить мероприятие. Неужели кому-то действительно была интересна встреча, темой которой были легковесные методологии?

Однако мы все собрались в Сноуберде в гостиничном номере с прекрасным видом из окна.

Пришли 17 человек. С тех пор нас не раз критиковали за то, что все собравшиеся были белыми мужчинами среднего возраста. Критика была бы вполне справедлива, если бы не одно «но». Дело в том, что в списке приглашенных фигурировала одна женщина – Агнета Якобсон, но она не смогла приехать.

И, в конце концов, в то время во всем мире подавляющее большинство квалифицированных программистов было белыми мужчинами среднего возраста. А вот почему так сложилось – это отдельная история для совершенно другой книги.

У всех 17 из нас были довольно разные взгляды на пять различных легковесных методологий. Сторонников экстремального программирования было больше всех. Это были Кент Бек, Джеймс Греннинг, Уорд Каннингем, Рон Джеффрис и я.

Сторонников Scrum было немного меньше – Кен Швабер, Майк Бидл и Джефф Сазерленд.

Джон Керн высказывался в поддержку разработки, управляемой функциональностью, а Ариван Беннекум был сторонником метода разработки динамических систем. Наконец, Алистер Кокберн выступал за семейство методик, являвшихся его собственной разработкой – Crystal.

Остальные участники были относительно самостоятельны. Например, Энди Хант и Дейв Томас пропагандировали прагматизм в программировании. Они даже написали работу на эту тему. Брайан Марик был консультантом по тестированию. Джим Хайсмит был консультантом по управлению разработкой и сопровождению программного обеспечения. Стив Меллор следил за честностью каждого, потому что был сторонником подходов, управляемых моделями, к которым многие из нас относились с недоверием. И, наконец, присутствовал Мартин Фаулер. У него были личные взаимоотношения с командой, занимавшейся экстремальным программированием, однако к каким-либо «фирменным» методикам он относился довольно скептически. Мнения всех присутствующих он воспринимал благожелательно.

Я почти ничего не помню из того, что произошло за два дня нашей встречи. Другие участники событий видят картину по-своему, не так, как я[19]. Поэтому просто расскажу вам то, что сам помню. Расценивайте мои слова как воспоминания пожилого человека. Мне уже 65, а с того времени прошло почти два десятка лет. Возможно, я упустил несколько подробностей, но суть, думаю, передал правильно.

Каким-то образом мы решили, что я буду открывать встречу. Я поблагодарил всех за присутствие и высказал мнение, что наша цель состоит в составлении манифеста, в котором бы говорилось о разработке программного обеспечения в целом и описывались общие черты всех легковесных методологий, подмеченные нами. Закончив, я сел.

Я считаю, что это был мой единственный вклад в проведение встречи.

Мы не занимались ничем необычным, когда записывали различные проблемы на карточках, а затем сортировали их на полу в группы по сходству. На самом деле я понятия не имею, что это нам дало. Просто помню, что мы это делали.

Затрудняюсь сказать, на какой день произошло чудо, – на первый или второй. Как мне кажется, это произошло к концу первого дня.

Возможно, именно группирование по сходству помогло нам выделить четыре ценности: личности и взаимодействие, рабочее программное обеспечение, взаимодействие с клиентами и реагирование на изменения. Кто-то написал это на магнитно-маркерной доске, находившейся в передней части комнаты. Затем ему в голову пришла блестящая мысль о том, что эти ценности приоритетны, но не заменяют остальные взаимодополняющие ценности методов, инструментов, документации, договоров и планов.

Это ключевая идея Манифеста Agile, и, кажется, никто отчетливо не помнит, кто первый обозначил ее на доске. Как мне помнится, это был Уорд Каннингем. Но сам Уорд приписывает это авторство Мартину Фаулеру.

Посмотрите на фотографию на сайте agilemanifesto.org. Уорд говорит, что сделал снимок, чтобы запечатлеть тот самый момент. На фото можно разглядеть Мартина Фаулера у доски и прочих участников встречи, которые собрались вокруг него[20]. Это придает правдоподобность высказыванию Уорда о том, что идея на самом деле принадлежала Мартину.

С другой стороны, возможно, и хорошо, что мы никогда уже этого не узнаем точно.

Как только произошло чудо, все собравшиеся объединились под его знаменем. Мы проявляли таланты ораторского мастерства, как могли. Насколько мне помнится, именно Уорд написал преамбулу к Манифесту, которая гласила: «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим». Некоторые из нас внесли крошечные изменения и предложения, однако было ясно, что мы достигли согласия. В номере ощущалась изоляция от всего мира. Никаких разногласий. Никаких споров. Никаких обсуждений или альтернатив. В этих четырех строках была вся суть.

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

Я говорил, что это все? Тогда так и казалось. Но, конечно, предстояло прояснить много частностей. Первая их них – как назвать то, что нам удалось определить?

Название Agile не сулило легкого успеха. Было много разных претендентов. Мне понравилось что-то вроде «легковесный» (lightweight), но кроме меня – никому. Остальные считали, что в таком названии подразумевалась несущественность. Им полюбилось слово «адаптивный» (adaptive). Кто-то вспомнил слово agile[21], а кто-то заметил, что в то время это слово было в ходу в армии. В результате, хотя никому особо не нравилось слово agile, его выбрали в качестве названия как наименьшее из зол.

Когда второй день подходил к концу, Уорд вызвался самостоятельно сделать сайт agilemanifesto.org и опубликовать манифест. Полагаю, что выставить манифест на всеобщее обозрение – его идея.

После событий в Сноуберде

Следующие две недели были не столь насыщенны и романтичны, как те два дня в Сноуберде. В основном это время было занято трудоемкой работой над составлением документа, провозглашавшего наши ценности, который Уорд в итоге выложил на сайт.

Мы все соглашались в необходимости написать такой документ, чтобы показать и объяснить четыре ценности. Все же те четыре ценности являются своего рода утверждениями, с которыми каждый может согласиться, не внося при этом в их понимание никаких изменений. Принципы дают понимание того, что действие этих ценностей выходит за пределы второстепенного значения так называемых прописных истин.

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

Никто и подумать не мог, что нас так поддержат. Никто не ожидал, насколько судьбоносными окажутся те два дня. Но чтобы не задирать нос от своей важности и причастности, я непрестанно напоминаю себе о том, что Алистер Кокберн тоже был близок к проведению подобной встречи. И поэтому задаюсь вопросом, сколько еще было таких же, как я. Поэтому успокаиваю себя мыслью, что просто настало время, и если бы не мы, 17 человек, собравшихся в горах Юты, то собралась бы другая группа, которая пришла бы примерно к тому же самому.

Краткий обзор Agile

Как вести управление проектом по разработке и сопровождению программного обеспечения? На протяжении многих лет существовало много подходов – и большинство из них, мягко говоря, далеки от идеала. Надежды и молитвы распространены среди менеджеров, верующих в то, что судьба их проекта зависит от воли божьей. А те, кто в это не верит, частенько полагаются на мотивационные методики: жесткие сроки с наказаниями плетками, цепями, раскаленным маслом, фотографии людей, покоряющих скалы, и чаек, парящих над морем.

Подобные подходы почти повсеместно приводят к характерным признакам отвратительного управления проектами – команды разработчиков постоянно задерживают проект, несмотря на то что много работают сверхурочно. Команды, которые пишут программы явно низкого качества, не соответствующие потребностям клиентов.

Правило креста

Причина, по которой эти методы терпят крах, заключается в том, что менеджеры не понимают элементарную сущность программных проектов. Сама сущность любого проекта накладывает на него ограничения. Есть такое понятие в управлении проектами, как «правило креста». Хорошо, быстро, дешево, готово. Выбирайте три любых пункта. Но четвертый будет не под силу. Проект может быть одновременно хорошим, дешевым, быстро выполняться. Но он никогда не будет завершен. Проект может быть завершен, и быть при этом быстрым и дешевым. Но вот хорошим не выйдет.

Реальность диктует свои правила, и умелый менеджер понимает, что у всех четырех параметров есть свои коэффициенты. В руках грамотного менеджера проект будет достаточно хорошим и дешевым, достаточно быстро выполняться и при этом будет завершен на требуемом этапе. Умелый менеджер распределяет эти коэффициенты по нужным параметрам, а не выдвигает требования к проекту по всем параметрам на 100 %. Такой способ управления проектами старается внедрить Agile.

Сейчас я хотел бы убедиться в вашем понимании того, что Agile – это набор методов, помогающийразработчикам и менеджерам проявлять необходимый прагматизм в управлении проектами. Однако такое управление не достигается автоматически. Нет никаких гарантий, что менеджер примет уместное решение. Действительно, вполне можно работать в рамках набора методов Agile, но несмотря на это управление проектом будет неграмотным и проект провалится.

Конец ознакомительного фрагмента.