Роберт Мартин - Чистый Agile. Основы гибкости

Завершение обзора

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

Планку качества нужно держать как можно выше. График в основном зависит от объема выполняемых работ.

Это и есть Agile.

Схема Рона Джеффриса, изображенная на рис. 1.8, объясняет принципы экстремального программирования. Эта схема также известна как «жизненный цикл».

Рис. 1.8. Жизненный цикл

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

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

Кент Бек — отец экстремального программирования, а Уорд Каннингем — его дедушка. Эти два человека, работая совместно в компании Tektronix в середине 1980-х, исследовали множество идей, которые в конечном итоге породили экстремальное программирование. Впоследствии Бек придал этим идеям точную форму. Таким образом, около 1996 года появилось экстремальное программирование. В 2000 году Кент Бек обнародовал свою окончательную работу: Extreme Programming Explained: Embrace Change [26] Beck K. Extreme Programming Explained: Embrace Change. Boston, Massachusetts: Addison-Wesley, 2000. Также существует второе издание 2005 года, но мое любимое издание — первое, я считаю именно эту версию окончательной работой. Возможно, Кент не согласится со мной. (На русском языке: Бек К. Экстремальное программирование. — СПб.: Питер, 2002. — 224 с.: ил. — Примеч. ред. ) .

Жизненный цикл подразделяется на три кольца. Внешнее кольцо отражает методы экстремального программирования при взаимодействии с клиентами. Это кольцо, по сути, эквивалентно тому, что предлагает методология Scrum [27] Или, по крайней мере, так изначально задумывалось. Сейчас Scrum вобрал в себя множество методов экстремального программирования. . Эти методы обеспечивают структуру взаимодействия между командой разработчиков и клиентами, а также принципы, по которым заказчики и разработчики ведут управление проектом.

• Прием «игра в планирование»занимает центральное положение. Благодаря ему мы можем понять, как разбить проект по функциям, историям и задачам. Он содержит указания по оценке, постановке приоритетов, а также планированию соответствующих функций, историй и задач.

• Небольшие и частые релизыне позволяют команде «откусить» больше, чем возможно.

• Приемочное тестированиепозволяет определять, какие функции реализованы, а также какие истории и задачи выполнены. Оно показывает команде, как определить однозначные показатели завершения.

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

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

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

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