Манифест Агил: 4 основных ценности и 12 принципов, объясненные

Изображение ниже взято с сайта Манифеста Агил и показывает четыре заявления о ценностях Агил.

Agile Manifesto and the 4 Agile Values answer what agility is

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

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

Как уже упоминалось, когда был опубликован Манифест Агил, он оспаривал тяжеловесные методологии. В то время модель зрелости способностей (CMM) и ITIL были популярным трендом в сторону процессно-ориентированных подходов.

Поэтому было удивительно, что эти мыслители решили начать с людей. Они считали, что найти правильных людей (людей) в команде и помочь им эффективно взаимодействовать (взаимодействие) гораздо важнее, чем следование какому-либо конкретному процессу и/или использование определенных инструментов. Именно поэтому они сделали акцент на левой стороне: люди и взаимодействие.

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

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

Сотрудничество с клиентом важнее переговоров по контракту

Третья ценность — сотрудничество с клиентом вместо переговоров по контракту, где переговоры по контракту означают споры о том, что входит в объем. Например, вы можете услышать фразы вроде «Это не то, что было в вашем документе требований». Эти мыслители считали, что сотрудничество с нашими клиентами для предоставления решения, которое им действительно нужно, гораздо важнее.

Ответ на изменение важнее следования плану

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

Все эти ценности в манифесте важны, но те, что слева, имеют более высокий приоритет, чем те, что справа.

12 принципов Агил

Помимо этих 4 ценностей Агил, авторы Манифеста Агил согласились с набором 12 принципов Агил, которые составляют основу подходов Агил. Хотя они менее известны, чем 4 ценностей Агил, я считаю, что 12 принципов Агил более практичны и дают более четкие указания по практикам Агил.

12 Agile Principles behind the Agile Manifesto

