Принципы agile

4.1 Что есть принцип?

Для прояснения методологического контекста полезно квалифицировать, что же является принципом, а что нет. Настоящий принцип обладает двумя свойствами – абстрактность и нетривиальность. Абстрактность отличает принцип от практик, нетривиальность – от банальностей.

Абстрактность означает, что принцип должен быть общим правилом, а не специфической практикой. "Создавайте прочную финансовую основу для будущего" – это принцип. "Откладывайте ежемесячно 10 % заработка на сберегательный счет" – это практика. Часто, как в этом примере и как в случае с agile практиками, рассматриваемыми в этой главе, многие практики существуют для поддержки принципов.

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

Принципы, рассматриваемые в этой главе, удовлетворяют предлагаемым критериям. Практики также важны, и они будут рассмотрены в последующих главах. Банальности, которых также хватает в литературе по agile, будут игнорироваться в данном рассмотрении.

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

4.2 Официальные принципы

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

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

• Некоторые из перечисленных пунктов являются практиками, а не принципами – А6, А12.
• Другие являются банальностями: А9 и А5 – кто стал бы поддерживать построение системы немотивированными разработчиками.
• Некоторые пункты выражены в форме утверждений, а не предписаний. В этом нет ничего страшного, если они допускают простое перефразирование. Например, пункт А7 можно сформулировать следующим образом: "Используйте работающий продукт в качестве основной меры измерения прогресса разработки".
• Для некоторых пунктов возникают проблемы при переходе к императивному стилю. В пункте 10 утверждается, что простота означает минимизацию лишней работы. Но "стройте как можно более простую систему" и "минимизируйте лишнюю работу" – это два разных принципа. У них есть существенное отличие, что позже будет рассмотрено подробнее. Переход к императивному стилю принципов позволяет избежать неточностей.
• Хотелось бы иметь независимые правила. Те, что были перечислены, частично пересекаются. Частота поставки упоминается в А1 и А3, важность работающего ПО – в А3 и А7.
• С другой стороны, правила явно неполны. Ни одно из них не упоминает тестирование. Упор на тестирование для достижения качества является одним из центральных свойств agile.

4.3 Используемый список

Для замены официального списка используем классификацию agile принципов, введенную в обзорной главе. Для простоты приведем этот список повторно:

Рассмотрим вначале организационные принципы, затем технические, имеющие программную специфику.