Если проект организован правильно, то заказчики в конечном итоге задумчиво покивают головой, соглашаясь со сказанным, и начнут тщательный пересмотр плана. По очереди, методом исключения, они определят тот функционал, который им нужен к ноябрю, как собаке пятая нога. Неприятно, но что поделать, если мы хотим адекватно организовать работу? Итак, план подгоняют под действительность. Некоторые функции оставляют на потом.
Порядок реализации функционала
Непременно будет так, что заказчики прицепятся к какой-то функции, которую мы уже реализовали, и скажут нам: «Позорище! Зачем вы это сделали? Нам это не надо».
Мы не хотим снова это выслушивать! Так что теперь в начале каждой итерации придется спрашивать заинтересованные стороны, какие функции реализовать следующими. Да, разные функции зависят друг от друга, но мы же программисты и должны справляться с этим. Так или иначе, мы будем реализовывать функции в том порядке, в котором попросят заинтересованные стороны.
Завершение обзора
Вот мы и рассмотрели Agile. Но пока что только издалека. В обзоре опущены многие подробности, но в нем вся суть гибкой методологии. Agile — это процесс, в котором проект разделяют на отрезки, называемые итерациями. Объем работ, проделанный во время каждой итерации, измеряют и исходя из этого выверяют график. Функционал реализуется в том порядке, в котором это удобнее заинтересованным сторонам. Функции, необходимые в первую очередь, реализуют в первую очередь.
Планку качества нужно держать как можно выше. График в основном зависит от объема выполняемых работ.
Это и есть Agile.
Жизненный цикл
Схема Рона Джеффриса, изображенная на рис. 1.8, объясняет принципы экстремального программирования. Эта схема также известна как «жизненный цикл».
Рис. 1.8. Жизненный цикл
Я посчитал, что для этой книги лучше всего подойдут методы экстремального программирования, потому что из всех методологий, составляющих Agile, экстремальное программирование является наиболее определенным, исчерпывающим и наименее замутненным.
Почти все прочие методологии, входящие в Agile, — это составляющие или разновидности экстремального программирования. Это не означает, что остальными методологиями, образующими Agile, нужно пренебрегать. Они могут быть очень ценны для различных проектов. Но чтобы понять, что такое Agile и с чем его едят, нет способа лучше, чем изучить экстремальное программирование. Оно прообраз, лежащий в основе Agile, который одновременно является его лучшей составляющей.
Кент Бек — отец экстремального программирования, а Уорд Каннингем — его дедушка. Эти два человека, работая совместно в компании Tektronix в середине 1980-х, исследовали множество идей, которые в конечном итоге породили экстремальное программирование. Впоследствии Бек придал этим идеям точную форму. Таким образом, около 1996 года появилось экстремальное программирование. В 2000 году Кент Бек обнародовал свою окончательную работу: Extreme Programming Explained: Embrace Change[26].
Жизненный цикл подразделяется на три кольца. Внешнее кольцо отражает методы экстремального программирования при взаимодействии с клиентами. Это кольцо, по сути, эквивалентно тому, что предлагает методология Scrum[27]. Эти методы обеспечивают структуру взаимодействия между командой разработчиков и клиентами, а также принципы, по которым заказчики и разработчики ведут управление проектом.
• Прием «игра в планирование» занимает центральное положение. Благодаря ему мы можем понять, как разбить проект по функциям, историям и задачам. Он содержит указания по оценке, постановке приоритетов, а также планированию соответствующих функций, историй и задач.
• Небольшие и частые релизы не позволяют команде «откусить» больше, чем возможно.
• Приемочное тестирование позволяет определять, какие функции реализованы, а также какие истории и задачи выполнены. Оно показывает команде, как определить однозначные показатели завершения.
• «Одна команда» позволяет понять, что в процессе разработки программного обеспечения принимают участие различные специалисты, в том числе программисты, тестировщики и руководители, а также то, что клиенты и сами принимают непосредственное участие, находясь на связи и будучи открытыми для вопросов. Все должны работать совместно для достижения общей цели.
Среднее кольцо жизненного цикла отражает методы экстремального программирования при взаимодействии внутри команды. Эти методы обеспечивают рамочную основу для взаимодействия между членами команды разработчиков, а также для самоуправления.
• Постоянный темп — это метод, который предохраняет команду разработчиков от перерасхода своих сил и банального выгорания до достижения финишной черты.
• Коллективное владение не позволяет членам команды тянуть одеяло на себя, благодаря чему каждый вносит посильный вклад в проект и несет ответственность за всю работу.
• Непрерывная интеграция позволяет команде сосредоточиться на частом слиянии рабочих копий в основную ветвь разработки и частом создании сборок, чтобы своевременно выявить ошибки и точнее отследить продвижение проекта.
• Метафора — это метод, который позволяет создавать и утверждать общую терминологию, благодаря которой команда разработчиков и клиенты находят понимание при обсуждении вопросов, связанных с проектом.
Внутреннее кольцо жизненного цикла представляет собой технические методы, которые позволяют направлять и в чем-либо ограничивать программистов для достижения наиболее высокого уровня качества.
• Парное программирование — это метод, который помогает членам команды делиться сведениями и сотрудничать в парах, в том числе проводить совместный анализ, чем достигается высокий уровень обеспечения точности и внедрения новшеств.
• Простота проектирования — это метод, который позволяет команде не расходовать силы впустую.
• Рефакторинг кода способствует непрерывному совершенствованию и доработке всего, что получается в ходе работы.
• Разработка через тестирование — это страховочный канат, благодаря которому команда технических специалистов может быстро выполнять работу, не снижая планку качества.
Все методы очень тесно связаны с целями, которые провозглашает Манифест Agile, по меньшей мере в том, что перечислено ниже:
• Люди и взаимодействие важнее процессов и инструментов.
• «Одна команда», метафора, коллективное владение, парное программирование, 40-часовая рабочая неделя.
• Работающий продукт важнее исчерпывающей документации.
• Приемочное тестирование, разработка через тестирование, простота проектирования, рефакторинг кода, непрерывная интеграция.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Небольшие и частые релизы, игра в планирование, приемочное тестирование, метафора.
• Готовность к изменениям важнее следования первоначальному плану.
• Небольшие и частые релизы, игра в планирование, 40-часовая рабочая неделя, разработка через тестирование, рефакторинг кода, приемочное тестирование.
Однако по мере знакомства с этой книгой можно будет заметить, что связи между жизненным циклом и Манифестом Agile гораздо глубже и теснее, чем упрощенная модель, которая приведена выше.
Заключение
Таков Agile и история его появления. Agile — небольшая дисциплина, помогающая решению небольших задач, поставленных небольшими командами программистов для управления небольшими продуктами. Но несмотря на то что Agile невелик сам по себе, его значение и влияние достаточно велико, поскольку все большие проекты так или иначе состоят из множества маленьких.
С каждым днем программное обеспечение все больше переплетается с нашей повседневностью. Число людей, не мыслящих свою жизнь без него, постоянно растет. Не побоюсь сказать, что без программного обеспечения Земля перестанет вертеться. Если Земля остановится без программного обеспечения, то Agile — именно то, что позволяет наилучшим образом вести его разработку.
Глава 2. Почему же Agile?
Прежде чем углубиться в тонкости разработки с помощью Agile, хотелось объяснить, что стоит на кону. Agile важен не только для отрасли разработки программного обеспечения, но и для промышленности, общества и, наконец, всей цивилизации.
Разработчики и руководители зачастую прибегают к Agile в силу каких-то временных обстоятельств. Они могут использовать его потому, что считают правильным подходом, или, возможно, просто потому, что купились на обещания уложиться в минимальные сроки при достижении самого высокого качества. Причины неосязаемы, неясны и могут противоречить друг другу. Многие отказались от Agile просто потому, что не смогли незамедлительно обрести ожидаемого, поскольку восприняли обещанное буквально.
Agile важен не по причинам, вызванным изменчивыми обстоятельствами. Agile важен в силу куда более глубоких философских и этических причин. Эти причины связаны с профессиональной деятельностью и обоснованными ожиданиями наших клиентов.
Профессионализм
Agile привлекает меня тем, что ставит на первое место дисциплину, а не церемониальность. Чтобы правильно применять Agile, нужно работать в парах, в первую очередь писать тесты, проводить рефакторинг кода и соблюдать правила простоты проектирования. Придется работать короткими циклами, получая в результате каждого из них рабочий результат. А еще придется постоянно и непрерывно взаимодействовать с клиентами.
Взгляните на жизненный цикл и рассмотрите каждый из приведенных методов как обещание или обязательство — вам станет понятно, откуда ноги растут. Для меня Agile — это очередной виток мастерства и приверженность идее продвигать профессиональный подход к работе по всей индустрии разработки ПО.