Для удобства я пронумеровал 12 принципов, хотя на официальном сайте.

  1. Первый принцип — это наивысший приоритетзаключается в удовлетворении клиента путем ранней и непрерывной доставки ценного программного обеспечения. Фраза «ценное программное обеспечение» сбивает некоторых с толку. Помните, в 2001 году, когда эти мыслители представили ценности и принципы Агил, они сосредоточились исключительно на разработке программного обеспечения. С тех пор Агил был принят почти во всех отраслях — архитектуре, производстве автомобилей, даже производстве истребителей. Если вам будет понятнее, замените «ценное программное обеспечение» на «ценное решение».
  2. Второй принцип — это приветствуем изменяющиеся требования, даже на поздних этапах разработки. Хотя большинство людей сегодня сосредоточены на контроле изменений или управлении «расширением области» (scope creep), реальность заключается в том, что изменения неизбежны. Гибкие процессы откладывают принятие решений, сокращают циклы разработки и способствуют своевременному анализу запросов. Это позволяет командам гибкой разработки быстро адаптироваться и с минимальными затратами. Это обеспечивает конкурентное преимущество и является одной из ключевых основ гибкой работы.
  3. Третий принцип заключается в том, чтобычасто предоставлять рабочий программный продукт, от нескольких недель до нескольких месяцев, предпочтительно с более короткими интервалами. Одним из основных преимуществ частой доставки является получение обратной связи, чтобы убедиться, что вы на правильном пути, и действительно создаете то, что нужно клиенту.
  4. Четвертый принцип гибкой разработки касаетсяежедневного взаимодействия бизнес-пользователей и разработчиков на протяжении всего проекта. Сегодня бизнес-заинтересованные стороны часто создают документы требований и «бросают их через стену» разработчикам. Через несколько месяцев или даже лет разработчики доставляют решение заказчику на финальное тестирование — и обнаруживают, что решение было неправильно понято, построено неправильно или уже не нужно. Акцент этого принципа — на сотрудничестве между теми, кто создает решение, и теми, кто его использует, чтобы избежать подобных результатов.
  5. Пятый принцип гибкой разработки заключается в том, чтобыстроить проекты вокруг мотивированных людей, обеспечивая их необходимой средой и поддержкой, и доверяя им выполнить работу. Это по сути трехэтапный подход: предоставление власти, предоставление автономии и доверие.
  6. Шестой принцип гибкой разработки способствуетустойчивой разработке. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп неограниченно долго. Когда я впервые начал работать над техническими проектами, они часто длились 6 месяцев, 12 месяцев или дольше. Было обычным делом, что в первые месяц или два было мало достигнуто. Неудивительно, что это приводило к огромным периодам напряжения в конце, когда нужно было выполнить огромные объемы работы. Члены команды ожидали работать вечерами или в выходные, чтобы соблюсти жесткие сроки и жесткие рамки. Такой проект известен как «поход к смерти». Гибкая разработка не говорит, что вы никогда не будете работать вечерами или в выходные — но она подчеркивает необходимость работы в устойчивом темпе для всех.
  7. Принцип семь гласит, чторабочий программный продукт является основным показателем прогресса. Традиционно для отслеживания прогресса проекта использовался процент завершения. Процент завершения крайне ненадежен, поскольку его трудно оценить, особенно когда он достигает 80% или 90%. 90% завершения часто означает, что осталось всего 10% усилий или времени. Команды гибкой разработки избегают использования процента завершения, разбивая работу на функции или функциональные возможности, деля их на небольшие части и отслеживая, завершены ли эти части. Такой подход исключает вводящие в заблуждение метрики прогресса.
  8. Восьмой принцип гласит, что наиболее эффективный и эффективный способ передачи информации команде разработки и внутри команды — это черезличное общение. Сегодня самым популярным инструментом коммуникации может быть электронная почта. Она эффективна для отправителя — ведь он может отправить сообщения сотням или тысячам человек одновременно. Но это не настоящее общение. Исследования показывают, что чтение чужого текста оставляет значительное пространство для недопонимания. Последователи гибкой разработки поняли, что истинное общее понимание достигается только при совместном присутствии людей. Если личное общение невозможно, используйте самый высокопроизводительный канал связи — это может быть видеосвязь или телефонные звонки. Это намного лучше, чем публиковать документы в SharePoint! Основной вывод здесь — использовать самый высокопроизводительный канал связи. Сторонником личного общения является и то, что имеет смысл размещать членов одной команды гибкой разработки в одном месте. Сегодня многие организации игнорируют этот очевидный факт.
  9. Принцип девять — постоянное внимание ктехническому превосходству и хорошему дизайну для повышения гибкости. Акцент делается на избегании упрощений или накопления технического долга. Не делайте ничего, что ускорит процесс в краткосрочной перспективе, но увеличит затраты в долгосрочной. Если вы продолжаете накапливать технический долг, вы потеряете гибкость. Это распространено в проектах по водопадной модели с жесткими сроками. Чтобы соблюсти обещанные сроки, делаются уступки. Циклы тестирования могут быть сокращены или полностью устранены, чтобы сэкономить время, что приводит к большему количеству проблем в производстве после запуска. Это приводит к постоянному решению аварий и коду, который трудно поддерживать.
  10. Принцип десятый касается упрощения и устранения ненужной работы.Простота — искусство максимизации объема не выполненной работы — является необходимой.Другими словами, мы должны проанализировать наши процессы и устранить все, что не приносит ценности клиенту, тем самым максимизируя объем незавершенной работы, при этом обеспечивая доставку необходимого.
  11. Принцип десятый также касается самоорганизующихся команд. Наилучшие архитектуры, требования и проекты создаютсясамоорганизующимися командами. Мы должны позволить тем, кто ближе всего к работе, решать, как лучше всего ее выполнить — именно это и является сутью этого принципа.
  12. Последний принцип, номер 12, касается ретроспектив. Команды регулярно анализируют, как стать более эффективными, и затемнастройте и адаптируйтесоответствующим образом изменяют свое поведение.

Ценности и принципы гибкости сегодня могут показаться не столь радикальными, но когда они были объявлены в 2001 году, они были весьма революционными. Отсюда и термин «Манифест». Они описали способ работы, который полностью отличался от того, как организации действовали в предыдущем столетии. До этого разработка программного обеспечения в значительной мере копировала производственные практики индустриальной эпохи. Понимание этого исторического контекста имеет решающее значение, как обсуждается ниже.

 

 

Leave a Reply