По пунктам я приведу перевод на русской версии "Манифеста гибкой разработки программного обеспечения" на понятный язык "как это следует трактовать".

Ценности

Agile-манифест разработки программного обеспечения

Перевод: читаем оригинал: Manifesto for Agile Software Development - это Манифест Гибкой разработки программного обеспечения. Это значит, что он "заточен" на программное обеспечение и для других сред требует адаптации.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Перевод: Манифест придуман инженерами по разработке ПО и для инженеров, не для менеджеров, не для руководителей, а для инженеров.

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

Перевод: Мы как инженеры не всегда понимаем что хочет заказчик, он это и сам не понимает. Практика 1970 года "больше документов чтобы быстрее делать" уже не работает, поэтому давайте больше общаться.

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

Перевод: Дорогой собрат-инженер - твои выкладки в документах конечно хороши, но ты не забыл, что Клиенту нужно, чтобы что-то работало?

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

Перевод: Ты же согласен с тем что Клиент не знает что он хочет? Это значит что как бы мы не фиксировали в ТЗ все его хотелки, всё равно будут изменения. Клиенту важнее что он хочет, наше дело реализовать в полном объеме то, что хочет. И нет, мы не бизнес-аналитики и не можем указывать клиенту, что ему на самом деле надо.

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

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

Принципы манифеста

Мы следуем таким принципам:

Перевод: Если у нас есть принципы, то мы можем из них развивать ценности. Это математика.

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

Перевод: Мы, с тобой брат, инженеры, а не аналитики. Мы умеем конструировать лучшие решения под заказ, а не выяснять проблемы в голове Заказчика. Если Заказчик не знает что хочет, мы ВЫНУЖДЕНЫ экспериментально это выяснять. Поэтому, давай чаще поставлять результат, чтобы корректировать программный продукт под изменяющиеся требования Заказчика.

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

Перевод: Если Клиент не понимает "что хочет", значит давай запроектируем гибкую архитектуру и применим всю мощь XP/Crystal/Agile-process для поддержания надежности продукта чтобы он не развалился при изменениях.

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

Перевод: Мы с тобой инженеры, а не психологи. И мы не можем залезть в голову Заказчику. Поэтому ели Клиент не понимает "что хочет", то сверяйся с его желаниями чаще чтобы он был доволен.

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Перевод: Ты помнишь, что Клиент может быть недоволен нашей работой? Если он не доволен, то он не заплатит. Потому повышай прозрачность и вовлекай Заказчика в процесс. Тогда, это будут "его решения" и он не сможет отвертеться. И в дискуссиях есть шанс что он наконец-то найдет то что ему действительно нужно. А если не найдет, пусть платит.

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

Перевод: Мы те - кто обсуждали это, профессионалы своего дела. И надеемся, что ты брат, тоже такой. И ты понимаешь, что не нужно лезть под руку профессионалу. Поэтому расскажи об этом своему менеджеру. С другой стороны, если Клиент не понимает что ему нужно, то в проекте должны быть только мотивированные профессионалы. Иначе наш подход не сработает и Клиент будет недоволен результатом.

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

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

Работающий продукт — основной показатель прогресса.

Перевод: Мы с тобой, брат инженер, понимаем как ценно для нас создавать идеальную программную архитектуру, которая будет превосходить всё, что мы с тобой создали прежде. Но помни, что Клиенту важны не твои выкладки, документы, классы и прототипы. Ему нужно, чтобы продукт работал! Поэтому не уходи в паралич анализа, а сделай чтобы работало.

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

Перевод: Если Клиент и инвестор не понимает что хочет, то выстрой им Agile-процесс. У них есть деньги, дай им прозрачность и уверенность, что ты можешь сделать все их "хотелки". Практики XP/Crystal/DSDM/DAD/Pragmatic programmer придадут тебе Силу.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Перевод: Друг, не разменивай качество на скорость. Скорость убьет тебя на длинной дистанции. Встрой качество в процесс. Если Клиент не знает что хочет, то нам нужно обеспечить гибкую архитектуру чтобы быстро её менять. Для этого нужно 100% покрытие модульными тестами и придерживаться TDD, CI, CD.

Простота — искусство минимизации лишней работы — крайне необходима.

Перевод: Чем проще система, тем проще её поддерживать. А изменений будет много. Спроектируй сразу так, чтобы было легко поддерживать.

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

Перевод: Мы с тобой профессионалы. Скажи своему менеджеру чтобы не вмешивался. Но помни, что если у тебя есть стажеры и середнячки, схема работать не будет, замкни менеджера на себя и сам рули процессом.

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

Итого

Манифест - религия инженеров.

Манифест - религия профессионалов и для профессионалов. В иных условиях это не работает.

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

Ссылки

• Авторы Манифеста, кто они.
• "Мой Agile" - это Метод управления проектным бизнесом "Pulse management". Как держать руку на пульсе бизнеса и выполнять все обязательства компании в вовремя и в полном объеме.

Книга: https://ridero.ru/books/upravlenie_proektnym_biznesom/